MDA en actionIngénierie logicielle guidée par

les modèles

Xavier Blanc

Université Pierre et Marie CurieXavier.Blanc@lip6.fr

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