Architecture technique générale

3.2.1. Le choix des langages et outils de transformation

Le choix d’un bon langage de transformation permet de répondre parfaitement à nos exigences.

Durant ces dernières années, la création d’un langage de transformation normalisé est devenue le centre de réflexions autour de MDA [Lopes 2005]. L’OMG a lancé en 2002 un appel à travers son RFP QVT [OMG 2002], pour que des propositions d’un langage de transformation soient faites. Le RFP QVT pour Query, View and Transformation n’est pas seulement destiné à la transformation, mais aussi à l’expression des requêtes (Query) et la définition de vue (View). Plusieurs langages s’inscrivent dans la recommandation QVT. Nous citons MOLA (Model transformation LAnguage) [Kalnins et al. 2004], ATL© (Atlas Transformation Language) [Jouault 2006], GreAT [Karsai et al. 2003], AndroMDA [Andro 2007].

Ces outils de transformation peuvent être classés suivant plusieurs critères : 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. 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 langage unique. Nous fixons deux critères liés aux transformations de modèles que nous souhaitons établir : la simplicité d’établissement des règles et la possibilité de gérer du code de service interactif. ATL© semble répondre à ces deux critères. En plus d’être un outil libre, les règles ATL© sont simples à mettre en œuvre. Son langage à base de variables et d’affectation le rend accessible.

3.2.2. La transformation de modèles avec ATL©

Dans cette section, nous présentons uniquement les caractéristiques de l’outil ATL©, qui nous ont été utiles dans l’implémentation de notre atelier. Une présentation plus détaillée du langage ATL©, est fournie dans [Jouault 2006].

3.2.2.1. Un langage déclaratif et impératif

Une des caractéristiques du langage ATL©, relève de son langage de programmation qui présente la particularité d’être hybride (déclaratif et impératif).

1 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-modèle cible de la transformation (matched rule).

A562 2

Figure 5.14. : Une transformation déclarative

1 En ATL© une transformation s’appelle module. Le mot-clé OUT montre le méta- modèle cible JAVA (ligne 2). Le mot clé IN montre 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 (classe UML) du méta-modèle source va être traduit vers l’élément jclass du méta-modèle cible (ligne 6). On précise ensuite en utilisant l’opérateur de liaison3, que l’attribut « name » de la nouvelle classe va être égal au nom de la classe UML source (ligne 7).

1 La partie impérative d’ATL© complète ces correspondances directes entre éléments. Elle comporte des déclarations conditionnelles (if…then…else...endif), des déclarations de variables (let VarName : varType = initialValue), des déclarations 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.).

3.2.2.2. Gestion de méta-modèles avec ATL©

ATL© doit permettre de gérer les méta-modèles liés à la transformation. Il gère notamment les méta-modèles écrit sous Ecore [Budinski et al. 2003]. Ce dernier est un langage de métamodélisation qui fait partie d’EMF (Eclipse Modeling Framework), résultat des efforts du projet Eclipse (Eclipse Tools Project). Ecore ressemble dans sa structure à un diagramme de classe UML. Il est basé sur des classes, des attributs, des associations pour lier les classes, des généralisations / spécifications entre classes, etc. Ecore présente donc un outil performant pour la réalisation de méta-modèles pour la transformation avec ATL©.

Quelques outils permettent l’édition de méta-modèles conformes à Ecore, tels que : Omondo ou bien l’éditeur Ecore fourni par EMF [Budinski et al. 2003].

Une fois les deux méta-modèles de la transformation (source et cible) et le modèle source réalisés, il faut les déclarer en utilisant une fenêtre de configuration de la transformation. La figure (Fig V.6) montre l’utilisation de la fenêtre de configuration pour l’initialisation de la transformation ServiceCoordination2BPEL. Les champs du haut IN et OUT font correspondre les modèles et méta-modèles de la transformation à leurs déclarations dans le code ATL©, alors que le champ du bas Path Editor fait correspondre ces déclarations à des fichiers portant une extension .ecore .

