Vous êtes sur la page 1sur 45

CONSERVATOIRE NATIONAL DES ARTS ET MTIERS

CENTRE RGIONAL ASSOCI DE NANTES

___________

MMOIRE

prsent en vue d'obtenir

l'EXAMEN PROBATOIRE

en INFORMATIQUE

par

Jacques BARZIC

___________

Sujet

Model Driven Architecture (MDA)

Soutenu le 2 fvrier 2007

JURY
Prsidente : lisabeth METAIS, professeur au CNAM Paris

Responsable du cycle : Henry BRIAND, professeur l'EPUN

metteur du sujet : Claude BELLEIL, professeur l'Universit de Nantes

Note : cette version du mmoire est celle que j'ai livre au CNAM et
qui a servi mon valuation de probatoire (note : 14/20). Chacun doit
l'utiliser avec l'esprit critique ncessaire et indispensable.
Si votre seul outil est un marteau, tous les
problmes, pour vous, ressembleront des clous.
Mark Twain.

Le modle est essentiel l'acquisition d'une


comptence professionnelle, mais il peut aussi
emprisonner celui qui le suit la lettre
[LESCARBEAU et al. 2003]
Probatoire informatique : Model Driven Architecture (MDA) 3

Le sujet
Sujet propos par Claude Belleil
claude.belleil@univ-nantes.fr
Universit de Nantes

Model Driven Architecture

Le Model Driven Architecture (MDA) est une dmarche de dveloppement propose par lOMG. Elle
permet de sparer les spcifications fonctionnelles dun systme des spcifications de son
implmentation sur une plate-forme donne. A cette fin, le MDA dfinit une architecture de
spcifications structure en modles indpendants des plates-formes (PIM) et en modles spcifiques
(PSM).
Lapproche MDA permet de raliser le mme modle sur plusieurs plates-formes grce des projections
standardises. Elle permet aux applications dinteroprer en reliant leurs modles et supporte lvolution
des plates-formes et des techniques. La mise en uvre du MDA est entirement base sur les modles et
leurs transformations.
LOMG voulait faire de CORBA LE middleware, mais aujourdhui, il est loin dtre le seul tre
utilis.
Dautres comme EJB ou .NET sont largement rpandus. Cest en partant de cette observation que lOMG
sest engag sur la voie du MDA, afin de rsoudre les problmes dinteroprabilit et de portabilit ds le
niveau modlisation. Le MDA se veut donc indpendant de toute plate-forme et de tout systme, il
permet de concevoir des applications portables au niveau des langages de programmation, des systmes
dexploitation mais aussi des middlewares. Cette indpendance totale doit permettre de changer
dinfrastructure sans perdre ce qui a dj t conu. Cette approche permet ainsi de capitaliser le travail
effectu pendant les phases danalyse et de conception.

Le logo du MDA (ci-dessus) reprsente les diffrentes couches de spcification. Au cur se trouvent les
techniques (UML, MOF, CWM), autour, quelques-unes des plates-formes supportes, en surface les
services systmes et enfin lextrieur les domaines pour lesquels des composants mtiers doivent tre
dfinis (Domain Facilities). Ces services (aussi bien systmes que mtiers) doivent tre disponibles ds
les premires phases de modlisation, cest pourquoi ils doivent faire partie des spcifications du MDA.

Lauditeur sattachera prsenter les principales fonctionnalits de cette mthode en illustrant son
propos par des exemples originaux.

http://www.omg.org/mda/

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 4

Table des matires


Le sujet............................................................................................................................ 3
Index des illustrations................................................................................................... 6
Liste des abrviations................................................................................................... 7
Avertissement................................................................................................................. 8
Introduction.................................................................................................................... 9
1re Partie : mta-mta-modle, mta-modle, modle, systme, transformation ?
IDM, au secours ! !....................................................................................................... 11
1. Gnralits propos de l'IDM........................................................................................... 11
2. Les concepts socles de l'IDM..............................................................................................11
2.1. Le systme..................................................................................................................... 11
2.2. Le langage......................................................................................................................12
2.3. Le modle...................................................................................................................... 13
2.4. Le mta-modle............................................................................................................. 14
2.5. Le mta-mta-modle.................................................................................................... 14
2.6. La transformation.......................................................................................................... 15
3. Conclusion............................................................................................................................16
2me Partie : Model Driven Architecture, approche pour les architectes
fabricateurs ?............................................................................................................... 17
1. Introduction......................................................................................................................... 17
2. Le schma gnral de MDA................................................................................................18
3. Point de vue de l'utilisateur Computation Independent Model (CIM).......................19
3.1. Objectif.......................................................................................................................... 19
3.2. Illustration : le Portillon ...........................................................................................20
4. Point de vue de l'analyste - Platform Independent Model (PIM)................................... 20
4.1. Objectif et standard socle (UML)..................................................................................20
4.2. Organisation et standards complmentaires (OCL, AS)............................................... 21
4.2.1 Principe pour la ralisation..................................................................................... 21
4.2.2 Les vues de l'architecture couvertes........................................................................21
4.2.3 Les modles pertinents............................................................................................21
4.3. Illustration : le Portillon (suite)................................................................................22
4.3.1 Les composants.......................................................................................................22
4.3.2 Un diagramme de squence.................................................................................... 23
4.3.3 Un composant......................................................................................................... 24
4.3.4 Rendre plus productif les modles UML : OCL et AS...........................................24
5. La plate-forme d'excution Platform Description Model (PDM)................................ 26
5.1. Choix de la plate-forme................................................................................................. 26
5.2. Modlisation de la plate-forme......................................................................................27
5.3. On se passe du mta-modle du modle de la plate-forme........................................... 27
6. La transformation............................................................................................................... 28
6.1. Gnralits.....................................................................................................................28
6.2. Le passage du PIM au PSM...........................................................................................29

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 5

6.2.1 Description globale................................................................................................. 29


6.2.2 Modlisation des rgles de transformation : le mapping........................................ 30
6.2.3 Construction d'un modle intermdiaire : le PIM marqu......................................32
6.2.4 Excution de la transformation...............................................................................32
7. Point de vue du concepteur Platform Specific Model (PSM).......................................32
8. propos des standards utiliss par MDA........................................................................ 33
8.1. Les autres standards de MDA........................................................................................33
8.1.1 CWM (Commun Warehouse Metamodel)..............................................................33
8.1.2 XMI (XML Metadata Interchange).........................................................................33
8.1.3 Les profils UML..................................................................................................... 34
8.2. En guise de conclusion ................................................................................................. 35
3me Partie : les outils pour MDA.............................................................................. 37
1. Gnralits........................................................................................................................... 37
2. Une grille d'analyse des outils............................................................................................ 37
2.1. Pour la modlisation......................................................................................................37
2.2. Pour les transformations................................................................................................ 38
2.3. Pour la gnration du code............................................................................................ 38
2.4. Pour le rfrentiel socle................................................................................................. 39
3. Synthse................................................................................................................................39
Conclusion.................................................................................................................... 40
1. MDA = nouveau paradigme actif et/ou utopie ?.............................................................. 40
1.1. Une rponse institutionnelle : les technologies cls pour 2010.....................................40
1.2. Une rponse mthodologique : MDA............................................................................40
1.3. Une rponse organisationnelle : une mutation.............................................................. 41
2. Caf-Philo (ou philosophie de comptoir ?)........................................................................42
Bibliographie................................................................................................................ 43

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 6

Index des illustrations


Illustration 1 - La pile de modlisation de l'OMG (inspiration [BEZIVIN 2003])....................... 12
Illustration 2 - Le cycle en Y de MDA (inspiration [BEZIVIN 2003]).......................................... 18
Illustration 3 - CIM du "Portillon"................................................................................................20
Illustration 4 - PIM du "Portillon" - Les Composants.................................................................. 22
Illustration 5 - PIM du "Portillon" Diagramme de squence : Cration de Planning..............23
Illustration 6 - PIM du "Portillon" - Diagramme de classes : Messagerie ..................................24
Illustration 7 - Le cycle en Y de MDA, adapt (inspiration [BEZIVIN 2003])............................. 27
Illustration 8 : Oprations de transformation sur les modles MDA [BEZIVIN-BLANC 2002].. 28
Illustration 9 - Le cycle en Y de MDA, adapt et complet (inspiration [BEZIVIN 2003])............29
Illustration 10 - Les classes modlisant un groupe d'apprentis.................................................... 30
Illustration 11 - Le MCD d'un groupe d'apprentis........................................................................ 30
Illustration 12 - La ronde des standards MDA..............................................................................35
Illustration 13 - Intgration d'outils pour MDA [KADIMA 2005]................................................38

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 7

Liste des abrviations


