Les transformations de modèles

Concepts de base

La notion de transformation est primordiale dans une démarche de type MDA. C'est elle qui permet le passage d'un niveau à un autre (PIM vers PSM par exemple). Par dénition, une transformation est une opération qui prend en entrée un modèle source et qui génère en sortie un modèle cible. Ces deux modèles doivent avoir une relation de conformité avec leurs méta-modèles respectifs (qui peuvent être identiques). Une transfor-mation est donc un ensemble de règles à respecter pour représenter des correspondances entre les éléments du modèle source et les éléments du modèle cible.

Les étapes principales de l'approche MDA sont constituées des niveaux CIM, PIM et PSM qui contiennent des modèles nécessaires à la génération d'un environnement exé-cutable. Ce dernier est obtenu par génération à partir du PSM qui est lui-même obtenu par transformations entres les diérents niveaux, du PIM vers le PIM et du PIM vers le PSM. En eet, un des objectifs majeurs du MDA est de rendre opérationnel les modèles en utilisant des transformations successives entre eux. Ainsi, le ranement du PIM vers le PIM puis du PIM vers le PSM nécessite l'utilisation d'outils et de techniques de transfor-mations. Le but est de préciser ce que sera l'application à partir de modèles génériques. Ce sont les transformations successives qui permettent aux modèles de devenir des éléments productifs de MDA.

Pour réaliser les transformations, il est important que les modèles (source et cible) soient exprimés dans un langage de modélisation. Il existe plusieurs types de

transforma-tions :

 endogène : il concerne des transformations s'appuyant sur le même méta-modèle. Le modèle cible obtenu par transformation est conforme au même méta-modèle cible qui est dans ce cas précis le même que le modèle source.

 exogène : il concerne des transformations s'appuyant sur des méta-modèles dié-rents. Le modèle cible obtenu par transformation est conforme à un méta-modèle diérent que le méta-modèle source.

 horizontale : il concerne des transformations entre deux modèles du même niveau d'abstraction. Par exemple une transformation entre deux PIM.

 verticale : il concerne des transformations entre deux modèles de diérents niveaux d'abstraction, par exemple la transformation du CIM vers PIM.

Le fonctionnement du processus de transformation peut être décrit en 2 phases. La première phase consiste à dénir un méta-modèle cible et à mettre en correspondance les éléments de celui-ci avec le méta-modèle source. La mise en correspondance est réalisée grâce à des règles de transformation. Ces règles se basent sur un modèle source (conforme au modèle source) en entrée et génère en sortie un modèle cible (conforme au méta-modèle cible). La deuxième phase concerne l'exécution des règles de transformation dans un langage donné. Le modèle d'entrée permet ainsi la production du modèle cible par cette exécution. Le schéma ci dessous résume le principe de fonctionnement des transformations de modèles (g. 2.6).

Figure 2.6  Transformations de modèles Approche Query View Transformation (QVT)

QVT est une spécication établie par l'OMG qui propose un standard dans la mo-délisation des transformations. Il permet de dénir des langages de transformation et de

2.3. Ingénierie Dirigée par les Modèles manipulation des modèles de transformation grâce à ses méta-modèles conformes et to-talement immergés au MOF. C'est un standard pour la transformation de modèles vers modèles (M2M). Ce standard possède trois méta-modèles (langages) de transformation :  relations : il correspond à un langage déclaratif et est basé sur le concept des patterns objets. Il est utilisé comme représentation des relations entre les modèles ou comme transformation (par la transformation RelationsToCore) en modèle core. Le langage Relations dispose également d'éléments de traces générées automatiquement lors de transformations entre modèles. Ainsi des mécanismes permettent la reconnaissance de motifs dans un modèle. De plus, il permet également l'interfaçage avec la partie impérative.

 operational mapings : langage impératif spécique qui permet de décrire des trans-formations. Il peut être utilisé de manière autonome (en dénissant des règles de transformation dans une boite noire) ou faire appel aux langages déclaratifs pour une utilisation hybride. L'OCL est le langage utilisé pour la dénition des règles de transformation.

 core : langage déclaratif avec une syntaxe textuelle. Il permet de dénir des règles de transformations. Contrairement au langage Relations, Core ne supporte pas les mécanismes de patterns. Les traces de la transformation doivent être générées par l'utilisateur.

L'OMG propose ainsi aux utilisateurs une approche hybride (déclaratif/impératif) dans le but de pouvoir satisfaire chacun d'entre eux. De plus, l'approche QVT est utilisée dans plusieurs langages dont Atlas Transformation Language qui est le plus courant et le plus utilisé dans les projets concernés par MDA.