Figure 5.15. : Exécution d’une transformation avec ATL©

3.2.2.3. Structure globale des programmes de transformation

En ATL, une transformation s'appelle un module. Un module contient un en-tête, un ensemble d'importation de bibliothèques de fonctions et un ensemble de fonctions et de règles de transformation. Les fonctions sont appelées helper en ATL.

L'en-tête donne le nom du module de transformation et déclare les modèles source et cible. La figure 5.16 donne un exemple d'en-tête.

Figure 5.16 : Entête d’un programme ATL

L'en-tête commence par le mot-clé module suivi du nom du module. Ensuite, les modèles source et cible sont déclarés comme des variables typées par leurs méta-modèles. Le mot-clé

create indique les modèles cible. Le mot-clé from indique les modèles source. Dans notre

847 DFF1=,/:>2CC "F2;) E97627 (.;2?2=,/:2F9 &@2?2DFF>

A582 2

exemple, le modèle cible est représenté par le variable OUT à partir du modèle source représenté par IN. Les modèles source et cible sont respectivement conformes aux méta- modèles BPEL et Coordinateurs. En général, plus d'un modèle source et d'un modèle cible peuvent être listés dans l'en-tête.

Les fonctions et règles de transformation sont les constructions utilisées pour définir une transformation. Elles sont expliquées dans les deux sections suivantes : les helpers et les

règles de transformations.

3.2.2.4 Les Helpers

Les fonctions ATL sont appelées helpers d'après le standard OCL sur lequel ATL se base. OCL définit deux sortes de helpers : opération et attribut.

En ATL, un helper peut être spécifié dans le contexte d'un type OCL (par exemple String ou Integer) ou d'un type source (venant de l'un des méta-modèles source). Les modèles cible ne sont en effet pas navigables. Les helpers opération peuvent être utilisés pour définir des opérations dans le contexte d'un élément de modèle ou du module de transformation. Le rôle principal des helpers opération est de réaliser la navigation des modèles source. Ils peuvent avoir des paramètres et peuvent utiliser la récursivité. Les helpers opération définis dans le contexte d'éléments de modèles permettent les appels polymorphiques.

Puisque la navigation n'est autorisée que sur les modèles source en lecture seule, une

opération retourne toujours la même valeur pour un contexte et un ensemble d'arguments donnés.

Les helpers attribut sont utilisés pour associer des valeurs nommées en lecture seule sur les éléments de modèles source. Comme les opérations, ils ont un nom, un contexte et un type. La différence est qu'ils ne peuvent pas avoir de paramètre. Leur valeur est définie par une expression OCL. Comme les opérations, les attributs peuvent être définis récursivement avec les mêmes contraintes de terminaison et de cycles.

Les helpers attribut peuvent être considérés comme un moyen de décorer les modèles source avant l'exécution de la transformation. La décoration d'un élément de modèle peut dépendre de la déclaration d'autres éléments.

3.2.2.5. Règles de transformation

La règle de transformation est la construction élémentaire en ATL pour exprimer la logique de transformation. Les règles ATL peuvent être soit déclaratives soit impératives. Nous considérons ici les premières, appelées matched rules.

Une matched rule est composée d'un motif source et d'un motif cible. Le motif source d'une règle définit un ensemble de types source (venant des méta-modèles source) et une garde sous la forme d'une expression OCL booléenne. Un motif source est évalué en un ensemble de tuples dans les modèles source. Le motif cible est composé d'un ensemble d'éléments. Chacun de ces éléments définit un type cible (venant d'un méta-modèle cible) et un ensemble d'affectations appelées bindings. Un binding fait référence à une propriété (attribut ou référence) du type et spécifie une expression dont la valeur est utilisée pour initialiser la propriété.

3.3. Implémentation des règles de transformation pour la mise en œuvre de