L’outil ATL

La difficulté rencontrée lors de la mise en place de notre atelier a été le choix d’un lan-gage de transformation qui permette de répondre à nos besoins. En effet, la création d’un langage de transformation normalisé est devenue un point important autour de l’approche MDA [Jouault et Kurtev,2006b] [Kleppe et al.,2003b] et [Kleppe Anneke,2002]. Les langages de transformation peuvent être classés suivant plusieurs critères comme la nature des règles (impératives, déclaratives ou hybrides), la gestion des modèles (textuels ou graphiques), la gestion de la traçabilité des transformations, le fait que l’outil soit libre ou pas, etc [Touzi, 2007]. Il est alors possible qu’un langage de transformation soit plus adapté qu’un autre dans un contexte spécifique. En conclusion, il apparaît difficile de converger vers un lan-gage unique. Dans notre travail, nous avons défini deux critères, sur lesquels nous nous sommes basés, et qui nous semblent pertinents, liés aux transformations de modèles que nous souhaitons établir :

– La compatibilité avec la plate-forme utilisée

– La possibilité de gérer des modèles ou des profils UML

ATL semble répondre à ces deux critères. En plus d’être un langage libre, les règles ATL sont simples à mettre en œuvre. Son langage à base de variables et d’affectation le rend ac-cessible. De plus, le langage ATL est défini dans un IDE d’Eclipse, et donc permet de générer des modèles UML (moyennant le méta-modèle d’UML) qui sont compatibles et utilisables dans la plateforme UML2 d’Eclipse, utilisé aussi dans le cadre de ce travail. Enfin, un autre avantage d’ATL, est qu’il supporte les profils UML. En effet, ce langage permet d’introduire efficacement un profil UML (réalisé avec un éditeur UML) en entrée de la transformation (avec le fichier source de la transformation). Des instructions particulières d’ATL permettent

par la suite d’utiliser le profil UML pour typer les éléments du modèle UML en sortie de la transformation.

Dans cette section, nous allons nous limiter à présenter uniquement les caractéristiques de l’outil ATL, qui nous ont été utiles dans l’implémentation de notre atelier. Une des carac-téristiques du langage ATL, relève de son langage qui présente la particularité d’être hybride (déclaratif et impératif).

La partie déclarative permet de faire correspondre directement un élément du méta-modèle source de la transformation avec un élément du méta-méta-modèle cible de la transfor-mation (matched rule). L’exemple ATL suivant montre une transfortransfor-mation complètement déclarative de UML vers Java qui à toute classe UML fait correspondre une classe Java :

1 module UML2JAVA ;

2 create OUT : JAVA from IN : UML ;

3 rule Class2Jclass

4 {

5 from uclass : UML !Class

6 to jclass : JAVA !JClass(

7 uclass.name <- jclass.name

8 ) }

En ATL une transformation s’appelle module. Le mot-clé OUT désigne le méta-modèle cible JAVA (ligne 2). Le mot clé IN désigne le méta-modèle source (UML) (ligne 2). La règle (Class2Jclass) du fichier de transformation (UML2JAVA) est déclarative. L’élément class (méta-classe qui décrit une classe UML) du méta-modèle source va être traduit en l’élément Jclass du méta-modèle cible (ligne 6). On précise ensuite en utilisant l’opérateur de liaison <– , que l’attribut « name » de la nouvelle classe va être égal au nom de la classe UML source (ligne 7).

La partie impératived’ATL permet de décrire les correspondances directes entre élé-ments. Elle comporte des déclarations conditionnelles (if, then, else...endif), des déclara-tions de variables (let VarName : varType = initialValue), des déclaradéclara-tions de boucle (while (condition...do), etc. Cette partie permet également de manipuler les éléments générés par les règles déclaratives (modification d’attributs, etc.).

ATL supporte aussi le mécanisme des Helpers. Ce sont simplement des mots-clés faisant référence à des procédures stockées (qui peuvent ainsi être appelées dans une règle lorsqu’il y en a besoin). Les helpers servent à éviter la redondance de code et la création de grandes expressions dans une règle. Ceci conduit aussi à une meilleure lisibilité des modules ATL. Un helper en ATL peut recevoir des paramètres et retourner une valeur.

Les règles appelées (called rule) ressemblent aux helpers. L’exécution d’une règle ap-pelée est déclenchée par son appel explicite depuis une autre règle. Ces règles s’exécutent pour générer des éléments dans le modèle cible après une première génération assurée par les règles déclaratives. Ces dernières s’exécutent en effet en même temps lors de l’exécution de la transformation.

6.2.2.1 Gestion de méta-modèles avec ATL

ATL permet la gestion des méta-modèles liés à la transformation. Il gère notamment les méta-modèles écrit sous Ecore. Dans ce travail, nous nous intéressons au méta-modèle UML 2.0 comme seule méta-modèle de la transformation. Dans ce cas, la transformation est dite «endogène » car les méta-modèles source et cible sont identiques comme le montre la figure 6.2.

MM

MM ^Mt MM

Conforme à

Figure 6.2 — Principe de la transformation endogène

Une fois les deux méta-modèles de la transformation source et cible réalisés (dans notre cas il s’agit du même), il faut les déclarer en utilisant une fenêtre de configuration de la transformation. La figure6.3 illustre l’utilisation de la fenêtre de configuration pour l’ini-tialisation de la transformation « Security_Pattern_Integration PIM2secPIM ». Les champs permettent de faire correspondre les modèles (in et out), le méta-modèle ainsi que le profil UML de la transformation à leurs déclarations dans le code ATL ainsi que leurs chemins d’accès.

6.2.2.2 Gestion des profils UML avec ATL

Parmi les avantages de l’utilisation d’ATL, on peut citer sa capacité à gérer les profils UML. Dans ATL, un profil UML se présente comme un fichier créé par un éditeur UML (Plug-in UML2, etc.) et portant l’extension (.profile.uml). En ATL, nous pouvons ainsi utili-ser un fichier profil UML conjointement avec le fichier du méta-modèle cible, qui doit être celui d’UML. La déclaration du profil UML se fait en même temps que la déclaration des méta-modèles de la transformation (voir figure6.3) (ligne 2) comme suit :

10 create OUT : UML2 from IN:Meta-modèle source, NomDeProfile : UML2;

11 ...

L’application du profil ne peut commencer qu’une fois la partie déclarative du fichier de transformation exécutée. Elle se fait dans la partie impérative limitée par l’instruction do ? (ligne 3) : la commande prédéfinie dans ATL applyProfile permet d’appliquer le profil UML sur le modèle UML généré (ligne 5) :

13 -- apply the profile to the model created

14 out.applyProfile(UML2!Profile.allInstances()->select(e | e.name =

nomDeProfile?).

15 asSequence().first());

16 ...

17 }

Enfin, la commande applyStereotype permet d’appliquer un stéréotype de profil sur un artefact UML généré au sein du modèle cible (ligne 9) :

19 nomDeLaClasseUML.applyStereotype(nomDeLaClasseUML.

20 getApplicableStereotype(’nomDeStereotype’));

21 ?