3.3 Facilités d’ingénierie pour les langages de modélisation dédiés
3.3.2 Réutilisation de transformations de modèles
Les transformations de modèles définissent le comportement d’un langage de modélisation dédié. Elles peuvent implémenter des manipulations de modèles complexes et difficiles à écrire, telles qu’un compilateur. Il n’est donc pas surprenant que de nombreuses approches aient été proposées afin de réutiliser les transformations de modèles. Certaines approches s’appuient sur la définition de transformations de modèles génériques, i.e., de transformations acceptant des modèles conformes à différents métamodèles. D’autres approches composent ou chaînent des transformations de modèles atomiques afin de créer des transformations plus complexes. Les transformations de modèles atomiques peuvent donc être réutilisées au sein de différentes chaînes.
3.3.2.1 Transformations de modèles génériques
Les transformations de modèles génériques sont des transformations de modèles qui ac- ceptent ou retournent des modèles issus de plusieurs langages de modélisation dédiés. Pour cela, elles sont définies sur des entités différentes des métamodèles. En effet, puisqu’un modèle ne se conforme qu’à un unique métamodèle, définir les transformations sur un métamodèle les empêchent d’accepter des modèles conformes à d’autres métamodèles. Une transformation de modèles qui est définie à partir des classes d’un métamodèle ne peut manipuler que des objets instances de ces classes. Dès lors, un modèle conforme à un autre métamodèle ne peut pas être manipulé par la transformation, puisque les objets qu’il contient sont instances d’autres classes.
Pour appliquer une transformation générique définie sur une de ces entités (motifs de trans- formations contenant des entités variables, templates ou concepts), il faut établir une relation entre le métamodèle du modèle et ladite entité. Cette relation s’appuie sur une comparaison des structures du métamodèle et de l’entité à partir de laquelle la transformation a été définie. Ainsi, une transformation générique s’établit non pas sur un langage de modélisation dédié, mais sur une famille de langages, établie à l’aide de cette comparaison de structures.
Varrò et Pataricza ont introduit des entités variables (variable entities en anglais) dans les motifs (patterns en anglais) de règles de transformation déclaratives [VP04]. Le motif d’une règle de transformation peut être exprimé en faisant référence aux éléments d’un métamodèle ou en utilisant des entités variables qui spécifient uniquement les concepts nécessaires pour appliquer la règle (i.e., types, champs, etc). La reconnaissance de motifs (pattern matching en
Facilités d’ingénierie pour les langages de modélisation dédiés 41
anglais) peut ensuite sélectionner un modèle présentant ces concepts, indépendamment de son métamodèle.
Cuccuru et al. ont proposé la notion de points de variation sémantique dans les métamo- dèles [CMTG07]. Un métamodèle peut contenir des points de variation spécifiés par des classes abstraites, il définit alors un template. Une transformation de modèles écrite sur un template peut-être réutilisée sur les modèles d’autres métamodèles. Pour cela, les métamodèles doivent fixer les points de variation en les liant à des classes qui étendent les classes abstraites. Les métamodèles créés à partir d’un template forment une famille de langages de modélisation dé- diés partageant une partie de leur structure et le comportement défini par les transformations écrites à partir du template.
De Lara et Guerra introduisent le mécanisme de concept inspiré de la programmation gé- nérique [DLG10]. Les concepts définissent les exigences que doit remplir un métamodèle, sous la forme d’un ensemble de classes, pour réutiliser une transformation. À partir d’une trans- formation définie sur un concept et d’une correspondance entre le concept et un métamodèle, établie à l’aide d’un langage dédié, une transformation spécifique à ce métamodèle est générée. Ces approches s’appuient sur une correspondance structurelle forte entre le métamodèle et l’entité sur laquelle est définie la transformation. En effet, le métamodèle doit contenir un sous-graphe isomorphe [Coo71] de l’entité, i.e., un sous-ensemble du graphe de classes de sa syntaxe abstraite doit être identique (même noms, multiplicités, etc.) au graphe de classes défini par le motif à entités variables, le template ou le concept sur lequel est définie la transformation. C’est pourquoi Sanchez et al. et Wimmer et al. ont étendu le mécanisme de liaison pré- sentée pour les concepts [DLG10] pour autoriser des adaptations [SCGdL11,WKR+11]. Ces
adaptations incluent le renommage, la liaison de plusieurs éléments d’un métamodèle à un seul élément d’un concept et la navigation et le filtrage de champs en utilisant des expressions de l’Object Contrainst Language (OCL) [OMG03]. Ces adaptations sont possibles grâce à une approche qui mêle adaptation des modèles à transformer et génération de transformations spécifiques pour leurs métamodèles.
3.3.2.2 Décomposition et chaînage de transformations de modèles
Un processus de développement dirigé par les modèles complet peut impliquer de nom- breuses transformations de modèles. De plus, certaines transformations de modèles sont suf- fisamment complexes pour qu’il soit utile de les décomposer en plusieurs transformations de complexité moindre. Pour supporter cette modularisation des transformations de modèles, plusieurs approches ont été proposées pour définir des chaînes de transformations de modèles. Les transformations atomiques peuvent être chaînées au sein de transformations compo- sites(ou complexes) [Old05,VJBB13] ou à l’aide d’un langage d’orchestration [Kle06,PVSGB08,
RRGLR+09]. Pour déterminer si deux transformations peuvent être chaînées, les environne-
ments d’orchestration ou de définition de transformations de modèles comparent les signatures des transformations. Ces signatures sont exprimées sous la forme T : I1...In→O1...On, où I1...In représentent les types des modèles d’entrée de la transformation, et O1...Onles types des mo- dèles de sortie de la transformation. Ces types sont exprimés sous la forme des métamodèles auxquels se conforment les modèles. Par exemple une transformation MMA→MMBaccepte en entrée un modèle conforme au métamodèle MMA et retourne un modèle conforme au métamodèle MMB.
Pilgrim et al. autorisent l’utilisateur à définir des pré et post-conditions aux transforma- tions pour contraindre les modèles d’entrée et de sortie au-delà de la conformité [PVSGB08]. Aranega, Etien et al. ont proposé des analyses statiques, qui analysent le code des transforma-
42 Définition de langages de modélisation dédiés
tions afin de déduire quelles actions CRUD14(création, lecture, modification ou suppression)
peuvent être réalisées par la transformation sur une classe donnée [AEM12,EABP12]. Ces informations permettent d’obtenir une signature plus précise des transformations de modèles en annotant les classes du métamodèle.
Pour chaîner deux transformations de modèles, celles-ci doivent avoir des signatures com- patibles : l’exécution de la transformation Tf st: If st
1 ...I f st n →O f st 1 ..O f st
n peut être suivie de l’exé- cution de la transformation Tsnd: Isnd
1 ...Isndn →Osnd1 ...Osndn si et seulement si O f st 1 ...O
f st
n =Isnd1 ...Isndn . Deux transformations ne peuvent donc être chaînées que si le métamodèle (éventuellement étendu par des informations supplémentaires) du modèle de retour de la première est le même métamodèle que le métamodèle du paramètre de la seconde.