Problématique de la méta-modélisation DEVS

4.1.1. Quels apports pour la modélisation DEVS ?

Comme nous l’avons vu tout au long du chapitre II, l’approche orientée modèle définie par l’IDM est un paradigme de développement logiciel centré sur la définition de modèles à différents niveaux d’abstraction et sur la mise en œuvre de transformations entre ces modèles. L’objectif principal est de parvenir à l’automatisation, même partielle, du processus de développement et de faciliter la portabilité des applications.

Dans le contexte de la modélisation et simulation DEVS, l’utilisation des concepts, techniques et outils issus de l’IDM offre des solutions aux problèmes de la réutilisabilité et l’interopérabilité de modèles.

La définition d’une architecture centrée sur les modèles, ayant pour élément central un méta-modèle du formalisme DEVS, permet de :

− proposer un format de représentation, à la fois syntaxique et sémantique, standardisé, fiable des modèles DEVS (fonctions y compris : fonctions de transition interne, externe, de sortie et d’avancement du temps) en faisant totalement abstraction de tout langage de programmation et de toute plateforme de simulation ;

− faciliter le stockage de modèles DEVS, leur édition, leur visualisation, leur modification, leur réutilisabilité ;

− rendre les modèles DEVS « productifs » grâce aux techniques de transformations de modèles (modèles vers modèles, modèles vers code) et assurer ainsi leur interopérabilité.

Dans le cadre d’une telle architecture, chaque modèle DEVS créé sera conforme au méta-modèle MetaDEVS et indépendant de tout environnement de modélisation et simulation. On pourra désormais parler de PIM (Platform Independent Model) DEVS pour désigner les modèles DEVS typés par ce méta-modèle.

4.1.2. Méta-méta-formalisme

Afin de pouvoir rendre, à terme, nos modèles productifs en réalisant des transformations, nous avons retenu l’environnement de méta-modélisation Eclipse EMF

112 (2.1.3.c)). Sans pour autant revenir en détail sur les caractéristiques de ce framework, rappelons tout de même celles qui ont conditionné notre choix :

− ce framework supporte à la fois la définition de méta-modèles et la génération de code, − il possède pour cela deux méta-méta-modèles : le méta-méta-modèle Ecore qui est

basé sur MOF 1.4 (2.1.3.c)),

− il est possible d’y créer des méta-modèles selon plusieurs vues : sous forme d’Ecore diagrams, ou alors avec l’éditeur classique (Sample Ecore Model Editor) qui offre lui aussi une interface graphique moins précise, mais donnant une bonne vue d’ensemble des éléments du projet, et même avec la vue de l’éditeur OCLinEcore pour ajouter directement des contraintes OCL au méta-modèle,

− on peut également en fonction de nos besoins créer un méta-modèle avec Ecore mais aussi Java et XMI qui sont supportés nativement par Eclipse EMF, voire au moyen d’autres méta-formalismes tels que Kermeta,

− il est facile de créer une instance dynamique à partir d’un méta-modèle, de la valider (établir qu’elle est conforme à ce dernier), de la modifier, de la stocker, ce qui facilite la mise au point d’un méta-modèle lors de la phase expérimentale,

− le format d’échange des modèles est par défaut XMI : le format d’échange de métadonnées de type UML basé sur XML.

En ce qui concerne le méta-méta-formalisme, notre choix s’est naturellement porté sur MOF et plus précisément sur Ecore, son implémentation dans l’environnement EMF-Eclipse. Dans la mesure où MOF ne bénéficie pas d’une syntaxe concrète spécifique, nous utilisons, pour donner une représentation graphique des concepts du méta-modèle, les diagrammes de classe UML. La Figure IV-1 montre comment le méta-modèle DEVS et les modèles DEVS s’inscrivent dans la hiérarchie de référence issue de l’IDM. Un modèle DEVS est vu comme « une instance » du méta-modèle DEVS qui est lui-même vu comme « une instance » du méta-méta-modèle MOF(ECORE).

Figure IV-1 : Méta-modèle de DEVS et niveaux méta 4.1.3. Le méta-modèle DEVS : le pivot de notre approche

Disposer d’un méta-modèle de DEVS indépendant de toute plateforme conçu selon l’architecture IDM permet en premier lieu la spécification directe de modèles conformes à celui-ci, et donc homogènes, et améliore de ce fait leur interopérabilité. Mais en raisonnant

113 toujours dans un esprit IDM, nous allons voir que ce méta-modèle occupe également une place centrale dans notre approche car il peut être vu comme un carrefour vers lequel « convergent » des modèles hétérogènes et duquel « repartent » des modèles DEVS qui lui sont conformes et qui deviennent par conséquent homogènes eux aussi. Ce chapitre traite spécifiquement de la mise en place de ce pivot, mais pour mieux situer notre approche dans sa globalité, nous donnons ici des éléments que nous approfondirons dans le chapitre suivant.

Figure IV-2 : Le méta-modèle de DEVS au centre de notre approche

La Figure IV-2 ci-dessus complète donc la figure présentée en début de chapitre, en illustrant le rôle de pivot du méta-modèle que nous allons définir par la suite. La partie gauche montre le niveau M2 et le rôle « unificateur » qu’occupe MetaDEVS. La partie de droite montre des modèles, instances de leurs méta-modèles respectifs.

La zone contenant les modèles PSM (Platform Specific Model) et le code est particulière : en effet, si en théorie, l’IDM fournit le concept de PSM, ce dernier n’est toutefois pas indispensable à la génération de code, tout dépend en fait du niveau de complexité du modèle que l’on désire transformer. Ce qui signifie en d’autres termes que, malgré le fait qu’un modèle de code soit de préférence généré à partir d’un PSM, il est tout à fait possible de générer un tel modèle, propre à une plateforme de simulation DEVS, directement à partir d’un PIM, pour peu que ce dernier soit « simple », et ne fasse pas appel à des fonctions ou des mécanismes trop spécifiques à un langage de programmation donné. Nous discutons plus en détail de ces possibilités au début du chapitre suivant consacré aux transformations de modèles.

Les modèles hétérogènes évoqués plus haut peuvent être exprimés :

− soit dans des langages de modélisation de type états-transitions par exemple, car nous avons vu que tout formalisme ou langage basé sur les états-transitions et à indications temporelles pouvait être transformé en DEVS

114 − soit des langages dits « d’interface », c’est-à-dire des front-ends de DEVS. Dans tous les cas, il est bien entendu indispensable de disposer de leur méta-modèle pour pouvoir effectuer de telles transformations. Elles sont rendues possibles par l’approche IDM que nous suivons, qui permet de décrire des règles de transformation établissant des correspondances entre chaque méta-modèle source et le méta-modèle cible (qui sera toujours notre pivot), permettant de transformer un modèle « quelconque » en un PIM DEVS.

De la même manière, pour un modèle DEVS donné (peu importe sa provenance, qu’il ait été défini directement en respectant les règles de notre méta-modèle ou transformé selon celui-ci) l’approche IDM permet de le rendre productif en le transformant en PSM, et/ou en code objet directement utilisable dans un simulateur DEVS donné. Là encore, ce sont des transformations de modèles qui sont mises en oeuvre, faisant correspondre le méta-modèle de DEVS à un méta-modèle de simulateur, et en transformant un modèle DEVS en fichier texte contenant du code.

Toutes ces transformations seront largement détaillées dans les chapitres V et VI. Par ailleurs, le code complet de MetaDEVS, tel qu’il est utilisé pour toutes les transformations effectuées dans le cadre ce mémoire, figure en annexe 4 de ce document.