Transformation de Modèles

2 Principe de la Transformation de Modèles

 Dans le contexte du MDA (Model Driven Architecture) :
«Le processus de conversion d’un modèle dans un autre modèle du
même système».
 IDM :
« une transformation de modèles est la génération d’un ou de plusieurs
modèles cibles à partir d’un ou de plusieurs modèles sources »
 La transformation se fait par l’intermédiaire de règles de transformations
qui décrivent la correspondance entre les entités du modèle source et
celles du modèle cible.
 La transformation se situe entre les métamodèles source et cible qui
décrivent la structure des modèles cible et source.
 Le moteur de transformation de modèles prend en entrée un ou
plusieurs modèles sources et crée en sortie un ou plusieurs modèles
cibles.
 Deux étapes :
3
 La première étape : permet
d’identifier les correspondances
entre les concepts des modèles
source et cible au niveau de
leurs métamodèles, ce qui
induit l’existence d’une fonction
de transformation applicable à
toutes les instances du
métamodèle source.
 La seconde étape : consiste à
appliquer la transformation du
modèle source afin de générer
automatiquement le modèle
cible par un programme appelé
moteur de transformation ou
d’exécution.
 Deux types de transformations :
4  Transformation endogène: les modèles impliqués sont issus du même
métamodèle (Dans le même espace technologique).
Ex : transformation d'un modèle UML en un autre modèle UML
 Optimisation : améliorer les performances tout en maintenant la sémantique.
 Refactoring : transformation qui opère un changement dans la structure pour
améliorer certains aspects de la qualité du logiciel tels que la compréhension, la
maintenance, la modularité et la réutilisation sans changer le comportement
observable.
 Simplification ou normalisation : transformation dont le but est de réduire la
complexité syntaxique.
 Transformation exogène : les modèles source et cible sont de différents
métamodèles (Entre 2 espaces technologique différents), la transformation est
dite exogène ou encore translation.
Ex : - Transformation d'un modèle UML en programme Java
- Transformation d'un fichier XML en schéma de BDD
 Synthèse : transformation d’un certain niveau d’abstraction vers un niveau
d’abstraction moins élevé. Un exemple typique est la génération de code,
 Rétro-ingénierie : inverse de la synthèse,
 Migration : transformation d’un programme écrit dans un langage vers un autre
langage du même niveau d’abstraction.
 Transformation exogène vs transformation endogène
5
 Approches de Transformation de Modèles
6
 Approche par programmation
 Utiliser les langages de programmation en général, et plus
particulièrement les langages orientés objet.
 La transformation est décrite sous forme d’un programme informatique
à l’image de n’importe quelle application informatique.
 Approche très utilisée car elle réutilise l’expérience accumulée et
l’outillage des langages existants.
 L’approche par « Template »
 Définir des canevas des modèles cibles souhaités.
 Ces canevas sont des modèles cibles paramétrés ou des modèles
Template.
 L’exécution d’une transformation consiste à prendre un modèle
Template et à remplacer ses paramètres par les valeurs d’un modèle
source.
 Cette approche est implémentée par exemple dans Softeam MDA
Modeler (modelio/ objecteering).
7
 L’approche par modélisation
 Appliquer les concepts de l’ingénierie des modèles aux
transformations des modèles elles-mêmes.
 L’objectif est de modéliser les transformations de modèles et de
rendre les modèles de transformation pérennes et productifs, en
exprimant leur indépendance vis-à-vis des plates-formes
d’exécution.
 Le standard MOF 2.0 QVT de l’OMG a été élaboré dans ce cadre
et a pour but de définir un métamodèle permettant l’élaboration
des modèles de transformation de modèles.
 Cette approche a été choisie par le groupe ATLAS à travers son
langage de transformation de modèles «ATL».
8
Règles de Transformation
« Les règles de transformation décrivent les correspondances entre les concepts
utilisés en entrée de la transformation et ceux résultant de l'application de cette
dernière »
 Il existe des langages impératifs qui décrivent comment une règle est
exécutée et des langages déclaratifs qui décrivent ce qui est créé par la
règle.
 Une règle de transformation passe par trois étapes :
