1. Présenter par:
Comparaison de outils MDA
Proposée par:
Dr.Maddah Mohamed
Melle:Zaghdou
d Mounira
Mr:Shili
Mohammed
République tunisienne
ministère de l’enseignement
Supérieur et de la recherche
Scientifique université
De sousse
INSTITUT SUPÉRIEUR DES
SCIENCES
APPLIQUÉES ET DE
TECHNOLOGIE
DE SOUSSE
3. Introduction
Dans le domaine du génie logiciel, l’apparition de l’Ingénierie
Dirigée par les modèles (IDM) propose une démarche dont les
deux originalités sont d’une part la formulation des modèles, et
d’autre part des programmes de transformation de modèles.
Ces outils de transformation se diffèrent
3
4. ATL: Atlas transformation Language
ATL est un langage de transformation de modèles dans le
domaine de l’IDM (Ingénierie Dirigée par les Modèles) ou
MDE (Model-Driven Engineering). Il fournit aux
développeurs un moyen de spécifier la manière de produire
un certain nombre de modèles cibles à partir de modèles
sources.
Le modèle de transformation doit être conforme au méta-
modèle qui définit la sémantique de transformation de modèles
(ATL).
Tous les méta-modèles doivent être conformes au méta-méta-
modèle considérée (Ecore).
4
6. Les règles d’ ATL
Les règles :Le langage ATL est un langage hybride :
Les règles standards (Matched rules) : Ils constituent le noyau de la
transformation déclarative
Les règles paresseuses (lazy rule): Elles ressemblent aux règles
standards, à la différence qu’elles ne sont déclenchées que par d'autres
règles.
Les règles paresseuses uniques (unique lazy rule): Identiques aux règles
paresseuses non uniques, à la différence qu elles sont appliquées une unique‟
fois pour chaque tuple.
Les règles appelées (called rules) : Ils fournissent le style de programmation
impératif.
6
7. Contrôle des transformationsles transformations ATL ne sont pas interactives
plusieurs approches :
•utilisation de «méta-informations» dans le modèle source,
•isolation des choix dans un modèle séparé
•(utilisé conjointement au modèle source),
•transformation de transformation,
•enchainement de transformations,
orientation des transformations :
•utilisation de called rules (dangereux dans un contexte d
´eclaratif),
•utilisation des conditions d’application des matched rules.
7
9. QVT:Query,Views ,Transformation
Query/Views and Tranformations :
est une spécification en cours d’approbation pour standardiser un
langage de définition de transformations de modèles et de
spécifications des vues et requêtes sur les modèles basés sur
MOF.
Requête:
sur les modèles MOF
oblige à filtrer et sélectionner les éléments à partir d'un modèle
Filtrer et sélectionner des éléments d’un modèle
Vues
est un modèle qui est dérivé d'un autre modèle.
Un mécanisme pour créer des vues
Transformation:
Normaliser les règles de transformation 9
11. Les niveaux de QVT
• QVT-Relation : langage déclaratif (Prolog)
• QVT-Core : la sémantique des concepts déclaratifs (Pascal, C)
• QVT-Operational : langage hybride
11
12. QVT modeltype
• Déclare un type de métamodèle
• Permet de spécifier l’URI du métamodèle
exemple: on défini que mjavaMMcorrespond à http:///mjava.ecore
(Déclaré avant la signature) :
12
13. QVT main
Défini le point d’entré de la transformation
La seule méthode qui est exécutée quand la transformation est lancée
contient un ensemble d’expression
13
14. QVT mapping
• mapping== règle de transformation
• Définit un mapping entre [1..*] éléments sources et [1..*]
éléments cible
• Eléments source et cible définit par la signature de l’opération
• Appel de l’opération : a.map AtoB();
14
16. Kermeta :kernel de transformation
-Un langage pour construire et spécifier des métamodèles
-Un environnement pour toutes les étapes de développement basées sur
l'utilisation de métamodèles:
-De la production des MM jusqu'à leur exploitation
-Intégration et/ou interopérabilité avec les autres outils du domaine
-Adapté pour construire des DSL (Domain Specific Language)
(Ingénierie des langages)
Approche OO permettant de simplifier les tâches des développeurs de
DSL grâce à des mécanismes dédiés:
-Manipulation intuitive des éléments de modèle
-Tissage, patron de conception,
-Clôtures lexicales,
-Type modèle, généricité, …
16
17. Cas d'utilisation
-Pour définir la structure, le comportement et les contraintes d'un
métamodèle (compatible avec EMOF et Ecore),
-Pour vérifier des modèles
-Pour animer/simuler des modèles
-Pour manipuler/transformer/tisser des modèles
17
20. Conclusion
Le programme de transformation de modèles peut être utilisé pour la
réutilisation de modèles ou fournir des modèles en fonction des besoins de
l’utilisateur.
Il permet aussi de comparer de modèles dans un même domaine.
La transformation a des avantages comme suivants :
- Permettre de diminuer le temps de développement des transformations,
- Réduire les éventuelles erreurs pouvant se produire dans le codage manuel
- Améliorer la qualité du code final de la transformation
20
Deux langages déclaratifs : le langage de relations (Relations) et le langage noyau (Core), doivent permettre d’opérer des filtrages sur les éléments des modèles.Deux langages procéduraux : un langage d’opérations de filtrage (Operational Mappings) et un langage d’implémentations opaque d’opérations (Black Box), doivent donner accès aux relations et éventuellement aux opérations des modèles traités.
--------------------------------------------------------------------------------------------------------------------------------------
La dernière version du standard QVT [OMG-QVT, 2008] présente un caractère hybride dans
le sens qu’elle est composée de trois langages de transformation différents (voir Figure II.8). La partie
déclarative de QVT est définie par les langages Relations et Core qui ont des niveaux d’abstraction
différents. Relations est un langage orienté utilisateur permettant de définir des transformations à un
niveau d’abstraction élevé. Il a une syntaxe textuelle et graphique. Le langage Core forme
l’infrastructure de base pour la partie déclarative ; c’est un langage technique de bas niveau défini par
une syntaxe textuelle. Il sert à spécifier la sémantique d’exécution du langage Relations, sous la forme
d’une transformation Relations2Core. La vision déclarative passe par une association de patterns, côté
source et cible pour exprimer la transformation. Manifestement, elle permet une expression plus
simple des transformations de type mappings (transformation unidirectionnelle).
La composante impérative de QVT est supportée par le langage Operational Mappings. La vision
impérative impose une navigation explicite et une création explicite des éléments du modèle cible. Le
langage Operational Mappings propose un premier mécanisme d’extension des deux langages déclaratifs de
QVT (Relations, Core) en ajoutant des constructions impératives (séquence, sélection, répétition, etc.)
ainsi que des constructions OCL à effet de bord. Les langages de style impératif sont mieux adaptés
pour des transformations complexes qui comprennent une composante algorithmique importante.
Par rapport au style déclaratif, ils ont l’avantage de gérer les cas optionnels dans une transformation.
Enfin, QVT propose un deuxième mécanisme d’extension pour spécifier des transformations, en
permettant d’invoquer des fonctionnalités de transformations implémentées dans un langage externe,
appelé « Black Box »