MDA: Architecture dirigée par les modèles

Ingénierie logicielle guidée par les modèles

Dr. Amira BAILI

amira.baili@supcom.tn
 Définition MDA
MDA

 La complexité croissante des systèmes d'information a pour

conséquence de reconsidérer les techniques traditionnelles de

développement d'applications logicielles. L'Object Management

Group (OMG) propose une approche basée sur la modélisation des

architectures dirigées par les modèles.

 Définition MDA
MDA
Les modèles constituent le socle de l'architecture pilotée par les modèles ( Model Driven Architecture
MDA ). Dans le model driven engineering, un modèle est défini selon la sémantique d'un modèle de modèles
appelé métamodèle. Un modèle respectant la sémantique d'un métamodèle est dit "conforme" à
ce métamodèle.

Le modèle du réseau de Petri est composé de différents éléments : places, transitions et arcs.

Ils sont définis dans le métamodèle du réseau de Petri. De même, dans un modèle conforme à
un métamodèle, il existe une relation entre les éléments du modèle et ceux du métamodèle appelée "méta
relation", associant chaque élément du modèle instancié à un élément du métamodèle.

Mais un métamodèle est lui même un modèle qui doit être conforme à son propre métamodèle. Pour cela
le Model Driven Architecture MDA défini un 3ème niveau correspondant au métamétamodèle.

Un métamétamodèle a pour objectif de définir la sémantique nécessaire à la spécification du métamodèle qui

sera donc conforme à son métamétamodèle.

Pour éviter d'avoir un mécanisme sans fin ( métamétaméta... ), le métamétamodèle se défini lui même c'est à
dire qu'il peut être spécifié avec sa propre sémantique. Par conséquent un métamétamodèle est conforme à lui
même.
 Définition MDA
MDA

Plusieurs métamétamodèles sont disponibles.

Le langage ATL ( Atlas Transformation Language ) fourni 2 technologies :

Meta Object Facilities ( MOF 1.4 ) de l'Object Management Group OMG

Ecore metametamodel défini par Eclipse Modeling Framework (EMF).
Cela signifie que ATL peut gérer des métamodèles spécifiés avec la sémantique du MOF ou de Ecore.
Plan
 MDA: Model Driven Architecture
 Pérennité des savoir-faire
 Architecture de métamodélisation
 UML, OCL, AS
 XMI
 Gains de productivité
 JMI & EMF
 Transformation de modèles
 Outils
 Prise en compte des plates-formes d’exécution
 Profils de plate-forme
 Métamodèle de plate-forme
 Etude de Cas: PetStore
MDA:
Model Driven Architecture

Vue macroscopique
 Architecture MDA
Modèles
 « Modéliser est le futur, et je pense que les sociétés qui travaillent
dans ce domaine ont raison » B. Gates
 « Obtenir du code à partir d’un modèle stable est une capacité qui
s’inscrit dans la durée » R. Soley

 « A quoi bon modéliser puisque in fine il faudra toujours écrire du

code? »
 « Un bon schéma vaut mieux qu’un long discours … sauf qu’à un
schéma (UML) correspond plus d’un long discours ! »

Besoin de bonnes pratiques et d’objectifs précis

 Architecture MDA
Pratiques & Objectifs

Pratiques
 Décomposer en niveaux d’abstraction

 Automatiser les relations inter/intra niveaux

 Formaliser les informations contenues dans les

niveaux

Objectifs
 Élaboration de nouvelles applications

 Évolution d’applications existantes

 Maîtriser l’impact des nouvelles technologies

 Architecture MDA
Principes
Le principe de MDA est de séparer les spécifications
fonctionnelles des spécifications de l'implantation sur une
plate-forme donnée
=> interopérabilité des applications

L'idée centrale de MDA est d'élaborer des modèles,

d'abord d'analyse puis de conception, jusqu'au code, par
transformations, dérivations et enrichissements successifs

L'OMG propose le langage déclaratif (à base de règles)

"QVT" (Query/View/Transformation) pour exprimer les
transformations de ces modèles
 Architecture MDA