1. La vérification de la condition correspond à l’analyse du modèle source de la
transformation de manière à détecter la présence d’un ensemble de concepts
qui correspond à ce que la règle « attend » en entrée.
2. L’exécution de la règle par le moteur de transformation pour ensemble de
concepts vérifiant la condition.
3. La création consiste à générer un ensemble de concepts dans le modèle de
sortie dont les champs sont remplis par les variables affectées durant l’exécution.
 L’agencement et la structuration des règles exécutées dans une
transformation permettent de reconstruire l’ensemble du modèle de sortie.
 Une règle de transformation contient deux parties :
9  une partie gauche (Left-Hand Side «LHS») exprime des accès aux modèles sources,
 une partie droite (Right-Hand Side «RHS») indique les expansions (création,
modification, suppression) dans les modèles cibles. Chacune des deux parties peut
être représentée par une combinaison de :
 Variables : une variable contient un élément de modèle (source ou cible) ou une valeur
intermédiaire nécessaire à l’expression de la règle.
 Patterns : un pattern désigne un fragment de modèle et peut contenir des variables. Il
peut être représenté à l’aide d’une syntaxe abstraite ou concrète dans le langage des
modèles correspondants. Cette syntaxe peut être textuelle ou graphique.
 Logique : une logique permet d’exprimer des calculs et des contraintes sur les éléments
de modèles. Cette expression peut être non exécutable (expression de relations entre
modèles) ou exécutable
Une logique exécutable peut être sous une forme déclarative ou impérative :
 exemple de logique déclarative : des expressions de requêtes OCL pour extraire des
éléments d’un modèle source et la création implicite des éléments du modèle cible via les
contraintes.
 Une logique impérative est souvent exprimée par un langage de programmation qui fait
appel à des APIs pour manipuler directement les modèles.
 Exemple : règle de transformation en ATL
rule Journal2Book {
10 from
j : Biblio!Journal
Pattern source to
b : Biblio!Book (
title <- j.title + '_(' + j.vol + '):' + j.num,
authors <- j.articles
Pattern cible ->collect(e | e.authors)->flatten()->asSet()
chapters <- j.articles,
pagesNb <- j.articles->collect(e | e.pagesNb)->sum()
)
}

Cette règle génère un élément du modèle Book à partir d’un élément de modèle Journal :
1.Le “title” du “Book” correspond au “title” du “journal” concaténé avec “vol” et num;
2.Le “chapters” du “Book” correspond aux éléments de modèle qui seront générés à partir de “articles” de
“Journal”;
3.L’entité “authors” de “Book” correspond à tous les “authors” des différents “articles” de “Journal” sans doublon;
4.L’attribut “pagesNb” est initialisé avec la somme des nombres de page (pagesNb) de tous les articles du modèle
source “Journal”.
11
Le métamodèle Biblio
 Approche MDA pour la Transformation de Modèles
12
 L’approche MDA est basée sur la manipulation de modèles,
 Le passage de l'un à l'autre (et vice versa) est une activité centrale de la
méthode.
  Les transformations réflexives de modèles :
13
 PIM/PIM (1),
 PSM/PSM (3),
 Code/Code (6)
Sont effectuées soit lors d'ajout d'éléments pour représenter des niveaux d’abstraction
différents, soit pour optimiser un modèle lorsqu'une transformation non réflexive est
incomplète ou pas assez précise (raffinage).
Il est important de noter que ces transformations réflexives ne sont pas toujours
automatisables.
 Les transformations (4) et (7) :
font partie de l'activité de rétro-ingénierie. Cette dernière fait partie de la philosophie de
MDA.
 Génération du code (5) :
Le passage d'un modèle type UML à du code écrit en langage évolué (Java, C++,...) que
l'on considère ici comme un modèle.
 La transformation (2) :
C’est la transformation centrale de MDA (et aussi la plus délicate) : Le passage du PIM
vers le PSM.
14 Deux types de transformation de base :
 La transformation Horizontale : le niveau d’abstraction en terme de
modélisation est préservé (PIM à PIM, ou bien PSM à PSM).
 permet de faire des mises à jour au niveau des modèles
transformés. L’exemple du passage de l’analyse à la
conception, illustre la transformation PIM à PIM.
 La transformation verticale : le niveau d’abstraction des deux
modèles, source et cible est différent (PIM vers PSM, ou bien PSM au
PIM).
 La passage de PIM vers PSM, permet par exemple d’intégrer les
éléments spécifiques à une plateforme technique, tels que J2EE,
CORBA, .NET, etc.
 L’abstraction PSM au PIM, s’avère très utile pour la reconstruction
