Le modèle objet et l’instanciation

Le modèle objet est une représentation physique (ici logicielle) des objets haut niveau du modèle de conception. Il définit des objets physiques (c.-à-d. typiquement des objets de la programmation orientée objet) servant de support pour l’exécution des objets du modèle de conception sur une plateforme d’exécution. Le modèle objet permet également de définir les données d’exécution des modèles. Pour rappel, ces données d’exécution peuvent être divisées en deux catégories :

— Les attributs dynamiques issus du modèle et pour lesquels la valeur courante doit être stockée dans la mémoire de la plateforme d’exécution (p. ex. une variable d’instance) ; — Les attributs ou les objets internes au moteur d’exécution qui sont nécessaires pour

l’implémentation de la sémantique du langage (p. ex. la variable stockant la valeur du compteur de programme (ou en anglais program counter ) qui indique l’instruction ac-tuellement exécutée).

Étant donné ces éléments, il apparaît évident que les concepts du fragment Métamodèleext RTD définissant le métamodèle du modèle objet ne doivent pas être définis directement dans le Métamodèle DSML pour au moins deux raisons. (i) Pour définir un modèle, les éléments de

8.3. Métamodélisation

la syntaxe abstraite doivent être associés aux éléments de la syntaxe concrète. Cependant, avoir les données d’exécution (p. ex. le compteur de programme) dans la syntaxe concrète n’a pas de sens car le modèle est défini de façon statique. (ii) Différentes plateformes d’exécution peuvent nécessiter différentes relations d’instanciation et chacune de ces relations peut être réutilisée pour d’autres langages.

On distingue deux grands types de relations d’instanciation [AK03 ; BL98] :

— L’instanciation logique (ou instanciation linguistique) qui permet de passer d’un niveau de modélisation au niveau inférieur (p. ex. de M2 à M1) ;

— L’instanciation physique (ou instanciation ontologique) qui permet de passer des con-cepts d’un langage aux concon-cepts physiques d’un domaine donné.

Cette seconde relation d’instanciation est justement celle qui est employée dans notre ap-proche pour construire le modèle objet qui servira à l’exécution du modèle de conception. Il existe cependant différentes relations d’instanciation physique [BL98] car chaque domaine dé-finit des concepts qui lui sont propres. Dans cette thèse, les objets du langage de modélisation sont instanciés en objets informatiques pouvant être déployés sur une plateforme d’exécution. La Figure 8.3 présente l’architecture de modélisation utilisée pour construire le modèle objet d’un modèle de Train à Grande Vitesse (TGV). Pour illustrer les concepts de façon générique, on considère ici que le modèle du TGV est conçu dans un DSML quelconque. Le métamodèle de ce langage (Métamodèle DSML) est conforme à Ecore. Pour faciliter la compréhension, seul le concept de Class est représenté dans le métamodèle du DSML considéré. Par la re-lation d’instanciation logique, Class est une instance de EClass et le Modèle DSML possède une classe Train instance de Class. Toujours pour simplifier l’illustration de cet exemple, on considère ici que le Modèle DSML possède une seule instance par Class¹. Ici, l’instance de la classe Train représente un TGV. Néanmoins, le niveau M0 n’étant pas un niveau de modé-lisation, il n’est pas possible de modéliser cette instance pour définir les données dynamiques nécessaires à son exécution.

Pour y parvenir, on utilise le mécanisme de promotion [JB06] qui permet de remonter le mo-dèle objet au niveau M1 et donc d’en faire un momo-dèle au sens de l’IDM. L’extension du momo-dèle permettant de représenter ce modèle objet est ModèleextRTD. Il définit les instances physiques du modèle qui seront utilisées pour l’exécution. De même, les concepts de modélisation de ce modèle objet sont promus au niveau M2 sous la forme du fragment Métamodèleext RTD qui étend le métamodèle du DSML. Le fragment Métamodèle_extRTD définit ici le concept de Phy-sicalInstance pour pouvoir les représenter. PhyPhy-sicalInstance représente l’instance d’une Class par la relation d’instanciation physique. À titre d’exemple, une donnée d’exécution appelée pro-gramCounter a également été ajoutée pour représenter le compteur de programme de chaque instance et ainsi pouvoir implémenter la sémantique du langage. Au niveau M1, il devient ainsi

FIGURE8.3 – Architecture de modélisation utilisée pour construire un modèle objet.

possible de modéliser l’instance de la classe Train. Celle-ci est en fait une instance de Phy-sicalInstance construite à partir de la classe Train via la relation d’instanciation physique. En pratique, la relation d’instanciation physique permettant de passer du Modèle DSML aux objets du Modèle_extRTD doit être renseignée par l’ingénieur du langage car elle fait partie intégrante de sa sémantique. Le modèle exécutable (Modèle xDSML) possède ainsi le modèle statique, les instances du modèle et les données d’exécution qui leur sont associées.

Concrètement, chaque instance de PhysicalInstance possède les attributs d’exécution dé-finis par cette classe ainsi qu’une référence vers le type de l’objet modélisé (ici Train). Pour permettre d’instancier plusieurs objets pour chaque Class (p. ex. plusieurs trains), il suffit sim-plement que chaque instance de PhysicalInstance possède également une référence pointant sur la propriété du Modèle DSML représentant l’objet devant être instancié.

En résumé, cette architecture permet ainsi d’avoir quatre niveaux de modélisation. Ecore définit la relation d’instanciation (logique) permettant de passer de M3 à M2 et de M2 à M1. Pour le passage à M0, c’est la sémantique du langage de conception qui définit comment faire

8.3. Métamodélisation

l’instanciation (et non plus celle d’Ecore). Le mécanisme de promotion permet de remonter le modèle objet dans un espace de modélisation et d’instancier les objets physiques servant à l’exécution via une relation d’instanciation physique.

Application à UML. Un exemple de métamodèle_ext RTD pour le langage UML est donné sur la Figure 8.4. Un interpréteur (Interpreter ) contient l’ensemble des objets (Object) dyna-miques du modèle. Par analogie à une PhysicalInstance, chaque Object possède une part et un type indiquant respectivement l’objet instancié par instanciation physique et sa classe. Un Object peut être soit passif (PassiveObject) soit actif (ActiveObject). Un PassiveObject pos-sède uniquement des attributs dynamiques modélisés par InstanceSlot (c.-à-d. des variables d’instance). Un ActiveObject possède également un currentState représentant l’état courant de sa machine à états et un eventPool permettant de stocker les évènements (Event) envoyés par les autres objets du système.

FIGURE8.4 – Exemple simplifié de métamodèle_extRTD pour le langage UML.