Les métalangages utilisés au sein de l’environnement Kermeta permettent de déclarer et manipuler les concepts de modélisation in-the-small. Afin de permettre à l’utilisateur de mani- puler les concepts de modélisation in-the-large introduits dans la syntaxe abstraite de Kermeta, nous avons introduit de nouvelles notations dans sa syntaxe concrète. Nous fournissons ainsi le moyen de déclarer les propriétés et les opérations de modèles au sein d’un métamodèle. Le corps d’une transformation de modèles peut contenir des types chemins-dépendants pour les- quels nous avons également fourni une syntaxe concrète. Enfin, nous avons défini des mot-clés permettant de déclarer les relations de sous-typage et d’héritage.
126 Implémentation d’un système de types orienté-modèle dans Kermeta ControlFlowGraph +computeNodeReachability() Node +isReachable: Boolean +computeReachability(): Boolean nodes 1..* entry 1 +reachabilityAnalysis() +graphs : ^simple::ControlFlowGraph <<modeltype>> CFG_Simple previous 0..* next 0..*
Figure 8.5 – Type de modèles CFG_Simple.
Listing 8.4 – Exemple de déclaration de méta- modèle à l’aide du langage kp.
1 metamodel CFG_Simple {
2 import "${ project . baseUri }/ src / main / ecore /
3 simple . ecore "
4 import "${ project . baseUri }/ src / main / kmt /
5 NodeReachabilityAnalysis . kmt "
6 import "${ project . baseUri }/ src / main / kmt /
7 GraphAspect . kmt "
8 import "${ project . baseUri }/ src / main / kmt /
9 NodeAspect . kmt "
10 }
Listing 8.5 – Exemple de variable contenant un modèle en Kermeta.
1 var model : CFG_Simple i n i t CFG_Simple . new
8.4.1 Métamodèles et types de modèles
Par défaut, Kermeta crée un métamodèle quand il compose différents fichiers déclarés à l’aide du métalangage kp. Selon les différents fichiers (et les métalangages utilisés dans ces fichiers), ce métamodèle est composé de classes, de champs et de signatures d’opérations (déclarés à l’aide d’Ecore), d’opérations (déclarées à l’aide du métalangage d’action Kermeta) et de champs et d’opérations de modèles (également déclarés avec le métalangage Kermeta).
Un métamodèle est donc déclaré au sein du fichier kp et prend la forme présentée en Lis- ting8.4. Le Listing8.4présente un métamodèle nommé CFG_Simple qui implémente le type de modèles présenté en Figure8.5. Le mot-clé metamodel suivi de l’identifiant CFG_Simple déclare un métamodèle. Les import déclarent les chemins vers les fichiers utilisés pour construire ce métamodèle :
– un fichier Ecore (simple.ecore) qui déclare le graphe de classes du métamodèle ; – un fichier Kermeta (NodeReachabilityAnalysis.kmt) déclarant les champs et opérations
de modèles nécessaires à l’analyse d’atteignabilité des blocs d’un graphe de flot de contrôle ;
– deux fichiers Kermeta (GraphAspect.kmt et NodeAspect.kmt) qui déclarent les champs et opérations d’objets nécessaires à l’analyse d’atteignabilité dans les classes ControlFlow- Graphet Node.
Puisque les types de modèles ne sont pas séparés des métamodèles d’un point de vue utilisateur, le nom d’un métamodèle est utilisé pour typer des variables, des paramètres ou des opérations. Le Listing8.5montre un exemple de l’utilisation du métamodèle CFG_Simple pour typer une variable.
Le nom du métamodèle peut également être utilisé pour instancier un modèle à l’aide de l’opération spécifique new. En Kermeta, new est une opération disponible sur les classes et les métamodèles qui permet de produire une instance de ces classes ou métamodèles. Dans le Listing8.5, l’expression CFG_Simple.new utilisée pour initialiser la variable model produit un nouveau modèle instance de CFG_Simple, i.e., réserve l’espace mémoire pour le modèle, contenant le champ de modèles graphs et un pointeur vers la table des opérations de modèles définies par le métamodèle CFG_Simple.
Syntaxe concrète 127
Listing 8.6 – Exemple de types chemin-dépendants en Kermeta.
1 a t t r i b u t e rootNode : ^ simple :: Node
2
3 operation convertToDot [ MT ^: Dot ]() : MT ^ dot :: DotGraph i s do
4 ...
5 end
8.4.2 Types chemins-dépendants
Les types chemins dépendants sont utilisés pour déclarer des variables, des opérations ou des paramètres dont le type objet varie en fonction d’un type de modèles (cf. Section4.3). Nous différencions deux sortes de types chemin-dépendants : les types qui appartiennent au même type de modèles que le terme qu’ils typent (variable, opération ou paramètre) ; et les types qui appartiennent à un autre type de modèles.
Le Listing 8.6présente un exemple de chacun de ces types chemin-dépendants, suppo- sant que l’attribut rootNode et l’opération convertToDot sont contenus par le métamodèle CFG_Simple:
– le champ rootNode déclare un type ^simple::Node ;
– l’opération convertToDot déclare un type de retour MT^dot::DotGraph.
Ici le caractère ^ est utilisé comme séparateur entre un type de modèles et un package dans le nom qualifié d’un type objet et les caractères :: sont utilisés comme séparateur entre packages et entre un package et un type. Si aucun type de modèles n’est indiqué avant le ^, le type objet appartient au même type de modèles que le terme typé. Ainsi, ^simple::Node indique le type Node, du package simple appartenant au même type de modèles que le champ rootNode, i.e., le type de modèles extrait du métamodèle CFG_Simple (^simple::Node indique donc ici le type CFG_Simple^simple::Node). Si le champ rootNode est hérité dans un mé- tamodèle CFG_Dominance, son type changera avec le type de modèles pour indiquer le type CFG_Dominance^simple::Node.
Il est également possible d’utiliser un paramètre de type (cf. Section4.2.4) pour déclarer un type chemin-dépendant. L’opération convertToDot possède un paramètre de type nommé MT dont la borne supérieure est le type de modèles Dot (en Kermeta, la borne supérieure d’un paramètre de type est indiquée par : pour les types objets et par ^: pour les types de modèles). Le paramètre de type MT est ensuite utilisé pour définir le type de retour de l’opération (MT^dot::DotGraph). Selon le type de modèles passé en paramètre à l’opération lors de son appel, MT^dot::DotGraph désignera donc un type objet différent.
8.4.3 Opérations et champs de modèles
L’ajout de champs et d’opérations de modèles se fait dans un métamodèle déclaré à l’aide d’un fichier kp. Les champs et opérations de modèles sont donc déclarés indépendamment dans un fichier Kermeta, comme celui présenté en Listing8.7. Le mot-clé metamodel, suivi du nom du métamodèle, est utilisé pour déclarer un ensemble de champs et d’opérations de modèles.
Les champs et opérations de modèles sont déclarés d’une manière équivalente aux champs et opérations : à l’aide des mot-clés attribute (pour les champs composite), reference (pour les champs non-composite) et operation pour les opérations. Les champs et opérations de modèles sont nommés et typés : le champ de modèles graphs est un ensemble d’objets typés par ControlFlowGraph, l’opération de modèles reachabilityAnalysis ne prend aucun paramètre
128 Implémentation d’un système de types orienté-modèle dans Kermeta
Listing 8.7 – Exemple de déclaration de champ et d’opération de modèles en Kermeta.
1 metamodel CFG_Simple {
2 a t t r i b u t e graphs : s e t ^ simple :: ControlFlowGraph [0..*]
3
4 operation reachabilityAnalysis () : Void i s do
5 graphs . each {g|
6 g. computeNodeReachability ()
7 }
8 end 9 }
Listing 8.8 – Exemple d’appel de champ et d’opération de modèles en Kermeta.
1 var model : CFG_Simple i n i t CFG_Simple . new
2
3 model . reachabilityAnalysis ()
4
5 var modelGraphs : Set [ CFG_Simple ^ simple :: ControlFlowGraph ] i n i t model . graphs ()
et ne retourne rien. Le corps d’une opération de modèles, comme le corps d’une opération d’objets est déclaré entre les délimiteurs do et end à l’aide du métalangage d’action Kermeta (i.e., le corps d’une opération de modèles est une séquence d’expressions Kermeta).
Un champ de modèles ou une opération de modèles peut ensuite être appelé à partir d’un modèle, à l’aide de la notation pointée classique des langages orientés-objet (cf Listing8.8).
8.4.4 Relation de sous-typage et d’héritage
La relation d’héritage est implémentée dans Kermeta comme une facilité de construction des métamodèles. C’est pourquoi, la relation d’héritage est déclarée au moment de la déclaration d’un métamodèle dans un fichier kp, là où sont déclarés les différents imports nécessaires à la construction du métamodèle. La déclaration de la relation d’héritage se fait à l’aide du mot-clé extendssuivi du nom du métamodèle à étendre (cf. Listing8.9).
Une relation de sous-typage se déclare à l’aide du mot-clé subtypeof suivi du nom du super-type (cf. Listing8.10). Puisque la syntaxe concrète ne sépare pas les métamodèles des types de modèles, les noms utilisés sont ceux des métamodèles, bien que la relation de sous- typage soit définie entre les types de modèles qui sont extraits de ces métamodèles. Cette déclaration se fait dans les fichiers Kermeta dans lesquels sont déclarés les champs et les opérations de modèles.
La déclaration des deux relations est séparée afin de laisser la possibilité de fournir des facilités de redéfinition découplées du sous-typage et d’autoriser la déclaration de sous-typage après la définition de deux métamodèles (cf. Section4.2.3).
Listing 8.9 – Exemple de déclaration d’héritage entre CFG_Simple et CFG_Dominance en kp
1 metamodel CFG_Dominance extends CFG_Simple {
2 ...
3 }
Listing 8.10 – Exemple de déclara- tion d’une relation de sous-typage entre CFG_Simple et CFG_Dominance en Ker- meta.
1 metamodel CFG_Dominance {
2 subtypeof CFG_Simple
Sémantique 129