mda en action ingénierie logicielle guidée par les modèles xavier blanc université pierre et...
TRANSCRIPT
MDA en actionIngénierie logicielle guidée par
les modèles
Xavier Blanc
Université Pierre et Marie [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
ArchitectureVue macroscopique
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
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
CIM PIM PSM Code
Application Informatique
MOF
M2 QVT M2
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 Architecture MDA
pérennité
productivité
Plate-forme
XMI2.1
JMI
UML2.0
Profil EJB
QVT
UML->Java
MOF2.0
EMFUML1.4
MOF1.4
Profil Corba
Profil QoS GenDoc
UML/EJB->J2EE
Pour mettre en œuvre le MDA il faut fixer ses priorités selon ces trois axes
• Il est actuellement trop tôt pour 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é
+intitulé
Cas d'Utilisation
+nom
Acteur
+nom
Système
1
*
+participe
*
*
+hérite
0..1
+inclut*
*
*
+étend
0..*
Client
Commander Article
PetStore
Valider Panier
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.
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.
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.
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’auto-définit.
+nom
Class
+nom
Package
+nom+multiplicité
Attribut
Type
1 *
1
*
*
+import
*
*
+super
0..1
1
+type
*
DataType
String Integer Boolean
+nom
Association+nom+multiplicité
AssociationEnd
1 2
1
* *
-type 1
-nom
Operation
+direction
Parameter
1*
1*
Pérennité
Niveaux Méta Pérennité
MOF
UML
ModèleModèleModèle
Métamétamodèle
UMLUMLMétamodèle
Modèle
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)
Infrastructure 2.0 Pérennité
MOF
Infra
UML
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
L’infrastructure n’a pas de niveau fixe. Cela dépend de qui l’utilise.
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
Interface
Class
Component Realization
Classifier
+/provided
*
+/required* *
+abstraction
1
+realization
*
+realizingClassifier1
Port
StructuredClassifier
EncapsulatedClassifier Interface
ConnectableElement StructuralFeature
0..1
+ownedPort
**
+/required
*
* +/provided *
Classifer
StructuredClassifier
NamedElement
ConnectableElement
Property
Connector
0..1
+/part *0..1
+ownedConnector
*
*
+/node
*
0..1
+ownedAttributs
*
Pérennité
:Order
:Product
:Service
:ShopingCart
:BackOrder
:Organization
:Customer
UML2.0 permet la modélisation intégrale d’applications à base de composants. De l’analyse/conception au déploiement
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 concrète permettant de facilement saisir les contraintes
Pérennité
Class
+solde
CompteBancaire{context CompteBancaire inv: solde > -1000}
Constraint
Expression
ExpressionInOcl OclExpression
ModelElement
* * 1*
**
PropertyCallExp
>
Literal
-1000ModelPropertyCall
solde
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é
CreateObjectAction WriteStructuralAction
Pin
CallOperationAction
+debit()
+solde
CompteBancaire
cb
100 10
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
Pérennité
Gains de productivité
Framework et outils
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
Production
Métamodèle
modèles
Interface Java
Objets Java
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
Production
PetStore PetStorePHP
UML PHPAPIUML
APIPHP
ProgrammeJava
lire écrire
Template
La transformation est un template écrit dans un langage dédié
Production
PetStore PetStorePHP
UML PHP
Interpréteurde template
Template pour UML vers PHP
Modélisation Production
PetStore PetStorePHP
UML PHP
Programme
Modèle Transfo
QVT
La transformation est un modèle instance du métamodèle QVT
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
Production
Prise en compte des plates-formes d’exécution
Framework et outils
Cycle en Y et plate-formePlate-forme
PIM
PIM
PIM
PSM
PSM
Code
Exigence
Analyse
Conception (Abstraite)
Conception (concrète)
Conception (fine)
PM Besoins Techniques
Architecture Technique
PM
Prise en compte de la plate-forme
Explicitation de la 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)
Plate-forme
Étude de Cas
PetStore
PetStore selon MDA Étude de Cas
CIM & PIM en UML
PSM JavaProfil UML
PSM PHP Méta-modèle
public class {}
php {}
Modèle de transformation PIM vers PSM
Intervention Humaine
PIM vers PSM Java avec MDA Modeler
PIM vers PSM PHP avec RSA
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
Étude de Cas
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