Ce document décrit le modèle objet de Capsis 4.1. Cette version a subit de légères évolutions par rapport au rapport d'étude initial et à la version 4.0. Ces évolutions sont de plusieurs ordres : changement de noms, présentation différente et spécifications plus tournées vers l'évolution (pour les pilotes non graphiques). Les notions de classes fondamentales, organisationnelles et fonctionnelles pour le noyau sont conservées.

Le schéma suivant représente le modèle objet de Capsis 4.1. On reconnaît les classes principales du noyau applicatif (capsis.kernel).

La classe moteur du noyau est pilotée par une sous-classe de la classe GPilot (pilote générique). Chaque pilote Capsis4 sous-classe GPilot en une classe Pilot. Les classes Pilot sont différenciées par la JVM grâce à leurs noms de package différents (capsis.gui.Pilot, capsis.console.Pilot…).

Le nouveau mécanisme de lancement de Capsis (en utilisant le script de démarrage) démarre d'abord le pilote déterminé par un paramètre de la ligne de commande (ex : -pgui). C'est le pilote qui se charge de la construction des paramètres de l'application (CapsisSettings) et qui lance ensuite le moteur de l'application (Engine). Le pilote peut ensuite executer du code pour préparer l'acquisition des commandes de l'utilisateur : par exemple des fenêtres et menus pour un pilote interactif ou encore un interpréteur de fichiers pour lire des scénarios et des jeux de paramètres préétablis .

Le noyau Capsis4 ne connaît de son pilote que le nom (ex : “gui”). Ainsi, ni la classe Engine ni aucune autre classe du noyau ne détiennent de référence vers la classe Pilot du pilote courant. C'est en effet le pilote qui a l'initiative des actions pendant le déroulement de la session de travail.

La création d'un projet capsis4 (classe Scenario) implique le chargement d'un module, qui devient associé au projet, un paramétrage initial pour ce module ainsi que la création d'un peuplement initial (sous-classe de GStand) qui est associé à l'étape racine du scénario.

La méthode de création du peuplement initial n'est pas spécifiée (chargé depuis un inventaire sur disque, généré virtuellement…), elle est à la charge du module.

Les classes du noyau effectuent les opérations de base techniques et communes à tous les modèles comme la détection et le chargement des modules ou l'intervention sur la structure organisationnelle (création, ouverture, sauvegarde ou fermeture de Session et de Scenario, création de nouveau Step).

Les tâches fonctionnelles sont déléguées aux classes du module qui viennent compléter l'architecture de l'application pour le Scenario concerné.

Lorsqu'un module est chargé initialement ou lorsqu'un projet est réouvert après sauvegarde, le noyau tente de charger la classe relai du module pour le pilote courant (ex : une classe relai pour le pilote gui). En cas d'échec, le module est déclaré inutilisable avec ce pilote. Les modules doivent donc disposer de classes relai spécifiques pour être utilisées avec un pilote donné.

Ces relais sont chargés dynamiquement par le noyau a partir d'une convention de nommage :

<modulePackageName>.<pilotName>.<modulePrefix>Relay

Chaque classe relai d'un module doit hériter de GRelay qui est la classe qui fixe les contrats a respecter pour être utilisable par un pilote Capsis. Ces contrats permettent au pilote de demander au module d'acquérir certains paramètres (paramétrage initial du module, paramètres conditionnant une phase d'évolution) ou de déclencher certaines actions (pré-traitements, phase d'évolution d'un peuplement…).

Ainsi, un relai interactif pourra ouvrir des boîtes de dialogue pour permettre à l'utilisateur de saisir ses paramètres, alors qu'un relai en mode non interactif pourra chercher ces paramètres dans un fichier préalablement spécifié.

Chaque module, enfin, implémente une sous-classe de GModel qui contient par convention la description de tous les traitements fonctionnels pour le module. Il est en effet essentiel de ne rien implémenter de fonctionnel dans les classes relay (il peut y en avoir plus d'une) car ces traitements ne seraient pas réutilisables avec un autre pilote.

Classiquement, la classe xModel (x est remplacé par le préfixe du module) implémente des méthodes d'initialisation du modèle (pré-traitements) et d'évolution : calculer un ou plusieurs peuplements qui soient l'évolution d'un peuplement de référence.

Cette délégation de l'évolution permet de laisser au choix du modélisateur le pas de calcul (mois, année…). Chaque fois qu'un peuplement est calculé, le module utilise une méthode du moteur Capsis4 pour créer une nouvelle étape et l'attacher à la précédente.

Les interventions que l'on peut pratiquer sur le peuplement ne sont pas décrites dans le module mais dans des extensions décrites ailleurs.

Pour chaque action a effectuer par le pilote, on considère d'abord l'étape concernée. A partir de cette étape, on détermine la référence du relai de pilotage du module sous-jacent : du Step, on remonte au Scenario, puis au GModel et enfn au GRelay.

Sur cette référence, le pilote peut invoquer les méthodes prévues dans les contrats fixés par GRelay, par exemple une demande d'acquisition de paramètres d'évolution suivie d'une demande d'évolution en repassant les paramètres rendus.

Le relai se charge des opérations dépendant du contexte d'utilisation (par exemple les dialogues en mode interactif s'il y a lieu), puis invoque directement les méthodes fonctionnelles de la classe xModel du module, pour leur laisser faire le travail fonctionnel.

Par exemple, pour l'évolution, une boucle compte tenu d'une durée paramétrée et d'un pas de temps par construction du modèle, avec calcul de n peuplements résultant de l'évolution de celui de l'étape de référence, et avec pour chacun rattachement au projet en cours à la suite de l'étape précédente.