Principes
Lʼinitiative d'architecture dirigée par les modèles de
l'OMG "Model Driven Architecture" (MDA) est motivée par
le besoin de réduire les tâches de reconception des
applications (nécessitées, en autre, par lʼévolution
constante des technologies informatiques)

Puisque les modèles sont plus pérennes que les codes, ils permettent de :

! conserver les exigences métiers (échanges entre

analystes et donneurs d'ordre)

! réutiliser les choix dʼarchitecture et de codage (échanges entre analystes

et programmeurs)

! assurer lʼintégrité et la cohérence entre les phases du

projet (tests)
 Architecture MDA
Principes
MDA : Ensemble de techniques de modélisation et de transformation

Les principaux modèles sont :

! CIM (computation independant model) modèle

indépendant de calcul :décrit les flux et les
actions sur le système

!  PIM (plateform independant model) modèle

indépendant des plates-formes : décrit les
traitements orientés métier

! PDM (plateform dependant model) modèle des plates-formes

décrit une architecture technique (plusieurs par projet)

! PSM (plateform specific model) modèle dépendant des plates-formes :

décrit les détails techniques liés à l'implantation pour une plate-forme
 Architecture MDA
L’approche
Modèle d’exigences:
représente l’application
dans son environnement.

Modèle d’analyse et de
conception abstraite:
représente l’architecture
de l’application.

Modèle de code:
représente la construction
de l’application.

Code de l’application et
fichier de configuration.
 Architecture MDA
L’approche
Le CIM (Computation Independent Model)
Le CIM :
!  est le modèle d'analyse de base du métier ou du domaine dʼapplication

!  est indépendant de tout système informatique

!  décrit
les concepts de l'activité métier, le savoir faire les processus, la terminologie et les règles
de gestion (de haut niveau)

!  décrit la situation dans lequel le système est utilisé

!  n'est
modifié uniquement que si les connaissances ou les besoins métier changent (très longue
durée de vie)

Les exigences modélisées dans le CIM seront prise en compte dans les constructions des PIM
(Platform Independent Model) et des PSM (Platform Specific Model)
 Architecture MDA
L’approche
Le PIM (Platform Independent Model)

Le PIM :
!  est un modèle de conception

!  décrit le système indépendamment de toute plate-forme technique et de toute technologie

utilisée pour déployer lʼapplication

!  représente la logique métier spécifique au système (fonctionnement des entités et des

services)

!  est pérenne dans le temps

!  consiste en des diagrammes UML de classes (avec des contraintes en OCL)

Les différents niveaux de PIM précisent les choix de persistance, de gestion des transactions, de
sécurité…
 Architecture MDA
L’approche
Le PDM (Plate-forme Description Model)

Un PDM :

!  contient des informations pour la transformation des modèles vers une plateforme

!  est spécifique à une plateforme

!  est un modèle de transformation pour permettre le passage du PIM vers le PSM

 Architecture MDA
L’approche
Le PSM (Plate-forme Specific Model)

Un PSM :

!  sert à la génération du code exécutable pour les plates-formes techniques particulières

!  décrit comment le système utilisera la plate-forme

!  est dépendant de la plate-forme

Niveaux de PSM :
Le premier niveau, issu de la transformation dʼun PIM par l'adaptation des modèles UML aux
spécificités la plate-forme

Les autres niveaux PSM sont obtenus par transformations successives en prenant en compte
le langage (Java, C#, PHP...), les choix de conception...

Le dernier niveau, ou PSM dʼimplantation, décrit, en autres, le code du programme, les

schémas des tables, les bibliothèques utilisées, les descripteurs de déploiement...
 Architecture MDA
L’approche
La transformation des modèles MDA

L'approche MDA précise quatre types de transformations pendant le cycle de développement, les
modèles devenant de plus en plus concrets jusquʼà lʼobtention du code

Par transformations successives, le PIM, modèle de niveau le plus abstrait, est transformé en un
PSM exécutable (ou code exécutable)

Si la démarche MDA a été respectée, il est possible de générer un PSM, puis un PIM, à partir du
code exécutable
(rétro-ingénierie)
 Architecture MDA
L’approche
La transformation des modèles MDA

Transformation de PIM vers PIM, ou raffinement, consiste à

ajouter des informations (non liées à une plate-forme) sous forme
d'annotations

Transformation de PIM vers PSM consiste à ajouter au PIM des

informations propres à une plate-forme technique

Les plates-formes visées (J2EE, .NET...) sont décrites dans un

PDM
Les règles de transformation sont généralisées et capitalisées
pour un reutilisation future

Transformation de PSM vers PSM (raffinement), souvent nécessaire pour générer un code, se fait par l'utilisation de
formalismes intermédiaires comme SDL Specification and Description Language)

Transformation de PSM (ou du code) vers PIM, ou rétroingénierie (reverse engineering), indispensable pour
permettre lʼintégration dʼapplications existantes
 Architecture MDA
Architecture
MOF

M2 QVT M2

CIM PIM PSM Code

Application Informatique
 Architecture MDA
Les moyens
 Définition de tous les métamodèles de manière uniforme
 Le standard MOF définit le langage de définition des
métamodèles
 Format standard d’import et d’export des modèles
 Le standard XMI définit les moyens d’import et d’export de tous
les modèles selon le format XML
 Langage de manipulation des modèles
 Les frameworks JMI/EMF définissent les moyens de
représentation des modèles à l’aide de langages de
programmation objet.
 Langage dédié au transformation de modèles
 Le standard QVT définit le langage d’expression de
transformations de modèles
 Architecture MDA
Les résultats
 Pérennité des savoir-faire
 L’ambition du MDA est de faire en sorte que les modèles (CIM,
PIM) aient une durée de vie supérieure au code.
 L’objectif est donc de fournir des langages de modélisation
supportant différents niveaux d’abstraction.
 Gains de productivité
 MDA vise à apporter des gains de productivité en automatisant
les opérations sur les modèles.
 L’objectif est donc de faciliter la création d’opérations de
production sur les modèles (du contemplatif au productif)
 Prise en compte des plates-formes d’exécution
 MDA veut rendre explicite la prise en compte des plates-formes
d’exécution dans le cycle de vie des applications.
 L’objectif est donc de construire des langages permettant de
modéliser les plates-formes et de lier ces modèles aux modèles
des applications.
 Architecture MDA
Les 3 axes du MDA
pérennité
Pour mettre en œuvre le
UML2.0 QVT MDA il faut fixer ses
MOF2.0 priorités selon ces trois
XMI2.1
axes
Profil QoS GenDoc
• Il est actuellement trop tôt pour
UML1.4 utiliser UML2.0 et être productif.
MOF1.4 EMF
Profil EJB JMI • Il est actuellement trop tôt pour
pouvoir dire que EMF est
Profil Corba
pérenne.
productivité
• Il est actuellement trop tôt pour
UML->Java pouvoir expliciter la plate-forme
UML/EJB->J2EE sous forme de modèle.

Plate-forme
Pérennité des savoir-faire

Architecture et Standard
 Pérennité
Métamodèle
Système
+nom
Un métamodèle est
essentiellement la définition d’un
1
ensemble de concepts et de leurs * * *
relations à l’aide d’un diagramme +hérite 0..*
Acteur +participe Cas d'Utilisation
de classes. +nom +intitulé
*
0..1 +étend
*
Un métamodèle ne définit que la
structure et pas la sémantique. * +inclut

Un modèle est une instance d’un

métamodèle s’il respecte la
structuration définie par le PetStore
métamodèle.
Commander Article
Le métamodèle UML définit les
concepts UML et leurs relations.
Client Valider Panier
Un modèle UML doit respecter la
définition du métamodèle.
 Pérennité
Métamétamodèle

 Le MOF définit le langage

Attribut

permettant de définir des +nom

+multiplicité
1

métamodèles *

 Les concepts du MOF sont Parameter

+direction +type Type

les concepts de *
1
*

métaclasse, méta-attribut, -nom

Operation

méta-association, etc. 1
1

Package * Class DataType

 MOF peut être défini à +import

+nom
1 *
+nom
0..1

* +super
l’aide d’un diagramme de * 1 -type * 1

classe. Ce diagramme est

String Integer Boolean

le métamétamodèle
*
*

AssociationEnd
Association
+nom

 Le métamétamodèle s’auto- +nom

1 2
+multiplicité

définit.
 Pérennité
Niveaux Méta

 Les relations entre les MOF

Métamétamodèle
niveaux méta sont des
relations de définition de
structure UML
UML
UML
 Les relations entre les
Métamodèle
niveaux méta ne sont pas
des relations d’abstraction.
 Les relations entre les Modèle
Modèle
Modèle Modèle
niveaux méta sont
semblables aux relations
entre les grammaires (BNF,
ou XML Schema)
 Pérennité
Infrastructure 2.0

 UML définit les concepts

nécessaires à l’expression
des diagrammes de classe MOF
 MOF définit les concepts
nécessaires à l’expression
des diagrammes de classe Infra

=> Capitaliser sur les concepts UML

nécessaires à l’expression
des diagrammes de classe :
Infrastructure
L’infrastructure n’a
pas de niveau fixe.
Cela dépend de qui
l’utilise.
 Pérennité
UML2.0
 UML2.0 fait rentrer UML dans MDA, il est bien plus qu’une
évolution de UML1.4.
 UML est actuellement le métamodèle le plus important de
l’approche MDA. Sa conception est le fruit de plus de 3 ans de
travail collaboratif des meilleurs experts du domaine.
 C’est le métamodèle qui définit la structuration des modèles des
applications informatiques
 UML2.0 est un métamodèle instance de MOF2.0.
 La sémantique de UML2.0 est définie à l’aide de langage naturel
 Les diagrammes UML2.0 sont définis à partir du métamodèle
 UML2.0 supporte différents niveaux d’abstractions et différents
points de vue
 Cas d’utilisation, Séquences, Structuration Interne, Etats,
Déploiement, etc.
 Pérennité
Composant UML2.0
UML2.0 permet la modélisation intégrale
d’applications à base de composants.
De l’analyse/conception au déploiement
 Pérennité
UML dans MDA
 UML permet principalement de construire des modèles
d’applications informatiques indépendants des plates-formes
d’exécution (phase d’analyse et de conception abstraite)
 UML est donc le métamodèle naturel pour les PIM (Platform
Independant Model)
 UML permet aussi de représenter une application dans son
environnement afin d’en faire ressortir les exigences (cas
d’utilisation)
 UML peut être utilisé pour les CIM (Computational Independant
Model)
 UML peut être profilé afin de cibler des plates-formes d’exécution
(ex: profil pour CORBA, profil pour EJB)
 UML peut être utilisé pour les PSM (Platform Specific Model)

Il serait donc possible d’appliquer MDA en utilisant uniquement UML

 Pérennité
Object Constraint Language
 OCL définit la structuration des
modèles représentant des
contraintes sur les applications
informatiques
 Invariant, Pré-post conditions
 OCL est un métamodèle
instance de MOF
 OCL est fortement couplé au
métamodèle UML
 OCL définit sa sémantique à
l’aide d’un métamodèle
(opération sans effet de bord)
 OCL définit une syntaxe PropertyCallExp
>
concrète permettant de
facilement saisir les
contraintes ModelPropertyCall
solde
Literal
-1000
 Pérennité
Action Semantics

 AS définit la structuration CreateObjectAction WriteStructuralAction CallOperationAction

des modèles représentant

des séquences Pin

d’instructions
 AS est un métamodèle qui
a été totalement intégré à 10
100
UML2.0
 AS n’a pas de syntaxe cb

concrète propre (utilisation

des diagrammes
dynamiques UML) CompteBancaire
+solde
 La sémantique d’AS n’est +debit()

pas formellement définie

(RFP en cours)
 Pérennité
XMI
Fonctionnement
 Le standard XMI (XML Metadata Interchange) permet le passage des
modèles aux documents XML
 Il définit des règles permettant de construire des schéma XML à partir
de métamodèle
 Ainsi il est possible d’encoder un modèle dans un document XML

XMI et UML
 XMI se décline en 6 versions et UML se décline en 4 versions
 Cela explique pourquoi l’échange de modèle UML en XMI pose quelques
problèmes

XMI et diagrammes
 DI (Diagram Interchange) est une extension à XMI et UML qui permet
la représentation des diagrammes UML sous forme de document XML.
 Pérennité
Synthèse sur la pérennité
 MOF permet de décrire les métamodèles uniformément
 Permet la définitions de structuration et leur standardisation (ex:
réseaux de Petri)
 Le métamodèle UML est le métamodèle le plus abouti pour
élaborer des modèles d’applications informatiques
 Les modèles UML sont de très bons PIM (complets et
indépendants des plates-formes).
 OCL et AS sont les métamodèles permettant la définition précise
de comportements
 Ils permettent la construction de modèles UML très précis.
 XMI permet l’échange de n’importe quel modèle sous forme de
document XML
 Les modèles MDA ont tous une représentation concrète standard
Gains de productivité

Framework et outils
 Production
API de manipulation

 MDA définit les principes de génération d’API de manipulation de

modèles
 A chaque métamodèle correspond une API de manipulation des
modèles instances
 Les frameworks définissent aussi des API réflectives pour tout
métamodèle

Métamodèle Interface Java

Objets Java
modèles
 Production
Eclipse Modeling Framework

 Élaboration d’un
métamodèle (instance
de Ecore)
 Génération de l’API
 Interface de manipulation
 Classes dans
l’environnement Eclipse
 Classes d’éditeur
graphique
 Utilisation directe dans
un nouveau
environnement Eclipse
 Production
Transformation de modèles
 Les transformations de modèles sont le cœur des aspects de
production de MDA
 CIM vers PIM, PIM vers PSM, PSM vers code (sens inverse).
 Les transformations de modèles sont basées sur les
métamodèles
 Tout composant UML se transforme en une classe PHP.
 Les constructeurs de plate-forme devraient produire les
transformateurs permettant d’exploiter les plates-formes
 UML vers EJB
 Les sociétés devraient pouvoir adapter les transformateurs selon
leurs propres expériences et leurs propres besoins
 Ex: ne pas utiliser de composant EJB Entity!
 Actuellement les transformations de modèles peuvent s’écrire
selon trois approches
 Programmation, Template, Modélisation
 Production
Programmation

 La transformation est un programme qui

utilise les API de manipulation des modèles

UML API API PHP

UML PHP

lire écrire

PetStore Programme PetStore

Java PHP
 Production
Template

 La transformation est un template écrit dans

un langage dédié

UML PHP
Template
pour UML
vers PHP

PetStore Interpréteur PetStore

de template PHP
 Production
Modélisation

 La transformation est un modèle instance du

métamodèle QVT

UML QVT PHP

Modèle
Transfo

PetStore Programme PetStore

PHP
 Production
Outils industriels

 Actuellement plusieurs outils clament leur

adhérence à MDA.
 Au déla de savoir ce qu’est un outil MDA, il est
intéressant de voir que les fournisseurs d’outils sont
très actifs sur ce domaine.
 Nous avons particulièrement pu apprécier deux
outils:
 RSA (Rational Software Architecte) qui supporte MDA en
offrant un modeleur UML2.0 et en permettant la définition
de transformations de modèles (approche par
programmation).
 Objecteering/MDA Modeler qui supporte MDA en offrant
des avantages considérables pour le développement et le
packaging d’opérations de production sur les modèles.
 Production
Synthèse sur la productivité

 MDA fait passer les modèles du contemplatif

au productif
 Les API de manipulation de modèles sont
totalement utilisables en contexte industriel
 Les transformations de modèles sont
réalisables même si actuellement seule
l’approche par programmation est pleinement
exploitable.
 Il est important de souligner l’engagement
des éditeurs d’outils
Prise en compte des plates-
formes d’exécution

Framework et outils
 Plate-forme
Cycle en Y et plate-forme
PIM PM
Besoins
Exigence Techniques
PIM

Analyse
PM Architecture
PIM Technique
Conception
(Abstraite) Explicitation de la
plate-forme
Conception PSM
(concrète)
Prise en compte
Conception PSM
de la plate-forme
(fine)

Code
 Plate-forme
Profil ou métamodèle
 Il n’existe pas de métamodèle permettant de modéliser les plates-
formes
 Un métamodèle de plate-forme définit plutôt la structure de modèles
d’applications utilisant les fonctionnalités de la plate-forme
 On appelle donc ces métamodèles des métamodèles de PSM
 par exemple le métamodèle EJB définit la structure de modèles
d’applications utilisant les fonctionnalités de la plate-forme EJB

 La transformation cœur de l’approche en Y est donc une transformation

entre deux métamodèles (métamodèle du PIM vers métamodèle du
PSM)
 D’où la nécessité de paramétrer le modèle PIM afin de préciser la façon
dont utiliser la plate-forme (notion de modèle intermédiaire).
 Comment savoir si un composant UML doit se transformer en un bean Entity
ou Session?
 Plate-forme
Métamodèle de PSM
 Approche par profil
 Le métamodèle de PSM est un profil UML
 La plate-forme doit donc être proche de UML (orientée objet)
 Les transformations PIM vers PSM sont facilitées car il existe une
sémantique commune (UML)

 Approche par métamodèle

 Le métamodèle de PSM est un métamodèle MOF
 La plate-forme peut donc être très éloignée de UML
 Les transformations PIM vers PSM sont moins facilitées car les
sémantiques PIM et PSM ne sont pas communes
 Cette approche rend possible les transformations PSM vers PSM
(migration de plates-formes)
Étude de Cas

PetStore
 Étude de Cas
PetStore selon MDA

Intervention Humaine CIM & PIM

en UML
Modèle de
transformation PIM
vers PSM

PSM Java
Profil UML
PSM PHP
Méta-modèle
PIM vers PSM Java
avec MDA Modeler
PIM vers PSM PHP
avec RSA
public class { php {
} }
 Étude de Cas
Pérennité

 L’application PetStore a pu être modélisée

entièrement en UML2.0
 Use Case de l’application
 Composants de l’application
 Contrainte OCL sur les opérations (notamment les
opérations de recherche)
 AS pour le comportement (notamment grâce aux nouveaux
diagrammes de séquences)
 Modèle entièrement indépendant des plates-formes
d’exécution
 Modèle échangeable(?) grâce à XMI
 Étude de Cas
Productivité

 Le modèle UML de l’application PetStore a

pu être manipulé automatiquement pour
générer du code et de la documentation
 RSA: Manipulation Java avec assistants
 MDA Modeler: Manipulation J avec assistants
 Malheureusement, il n’est pas encore
possible de pouvoir capitaliser les opérations
de production
 Étude de Cas
Plate-forme

 Réalisation de PetStore sur J2EE/EJB

 Définition du profil EJB
 Construction des transformations avec MDA Modeler
 Définition d’un profil de modèles intermédiaires permettant
de préciser les choix de transformation
 Réalisation de PetStore sur PHP
 Définition d’un métamodèle PHP
 Construction de générateur de code et de transformation
de modèles avec RSA
 Définition d’un profil de modèles intermédiaires permettant
de préciser les choix de transformation
Conclusion
MDA en action
 MDA entre dans une phase
d’industrialisation
 La pérennité est aujourd’hui
totalement atteinte grâce
aux standards MOF, UML,
OCL, AS et XMI
 La productivité des modèles
est une réalité. Les progrès
annoncés laissent entrevoir
un essor considérable
(MOF2.0 QVT)
 La prise en compte des
plates-formes reste encore
trop à la charge de celui qui
met en place l’approche
MDA