des systèmes en migration.
 Propriétés des Transformations
15 Les principales propriétés qui caractérisent les transformations de modèles sont :
 Réversibilité : une transformation est dite réversible si elle peut se faire dans les
deux sens. Exemple : « Model to text » et « text to Model ».
 Traçabilité : permet de garder des informations sur le devenir des éléments des
modèles au cours des différentes transformations qu’ils subissent.
 Dans un contexte d’IDM, l’information relative à la traçabilité est représentée par un
modèle.
 Une instance de ce modèle est associée à chaque exécution d’une transformation
tracée.
 La définition d’un métamodèle de traces nous permet de structurer les traces qui
seront générées par la plate-forme de traçabilité et ainsi de mieux les manipuler.
 Réutilisabilité : permet de réutiliser des règles de transformation dans d’autres
transformations de modèles. L’identification de patterns de transformation est un
moyen pour mettre en œuvre cette réutilisabilité.
 Ordonnancement : l’ordonnancement consiste à représenter les niveaux
d’imbrication des règles de transformation. En effet, les règles de
transformations peuvent déclencher d’autres règles.
 Modularité : une transformation modulaire permet de modéliser les règles de
transformation en faisant un découpage du problème. Un langage de
transformation de modèles supportant la modularité facilite la réutilisation des
règles de transformation.
 Langages et outils dédiés à la transformation de modèles
16
 L’Ingénierie Dirigée par les Modèles se focalise sur les spécifications du MOF
pour définir des langages de transformation de modèles.
 Les langages de transformation définis à partir des recommandations du MOF :
 MOF Query/View/Transformation (QVT), le langage de transformation standard de
modèles respectant le MOF.
 ATLAS Transformation Language (ATL), un langage de transformation calqué sur
QVT, implémenté en Java et pouvant manipuler des modèles EMF.
 MOF Query/View/Transformation (QVT) (voir exemple)
17
 Query/View/Transformation (QVT) est le langage de transformation standard
pour les modèles basés sur une architecture MOF (considéré comme étant
une partie des spécifications du MOF)
 QVT est basé sur une architecture de langages déclaratifs et procéduraux
permettant une manipulation facilitée des éléments issus de modèles ou de
métamodèles et la définition de règles de transformation sur ces éléments.
 QVT propose un langage déclaratif de relations (Relations) et un langage
noyau (Core) permettant de spécifier des correspondances sur les éléments
des modèles manipulés.
 Pour les langages procéduraux, QVT définit un langage d’opérations de
correspondances (Operational Mappings) et un langage d’implémentation
interne d’opérations (Black box).
 Les langages procéduraux donneront accès aux relations et éventuellement
aux opérations des modèles manipulés.
18
Architecture de QVT
  Le langage de relations de QVT est utilisé pour définir de manière déclarative
19 des relations existantes entre les éléments d’un modèle source et les éléments
d’un modèle cible suivant certaines contraintes.
 La vérification d’une relation et de ses contraintes conduira à la transformation de
l’élément source en élément cible.
 Il est nécessaire que ce langage soit déclaratif afin que les diverses transformations
nécessaires puissent se faire d’une manière parallèle.
 Par exemple, la transformation d’une classe UML fait appel non seulement à la relation qui
concerne cette classe, mais également à la relation qui concerne les éléments englobés par
la classe selon le métamodèle (attributs et opérations).

 Le langage Core de QTV est une extension minimale d’EMOF et OCL.

 Dans ce langage, tout comme dans le premier, l’utilisateur ne s’occupe ni de la
création ni de la suppression des objets.
 En revanche, il doit gérer lui-même la trace des transformations. Il définit ses règles de
Transformations et les informations de trace à l’aide d’un métamodèle MOF.
 Le langage Core ne supporte pas de mécanisme de patterns ni d’identification des
éléments des modèles cibles.
 L’absence de mécanisme de trace et d’identification des éléments rend ce langage
simple, mais difficilement exploitable, en pratique.
20  Le langage « Operational Mappings » constitue la partie impérative de QVT.
 Il fournit un langage impératif spécifique de domaine pour décrire les
transformations.
 OCL est utilisé comme le langage des requêtes avec une extension de celui-ci
pour introduire des effets de bord et une syntaxe concrète, familière à la
programmation impérative.
 QVT propose deux façons d’utiliser le langage « Operational Mappings » :
 Premièrement, il peut être utilisé pour spécifier une transformation uniquement