AS : Action Semantics (Smantiques de l'Action).
ATL : Atlas Transformation Language (Langage de Transformation du projet Atlas).
BI : Business Intelligence (Informatique Dcisionnelle).
CIM : Computation Independent Model ( Modle Indpendant de l'Informatisation).
CORBA : Common Object Request Broker : Architecture and Specifications (Architecture et
Spcifications pour la Mise Disposition et la Requte sur des Objets Partags).
CWM : Commun Warehouse Metamodel (Mta-modle Commun aux Entrepts de Donnes).
EDOC : Enterprise Distributed Object Computing (Informatique d'Entreprise Objets
Distribus).
GMF : Graphical Modeling Framework (Cadre pour la modlisation Graphique) Projet
Eclipse.
IDM : Ingnierie Dirige par les Modles.
J2EE : Java 2 Enterprise Edition (dition Entreprise de Java 2).
MDA : Model Driven Architecture (Architecture Dirige par les Modles).
MDE : Model Driven Engineering (voir l'quivalent en franais IDM).
MOA : Matrise d'OuvrAge.
MOE : Matrise d'OEuvre.
MOF : Meta Object Facility (Service Mta-Objet).
OCL : Object Constraint Language (Langage de Contraintes sur les Objets).
OMG : Object Management Group (groupe de standardisation des technologies objet).
PIM : Platform Independent Model (Modle Indpendant de la Plate-forme).
PM : Platform Model (Modle de la Plate-forme).
PDM : Platform Description Model (Modle de Description de la Plate-forme).
PSM : Platform Specific Model (Modle Spcifique la Plate-forme).
QVT : Query, View, Transformation (Demande, Vue, Transformation)
UML : Unified Modeling Language (Langage de Modlisation Unifi).
XMI : XML Metadata Interchange (Echange de Mta-donnes en XML).
XML : eXtensible Markup Language (Langage Balises eXtensible).

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 8

Avertissement

De nombreux termes de ce mmoire sont mentionns en langue anglaise. Bien que, dans la
plupart des cas, une traduction en franais soit possible, les termes anglais sont tout de mme
utiliss :
soit pour faire le lien avec les documents sources. Dans ce cas la traduction franaise apparat
aprs la premire apparition du terme,
soit parce que la traduction (par une expression courte) dnaturerait le concept dsign. Dans
ce cas, seule l'expression anglaise est utilise.

Les mots ou expressions en langue anglaise sont crits en italique.

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 9

Introduction

On aurait pu penser initialement que la technologie objet constituerait un aboutissement. C'tait


au contraire un point de dpart pour une nouvelle migration technologique [BEVIZIN 2004].

Un des chemins possibles pour cette migration est d'adopter un nouveau paradigme : le tout
modle aprs le tout objet.
Avec cette nouvelle donne, une discipline a vu le jour : le MDE (Model Driven Engineering) ou
l'IDM (Ingnierie Dirige par les Modles).

C'est dans ce contexte, en novembre 2000, que l'OMG (Object Management Group) a rendu
publique son initiative nomme MDA (Model Driven Architecture).

ce stade, et en caricaturant, un informaticien quelque peu obscurantiste, pourrait dire :


voil qu'ils nous ont encore ajout un tage la fuse. Je sortais peine de
l'intgration culturelle et mthodologique de l'UML (Unified Modeling Language) et il va
falloir encore partir sur autre chose. Ah ! Ces chercheurs n'ont que cela faire ! !

Nous allons, ici, tenter de recadrer un certain nombre de concepts qui, parfois, se tlescopent, se
mlangent ou semblent se concurrencer. Face cet imbroglio, la raction de notre informaticien
anonyme (ci-dessus) s'explique car, contraint par la vie quotidienne, il n'a pas toujours l'occasion
de prendre le recul ncessaire. Le propos de cette tude sera donc de participer la lutte contre
une certaine forme dobscurantisme.

MDA se veut une approche mthodologique qui permet une optimisation des investissements lis
aux dveloppements d'applications informatiques [OMG-MDA 2006].
MDA reprend la philosophie gnrale de l'IDM, la dcline pour l'adaptation de modles
mtiers la plate-forme d'implmentation.
MDA utilise des standards reconnus, ouverts (car ceux de l'OMG) et prouvs (car largement
utiliss dans l'industrie du logiciel - cf. UML).

Ces caractristiques font-elles de MDA une dmarche relle et srieuse ?

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 10

La premire partie de ce mmoire reprendra quelques concepts fondamentaux de l'Ingnierie


Dirige par les Modles. En effet, MDA est considre comme une dclinaison de l'IDM
[BEVIZIN 2004] ou comme une simple collection de standards [FAVRE et al. 2006]. Il apparat
utile de gnraliser, ici, des concepts qui sont utiliss par MDA.

Une seconde partie traitera de la manire dont MDA dcline ces concepts, pour en faire une
approche qui permet de modliser un systme en se dtachant de la plate-forme
d'implmentation. Cela, le plus loin possible dans le cycle de dveloppement. En toute logique,
sera aussi abord dans cette partie le processus de transformation de modle, pierre angulaire de
MDA.

Enfin, la troisime partie participera rassurer notre informaticien obscurantiste en faisant un


zoom sur les outils de mise en oeuvre de l'approche MDA.

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 11

1re Partie : mta-mta-modle, mta-modle, modle,


systme, transformation ? IDM, au secours ! !
1. Gnralits propos de l'IDM
Dans un contexte d'accroissement exponentiel de la complexit des systmes informatiques, la
modlisation de ces systmes est devenue un enjeu majeur de la russite des projets : bonne
prise en compte du besoin fonctionnel, rduction des dlais et des cots par la rutilisation des
conceptions et des liens avec le code et, enfin, souplesse ncessaire pour l'adaptation des
applications aux diffrentes technologies actuelles ou futures.
L'Ingnierie Dirige par les Modles (IDM), ou son quivalent en anglais Model Driven
Engineering (MDE), est une approche du dveloppement d'applications informatiques qui vise
mcaniser le processus que les ingnieurs expriments suivent la main [WIKIPEDIA-FR
2006].
Pour cela, il s'agit de faire passer les modles du statut contemplatif (utilis pour la
documentation, l'aide la comprhension) au statut productif (automatisation de la gnration de
code partir du modle) [FAVRE et al. 2006].
L'IDM doit tre vue comme une intgration, un prolongement, un renforcement d'approches dj
connues. Ce n'est pas une rvolution mais une volution qui puise dans l'existant [FAVRE et al.
2006].
En cela, notre informaticien obscurantiste de l'introduction doit dj tre rassur sur l'impact
culturo-mthodologique de ce genre d'approche : s'il a intgr les standards actuels de
modlisation (UML en tte), il sait dj presque tout !
Le sujet de ce probatoire n'tant pas l'IDM, nous nous contenterons, ici, de dfinir quelques-uns
de ses concepts fondamentaux qui seront, dans la suite du document, repris et adapts la
spcificit de MDA.

2. Les concepts socles de l'IDM


Sauf indication contraire, la rfrence pour cette section est [FAVRE et al. 2006].

2.1. Le systme
Le systme, au sens de l'IDM, est ce que l'on dsire modliser. Il est le rel.
Une typologie des systmes est propose : systme physique (chien, maison, vlo,...), systme
digital (fichier, diagramme, logiciel,...), systme abstrait (compte bancaire, cercle, cours,..).

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 12

Un systme peut aussi tre dynamique (changer dans le temps) ou statique (immuable, du moins
dans une chelle de temps relativement grande).
Le systme se situe au niveau M0 de la pile classique quatre niveaux de l'OMG, reprsente ci-
dessous.

Illustration 1 - La pile de modlisation de l'OMG (inspiration [BEZIVIN 2003])

Les quatre niveaux de la pyramide reprsentent les niveaux taxinomiques d'une pile de
modlisation. Les sections suivantes dfiniront leur rle et les relations entre eux.

Pour illustrer les concepts abords dans cette partie, nous allons prendre comme exemple le
systme que constitue le prsent mmoire de probatoire.
On constate, au passage, qu'il est ce stade difficile de le classer conformment la typologie ci-
dessus : la fois physique (il pse son poids !), digital (c'est un fichier manipul par un
traitement de texte), abstrait (il contient une vision du sujet abord). Tout cela est une question
de point de vue.

2.2. Le langage
Du point de vue de l'IDM, le langage est l'ensemble des systmes de la mme famille. Pour faire
une analogie avec les langues, on peut dire que le langage franais est l'ensemble des phrases
rdiges dans cette langue.
Exprim d'une autre manire, le langage est le domaine du monde rel (M0) auquel appartient le
systme que l'on se propose d'tudier. Bien entendu, il appartient aux acteurs d'un projet, de
s'entendre ds le dpart sur la surface de ce domaine.
Dans le cas de notre exemple, on considrera le langage comme l'ensemble des mmoires (de
probatoire ou non) qui ont t, qui sont et qui seront rdigs par des auditeurs du CNAM.

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 13

2.3. Le modle
Ici, plusieurs dfinitions se ctoient. Nous retiendrons celle qui semble couvrir le mieux notre
propos (elle est prte Bzivin et Grb par [FAVRE et al. 2006]).
Un modle est une simplification d'un systme, construit avec une intention de
comprendre le systme en adoptant un point de vue dfini. Le modle rpondra des
questions propos du systme.
Dans son cours, [BEZIVIN 2003] prcise cette dfinition :
un modle n'est qu'une reprsentation partielle (un aspect) du systme (le rel),
un systme peut donc avoir plusieurs modles.
Le modle se situe au niveau M1 de la pile OMG (voir Illustration 1).

Pour illustrer ce qu'est un modle, il est souvent fait rfrence une carte gographique comme
modle d'un territoire terrestre. Cette illustration rpond bien la dfinition car :
il y a reprsentation simplifie du rel,
on peut crer de nombreuses cartes pour rpondre d'aussi nombreuses questions :
comment trouver son chemin ? Quelles sont les rivires et leur parcours ?...

Si l'on dsire modliser ce mmoire de probatoire, on peut le faire de la manire suivante :


Auteur : Jacques Barzic
Statut de l'auteur : auditeur au CNAM de Nantes

Type : Mmoire de probatoire CNAM


Nombre de pages : 40
Titre : MDA (Model Driven Architecture)

Table des matire :


Introduction..........................................................................................................................................1
1re Partie : mta-mta-modle, mta-modle, modle, systme, transformation ? IDM, au
secours ! !...............................................................................................................................................3
1. Gnralits propos de l'IDM...................................................................................................... 3
2. Les concepts socles de l'IDM......................................................................................................... 3
2.1. Le systme......................................................................................................................... 3
2.2. Le langage......................................................................................................................... 4
2.3. Le modle.......................................................................................................................... 5
...

On obtient bien l une reprsentation simplifie du mmoire qui rpond certaines questions
son propos : nous nous plaons l du point de vue de la description du contenu (systme abstrait),
comme peut le faire une bibliothque (une librairie) pour diriger le lecteur (l'acheteur) potentiel.

La relation qui lie le modle et le systme est ReprsentationDe.

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 14

2.4. Le mta-modle
L'originalit de l'IDM est de faire appel ce concept, au lieu de faire systmatiquement appel
de nouveaux modles : on gnralise, en quelque sorte.
La dfinition d'un mta-modle est courte mais charge de sens : il s'agit d'un modle qui dfinit
le langage.
Le mta-modle se situe au niveau M2 de la pile OMG (voir Illustration 1).

Si l'on reprend l'exemple des cartes gographiques :


le langage pourrait tre l'ensemble des cartes routires (on pourrait rduire le domaine
en citant un diteur),
la lgende de ces cartes serait un modle de ce langage : une ReprsentationDe,
la lgende est donc un mta-modle d'une carte donne : celle des routes de France, par
exemple.
Dans le cas du mmoire de probatoire :
le langage : tous les mmoires d'auditeurs du CNAM rfrencs dans la
mmoirethque ,
la trame d'une fiche de la mmoirethque est un modle pour le langage :
ReprsentationDe,
cette trame est donc un mta-modle pour le prsent mmoire de probatoire.

La relation qui lie le modle et le mta-modle est Conforme.

2.5. Le mta-mta-modle
Pour dfinir le mta-mta-modle, il suffit de reprendre le raisonnement prcdent en montant
d'un niveau :
en considrant l'ensemble des modles comme un langage : l'ensemble des cartes d'un
pays (pas que les routires),
en considrant l'organisation d'une lgende (mta-modle en soi) comme un modle de
ce langage : ReprsentationDe,
l'organisation d'une lgende devient un mta-modle du modle : donc un mta-mta-
modle d'une carte donne (de celle des routes de France, mais aussi de celle des
dpartements franais).

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 15

Le mta-mta-modle se situe au niveau M3 de la pile OMG (voir Illustration 1).

La pile de l'OMG s'arrte au niveau M3. En effet, il faut, un moment donn, stopper la mta-
escalade . Les standards de reprsentation graphique (dans le monde des modles
objet)permettent de constater que le diagramme dont le niveau serait M4, est le mme que celui
du M3. En cela, on peut dire que le mta-mta-modle se reprsente lui-mme [BLANC 2005].

Quel peut tre alors le mta-mta-modle du prsent mmoire ?


La manire d'organiser une fiche de bibliothque.
Par exemple : une fiche de bibliothque devra comprendre, dans l'ordre suivant :
une section d'identification de l'auteur,
une section d'identification de l'ouvrage,
une section d'identification du contenu de l'ouvrage.
Pour l'anecdote (mais pas si anecdotique que cela, si on creuse), on voit dans cet exemple, se
profiler une discussion pour les soires d'hiver : le titre de l'ouvrage est-il dans la section
identification de l'ouvrage ou dans celle identification du contenu de l'ouvrage ?

2.6. La transformation
Cette notion, centrale pour l'IDM (et aussi pour MDA), implique un tat de dpart et un tat
d'arrive.
Il s'agit, ici, de transformer un modle existant (charg de ses mta et mta-mta modles) en un
modle n'ayant pas la mme pile de modlisation (autres mta et mta-mta modles). Dans
[FAVRE et al. 2006], les auteurs parlent d'espaces techniques diffrents.

Lors de cette opration, les mta-modles prennent toute leur importance. Les rgles de passage
d'un modle un autre modle seront spcifies au niveau des mta-modles. Ainsi, toutes les
transformations de modles pourront tre ralises par l'activation de ces rgles, thoriquement
sans nouvelle spcification. La dfinition des mta-rgles sera d'autant plus naturelle si les mta-
modles dpendent du mme mta-mta-modle.

Pour la reprsentation des territoires, cela consisterait, par exemple, transformer les cartes en
reprsentation 3D (type photos ariennes), autre reprsentation d'une mme ralit et rpondant
des rgles (pile de modlisation) diffrentes.

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 16

On peut imaginer, pour la fiche de mmoirethque du mmoire de probatoire, de la


transformer en une squence sonore pour les personnes mal-entendantes ou en Braille pour les
personnes non-voyantes.
En sortie de la transformation, on obtient un autre modle du mme systme (de la mme ralit).

3. Conclusion
L'enjeu est de taille : si l'on parvient rationaliser (puis automatiser) cette transformation d'un
espace technique vers un autre, on ouvre une porte vers la rutilisation des rsultats de la
conception, vers une adaptation possible des environnements diffrents, vers une prise en
compte de l'volution future des technologies.
La puissance de la mta-modlisation est un gage de russite de cette approche : en effet, on
s'aperoit que, plus on monte dans la pile de modlisation, plus les points communs entre les
espaces techniques sont nombreux. Ce qui aboutit une base commune sur laquelle s'ancrera la
transformation.

Dans tous les cas, si les mta-mta-modles et les mta-modles d'espaces techniques diffrents
sont formaliss et diffuss ou, mieux encore, se standardisent, la transformation des modles
pourra se faire automatiquement.

C'est cette standardisation que l'approche MDA participe dans son domaine d'action.

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 17

2me Partie : Model Driven Architecture, approche pour les


architectes fabricateurs1 ?
1. Introduction
Le titre de cette partie, un brin provocateur, rsume quelques questions centrales propos de
cette dmarche.
Comment monter d'un cran dans l'abstraction ?
L'automatisation totale des activits de codage est-elle une proccupation d'alchimiste ou une
ralit possible ?
Les enjeux sont pourtant importants [BLANC 2005] :
prennisation des savoir-faire,
amlioration de la productivit,
prise en compte des plates-formes d'excution.

Comme nous l'avons dj vu, MDA est une dmarche, de type IDM, pour la conception de
systmes informatiques. L'activit oprationnelle principale (unique ?) des informaticiens la
pratiquant doit tendre tre la modlisation.
Pour rpondre aux enjeux, MDA se concentre sur un objectif dichotomique : modliser le plus
possible en s'abstrayant de la plate-forme d'excution et modliser l'adaptation la plate-forme.

Dans cette partie, nous allons voir quelle mthode et quels outils standardiss MDA met en
oeuvre pour atteindre son objectif.

1 FABRICATEUR, TRICE : n. (lat. fabricator, -oris, construteur). Personne qui fabrique des produits sans valeur,
invente des choses mensongres ; fabricant (langue soutenue et pjor.) : Fabricateurs de mots inutiles.
Fabricateurs de fausses nouvelles, de rves. [LAROUSSE 1995].

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 18

2. Le schma gnral de MDA

Illustration 2 - Le cycle en Y de MDA (inspiration [BEZIVIN 2003]).

La dmarche MDA est une orchestration de diffrents modles issus de 4 points de vue
principaux. On devrait, plus exactement, dire 3 +1 points de vue.
Le guide MDA de l'OMG en dcrit explicitement trois [OMG-MDA 2003] : Computation
Indpendant Viewpoint, Platform Indpendent Viewpoint, Platform Specific Viewpoint. Ceux
sont les points de vue que prennent les modles sur le systme dvelopper.
On peut en ajouter un autre, dont le guide OMG [OMG-MDA 2003] cite le modle rsultant, qui
a son importance : la vue qu'a l'quipe-projet de la plate-forme d'implmentation. C'est un point
de vue que prend le systme dvelopper sur un versant de son environnement.

Chaque point de vue sera source de modle(s), lments fondamentaux de la dmarche (les
ovales de l'Illustration 2).
La rencontre des deux branches suprieures du Y est un moment dlicat : deux modles doivent
fusionner pour en produire un nouveau. MDA prconise aussi de modliser cette
transformation.

ce stade, on comprend mieux le caractre dirige par les modles de la dmarche. Dans un
processus idal allant du haut vers le bas ( top-down ), on part de modles, on traite des
modles successifs, pour obtenir, in fine, la ralit recherche : le code.

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 19

Mais ce propos : le code n'est-il pas lui-mme un modle ? Ne reprsente-t-il pas la ralit des
impulsions lectriques qui font fonctionner les ordinateurs ? Ou, d'une autre manire, la rponse
aux besoins de la matrise d'ouvrage (la raison de notre projet) ?
Admettons, ici, que le code est notre ralit, notre systme. Ses passages travers une machine
virtuelle et/ou un systme d'exploitation (et leurs compilateurs) sont aujourd'hui suffisamment
transparents pour nous permettre ce raccourci.
Bienvenue ModelLand ! !

3. Point de vue de l'utilisateur Computation Independent Model


(CIM)
3.1. Objectif
Littralement Modle Indpendant de l'Informatisation , ce modle est charg de reprsenter
les exigences de la matrise d'ouvrage. Comme son nom l'indique, ce modle devra reprsenter
ces exigences sans aucune rfrence la ralisation de l'application ou aux traitements [BLANC
2005]. Il est parfois aussi nomm Modle du Domaine ou Modle Mtier [OMG-MDA
2003].
L'expression classique des exigences client, se fait travers un cahier des charges. La plupart du
temps crit en langage courant, il est inexploitable dans un objectif de rationalisation et
d'automatisation du cycle de dveloppement.
La premire tape est donc de traduire le cahier des charges en un autre modle, outil de
communication entre les utilisateurs et les informaticiens analystes.
Ce premier modle doit tre un outil de traabilit, contractuel, par rapport au rsultat
(l'application) attendu [OMG-MDA 2003].
L'OMG ne prconise pas de formalisme particulier ce stade (mme si des travaux sont en cours
pour y adapter UML) [BLANC 2005].

L'utilisation du diagramme des cas d'utilisation UML est adapte ce modle. Issu du mme
mta-modle (UML) que les modles suivants dans le cycle (PIM et PSM), le lien existera entre
les exigences client et le code produit la fin du cycle en Y.

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 20

3.2. Illustration : le Portillon


Pour illustrer cette partie, nous allons suivre un portail trs simplifi qui pourrait tre celui d'un
Centre de Formation d'Apprentis. Voici le diagramme des cas d'utilisation qui constitue son CIM
(Illustration 3).

Illustration 3 - CIM du "Portillon"

4. Point de vue de l'analyste - Platform Independent Model (PIM)


4.1. Objectif et standard socle (UML)
Aprs la rcupration et la reprsentation des exigences client par le CIM, il faut maintenant
passer la reprsentation informatique des ces exigences : une nouvelle tape vers une
application.
Le point de vue de l'analyste doit se considrer avec l'objectif suivant : traduire l'expression des
experts mtiers pour qu'elle soit non seulement comprhensible, mais aussi exploitable par
les experts informatiques chargs de la production de l'application.
Ici, le mta-modle UML s'impose : il fait partie des standards de l'OMG, il est aujourd'hui
largement adopt par les quipes-projets et par les outils existants, il est indpendant des
langages (plates-formes) de programmation, il propose plusieurs diagrammes rpondant des
proccupations complmentaires [BLANC 2005].

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 21

4.2. Organisation et standards complmentaires (OCL, AS)

4.2.1 Principe pour la ralisation


Dans l'absolu, la transformation du CIM vers le PIM peut tre modlise et, ainsi, trace.
Comme, pour le moment, MDA ne prconise aucun mta-modle standard pour raliser le CIM,
le passage CIM/PIM se fera la main .
Le choix d'utiliser UML (diagramme des cas d'utilisation) pour le CIM est fait dans deux
optiques : appliquer le langage UML ds le dpart pour avoir une cohrence entre les deux tapes
et se prparer pour le moment o UML sera suffisamment dfini pour permettre une
mcanisation de ce passage.
Malgr sa connotation informatique, le PIM doit rester (comme son nom l'indique) indpendant
de la plate-forme d'excution. On va donc, ici, se concentrer sur la reprsentation de l'architecture
modulaire de l'application, des connections entres les modules, du contenu des modules, des
tches ralises par les modules.

4.2.2 Les vues de l'architecture couvertes


Il est aujourd'hui admis de considrer trois niveaux d'abstraction dans la construction de
l'architecture d'un systme d'information : le niveau mtier, le niveau fonctionnel et le niveau
technique [KADIMA 2005].
Le niveau technique de l'architecture correspond la plate-forme d'excution, il est couvert par le
PSM (voir 7). Si l'on considre que le PIM doit tre ralis du point de vue de l'entreprise (on
pourrait dire macro-mtier ), du point de vue informatique et, ventuellement, du point de vue
d'une architecture distribue [OMG-MDA 2003], on dduit qu'il couvre :
le niveau mtier de l'architecture : il s'agit l de modliser les invariants du mtier, par
dfinition non lis l'organisation de l'entreprise spcifique,
le niveau fonctionnel de l'architecture : on intgre ici l'organisation de l'entreprise
tudie ainsi que l'organisation de son systme d'information. On ralise un profil du
mtier pour l'entreprise [KADIMA 2005].

4.2.3 Les modles pertinents


Plusieurs modles distincts vont collaborer pour constituer le PIM : le diagramme de
composants2 (organis en paquetages) pour l'architecture, les diagrammes de classes pour les
aspects statiques, les diagrammes de squence ou d'activit pour les aspects dynamiques.

2 Meilleure prise en compte par UML 2.0.

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 22

cela viendra s'adjoindre une modlisation des contraintes et de l'algorithmie qui ne pourraient
tre exprimes dans les diagrammes UML. L aussi, des standards existent : OCL (Object
Constraint Language) pour les contraintes et AS (Action Semantics) pour l'algorithmie. Ces deux
standards sont des langages expression et sont aussi des mta-modles, conformes au mta-
mta-modle MOF (Meta Object Facility) comme UML [BLANC 2005].
OCL et AS sont deux standards cls utiliss par MDA, dans le but de rendre productifs des
modles.
OCL et AS sont indpendants de la plate-forme. Les modles correspondant peuvent (voire
doivent) tre intgrs au PIM.

4.3. Illustration : le Portillon (suite)


Un modle PIM qui se tient comportera diffrents diagrammes UML. Ils seront constitus et
raffins au cours de diffrentes itrations. On se retrouve appliquer un cycle de dveloppement
itratif et incrmental.
L'objet de ce mmoire n'tant de dcrire ni les cycles de dveloppement ni le langage UML, nous
allons continuer notre illustration avec des diagrammes simplifis et hypothtiques.

4.3.1 Les composants

Illustration 4 - PIM du "Portillon" - Les Composants

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 23

L'Illustration 4 montre les quatre composants qui pourraient constituer notre Portillon . Ce
diagramme offre l'intrt de bien montrer la rpartition des fonctionnalits et des oprations qui
seront ralises par chacun. Les interfaces sont les points de connexion entre les composants.
Cette vison est aussi une vision architecturale : on pourra, dans la suite du cycle MDA, dcider
de la distribution (ou s'adapter une distribution existante) du systme informatique. Dans le
mme esprit, une adaptation aux technologies pourra se faire : serveur de messagerie existant,
annuaire crer, planning en Web Service, par exemple.

4.3.2 Un diagramme de squence

Illustration 5 - PIM du "Portillon" Diagramme de squence : Cration de Planning

L'Illustration 5 prsente un diagramme de squence nominal d'un des scnarios possibles pour la
cration d'un planning de groupe.
Ce diagramme modlise le fonctionnement dynamique d'un composant (Planning, ici). La
mthode incrmentale permettra de prciser la totalit des scnarios possibles (nominaux,
alternatifs et d'erreur) au fur et mesure des itrations.

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 24

4.3.3 Un composant
L'intrieur des composants pourra tre reprsent par un diagramme de classes. L'Illustration 6
en donne un exemple possible pour notre composant Messagerie.

Illustration 6 - PIM du "Portillon" - Diagramme de classes : Messagerie

4.3.4 Rendre plus productif les modles UML : OCL et AS


Rappelons que ces deux langages sont partie intgrante du mta-modle UML. Ils sont donc
compltement spcifis dans celui-ci et conformes au mta-mta-modle MOF. Ces
caractristiques leur confrent bien une nature de standards transversaux la dmarche MDA.

OCL (Object Constraint Language)


En appliquant OCL un modle source (un PIM, par exemple), on rend celui-ci plus prcis et
plus complet. Cette richesse augmente (du modle source) rend possible l'obtention d'un modle
cible (PSM dans la dmarche MDA) d'autant plus riche (ayant donc une productivit augmente)
[KADIMA 2005].

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 25

Sans entrer dans une description de ce langage (hors du cadre de ce mmoire), voici quelques
lments caractristiques.
Son application aux modles UML permet de dfinir des contraintes sur l'tat des
objets modliss comme sur les donnes changes lors de l'vocation des mthodes
[BLANC 2005].
OCL ne produit pas d'effet de bord : son rle n'est pas de modifier une valeur mais de
contraindre ce que les valeurs soient dans un cadre prcis [BLANC 2005].
Les contraintes exprimes par OCL doivent se solder par un rsultat booleen.
Sa situation au niveau du mta-modle UML lui permet d'tre utilis dans la dfinition
des mta-modles (pour les prciser) ou pour assurer du lien entre mta-modles
[KADIMA 2005].
En plus de sa spcification au niveau du mta-modle, OCL dispose d'une syntaxe
textuelle standard pour s'exprimer. Ceci facilite son utilisation par des outils diffrents
(ce qui respecte l'objectif de prennit des modles).
Un exemple simple d'utilisation, sur notre composant Messagerie.
Ligne 1 : contexte Message
Ligne 2 : inv: emetteur exist
Ligne 3 : inv: destinataire exist
La ligne 1 dfinit l'lment cible de la contrainte : ici, la classe Message.
Les lignes 2 et 3 dfinissent la contrainte : ici, deux invariants (la contrainte doit tre vraie
pour toutes les instances de la classe). L'metteur et le destinataire d'un message doivent tre
spcifis.
Lors de contraintes sur les oprations, OCL peut aussi spcifier des pr-conditions et/ou des post-
conditions.
Exemple : ajout d'un contact dans le carnet d'adresse.
Ligne 1 : contexte CarnetAdresse::ajouterContact():Contact
Ligne 2 : pre: contact not exist
La pr-condition vrifie que le contact que l'on veut ajouter n'existe pas dj dans le carnet
d'adresse.

AS (Action Sementics)
Ce langage va permettre de pallier la limitation de OCL (qui ne peut pas agir sur l'tat du
modle) : il va dcrire le comportement dynamique du modle.

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 26

AS est le socle des modles dynamiques de UML (activit, squence, machine d'tats). Cela offre
une cohrence, porteuse de productivit, entre tous ces modles [BLANC 2005].
AS peut aussi tre utilis en tant que tel pour enrichir les modles. Il est compltement spcifi
dans le mta-modle UML mais il ne dispose pas d'une syntaxe textuelle standard. Cette dernire
caractristique est un frein son utilisation dans les outils de modlisation : chaque diteur doit
spcifier sa propre syntaxe, avec le corollaire de l'incompatibilit entre les diffrents outils (donc
du manque de portabilit des modles).
On peut considrer AS comme une abstraction des langages de programmation indpendante
d'un langage donn [KADIMA 2005]. Cela lui donne une puissance potentielle pour tre le mta-
modle (et pour les modlisations associes) de la gnration du code interne aux oprations.
Mme si la gnration complte de code partir d'un modle PIM parat actuellement peu
raliste (car complexe mettre en oeuvre), le chemin est ouvert.
Actuellement, AS est donc plus utilis au niveau des mta-modles pour spcifier les
comportements des lments des modles associs. Il va, grce cela, tre un des outils
disponibles pour grer l'opration de transformation [KADIMA 2005].

5. La plate-forme d'excution Platform Description Model (PDM)


Aprs avoir parcouru la branche situe gauche du cycle en Y de MDA (voir l'Illustration 2) et
avant de procder la transformation qui nous mnera vers le modle spcifique la plate-forme
d'excution, il nous faut dfinir cette plate-forme.
C'est la branche situe droite du Y. On en dgage deux tapes :
1. le choix de la plate-forme et l'obtention de son modle du point de vue de l'utilisateur
(que nous sommes, dans le cadre d'un projet),
2. la modlisation du filtre qui va permettre de rendre possible la transformation.

5.1. Choix de la plate-forme


Une plate-forme est une entit technique qui fournit un ensemble cohrent de fonctionnalits et
sur laquelle vont s'excuter les applications. L'intrt est que l'utilisation d'une plate-forme ne
ncessite pas de connatre comment les fonctionnalits sont ralises : l'accs se fait par les
interfaces qu'elle prsente [BLANC 2005].
Comme plate-forme, on peut citer J2EE, .Net, CORBA. Il faut avoir l'esprit la toute relativit
de cette liste : on peut aussi considrer que les systmes d'exploitation sont des plates-formes
(Windows, Unix,...).
L'indpendance par rapport la plate-forme et donc aussi trs relative (exemple : une application

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 27

J2EE, donc son modle spcifique, peut tre considre comme indpendante de la plate-forme
car pouvant s'excuter indiffremment sur plusieurs systmes d'exploitation). Une discussion sur
ce sujet dpasse le cadre de ce mmoire.
L'architecte du projet doit choisir une plate-forme ou faire avec l'existante. Disposant du modle
indpendant de l'application projet, c'est avant la transformation que l'architecte doit savoir
qu'elle est la plate-forme cible (ou les plates-formes cibles en cas de systme htrogne). C'est
cela qui va conditionner l'organisation de la transformation de modle.

5.2. Modlisation de la plate-forme


Dans l'absolu, la plate-forme, du point de vue du projet, est modlisable : description de ses
fonctionnalits, de son architecture, des modes d'accs ses fonctionnalits, des interactions
entre les diffrents lments la constituant,...
On obtient ainsi un PM (Platform Model) qu'il est possible de mettre en relation avec le PIM de
notre projet pour transformer ce dernier. Cette transformation passe par une mise en relation des
deux mta-modles (voir dfinition de la transformation, partie 1 2.6).
Et l, un manque vident apparat : si le mta-modle ayant servi l'laboration du PIM est
connu (UML, OCL,...), l'obtention du mta-modle du PM est loin d'tre acquise. Cela sous-
entendrait que les diteurs de plates-formes se mettent d'accord sur un mta-modle commun...

5.3. On se passe du mta-modle du modle de la plate-forme


Pour rsoudre ce problme, en attendant une standardisation des mta-modles de plates-formes,
on va adapter le cycle en Y de base.

Illustration 7 - Le cycle en Y de MDA, adapt (inspiration [BEZIVIN 2003]).

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 28

Cette adaptation part d'un constat : les informations relatives une plate-forme donne sont
contenues dans le mta-modle du PSM. Les rgles de transformation seront dfinies partir de
ce mta-modle, en lieu et place de celui du modle de la plate-forme. La limitation de cette
technique est que la gnralisation sera plus restreinte, car faite pour une plate-forme donne
[BLANC 2005] : il faudra un mta-modle par plate-forme.
Le mta-modle du PSM est aussi appel Platform Description Model (PDM) [KADIMA 2005].
ce stade, nous disposons d'une reprsentation indpendante de la plate-forme de notre
application (le PIM), d'une reprsentation de la plate-forme cible (le PDM) et de leur mta-
modles respectifs. Nous allons maintenant pouvoir organiser et procder la transformation
vers la reprsentation spcifique la plate-forme de notre d'application.

6. La transformation
6.1. Gnralits
MDA tant base sur la manipulation de modles, le passage de l'un l'autre (et vice versa) est
une activit centrale de la mthode. L'Illustration 8 prsente les diffrentes oprations de
transformation de modles que l'on peut trouver dans MDA.

Illustration 8 : Oprations de transformation sur les modles MDA


[BEZIVIN-BLANC 2002].

Le passage d'un modle type UML du code crit en langage volu (Java, C++,...) [5] 3, que l'on
considre ici comme un modle, est dj bien implment dans les outils de modlisation
(gnration de squelette d'application).
Les transformations rflexives de modles (PIM/PIM [1], PSM/PSM [3], Code/Code [6]) seront
effectues soit lors d'ajouts d'lments pour reprsenter des niveaux diffrents d'abstraction, soit
pour optimiser un modle lorsqu'une transformation non rflexive est incomplte ou pas assez
prcise (raffinage). Il est important de noter que ces transformations rflexives ne sont pas
toujours automatisables [BEZIVIN-BLANC 2002].
3 Sont nots sous cette forme les rappels aux numros de l'Illustration 8.

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 29

Les transformations [4] et [7], font partie de l'activit de rtro-ingnierie. Cette dernire fait
partie de la philosophie de MDA et mriterait une tude elle seule.
La transformation centrale de MDA (et aussi la plus dlicate) est le passage du PIM vers le PSM
[2]. Il est temps maintenant de s'y arrter plus longuement.

6.2. Le passage du PIM au PSM


Nous avons vu comment adapter le cycle en Y pour obtenir un modle de la plate-forme
d'implmentation (voir 5.3).
Voici une illustration plus complte de ce cycle. Dans cette section, nous allons dcrire les
nouveaux apports.

Illustration 9 - Le cycle en Y de MDA, adapt et complet (inspiration [BEZIVIN 2003]).

6.2.1 Description globale


ce stade du cycle de dveloppement, nous disposons :
du PIM et de son mta-modle (UML),
du mta-modle du PSM (profil UML4) ou PDM.
Les tapes suivantes vont se drouler :
modlisation des rgles de transformation (le mapping),
construction d'un modle intermdiaire (le PIM marqu),
excution de la transformation.
4 Sous-ensemble de UML comprenant des strotypes, des tagged-values et des contraintes. Ici le profil sera celui
de la plate-forme d'implmentation (voir complments 8 de cette partie).

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 30

6.2.2 Modlisation des rgles de transformation : le mapping


Cette tape consiste dfinir les rgles de transformation d'un modle l'autre. Comme nous
l'avons vu, cette dfinition se fait au niveau des mta-modles.

Un exemple
Le passage d'un diagramme de classes UML vers un MCD Merise5.

Illustration 10 - Les classes modlisant un groupe d'apprentis.

Passons sur la smantique mtier des lments, pour illustrer l'ide des rgles de
transformation (on pourrait parler de mta-rgles) liant les mta-lments UML et Merise :
une classe UML devient une entit Merise,
un attribut de classe devient une proprit d'entit,
une association devient une association.
L'application de ces trois rgles pourrait donner le MCD suivant :

Illustration 11 - Le MCD d'un groupe d'apprentis.

Commentaires
Notre exemple didactique et volontairement simplifi appelle des remarques et des questions,
caractristiques de la problmatique du mapping. Par exemple :
1. Les trois rgles donnent une correspondance entre types d'lments. Ceci permettra
d'automatiser l'opration.

5 Je travaille actuellement dans un Centre de Formation d'Apprentis : ceci explique l'inspiration de l'exemple !

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 31

2. A contrario, on trouve des attributs de classe qui deviennent de simples proprits d'entit, et
d'autres qui deviennent (participent tre) l'identifiant d'entit. On doit alors prciser la rgle :
un attribut de classe devient une proprit d'entit ou peut participer tre l'identifiant
d'entit .
Il ne faudra alors pas luder les questions : qui, au moment de l'excution de la
transformation, dcidera de la partie de l'alternative mettre en oeuvre ? Comment cette
dcision sera formalise ?

Gnralisation
Actuellement, trois approches permettent la spcification de rgles de correspondance [BLANC
2005].
1. Par programmation : on utilise un langage de programmation connu (Java, C++,..) et on
conoit la transformation comme n'importe quelle application informatique. C'est puissant,
efficace, habituel : c'est, sans doute, encore la mthode la plus utilise car trs outille. Le
revers est, l encore, la dpendance au langage de programmation.
2. Par template (patron) : on labore un canevas du modle cible souhait et, lors de la
transformation, on remplace les valeurs du canevas par celles du cas d'espce trait. La
puissance de la mthode dpend de la prcision des canevas et, donc, du langage utilis pour
les dfinir. Il faut aussi faire attention : un canevas peut devenir un carcan.
3. Par modlisation : sans doute la mthode la plus prometteuse [KADIMA 2005]. Elle ouvre la
voie vers une mta-modlisation des transformations avec les avantages que cela comporte :
prennit, productivit, indpendance par rapport aux outils et aussi harmonie avec le
paradigme MDA.

La potentialit de l'approche par la modlisation est renforce par deux faits principaux.
1. Dans le cycle en Y de MDA (voir Illustration 9), le modle source (le PIM) et le modle cible
(le PSM) sont issus du mme mta-modle (UML ou profil UML) : cela facilite la mta-
modlisation des rgles de correspondance.
2. Pour aller dans ce sens, l'OMG a dfini un mta-modle standard d'expression des rgles de
transformation : QVT (Query/View/Transformation). Ce standard dfinit un langage de
cration de vues sur le modle, un langage de modlisation de requte et un langage d'criture
des dfinitions de transformation. QVT est bien un mta-modle. Il est conforme au mta-
mta-modle MOF (le mme que UML), ce qui est porteur pour rendre plus aise la
collaboration entre les mta-modles de ce standard.

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 32

6.2.3 Construction d'un modle intermdiaire : le PIM marqu


Maintenant que nous disposons des rgles de transformation, dans un modle nomm mapping, il
faut rpondre au problme du choix en cas d'alternative inhrente au modle cible, ici le PSM.
Pour ce faire, on va construire un modle intermdiaire qui va prendre en compte les choix faits
par le concepteur [BLANC 2005].
On nomme aussi ce modle modle marqu (Marking Model [OMG-MDA 2003]). Le
principe est de poser des marques sur le modle indpendant (le PIM) qui prennent en compte
la fois les rgles du modle mapping et les choix faits par le concepteur. Un profil UML comme
mta-modle est adapt. Dans notre exemple prcdent, il suffirait de marquer les attributs
concerns par le strotype <primaryKey> pour que la transformation soit complte.

6.2.4 Excution de la transformation


Toutes les informations sont alors runies pour excuter la transformation proprement dite.
Selon le degr de prcision et d'aboutissement des diffrents modles construits lors des tapes
prcdentes (CIM, PIM, mapping) et de leur mta-modlisation (UML et profils, mta-mapping),
la transformation va avoir un degr d'aboutissement diffrent.
Elle sera plus ou moins automatisable (donc outillable) et demandera plus ou moins
d'interventions manuelles ensuite.

7. Point de vue du concepteur Platform Specific Model (PSM)


Un PSM est une vue du systme regard du point de vue de la plate-forme d'excution : il couvre
le niveau technique de l'architecture6. Il combine les spcifications contenues dans le PIM avec
les caractristiques qui spcifient comment ce systme peut fonctionner sur la plate-forme cible
[OMG-MDA 2003].
Dans la philosophie MDA, il s'agit d'une modlisation conforme au mta-modle UML. Elle est
obtenue suite tout une srie de crations et de manipulations de modles. In fine, il ne reste plus
qu' gnrer le code dans le langage qui correspond la plate-forme choisie, de la mme manire
et avec les mmes outils que dans une dmarche classique. L'ide de MDA est d'obtenir un PSM
le plus complet et le plus prcis possible, afin d'obtenir aussi le code le plus complet et le plus
prcis : le Graal tant d'obtenir le code fini de l'application.

Bien que nous sommes maintenant dans le domaine de la dpendance par rapport la plate-
forme, nous allons pouvoir illustrer l'ouverture de MDA en nous appuyant sur l'indpendance du
6 Voir 4.2.2 de cette partie.

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 33

PIM. Ce dernier tant conu dans une logique de composants, qu'est-ce qui empche [OMG-
MDA 2003] :
de gnrer notre application (du moins son PSM) pour plusieurs plates-formes
diffrentes,
de dcouper le PIM global en plusieurs morceaux (composants), de gnrer autant de
PSM, spcifiques la mme ou des plates-formes diffrentes, pour constituer un
systme rparti,
de faire des transformations en chane afin que le PIM puisse s'adapter diffrents
niveaux : on fait le PSM pour une machine virtuelle (Java, par exemple) et le mme
PIM peut servir gnrer le PSM pour un systme d'exploitation donn (Windows,
Unix,...),
de combiner les mappings afin d'en construire de nouveaux ?

8. propos des standards utiliss par MDA


8.1. Les autres standards de MDA

8.1.1 CWM (Commun Warehouse Metamodel)


CWM, acronyme que l'on peut traduire par Mta-modle Commun aux Entrepts de Donnes,
est un mta-modle inspir de UML. Il est ddi la modlisation des entrepts de donnes.
Promu par l'OMG, il est, bien entendu, conforme au mta-mta-modle MOF. Il fait partie du
noyaux de standards de MDA, un mme titre que UML et MOF (voir le logo MDA, page 3).
Cela veut dire que toute la mthodologie MDA, que nous avons dcrite dans ce mmoire pour
UML et les applications classiques, peut s'adapter au domaine spcifique de la modlisation des
donnes, de leur transformation et de leur prsentation7.
Pour en savoir plus, le lecteur consultera, pour une premire approche, [KADIMA 2005].

8.1.2 XMI (XML Metadata Interchange)


XMI (Echange de Mta-donnes en XML) se trouve, lui, dans le deuxime anneau des standards
utiliss par MDA.
XMI est le partenaire de UML. UML se charge de dcrire les contenus des modles alors que
XMI se charge de formater ces contenus. On dispose ainsi d'un standard permettant de
transporter, sous forme de fichiers XML (standard lui-mme trs usit), les modles dont la
smantique est base sur UML. Ce duo permet une transversalit entre les outils ayant le mme

7 Trois grandes activits de l'informatique dcisionnelle (BI Business Intelligence)

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 34

rle, mais aussi entre les outils agissant aux diffrents stades du cycle de vie des modles.
[KADIMA 2005].
Pour plus de dtails, le lecteur se rfrera la documentation abondante sur le sujet.

8.1.3 Les profils UML


Utiliss, entre autres, dans le cadre des mta-PSM, les profils UML peuvent aussi servir de mta-
modles typs UML dans de nombreux autres cas de figure.
Le principe est de prciser la smantique des lments de UML en leur ajoutant :
des strotypes : dfinissent, dans le mta-modle, des sous-mta-classes. Ils sont
applicables tous les lments du mta-modle.
Des tagged-values (valeurs marques) : dfinissent des nouvelles proprits. Elles
correspondent un couple nom/valeur.
Des contraintes : elles prcisent le rle des lments de UML. Elles peuvent tendre ou
restreindre la smantique du modle obtenu. Le langage naturel peut tre utilis, mais
OCL est, l aussi, tout indiqu.

L'OMG a standardis neuf profils UML [OMG-UML 2006]. On peut citer ceux qui sont en
rapports avec MDA : des profils pour CORBA (standard OMG pour les systmes distribus),
Enterprise Distributed Object Computing (EDOC) qui couvre notamment les spcifications de la
plate-forme J2EE,...
Les profils trouvent toute leur utilit lorsque les entreprises les utilisent pour organiser leurs
propres mta-modles. Les profils UML deviennent alors un outil pour fixer un cadre, une
cohrence, aux modles produits par les quipes projets d'une mme organisation8.

8 Le terme organisation peut prendre ici plusieurs reprsentations : entreprise de cration de logiciels,
entreprise en tant que matrise d'ouvrage, grand projet,...

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 35

8.2. En guise de conclusion


En conclusion de cette partie sur la mthodologie MDA nous porterons un regard sur
l'illustration ci-dessous.

Illustration 12 - La ronde des standards MDA

Elle montre les liens troits qui existent entre les diffrentes technologies utilises dans la
dmarche. Ces liens sont un gage de la prennit tant recherche, d'une optimisation du travail
par la rutilisation de rsultats de dveloppements achevs. Ils sont aussi garants de la possibilit
d'adaptation aux diffrentes technologies actuelles et futures, sans pour cela avoir tout
reconstruire.
Ayant toutes la mme racine (MOF), ces technologies facilitent les manipulations de
transformations.

On peut aussi, ce stade, avancer que MDA permet, par une application ordonne de standards
connus, de monter d'un cran dans l'abstraction : les rgles de correspondances d'un modle par
rapport un autre sont spcifies au niveau des mta-modles (M2).

Ceci tant, et mme si la chevaleresque qute du Graal est porteuse d'lan collectif, il faut faire

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 36

preuve de ralisme. Nous ne sommes pas au bout de la route vers l'obtention automatique
d'applications entirement codes (donc oprationnelles) partir des modles.

Le travail se situe au niveau des outils logiciels qui se rclament de MDA : la foison d'outils et de
projets qui appliquent cette dmarche partiellement, prouve que l'on s'en approche.

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 37

3me Partie : les outils pour MDA


1. Gnralits
Une des conditions pour l'intgration de la dmarche MDA dans les pratiques, et afin qu'elle ne
reste pas un voeu pieux ou un bel exercice de recherche, est la mise au point d'outils qui la
rendent productive.
Si l'on en croit la profusion de projets ou d'outils utilisables qui se rclament de l'ingnierie des
modles9, on peut facilement avancer que nous sommes bien en prsence d'un mouvement
raliste.

La complexit relative de la dmarche MDA, sa volont rassembler de multiples techniques


(modlisation, mta-modlisation, transformation de modles, gnration de code), rendent
difficile la mise au point d'outils qui intgrent la totalit de la dmarche. En effet, il faut la fois
automatiser de nombreuses tches (dj complexes prises indpendamment l'une de l'autre) et
respecter plusieurs standards, tout en prservant la souplesse ncessaire de la dmarche (et qu'a
sans doute voulu lui confrer l'OMG).

Actuellement, on trouve donc des outils qui n'ont ni la standardisation de MDA, ni sa richesse, ni
souvent non plus l'indpendance complte vis--vis de l'intergiciel10. Mais, ces outils ont
l'avantage d'tre efficaces, utilisables et stables [KADIMA 2005].

2. Une grille d'analyse des outils


Pour pouvoir dcrire les outils, qui ne couvrent souvent qu'une partie du cycle MDA (et sont
donc complmentaires), [KADIMA 2005] propose une vision intgre de l'outil complet autour
d'un rfrentiel (Illustration 13, page suivante).
Cette approche met en vidence les fonctions attendues de la part des outils et peut servir de
grille pour la comparaison fonctionnelle de ceux-ci.

2.1. Pour la modlisation


On trouve ici deux fonctions.
L'outil de modlisation (d'dition du modle) proprement dit. De prfrence avec une interface
graphique, il permet de tracer les diagrammes conformment un mta-modle.

9 Voir [PLANETEMDE.ORG 2006] : liste de plus de 70 outils.


10 Ce terme dsigne les plates-formes telles que J2EE, CORBA, .Net (autre terme utilis : middleware).

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 38

La modlisation doit aussi permettre le contrle de la conformit aux rgles : celles du mta-
modle et aussi celles qui devront pouvoir tre fournies par l'utilisateur.
Pour UML on peut citer Objecteering, Poseidon, Visual Paradigm, Anterprise Architect,
Rational Software Modeler. Il y a aussi le projet, trs attendu, de plugin pour Eclipse nomm
GMF (Graphical Modeling Framework).

Illustration 13 - Intgration d'outils pour MDA [KADIMA 2005].

2.2. Pour les transformations


Ici aussi, nous trouvons deux fonctions.
Il faut pouvoir diter (modliser) les rgles de transformation. La modlisation de ces
transformations doit la fois prendre en compte les standards utiliss (mta-modles, langages)
et les spcificits fixes par l'utilisateur en fonction du cas d'espce.
Bien entendu, l'outil doit possder un moteur de transformation qui ralisera effectivement les
transformations.
titre d'exemple, on peut citer le trs prometteur ATL (Atlas Transformation Language) projet
compltement intgr Eclipse.

2.3. Pour la gnration du code


Dans une optique de gnration automatique du code (credo de MDA), il faut pouvoir

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 39

chronologiquement :
1. gnrer, partir du modle, le code conforme au langage ( la plate-forme)
d'implmentation cible : c'est le rle du gnrateur de code,
2. enregistrer celui-ci sous une forme partageable entre les diffrents outils de la chane
(format XMI) : c'est le rle du parser de fichier de code,
3. lire le fichier enregistr pour pouvoir l'diter et, ainsi, donner la possibilit de le
raffiner manuellement : c'est le rle de l'diteur de code.
La premire fonction est la frontire du dernier modle (PSM dans la cas de MDA) et de
l'implmentation. Cette fonction est dj propose par les outils de modlisation. Certains
diteurs d'outils ne rsistent d'ailleurs pas rduire la dmarche MDA cette seule gnration
automatique de code.

2.4. Pour le rfrentiel socle


Vritable fdrateur d'outils, le rfrentiel est le gage d'une rponse intgre la dmarche MDA.
Il va permettre de concevoir une chane d'outils qui pourront ainsi partager leurs artefacts du
dbut la fin du cycle de vie du projet.
Il est le cadre pour la mise en oeuvre du standard XMI. Ce standard permet l'activation de
collaborations entre des outils issus d'horizons diffrents.
Cette architecture permet le partage d'une tche complexe : la mise au point d'un outil global qui
fait tout. Chaque outil peut ainsi se spcialiser et tre un maillon de la chane.

La plate-forme de dveloppement devra permettre la manipulation des objets stocks dans le


rfrentiel, indpendamment des outils de production appartenant aux catgories prcdentes.

3. Synthse
travers ce rapide zoom sur l'outillage ncessaire la mise en oeuvre industrielle de MDA, on
peut se risquer tirer deux enseignements :
le processus est plus qu'en marche car les outils intgrs ou modulaires sont dj
disponibles ou en passe de l'tre,
mme si des plates-formes globales mono diteur (mais tout de mme modulaires)
existent (comme, par exemple, la gamme Atlantic de IBM Rational), la tendance est
l'agrgation d'outils d'horizons diffrents autour d'un socle commun (comme, par
exemple, la dmarche Eclipse). Les deux exemples cits sont-ils vraiment si trangers
que cela l'un de l'autre ?

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 40

Conclusion
1. MDA = nouveau paradigme actif et/ou utopie ?
1.1. Une rponse institutionnelle : les technologies cls pour 2010
Rfrence : [DGE 2006]
Le monde du dveloppement logiciel est en pleine industrialisation. l'instar du monde
industriel, il cherche de plus en plus reprsenter le rel pour concevoir des outils ou des
produits adapts une fonction.
L'ingnierie des modles (dont fait partie MDA) facilite les procdures de tests et la
gnralisation de code. Chaque spcialiste apporte sa plus-value mtier et un architecte logiciel
met en musique l'ensemble des briques logicielles.
Les efforts importants de normalisation raliss ces dernires annes (UML, XML,...) doivent se
poursuivre par un effort de recherche et de transfert vers l'industrie. Cela, notamment, dans la
dfinition de nouveaux modles, de nouvelles architectures, de nouveaux langages, de nouvelles
mthodes de preuve, de nouvelles mthodes d'analyse de code.
Il est aussi notable que de nouveaux marchs de fournisseurs de composants sont en train de
s'ouvrir et sont largement accessibles de nouveaux acteurs, notamment au sein des jeunes
entreprises.
La rponse, d'un point de vue institutionnel, incite au dveloppement de la recherche et de
l'conomie dans le domaine de l'IDM.

1.2. Une rponse mthodologique : MDA


MDA traite des problmatiques lies la multitude des plates-formes d'excution, de la manire
de prenniser et de rendre productifs les efforts de conception des applications logicielles.
L'OMG, son promoteur, fait le choix technologique du paradigme objet, MDA est donc
l'incarnation dans le monde objet de l'IDM. En ce sens, MDA n'est ni un appauvrissement ni une
concurrence, mais bien une forme (une instance) d'IDM.
MDA est un rassemblement et une orchestration de techniques qui ont, par ailleurs, leur
autonomie : UML (pour la modlisation), les techniques de transformations de modles (voir
[KADIMA 2005]), les standards utilitaires (XML, OCL,...).
Les travaux de standardisation de l'OMG sur MDA ont pour objectif de sparer les
proccupations mtier des contraintes techniques et d'infrastructures, tout en permettant la
transformation des modles et la gnration automatique de code. Cette approche apporte des

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 41

gains de productivit, oblige les dveloppeurs se proccuper plus du mtier cible du projet et,
en corollaire, permet d'apporter une rponse plus en adquation avec les besoins des utilisateurs
[KADIMA 2005].
Le cycle de modlisation indpendant de la plate-forme (CIM et PIM), avant de passer une
spcialisation mcanique pour chaque plate-forme cible (PSM), permet d'apporter une
rponse mthodologique ces proccupations.
MDA peut donc avoir un impact important sur des enjeux majeurs tels que la transformation des
modles, la gnration 100% de code partir des modles ou, encore, la fdration d'outils
spcialiss dans l'une ou l'autre des tches du cycle de vie.
Mais, pour viter les obscurantismes mystiques qui sont la source d'enfermement, il faut tre
raliste : la route n'est pas termine et des freins existent. Des freins techniques, des freins lis au
manque de maturit de certains standards (cf. XMI et ses diffrentes versions [BLANC 2005]),
des freins concurrentiels,...
La rponse mthodologique MDA est pleine d'espoir, le processus est plus que dmarr (en
croissance et au stade de la diffusion d'aprs [DGE 2006]), les outils commencent arriver sur
les tablis .

1.3. Une rponse organisationnelle : une mutation


Pour obtenir une application qui soit quasi-totalement code, il faut un modle spcifique (PSM)
complet et prcis et donc un modle indpendant (PIM) suffisamment complet et prcis. Il faut
aussi une modlisation des transformations trs aboutie.
Cette modlisation ncessite un long travail (nombreux diagrammes, granulit fine de ces
diagrammes, richesse et prcision smantique de ces diagrammes), avec le souci de prenniser
les investissements (outillage) et et de capitaliser le travail fourni.
MDA induit un transfert des activits de dveloppement traditionnel (modlisation de
conception, criture du code - Java, C++,... - de l'application) vers des activits de mta-
modlisation, de rglage des transformations de modles. La modlisation analytique, plus
abstraite, reste, elle, la mme ou s'tend dans la phase de conception.
Une mutation, ou un glissement des activits, est donc prvisible, tout comme une volution
ventuelle des comptences ncessaires.
Mais, l, MDA limite le risque : les standards utiliss ont dj une vie autonome, et MDA n'est
qu'une application nouvelle de ceux-ci. Ils sont donc relativement connus.
En effet, on peut considrer que la cration des mta-modles (gnraux ou de transformation) ne

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 42

relvent pas des quipes-projets (sauf si c'est cela le projet !). Ils doivent tre intgrs aux outils
de production. MDA ne deviendra une relle pratique des quipes que si elles peuvent s'abstraire
de la complexit de la mthode et, donc, se placer en crateur de modles. Les modles seront
contrls dans leur conformit aux mta-modles et seront passs la moulinette des moteurs de
transformation prconus et prrgls. Seul un paramtrage restera raliser.
La rponse organisationnelle se fait en deux temps :
la mise en place oprationnelle de MDA entrane une mutation d'une partie des
activits de dveloppement,
cette mutation est envisageable si les nouveaux outils permettent de s'abstraire des
contraintes de la mthode.
Cela alimente (et la boucle est boucle) la pertinence des recherches dans le domaine des
techniques, des outils de modlisation et de transformation de modles (mta-modles,
langage,...).

2. Caf-Philo (ou philosophie de comptoir ?)


Les traits sduisants d'UML, pour ne pas dire ses intrts, sont la simplicit (le simplisme
parfois) et le cot intuitif de sa reprsentation graphique.
En partie grce cela, UML s'est impos, dans le monde du gnie logiciel, comme un outil de
communication puissant entre les acteurs humains, de cultures diffrentes, rencontrs tout au
long du cycle de vie d'une application informatique.
On peut y ajouter sa simplicit de mise en oeuvre. Pour utiliser UML, un papier, un crayon, une
gomme et, au moins, un cerveau humain sont suffisants pour actionner le processus de
conception, puis le dialogue.
Le paradoxe de l'volution fait qu'on arrive aujourd'hui dsirer outiller outrance UML pour
que des machines puissent communiquer entre elles et puissent fabriquer le produit fini qu'est
l'application informatique. Et cela avec toute la complexit qui est inhrente une
automatisation.
Certes, et il ne faut pas l'oublier, l'tre humain est au deux bouts de la chane : il exprime un
besoin et il utilise l'application. Il est aussi derrire la machine pour spcifier les rgles de
fonctionnement de la machine.
Mais, pour le dbat, on peut poser les questions suivantes :
qui est au service de qui, l'humain ou la machine ?
Qui gagnera la partie ; qui dirigera l'autre ?

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 43

Bibliographie
Classement par ordre alphabtique de l'abrg dans chaque famille.

LIVRES

[BLANC 2005] BLANC X., 2005. MDA en action. Ingnierie logicielle guide par les modle.
Eyrolles, Architecte logiciel, PARIS, 269 p.
Cet ouvrage, pdagogique, permet une entre dans la mthode MDA. Sans tre un
ouvrage de rfrence pour chacun d'eux (ce n'est pas son objectif), il aborde bien tous les
standards en jeu dans MDA. Par ailleurs, un exemple pratique (la clbre application
PetStore) permet une approche concrte. Il a t pour moi une base pour l'tude de
MDA.

[DGE 2006] Collectif, 2006. Technologies cls 2010. Les Editions de l'Industrie, Collection
Textes cls, PARIS, 345 p. (http://www.tc-2010.fr/).
Cette publication du Ministre de lconomie, des Finances et de lIndustrie est le
rsultat d'une tude sur les technologies cls pour 2010. Une part y est consacre aux
technologies de l'information et de la communication. On y trouve, notamment, trois
articles o la modlisation est partie prenante : Outils et mthodes pour le
dveloppement de systmes d'information , Composants logiciels (cet article fait
directement rfrence MDA), Modlisation, simulation, calcul .

[FAVRE et al. 2006] FAVRE JM., ESTUBLIER J., BLAY-FORNARINO M., 2006.
L'ingnierie dirige par les modles. Au-del du MDA. Lavoisier - Hermes, CACHAN, 226.
Ce livre est une tude scientifique sur l'IDL. Aprs une exposition des principes et de la
philosophie de base, il dcline selon diffrents points de vue (le gnie logiciel, les plates-
formes, les langages, les bases de donnes, le temps rel, la rtro-ingnierie) les apports
possibles de l'IDM. Dans les deux premiers chapitres (ceux que j'ai lus pour la rdaction
de la premire partie ce mmoire), il est sympathiquement pjoratif propos de MDA
(dans un esprit constructif et argument). Cet ouvrage, rcent, mrite une lecture
approfondie.

[KADIMA 2005] KADIMA H., 2005. MDA Conception oriente objet guide par les modles.
DUNOD, Etudes & Dveloppement, PARIS, 232 p.
L'auteur prsente la philosophie et les concepts de MDA et ne s'y arrte pas. Aprs un
approfondissement des techniques de transformation, il dcline MDA dans une
mthodologie de gnie logiciel, pour terminer sur la description d'une tude de cas
dcline sur deux plates-formes (EJB et CORBA).
Ouvrage intressant rdig par un expert, peut-tre difficile d'accs dans le cas d'une
premire approche du sujet.
Ce livre a t pour moi un complment par rapport [BLANC 2005], une autre vue sur
MDA.

[LAROUSSE 1995] Collectif, 1995. Grand Larousse Universel. Larousse, Paris.


Dictionnaire encyclopdique qui m'a servi recadrer la dfinition de certains termes
utiliss dans la littrature informatique.

Jacques Barzic janvier 2008 - prob_mda_4.0


Probatoire informatique : Model Driven Architecture (MDA) 44

ARTICLES

[BEVIZIN 2004] BEVEZIN J., 2004. Sur les principes de base de l'ingnierie des modles.
RSTI, 10/2004, 145-157.
Article de 12 pages qui dcrit globalement MDA : son architecture et ses principes.

[BEZIVIN-BLANC 2002] BEZIVIN J., BLANC X., 2002. MDA : Vers un important
changement de paradigme en gnie logiciel. Dveloppeur Rfrence, V.2.16, 1 et 7-11.
Deux articles qui prsentent le changement de paradigme li MDA, sa porte et ses
limites.

COURS

[BEZIVIN 2003] BEZIVIN J.. Ingnierie des modles logiciels. Cours, CEA EDF INRIA,
2003.
(http://www.aristote.asso.fr/Presentations/CEA-EDF-2003/Cours/JeanBezivin/IndexJeanBezivin.html)
Un ensemble de diaporamas (format PowerPoint) sur UML, MDA, la transformation de
modle.

DOCUMENTS WEB

[OMG-MDA 2006] Collectif, 2006. Executive Overview.


http://www.omg.org/mda/executive_overview.htm.
[OMG-MDA 2003] MILLER J., MUKERJI J., 1995. MDA Guide Version 1.0.1.
http://www.omg.org/docs/omg/03-06-01.pdf.
[OMG-UML 2006] , 2006. Catalog of UML Profile Specifications.
http://www.omg.org/technology/documents/profile_catalog.htm.
Trois documents du site officiel de l'OMG sur MDA et UML.

[PLANETEMDE.ORG 2006] , 2006. Tools and Research Tools. http://www.planetmde.org/.


Un site de rfrence sur l'Ingnierie Dirige par les Modles. Site gr par Jean-Marie
Favre, co-auteur de [FAVRE et al. 2006] (voir ci-dessus).

[WIKIPEDIA-FR 2006] Collectif, 2006. Divers documents. http://fr.wikipedia.org.


L'encyclopdie Web bien connue.

CITATION DE DBUT DE MMOIRE

[LESCARBEAU et al. 2003] LESCARBEAU R., PAYETTE M., SAINT-ARMAUD Y.,


2003. Profession : consultant. Gatan Morin Editeur, 4me dition, Monreal (Qubec), 333 p.
Ouvrage sur le mtier de consultant (comme le titre l'indique clairement) qui propose un
modle applicable dans ce mtier.

Jacques Barzic janvier 2008 - prob_mda_4.0


Rsum
MDA (Model Driven Architecture) est une dmarche pour le dveloppement logiciel qui prne la
modlisation lors de toutes les tapes du cycle de vie des applications. Diffuse par l'OMG (Object
Managment Group), ds l'anne 2000, elle est base sur l'utilisation de standards dj spcifis par cette
organisation. Ces dernires annes ont vu MDA faire l'objet de recherches mthodologiques, d'volutions
des standards, de ralisation d'outils de mise en oeuvre.
MDA est maintenant dans une phase de transfert de technologie vers les utilisateurs finaux que sont les
quipes projets dans les entreprises et les socits de services spcialises (SSII).
Le prsent mmoire, rdig dans le cadre d'un examen probatoire en informatique du CNAM
(Conservatoire National des Arts et Mtiers), fait un point sur cette approche.
Y sont dfinis les concepts fondamentaux de l'Ingnierie Dirige par les Modles (IDM) dont MDA est
une application.
Ensuite les diffrentes tapes de la mthode, les modles successifs prconiss (y compris ceux pour la
transformation) sont dcrits et situs dans leur rle respectif.
Une dernire partie pose un regard sur les outils disponibles pour la mise en oeuvre de MDA et sur les
fonctions qu'ils doivent offrir aux utilisateurs.
Le parti pris de l'auteur est de se placer du cot de ceux qui peuvent avoir dcider d'une migration des
mthodes dans ce sens, plutt que de dcrire en dtail les mcanismes sous-jacents (ce qui a dj
largement t fait). Pour cette raison, on peut considrer ce mmoire comme un modle de MDA du
point de vue de ses destinataires.

Mots cls : Model Driven Architecture, ingnierie logicielle, modle, mta-modle, transformation de
modles.

Summary
MDA (Model Driven Architecture) is a software development process which recommends modeling at
the time of all the stages of the life cycle of the applications. Diffused by the OMG (Object Managment
Group), as of the year 2000, it is based on the use of standards already specified by this organization.
These last years saw MDA being the subject of methodological research, of evolutions of the standards,
realization of tools of implementation.
MDA is now in a phase of technology transfers towards the end-users who are the projects teams in the
companies and the specialized service companies (software firm).
The present report, written within the framework of a grading examination in computing of the CNAM
(Conservatoire National des Arts et Mtiers), gives a progress report on this approach.
The fundamental concepts of the Model Driven Engenering (MDE) (whose MDA is an application) are
defined.
Then the various steps of the method, the recommended successive models (including those for the
transformation) are described and located in their respective role.
A last part throws a glance on the tools available for the implementation of MDA and on the functions
which they must offer to the users.
The party taken of the author is to rather place the with dimensions one of those which can have to
decide on an organization in this direction, than to describe in detail the subjacent mechanisms (what was
already largely made). For this reason, one can regard this memory as a model of MDA from the point of
view of his recipients.

Key words: Model Driven Architecture, software engineering, model, metamodel, model transformation.

Vous aimerez peut-être aussi