CHAPITRE 3 3.2. ARCHITECTURE DU CADRICIEL moteur_DEVS modélisation Entité simulation ModèleCouplé Couplage Port Modèle Executif_DSDEVS ModèleAtomique Message Réseau_DSDEVS Vecteur_Message Vecteur_Evénement Coordinateur_DSDEVS Coordinateur Evénement Root Processeur Simulateur FIG. 3.3: Le package moteur-DEVS
ciel puis les classes devant être redéfinies afin d’assurer l’intégration de nouvelles techniques dans l’environnement.
3.2.1 Le package moteur-DEVS
Le package moteur-DEVS, figure 3.3, contient les classes nécessaires à la définition de modèles et à leur simulation. Ce package a été séparé des autres pour simplifier l’intégra-tion éventuelle d’autres bibliothèques DEVS telles que ADevs [Nutaro, 2003] ou devsjava [Sarjoughian et Zeigler, 1998].
L’architecture du package suit l’architecture hiérarchique définie dans le formalisme DEVS [Zeigler, 2000] et permet également la définition de modèles à structure dynamique DSDEVS par l’utilisation d’un composant appelé exécutif qui gère les connexions interconnexions entre les modèles. Nous renverrons le lecteurs à [Barros, 1997] pour une explication en détail de cette technique. Un formalisme autorisant la définition de modèles à structure dynamiques est nécessaire
CHAPITRE 3 3.2. ARCHITECTURE DU CADRICIEL
Le package moteur-DEVS est composé de deux sous-packages :
– le sous-package modélisation : il contient les classes permettant la modélisation de mo-dèles DEVS et DSDEVS. Nous pouvons noter que dans ce package, la classe Modèle peut comprendre des objets de la classe Port ; cette agrégation est essentielle pour assurer l’in-terconnexion de modèles utilisant des techniques de modélisation différentes. En effet tous les couplages de modèles s’effectuent par des liens entre des ports. Chaque objet de la classe
Modèle communique avec les autres modèles par la médiation d’objets de la classe
Mes-sage: ces objets Message étant identiques quelle que soit la technique utilisée.
– Le sous-package simulation : il contient les classes implémentant les simulateurs abstraits des modèles DEVS et DSDEVS. Chaque objet de la classe Modèle du sous-package
modéli-sationest associé à un objet de la classe Processeur associée. Le passage d’informations se fait grâce aux objets de la classe Evènement contenus dans des listes de la classe
Vecteur-Evènement.
Tous les modèles créés à l’aide de l’environnement sont identifiés en spécialisant les classes d’un des packages de techniques de modélisation. Les modèles ainsi spécifiés héritent de la classe
ModèleAtomique, ModèleCouplé ou Réseau-DSDEVS. Grâce à ces composants de plus haut
niveau de spécification et aux interfaces de modèles basées sur les ports, il est possible d’utili-ser une interface graphique générique pour aider à la composition de multi-modèles. Le package
interface-Graphiqueprésenté dans la section suivante est composé des éléments de base permettant la multi-modélisation.
3.2.2 Le package interface-graphique
Le package interface-graphique contient les composants graphiques permettant la compo-sition visuelle et interactive de modèles. La figure 3.4 présente les classes composant ce pa-ckage. A chaque objet de la classe Composant-Modèle correspond un objet de la classe Panel permettant de modifier ses propriétés (états courants, nom d’instance). Les objets de la classe
Composant-Modèle sont contenus et affichés par la classe Espace-de-Travail, qui est le
utili-CHAPITRE 3 3.2. ARCHITECTURE DU CADRICIEL
sateur (ajout, sélection, déplacement et couplage de modèles). Deux classes spécialisent la classe
Composant-Modèle : La classe Modèle-Composition et la classe
Composant-Modèle-Atomique. Les Composant-Modèle-Composition sont des conteneurs graphiques pour
tous les modèles du modèle associé au composant, ils affichent récursivement tous les sous-modèles (atomiques et/ou couplés) qu’ils contiennent. Les Composant-Modèle-Atomique ont eux un comportement spécifique qui ne peut être défini qu’à l’aide d’un éditeur spécialisé. Le composant Bibliothèque est le composant graphique permettant l’ajout de composants déjà défini et le stockage des modèles créés. La classe Application définit l’interface utilisateur telle qu’elle sera utilisée par le modélisateur et contient un objet de la classe Espace-de-Travail lorsqu’un un modèle est chargé en mémoire.
Tous les composants définis dans les packages spécifiques aux techniques doivent hériter des composants du package Interface-Graphique. Ils possèdent donc tous une représentation graphique unifiée à haut niveau de description. Cette représentation permet la multi-modélisation par le cou-plage de modèles de techniques hétérogènes en définissant des liens entre les ports de ces modèles visibles à ce haut niveau de description.
Les objets de la classe Application vont rechercher à l’initialisation les packages de techniques disponibles (méthode GetAvailableTechniques()). Une liste contenant un objet de la classe Access par package spécifique aux techniques est ensuite chargés en mémoire pour acceder à ces sous-systèmes. Pour instancier ces objets, il est fait appel à un objet AccessLoader du package stockage qui définit les classes permettant le stockage et la récupération de modèles.
3.2.3 Le package stockage
Le package stockage, figure 3.5, contient les classes permettant de formater et de lire les mo-dèles. Dans un cadriciel qui se veut générique, il nous fallait choisir le format de stockage le plus ouvert possible. Nous avons donc choisi le langage de balise XML (eXtended Markup Language) comme format de stockage. L’utilisation du langage XML, en plus d’être devenu un standard de
CHAPITRE 3 3.2. ARCHITECTURE DU CADRICIEL
interface_graphique
{Renvoie une liste de composants de type "Access" des paquetages de techniques de modélisation disponibles.}
technique-de-modélisation Espace_de_Travail Bibliothèque Composant_Modele Composant_Modèle_Atomique Composant_Modèle_Composition Composant_Domaine Panel_Modèle_Composition Panel_Modèle_Atomique Panel Editeur Application Access GetAvailableTechniques()