Atlas transformation language (ATL)

Opérationnel et nature Atlas Transformation Language est un langage de transfor-mation de modèles à modèles (M2M). Il permet de produire un ou plusieurs modèles cibles à partir d'un ou de plusieurs modèles en entrée. Il est très utilisé dans le milieu industriel et académique. C'est un langage avec une syntaxe proche de l'OCL (utilisation de l'OCL pour des requêtes de transformation) qui s'appuie sur le méta-modèle EMF (Eclipse Modeling framework). En eet, les outils de transformation ATL font partie de l'environnement de développement Eclipse sous la forme de plug-in. De plus, l'ATL utilise le format standard XMI pour la dénition des méta-modèles.

Figure 2.7  Transformations avec ATL

Une transformation ATL consiste à créer un modèle cible (Mb) à partir d'un modèle source (Ma) en entrée. Cette transformation est basée sur des règles de correspondance entre le méta-modèle source (MMa) et cible (MMb). Ces règles sont regroupées dans le modèle ATL (MMa2MMb.atl) qui est lui aussi conforme au méta-modèle ATL. Tous les modèles (MMa, MMb et ATL) sont conformes aux méta-méta-modèle MOF de l'OMG. La transformation se déroule en parcourant le contenu du modèle en entrée (Ma), en compa-rant ce contenu avec les patterns sources (règles de correspondance dénies dans le chier .atl) et en produisant les patterns cibles dans le modèle cible en cas de correspondance.

Le langage ATL est un langage Hybride : déclaratif/impératif. La dénition des règles de correspondance entre les modèles d'entrée et les modèles de sortie représente la par-tie déclarative du langage. La parpar-tie impérative est surtout utilisée pour les invocations des règles et pour les blocs d'actions (séquence d'instructions). Cependant, le paradigme déclaratif est celui recommandé par les concepteurs du langage.

Concepts d'ATL Les principaux concepts du langage ATL sont :

 entête de la transformation (header) : la convention veut qu'une transformation d'un modèle à un autre, soit nommée d'après les méta-modèles avec un 2 (to) ajouté entre les deux. OUT et IN sont les noms donnés aux modèles. Ils ne sont pas utilisés par la suite. Les modèles sources et cibles sont typés, ici DB et GEN qui correspondent respectivement aux méta-modèle DB_metamodel et Generic_metamodel. Le code ci-dessous montre le header d'une transformation avec ATL.

 

−− @path DB=/Audros/Metamodels/DB_metamodele.ecore −− @path Gen=/Audros/Metamodels/Generic_metamodele.ecore

2.4. Conclusion

module Generic2db;

create OUT : DB fromIN : Gen;



Listing 2.1  Exemple d'un entête d'une transformation

 méthodes auxiliaires (Helpers) : un helper est déni sur un contexte et pourra être appliqué sur toute expression ayant pour type ce contexte (comme une méthode dans une classe en Java). Le contexte peut être celui du module ou bien celui d'un élément du module. Il peut prendre des paramètres (non obligatoires) et possède nécessairement un type de retour. Enn, le code d'un helper est une expression OCL.

 les règles déclaratives (Declarative Rules) : elles spécient un pattern source dans le modèle d'entrée et un pattern cible à créer dans le modèle de sortie. Elles sont de 3 types Standard (appliquée une fois pour chaque correspondance), lazy (appliquée pour chaque correspondance autant de fois qu'elle est référencée par une autre règle) et unique lazy (appliquée lorsqu'elle est référencée par une autre règle, pour chaque correspondance). Le code ci-dessous montre l'utilisation d'une règle déclarative en ATL.

 

rule Class2Table {

from −− source pattern

c:ClassDiagram!Class

to −− target pattern

t:Relational!Table }



Listing 2.2  Exemple de règle déclarative standard

2.4 Conclusion

Dans ce chapitre, nous avons présenté les concepts principaux de l'ingénierie des mo-dèles. En fait, nous avons restreint ces concepts à la démarche MDA proposée par l'OMG. Cette démarche est au c÷ur de notre proposition, car nous pensons que le découpage par niveau est une bonne approche vis à vis des problématiques explicitées dans le premier chapitre. En eet, que ce soit pour le déploiement initial du PLM ou la gestion de ses évolutions, le principe de caractériser les niveaux métiers permet de séparer les concepts métier des contraintes techniques liées au PLM. Ainsi, comme le propose la démarche MDA, il s'agit de mettre en évidence des mécanismes permettant de simplier et d'auto-matiser (grâce aux transformations) le travail du concepteur au sein des systèmes PLM.

Chapitre 3

Approche de construction de modèles