Transcript MDA en action - Master informatique

MDA en action
Ingénierie logicielle guidée par les modèles
Xavier Blanc
Université Pierre et Marie Curie
[email protected]
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
Modèles




Architecture MDA
« 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
Pratiques & Objectifs
Architecture MDA
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
L’approche
Architecture MDA
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
Architecture MDA
MOF
M2
CIM
QVT
PIM
M2
PSM
Application Informatique
Code
Les moyens




Architecture MDA
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
Les résultats



Architecture MDA
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.
Les 3 axes du MDA
Architecture MDA
pérennité
Pour mettre en œuvre le
MDA il faut fixer ses
priorités selon ces trois
axes
UML2.0 QVT
MOF2.0
XMI2.1
Profil QoS
Profil EJB
Profil Corba
GenDoc
UML1.4
MOF1.4
• Il est actuellement trop tôt pour
EMF
JMI
productivité
UML->Java
UML/EJB->J2EE
Plate-forme
utiliser UML2.0 et être productif.
• Il est actuellement trop tôt pour
pouvoir dire que EMF est
pérenne.
• Il est actuellement trop tôt pour
pouvoir expliciter la plate-forme
sous forme de modèle.
Pérennité des savoir-faire
Architecture et Standard
Métamodèle
Pérennité
Système
Un métamodèle est
essentiellement la définition d’un
ensemble de concepts et de leurs
relations à l’aide d’un diagramme
de classes.
+nom
1
*
*
*
+hérite
0..*
Acteur
0..1
+participe
+nom
Cas d'Utilisation
*
+étend
+intitulé
*
Un métamodèle ne définit que la
structure et pas la sémantique.
*
Un modèle est une instance d’un
métamodèle s’il respecte la
structuration définie par le
métamodèle.
+inclut
PetStore
Commander Article
Le métamodèle UML définit les
concepts UML et leurs relations.
Un modèle UML doit respecter la
définition du métamodèle.
Client
Valider Panier
Métamétamodèle




Le MOF définit le langage
permettant de définir des
métamodèles
Les concepts du MOF sont
les concepts de
métaclasse, méta-attribut,
méta-association, etc.
MOF peut être défini à
l’aide d’un diagramme de
classe. Ce diagramme est
le métamétamodèle
Le métamétamodèle s’autodéfinit.
Pérennité
Attribut
+nom
+multiplicité
1
*
Parameter
+type
+direction
Type
*
*1
Operation
-nom
1
1
*
Package
+import
Class
+nom
1
DataType
0..1
+nom
*
*
+super
*
-type
1
* 1
String
*
*
AssociationEnd
Association
+nom
+multiplicité
+nom
1
2
Integer
Boolean
Niveaux Méta



Les relations entre les
niveaux méta sont des
relations de définition de
structure
Les relations entre les
niveaux méta ne sont pas
des relations d’abstraction.
Les relations entre les
niveaux méta sont
semblables aux relations
entre les grammaires (BNF,
ou XML Schema)
Pérennité
MOF
Métamétamodèle
UML
UML
UML
Métamodèle
Modèle
Modèle
Modèle
Modèle
Infrastructure 2.0


UML définit les concepts
nécessaires à l’expression
des diagrammes de classe
MOF définit les concepts
nécessaires à l’expression
des diagrammes de classe
=> Capitaliser sur les concepts
nécessaires à l’expression
des diagrammes de classe :
Infrastructure
Pérennité
MOF
Infra
UML
L’infrastructure n’a
pas de niveau fixe.
Cela dépend de qui
l’utilise.
UML2.0




Pérennité
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.
Composant UML2.0
UML2.0 permet la modélisation intégrale
d’applications à base de composants.
De l’analyse/conception au déploiement
Class
Interface
+/provided
+abstraction
Component
*
*
+realization
1
+/required
Pérennité
Realization
*
*
Classifer
1
NamedElement
+realizingClassifier
Classifier
+/node
:BackOrder
ConnectableElement
*
*
StructuredClassifier
+ownedAttributs
Property
0..1
0..1
*
0..1
:ShopingCart
+/part
+ownedConnector
:Order
:Customer
*
Connector
*
ConnectableElement
StructuralFeature
:Service
StructuredClassifier
:Product
+/required
+ownedPort
EncapsulatedClassifier
Port
Interface
*
0..1
*
*
*
:Organization
+/provided
*
UML dans MDA



Pérennité
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
Object Constraint Language

OCL définit la structuration des
modèles représentant des
contraintes sur les applications
informatiques





ModelElement
Pérennité
Constraint
*
*
1
*
Expression
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
concrète permettant de
facilement saisir les
contraintes
Class
ExpressionInOcl
OclExpression
* *
CompteBancaire
+solde
{context CompteBancaire
inv: solde > -1000
}
PropertyCallExp
>
ModelPropertyCall
Literal
solde
-1000
Action Semantics




AS définit la structuration
des modèles représentant
des séquences
d’instructions
AS est un métamodèle qui
a été totalement intégré à
UML2.0
AS n’a pas de syntaxe
concrète propre (utilisation
des diagrammes
dynamiques UML)
La sémantique d’AS n’est
pas formellement définie
(RFP en cours)
Pérennité
WriteStructuralAction
CreateObjectAction
Pin
10
100
cb
CompteBancaire
+solde
+debit()
CallOperationAction
XMI
Pérennité
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.
Synthèse sur la pérennité




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
API de manipulation



Production
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
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





Production
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
Programmation

Production
La transformation est un programme qui
utilise les API de manipulation des modèles
UML
API
UML
API
PHP
lire
PetStore
PHP
écrire
Programme
Java
PetStore
PHP
Template

Production
La transformation est un template écrit dans
un langage dédié
UML
PHP
Template
pour UML
vers PHP
PetStore
Interpréteur
de template
PetStore
PHP
Modélisation

Production
La transformation est un modèle instance du
métamodèle QVT
UML
QVT
PHP
Modèle
Transfo
PetStore
Programme
PetStore
PHP
Outils industriels



Production
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.
Synthèse sur la productivité




Production
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 platesformes d’exécution
Framework et outils
Cycle en Y et plate-forme
PIM
PM
Exigence
Plate-forme
Besoins
Techniques
PIM
Analyse
PM
Conception
(Abstraite)
Conception
(concrète)
Conception
(fine)
PIM
Architecture
Technique
Explicitation de la
plate-forme
PSM
PSM
Code
Prise en compte
de la plate-forme
Profil ou métamodèle



Il n’existe pas de métamodèle permettant de modéliser les platesformes
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



Plate-forme
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?
Métamodèle de PSM
Plate-forme

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
PetStore selon MDA
Intervention Humaine
Étude de Cas
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 {
}
Pérennité

L’application PetStore a pu être modélisée
entièrement en UML2.0






Étude de Cas
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
Productivité

Le modèle UML de l’application PetStore a
pu être manipulé automatiquement pour
générer du code et de la documentation



Étude de Cas
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
Plate-forme

Réalisation de PetStore sur J2EE/EJB




Étude de Cas
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