dans le langage.
 Deuxièmement, il peut être utilisé de façon hybride. Dans ce cas, l’utilisateur
peut spécifier certains aspects de la transformation dans un des langages
déclaratifs (Relations ou Core) et implémenter, en boîte noire, des règles dans le
langage « Operational Mappings ».
 Black Box : Le mécanisme dit boite noire (Black Box) permet de connecter
et d'exécuter du code externe durant l'exécution de la transformation. Ce
mécanisme permet d'implémenter des algorithmes complexes et aussi la
réutilisation de bibliothèques externes
 ATLAS Transformation Language (ATL)
21
 Suite à la publication en 2001 du standard MDA par l’OMG, de nombreux
éditeurs de logiciels et laboratoires de recherches ont mit sur le marché des
outils se réclamant de cette architecture.
 Parmi ceux-ci le laboratoire de l’INRIA de Nantes a développé le langage
ATL (pour ATLAS Transformation Language) de transformation de modèles
dans le cadre de son Projet ATLAS.
 ATL est officiellement parti d’une tentative d’implémentation du QVT «
Request For Proposal » de l’OMG, en reprenant en particulier les diverses
façons déclaratives et impératives de spécifier une transformation.
 Il est développé sur la plateforme Eclipse et plus particulièrement sur sa
branche EMF (pour Eclipse Modeling Framework).
22
 Il est accompagné de nombreux outils pour faciliter son utilisation. La mise
en forme des mots clés du langage est assuré dans l’éditeur de code ATL,
un débogueur est fourni, et une notation textuelle simple appelée km3
(pour Kernel MetaModel) permet la spécification de métamodèles.

 Ce langage permet également l’écriture de simples requêtes sur des

modèles, comme le prévoit le volet Query de QVT.

 Il est évident que faire une transformation de modèle serait difficile sans la
capacité de lire (et donc d’effectuer des requêtes sur le modèle source). Ainsi
pour les transformations, ATL utilise intensivement le mode d’écriture et la
sémantique des mots clés de la norme OCL, aujourd’hui dans sa version 2.0.
 KERMETA
23
 Dans l’approche par programmation classique, on dit qu’un programme est
composé d’un ensemble de structures de données combinées à des
algorithmes.
 C’est sur la base de cette assertion que le langage de métamodélisation
KERMETA a été élaboré.
 Le langage KERMETA est une sorte de dénominateur commun des langages
qui coexistent actuellement dans le paysage de l’IDM. Ces langages sont
les langages de métadonnées (EMOF, ECORE,…), de transformation de
modèles (QVT, ATL,…), de contraintes et de requêtes (OCL), et d’action
(Action Semantics, Xion).
 Cette composition fait de KERMETA un véritable langage de
métamodélisation exécutable.
 KERMETA intervient à deux niveaux dans l’architecture de
métamodélisation de l’OMG.
 il intervient comme un langage de niveau M3 c’est-à-dire que tous les
métamodèles lui sont conformes,
 mais également comme une bibliothèque de base pour construire des
métamodèles de niveau M2.
  FUJABA

24 FUJABA, acronyme de «From UML to Java and Back Again», a pour but de fournir un environnement de
génération de code Java et de rétro-conception. Il utilise UML comme langage de modélisation visuel. Durant
la dernière décennie, l’environnement de FUJABA est devenu une base pour plusieurs activités de recherche
notamment dans le domaine des applications distribuées, ses systèmes de bases de données ainsi que dans
le domaine de la modélisation et de la simulation des systèmes mécaniques et électriques. Ainsi,
l’environnement de FUJABA est devenu un projet opensource qui intègre les mécanismes de l’IDM.

 OptimalJ

Optimal J est le fruit d’un travail au sein de la société «Compuware» qui utilise le langage TPL (Template Pattern
Language) comme langage de transformation. L’outil OptimalJ représente un exemple typique de l’approche
dite guidée par la structure qui est une approche de transformations de modèles à modèles. L’outil propose
l’ajout de patrons de transformations au processus métier (PIM). l’approche suivie est composée de deux
étapes.

- La première étape permet de créer la structure hiérarchique du modèle cible (PSM),

- Dans la seconde étape, les attributs et les références sont mis en place afin de compléter le modèle produit.
 Exemples de transformations de modèles dans un cycle logiciel

25