Probatoire informatique : Model Driven Architecture (MDA)

Transcription

CONSERVATOIRE NATIONAL DES ARTS ET MÉTIERS
CENTRE RÉGIONAL ASSOCIÉ DE NANTES
___________
MÉMOIRE
présenté en vue d'obtenir
l'EXAMEN PROBATOIRE
en INFORMATIQUE
par
Jacques BARZIC
___________
Sujet
Model Driven Architecture (MDA)
Soutenu le 2 février 2007
JURY
Présidente : É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 mémoire est celle que j'ai livrée au CNAM et
qui a servi à mon évaluation de probatoire (note : 14/20). Chacun doit
l'utiliser avec l'esprit critique nécessaire et indispensable.
« Si votre seul outil est un marteau, tous les
problèmes, pour vous, ressembleront à des clous. »
Mark Twain.
« Le modèle est essentiel à l'acquisition d'une
compétence professionnelle, mais il peut aussi
emprisonner celui qui le suit à la lettre »
[LESCARBEAU et al. 2003]
3
Le sujet
Sujet proposé par Claude Belleil
[email protected]
Université de Nantes
Model Driven Architecture
Le Model Driven Architecture (MDA) est une démarche de développement proposée par l’OMG. Elle
permet de séparer les spécifications fonctionnelles d’un système des spécifications de son
implémentation sur une plate-forme donnée. A cette fin, le MDA définit une architecture de
spécifications structurée en modèles indépendants des plates-formes (PIM) et en modèles spécifiques
(PSM).
L’approche MDA permet de réaliser le même modèle sur plusieurs plates-formes grâce à des projections
standardisées. Elle permet aux applications d’interopérer en reliant leurs modèles et supporte l’évolution
des plates-formes et des techniques. La mise en œuvre du MDA est entièrement basée sur les modèles et
leurs transformations.
L’OMG voulait faire de CORBA «LE» middleware, mais aujourd’hui, il est loin d’être le seul à être
utilisé.
D’autres comme EJB ou .NET sont largement répandus. C’est en partant de cette observation que l’OMG
s’est engagé sur la voie du MDA, afin de résoudre les problèmes d’interopérabilité et de portabilité dès le
niveau modélisation. Le MDA se veut donc indépendant de toute plate-forme et de tout système, il
permet de concevoir des applications portables au niveau des langages de programmation, des systèmes
d’exploitation mais aussi des middlewares. Cette indépendance totale doit permettre de changer
d’infrastructure sans perdre ce qui a déjà été conçu. Cette approche permet ainsi de capitaliser le travail
effectué pendant les phases d’analyse et de conception.
Le logo du MDA (ci-dessus) représente les différentes couches de spécification. Au cœur se trouvent les
techniques (UML, MOF, CWM), autour, quelques-unes des plates-formes supportées, en surface les
services systèmes et enfin à l’extérieur les domaines pour lesquels des composants métiers doivent être
définis (Domain Facilities). Ces services (aussi bien systèmes que métiers) doivent être disponibles dès
les premières phases de modélisation, c’est pourquoi ils doivent faire partie des spécifications du MDA.
L’auditeur s’attachera à présenter les principales fonctionnalités de cette méthode en illustrant son
propos par des exemples originaux.
http://www.omg.org/mda/
Jacques Barzic
janvier 2008 - prob_mda_4.0
4
Table des matières
Le sujet............................................................................................................................ 3
Index des illustrations................................................................................................... 6
Liste des abréviations................................................................................................... 7
Avertissement................................................................................................................. 8
Introduction.................................................................................................................... 9
1ère Partie : méta-méta-modèle, méta-modèle, modèle, système, transformation ?
IDM, au secours ! !....................................................................................................... 11
1. Généralités à propos de l'IDM........................................................................................... 11
2. Les concepts socles de l'IDM..............................................................................................11
2.1. Le système..................................................................................................................... 11
2.2. Le langage......................................................................................................................12
2.3. Le modèle...................................................................................................................... 13
2.4. Le méta-modèle............................................................................................................. 14
2.5. Le méta-méta-modèle.................................................................................................... 14
2.6. La transformation.......................................................................................................... 15
3. Conclusion............................................................................................................................16
2ème Partie : Model Driven Architecture, approche pour les architectes
fabricateurs ?............................................................................................................... 17
1. Introduction......................................................................................................................... 17
2. Le schéma général 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 complémentaires (OCL, AS)............................................... 21
4.2.1 Principe pour la réalisation..................................................................................... 21
4.2.2 Les vues de l'architecture couvertes........................................................................21
4.2.3 Les modèles pertinents............................................................................................21
4.3. Illustration : le « Portillon » (suite)................................................................................22
4.3.1 Les composants.......................................................................................................22
4.3.2 Un diagramme de séquence.................................................................................... 23
4.3.3 Un composant......................................................................................................... 24
4.3.4 Rendre plus productif les modèles UML : OCL et AS...........................................24
5. La plate-forme d'exécution – Platform Description Model (PDM)................................ 26
5.1. Choix de la plate-forme................................................................................................. 26
5.2. Modélisation de la plate-forme......................................................................................27
5.3. On se passe du méta-modèle du modèle de la plate-forme........................................... 27
6. La transformation............................................................................................................... 28
6.1. Généralités.....................................................................................................................28
6.2. Le passage du PIM au PSM...........................................................................................29
Jacques Barzic
5
6.2.1 Description globale................................................................................................. 29
6.2.2 Modélisation des règles de transformation : le mapping........................................ 30
6.2.3 Construction d'un modèle intermédiaire : le PIM marqué......................................32
6.2.4 Exécution de la transformation...............................................................................32
7. Point de vue du concepteur – Platform Specific Model (PSM).......................................32
8. À propos des standards utilisés 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
3ème Partie : les outils pour MDA.............................................................................. 37
1. Généralités........................................................................................................................... 37
2. Une grille d'analyse des outils............................................................................................ 37
2.1. Pour la modélisation......................................................................................................37
2.2. Pour les transformations................................................................................................ 38
2.3. Pour la génération du code............................................................................................ 38
2.4. Pour le référentiel socle................................................................................................. 39
3. Synthèse................................................................................................................................39
Conclusion.................................................................................................................... 40
1. MDA = nouveau paradigme actif et/ou utopie ?.............................................................. 40
1.1. Une réponse institutionnelle : les technologies clés pour 2010.....................................40
1.2. Une réponse méthodologique : MDA............................................................................40
1.3. Une réponse organisationnelle : une mutation.............................................................. 41
2. Café-Philo (ou philosophie de comptoir ?)........................................................................42
Bibliographie................................................................................................................ 43
Jacques Barzic
6
Index des illustrations
Illustration 1 - La pile de modélisation 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 séquence : Création 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 : Opérations de transformation sur les modèles MDA [BEZIVIN-BLANC 2002].. 28
Illustration 9 - Le cycle en Y de MDA, adapté et complet (inspiration [BEZIVIN 2003])............29
Illustration 10 - Les classes modélisant 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 - Intégration d'outils pour MDA [KADIMA 2005]................................................38
Jacques Barzic
7
Liste des abréviations
AS : Action Semantics (Sémantiques de l'Action).
ATL : Atlas Transformation Language (Langage de Transformation du projet Atlas).
BI : Business Intelligence (Informatique Décisionnelle).
CIM : Computation Independent Model ( Modèle Indépendant de l'Informatisation).
CORBA : Common Object Request Broker : Architecture and Specifications (Architecture et
Spécifications pour la Mise à Disposition et la Requête sur des Objets Partagés).
CWM : Commun Warehouse Metamodel (Méta-modèle Commun aux Entrepôts de Données).
EDOC : Enterprise Distributed Object Computing (Informatique d'Entreprise à Objets
Distribués).
GMF : Graphical Modeling Framework (Cadre pour la modélisation Graphique) – Projet
Eclipse.
IDM : Ingénierie Dirigée par les Modèles.
J2EE : Java 2 Enterprise Edition (Édition Entreprise de Java 2).
MDA : Model Driven Architecture (Architecture Dirigée par les Modèles).
MDE : Model Driven Engineering (voir l'équivalent en français IDM).
MOA : Maîtrise d'OuvrAge.
MOE : Maîtrise d'OEuvre.
MOF : Meta Object Facility (Service Méta-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 (Modèle Indépendant de la Plate-forme).
PM : Platform Model (Modèle de la Plate-forme).
PDM : Platform Description Model (Modèle de Description de la Plate-forme).
PSM : Platform Specific Model (Modèle Spécifique à la Plate-forme).
QVT : Query, View, Transformation (Demande, Vue, Transformation)
UML : Unified Modeling Language (Langage de Modélisation Unifié).
XMI : XML Metadata Interchange (Echange de Méta-données en XML).
XML : eXtensible Markup Language (Langage à Balises eXtensible).
Jacques Barzic
8
Avertissement
De nombreux termes de ce mémoire sont mentionnés en langue anglaise. Bien que, dans la
plupart des cas, une traduction en français soit possible, les termes anglais sont tout de même
utilisés :
•
soit pour faire le lien avec les documents sources. Dans ce cas la traduction française apparaît
après la première apparition du terme,
•
soit parce que la traduction (par une expression courte) dénaturerait le concept désigné. Dans
ce cas, seule l'expression anglaise est utilisée.
Les mots ou expressions en langue anglaise sont écrits en italique.
Jacques Barzic
9
Introduction
On aurait pu penser initialement que la technologie objet constituerait un aboutissement. C'était
au contraire un point de départ pour une nouvelle migration technologique [BEVIZIN 2004].
Un des chemins possibles pour cette migration est d'adopter un nouveau paradigme : le tout
modèle après le tout objet.
Avec cette nouvelle donne, une discipline a vu le jour : le MDE (Model Driven Engineering) ou
l'IDM (Ingénierie Dirigée par les Modèles).
C'est dans ce contexte, en novembre 2000, que l'OMG (Object Management Group) a rendu
publique son initiative nommée 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 fusée. Je sortais à peine de
l'intégration culturelle et méthodologique 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 télescopent, se
mélangent ou semblent se concurrencer. Face à cet imbroglio, la réaction 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 nécessaire. Le propos de cette étude sera donc de participer à la lutte contre
une certaine forme d’obscurantisme.
MDA se veut une approche méthodologique qui permet une optimisation des investissements liés
aux développements d'applications informatiques [OMG-MDA 2006].
MDA reprend la philosophie générale de l'IDM, la décline pour l'adaptation de modèles
« métiers » à la plate-forme d'implémentation.
MDA utilise des standards reconnus, ouverts (car ceux de l'OMG) et éprouvés (car largement
utilisés dans l'industrie du logiciel - cf. UML).
Ces caractéristiques font-elles de MDA une démarche « réelle et sérieuse » ?
Jacques Barzic
10
La première partie de ce mémoire reprendra quelques concepts fondamentaux de l'Ingénierie
Dirigée par les Modèles. En effet, MDA est considérée comme une déclinaison de l'IDM
[BEVIZIN 2004] ou comme une simple collection de standards [FAVRE et al. 2006]. Il apparaît
utile de généraliser, ici, des concepts qui sont utilisés par MDA.
Une seconde partie traitera de la manière dont MDA décline ces concepts, pour en faire une
approche qui permet de modéliser un système en se détachant de la plate-forme
d'implémentation. Cela, le plus loin possible dans le cycle de développement. En toute logique,
sera aussi abordé dans cette partie le processus de transformation de modèle, pierre angulaire de
MDA.
Enfin, la troisième partie participera à rassurer notre informaticien obscurantiste en faisant un
zoom sur les outils de mise en oeuvre de l'approche MDA.
Jacques Barzic
11
1ère Partie : méta-méta-modèle, méta-modèle, modèle,
système, transformation ? IDM, au secours ! !
1. Généralités à propos de l'IDM
Dans un contexte d'accroissement exponentiel de la complexité des systèmes informatiques, la
modélisation de ces systèmes est devenue un enjeu majeur de la réussite des projets : bonne
prise en compte du besoin fonctionnel, réduction des délais et des coûts par la réutilisation des
conceptions et des liens avec le code et, enfin, souplesse nécessaire pour l'adaptation des
applications aux différentes technologies actuelles ou futures.
L'Ingénierie Dirigée par les Modèles (IDM), ou son équivalent en anglais Model Driven
Engineering (MDE), est une approche du développement d'applications informatiques qui vise à
mécaniser le processus que les ingénieurs expérimentés suivent à la main [WIKIPEDIA-FR
2006].
Pour cela, il s'agit de faire passer les modèles du statut contemplatif (utilisé pour la
documentation, l'aide à la compréhension) au statut productif (automatisation de la génération de
code à partir du modèle) [FAVRE et al. 2006].
L'IDM doit être vue comme une intégration, un prolongement, un renforcement d'approches déjà
connues. Ce n'est pas une révolution mais une évolution qui puise dans l'existant [FAVRE et al.
2006].
En cela, notre informaticien obscurantiste de l'introduction doit déjà être rassuré sur l'impact
« culturo-méthodologique » de ce genre d'approche : s'il a intégré les standards actuels de
modélisation (UML en tête), il sait déjà presque tout !
Le sujet de ce probatoire n'étant pas l'IDM, nous nous contenterons, ici, de définir quelques-uns
de ses concepts fondamentaux qui seront, dans la suite du document, repris et adaptés à la
spécificité de MDA.
2. Les concepts socles de l'IDM
Sauf indication contraire, la référence pour cette section est [FAVRE et al. 2006].
2.1. Le système
Le système, au sens de l'IDM, est ce que l'on désire modéliser. Il est le réel.
Une typologie des systèmes est proposée : système physique (chien, maison, vélo,...), système
digital (fichier, diagramme, logiciel,...), système abstrait (compte bancaire, cercle, cours,..).
Jacques Barzic
12
Un système peut aussi être dynamique (changer dans le temps) ou statique (immuable, du moins
dans une échelle de temps relativement grande).
Le système se situe au niveau M0 de la pile classique à quatre niveaux de l'OMG, représentée cidessous.
Illustration 1 - La pile de modélisation de l'OMG (inspiration [BEZIVIN 2003])
Les quatre niveaux de la pyramide représentent les niveaux taxinomiques d'une pile de
modélisation. Les sections suivantes définiront leur rôle et les relations entre eux.
Pour illustrer les concepts abordés dans cette partie, nous allons prendre comme exemple le
système que constitue le présent mémoire de probatoire.
On constate, au passage, qu'il est à ce stade difficile de le classer conformément à la typologie cidessus : à la fois physique (il pèse 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 systèmes de la même famille. Pour faire
une analogie avec les langues, on peut dire que le langage français est l'ensemble des phrases
rédigées dans cette langue.
Exprimé d'une autre manière, le langage est le domaine du monde réel (M0) auquel appartient le
système que l'on se propose d'étudier. Bien entendu, il appartient aux acteurs d'un projet, de
s'entendre dès le départ sur la surface de ce domaine.
Dans le cas de notre exemple, on considérera le langage comme l'ensemble des mémoires (de
probatoire ou non) qui ont été, qui sont et qui seront rédigés par des auditeurs du CNAM.
Jacques Barzic
13
2.3. Le modèle
Ici, plusieurs définitions se côtoient. Nous retiendrons celle qui semble couvrir le mieux notre
propos (elle est prêtée à Bézivin et Gérbé par [FAVRE et al. 2006]).
Un modèle est une simplification d'un système, construit avec une intention de
comprendre le système en adoptant un point de vue défini. Le modèle répondra à des
questions à propos du système.
Dans son cours, [BEZIVIN 2003] précise cette définition :
•
un modèle n'est qu'une représentation partielle (un aspect) du système (le réel),
•
un système peut donc avoir plusieurs modèles.
Le modèle se situe au niveau M1 de la pile OMG (voir Illustration 1).
Pour illustrer ce qu'est un modèle, il est souvent fait référence à une carte géographique comme
modèle d'un territoire terrestre. Cette illustration répond bien à la définition car :
•
il y a représentation simplifiée du réel,
•
on peut créer de nombreuses cartes pour répondre à d'aussi nombreuses questions :
comment trouver son chemin ? Quelles sont les rivières et leur parcours ?...
Si l'on désire modéliser ce mémoire de probatoire, on peut le faire de la manière suivante :
Auteur : Jacques Barzic
Statut de l'auteur : auditeur au CNAM de Nantes
Type : Mémoire de probatoire CNAM
Nombre de pages : 40
Titre : MDA (Model Driven Architecture)
Table des matière :
Introduction..........................................................................................................................................1
1ère Partie : méta-méta-modèle, méta-modèle, modèle, système, transformation ? IDM, au
secours ! !...............................................................................................................................................3
1. Généralités à propos de l'IDM...................................................................................................... 3
2. Les concepts socles de l'IDM......................................................................................................... 3
2.1. Le système......................................................................................................................... 3
2.2. Le langage......................................................................................................................... 4
2.3. Le modèle.......................................................................................................................... 5
...
On obtient bien là une représentation simplifiée du mémoire qui répond à certaines questions à
son propos : nous nous plaçons là du point de vue de la description du contenu (système abstrait),
comme peut le faire une bibliothèque (une librairie) pour diriger le lecteur (l'acheteur) potentiel.
La relation qui lie le modèle et le système est ReprésentationDe.
Jacques Barzic
14
2.4. Le méta-modèle
L'originalité de l'IDM est de faire appel à ce concept, au lieu de faire systématiquement appel à
de nouveaux modèles : on généralise, en quelque sorte.
La définition d'un méta-modèle est courte mais chargée de sens : il s'agit d'un modèle qui définit
le langage.
Le méta-modèle se situe au niveau M2 de la pile OMG (voir Illustration 1).
Si l'on reprend l'exemple des cartes géographiques :
•
le langage pourrait être l'ensemble des cartes routières (on pourrait réduire le domaine
en citant un éditeur),
•
la légende de ces cartes serait un modèle de ce langage : une ReprésentationDe,
•
la légende est donc un méta-modèle d'une carte donnée : celle des routes de France, par
exemple.
Dans le cas du mémoire de probatoire :
•
le langage : tous les mémoires d'auditeurs du CNAM référencés dans la
« mémoirethèque »,
•
la trame d'une fiche de la « mémoirethèque » est un modèle pour le langage :
ReprésentationDe,
•
cette trame est donc un méta-modèle pour le présent mémoire de probatoire.
La relation qui lie le modèle et le méta-modèle est ConformeÀ.
2.5. Le méta-méta-modèle
Pour définir le méta-méta-modèle, il suffit de reprendre le raisonnement précédent en montant
d'un niveau :
•
en considérant l'ensemble des modèles comme un langage : l'ensemble des cartes d'un
pays (pas que les routières),
•
en considérant l'organisation d'une légende (méta-modèle en soi) comme un modèle de
ce langage : ReprésentationDe,
•
l'organisation d'une légende devient un méta-modèle du modèle : donc un méta-métamodèle d'une carte donnée (de celle des routes de France, mais aussi de celle des
départements français).
Jacques Barzic
15
Le méta-méta-modèle se situe au niveau M3 de la pile OMG (voir Illustration 1).
La pile de l'OMG s'arrête au niveau M3. En effet, il faut, à un moment donné, stopper la « métaescalade ». Les standards de représentation graphique (dans le monde des modèles
objet)permettent de constater que le diagramme dont le niveau serait M4, est le même que celui
du M3. En cela, on peut dire que le méta-méta-modèle se représente lui-même [BLANC 2005].
Quel peut être alors le méta-méta-modèle du présent mémoire ?
La manière d'organiser une fiche de bibliothèque.
Par exemple : une fiche de bibliothèque 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 soirées 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 départ et un état
d'arrivée.
Il s'agit, ici, de transformer un modèle existant (chargé de ses méta et méta-méta modèles) en un
modèle n'ayant pas la même pile de modélisation (autres méta et méta-méta modèles). Dans
[FAVRE et al. 2006], les auteurs parlent d'espaces techniques différents.
Lors de cette opération, les méta-modèles prennent toute leur importance. Les règles de passage
d'un modèle à un autre modèle seront spécifiées au niveau des méta-modèles. Ainsi, toutes les
transformations de modèles pourront être réalisées par l'activation de ces règles, théoriquement
sans nouvelle spécification. La définition des méta-règles sera d'autant plus naturelle si les métamodèles dépendent du même méta-méta-modèle.
Pour la représentation des territoires, cela consisterait, par exemple, à transformer les cartes en
représentation 3D (type photos aériennes), autre représentation d'une même réalité et répondant à
des règles (pile de modélisation) différentes.
Jacques Barzic
16
On peut imaginer, pour la fiche de « mémoirethèque » du mémoire de probatoire, de la
transformer en une séquence sonore pour les personnes mal-entendantes ou en Braille pour les
personnes non-voyantes.
En sortie de la transformation, on obtient un autre modèle du même système (de la même réalité).
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 réutilisation des résultats de la
conception, vers une adaptation possible à des environnements différents, vers une prise en
compte de l'évolution future des technologies.
La puissance de la méta-modélisation est un gage de réussite de cette approche : en effet, on
s'aperçoit que, plus on monte dans la pile de modélisation, 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 méta-méta-modèles et les méta-modèles d'espaces techniques différents
sont formalisés et diffusés ou, mieux encore, se standardisent, la transformation des modèles
pourra se faire automatiquement.
C'est à cette standardisation que l'approche MDA participe dans son domaine d'action.
Jacques Barzic
17
2ème Partie : Model Driven Architecture, approche pour les
architectes fabricateurs1 ?
1. Introduction
Le titre de cette partie, un brin provocateur, résume quelques questions centrales à propos de
cette démarche.
Comment monter d'un cran dans l'abstraction ?
L'automatisation totale des activités de codage est-elle une préoccupation d'alchimiste ou une
réalité possible ?
Les enjeux sont pourtant importants [BLANC 2005] :
•
pérennisation des savoir-faire,
•
amélioration de la productivité,
•
prise en compte des plates-formes d'exécution.
Comme nous l'avons déjà vu, MDA est une démarche, de type IDM, pour la conception de
systèmes informatiques. L'activité opérationnelle principale (unique ?) des informaticiens la
pratiquant doit tendre à être la modélisation.
Pour répondre aux enjeux, MDA se concentre sur un objectif dichotomique : modéliser le plus
possible en s'abstrayant de la plate-forme d'exécution et modéliser l'adaptation à la plate-forme.
Dans cette partie, nous allons voir quelle méthode et quels outils standardisés 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 mensongères ; fabricant (langue soutenue et péjor.) : Fabricateurs de mots inutiles.
Fabricateurs de fausses nouvelles, de rêves. [LAROUSSE 1995].
Jacques Barzic
18
2. Le schéma général de MDA
Illustration 2 - Le cycle en Y de MDA (inspiration [BEZIVIN 2003]).
La démarche MDA est une orchestration de différents modèles issus de 4 points de vue
principaux. On devrait, plus exactement, dire 3 +1 points de vue.
Le guide MDA de l'OMG en décrit explicitement trois [OMG-MDA 2003] : Computation
Indépendant Viewpoint, Platform Indépendent Viewpoint, Platform Specific Viewpoint. Ceux
sont les points de vue que prennent les modèles sur le système à développer.
On peut en ajouter un autre, dont le guide OMG [OMG-MDA 2003] cite le modèle résultant, qui
a son importance : la vue qu'a l'équipe-projet de la plate-forme d'implémentation. C'est un point
de vue que prend le système à développer sur un versant de son environnement.
Chaque point de vue sera source de modèle(s), éléments fondamentaux de la démarche (les
ovales de l'Illustration 2).
La rencontre des deux branches supérieures du Y est un moment délicat : deux modèles doivent
« fusionner » pour en produire un nouveau. MDA préconise aussi de modéliser cette
transformation.
À ce stade, on comprend mieux le caractère « dirigée par les modèles » de la démarche. Dans un
processus idéal allant du haut vers le bas (« top-down »), on part de modèles, on traite des
modèles successifs, pour obtenir, in fine, la réalité recherchée : le code.
Jacques Barzic
19
Mais à ce propos : le code n'est-il pas lui-même un modèle ? Ne représente-t-il pas la réalité des
impulsions électriques qui font fonctionner les ordinateurs ? Ou, d'une autre manière, la réponse
aux besoins de la maîtrise d'ouvrage (la raison de notre projet) ?
Admettons, ici, que le code est notre réalité, notre système. Ses passages à travers une machine
virtuelle et/ou un système 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
Littéralement « Modèle Indépendant de l'Informatisation », ce modèle est chargé de représenter
les exigences de la maîtrise d'ouvrage. Comme son nom l'indique, ce modèle devra représenter
ces exigences sans aucune référence à la réalisation de l'application ou aux traitements [BLANC
2005]. Il est parfois aussi nommé « Modèle du Domaine » ou « Modèle Métier » [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 développement.
La première étape est donc de traduire le cahier des charges en un autre modèle, outil de
communication entre les utilisateurs et les informaticiens analystes.
Ce premier modèle doit être un outil de traçabilité, contractuel, par rapport au résultat
(l'application) attendu [OMG-MDA 2003].
L'OMG ne préconise pas de formalisme particulier à ce stade (même si des travaux sont en cours
pour y adapter UML) [BLANC 2005].
L'utilisation du diagramme des cas d'utilisation UML est adaptée à ce modèle. Issu du même
méta-modèle (UML) que les modèles 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
20
3.2. Illustration : le « Portillon »
Pour illustrer cette partie, nous allons suivre un portail très 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)
Après la récupération et la représentation des exigences client par le CIM, il faut maintenant
passer à la représentation informatique des ces exigences : une nouvelle étape vers une
application.
Le point de vue de l'analyste doit se considérer avec l'objectif suivant : traduire l'expression des
experts « métiers » pour qu'elle soit non seulement compréhensible, mais aussi exploitable par
les experts informatiques chargés de la production de l'application.
Ici, le méta-modèle 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 indépendant des
langages (plates-formes) de programmation, il propose plusieurs diagrammes répondant à des
préoccupations complémentaires [BLANC 2005].
Jacques Barzic
21
4.2. Organisation et standards complémentaires (OCL, AS)
4.2.1 Principe pour la réalisation
Dans l'absolu, la transformation du CIM vers le PIM peut être modélisée et, ainsi, tracée.
Comme, pour le moment, MDA ne préconise aucun méta-modèle standard pour réaliser 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 dès le départ pour avoir une cohérence entre les deux étapes
et se préparer pour le moment où UML sera suffisamment défini pour permettre une
mécanisation de ce passage.
Malgré sa connotation informatique, le PIM doit rester (comme son nom l'indique) indépendant
de la plate-forme d'exécution. On va donc, ici, se concentrer sur la représentation de l'architecture
modulaire de l'application, des connections entres les modules, du contenu des modules, des
tâches réalisées par les modules.
4.2.2 Les vues de l'architecture couvertes
Il est aujourd'hui admis de considérer trois niveaux d'abstraction dans la construction de
l'architecture d'un système d'information : le niveau métier, le niveau fonctionnel et le niveau
technique [KADIMA 2005].
Le niveau technique de l'architecture correspond à la plate-forme d'exécution, il est couvert par le
PSM (voir § 7). Si l'on considère que le PIM doit être réalisé du point de vue de l'entreprise (on
pourrait dire « macro-métier »), du point de vue informatique et, éventuellement, du point de vue
d'une architecture distribuée [OMG-MDA 2003], on déduit qu'il couvre :
•
le niveau métier de l'architecture : il s'agit là de modéliser les invariants du métier, par
définition non liés à l'organisation de l'entreprise spécifique,
•
le niveau fonctionnel de l'architecture : on intègre ici l'organisation de l'entreprise
étudiée ainsi que l'organisation de son système d'information. On réalise un profil du
métier pour l'entreprise [KADIMA 2005].
4.2.3 Les modèles pertinents
Plusieurs modèles 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 séquence ou d'activité pour les aspects dynamiques.
2 Meilleure prise en compte par UML 2.0.
Jacques Barzic
22
À cela viendra s'adjoindre une modélisation des contraintes et de l'algorithmie qui ne pourraient
être exprimées 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 méta-modèles, conformes au métaméta-modèle MOF (Meta Object Facility) comme UML [BLANC 2005].
OCL et AS sont deux standards clés utilisés par MDA, dans le but de rendre productifs des
modèles.
OCL et AS sont indépendants de la plate-forme. Les modèles correspondant peuvent (voire
doivent) être intégrés au PIM.
4.3. Illustration : le « Portillon » (suite)
Un modèle PIM qui se tient comportera différents diagrammes UML. Ils seront constitués et
raffinés au cours de différentes itérations. On se retrouve à appliquer un cycle de développement
itératif et incrémental.
L'objet de ce mémoire n'étant de décrire ni les cycles de développement ni le langage UML, nous
allons continuer notre illustration avec des diagrammes simplifiés et hypothétiques.
4.3.1 Les composants
Illustration 4 - PIM du "Portillon" - Les Composants
Jacques Barzic
23
L'Illustration 4 montre les quatre composants qui pourraient constituer notre « Portillon ». Ce
diagramme offre l'intérêt de bien montrer la répartition des fonctionnalités et des opérations qui
seront réalisées 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, décider
de la distribution (ou s'adapter à une distribution existante) du système informatique. Dans le
même esprit, une adaptation aux technologies pourra se faire : serveur de messagerie existant,
annuaire à créer, planning en Web Service, par exemple.
4.3.2 Un diagramme de séquence
Illustration 5 - PIM du "Portillon" – Diagramme de séquence : Création de Planning
L'Illustration 5 présente un diagramme de séquence nominal d'un des scénarios possibles pour la
création d'un planning de groupe.
Ce diagramme modélise le fonctionnement dynamique d'un composant (Planning, ici). La
méthode incrémentale permettra de préciser la totalité des scénarios possibles (nominaux,
alternatifs et d'erreur) au fur et à mesure des itérations.
Jacques Barzic
24
4.3.3 Un composant
L'intérieur des composants pourra être représenté 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 modèles UML : OCL et AS
Rappelons que ces deux langages sont partie intégrante du méta-modèle UML. Ils sont donc
complètement spécifiés dans celui-ci et conformes au méta-méta-modèle MOF. Ces
caractéristiques leur confèrent bien une nature de standards transversaux à la démarche MDA.
OCL (Object Constraint Language)
En appliquant OCL à un modèle source (un PIM, par exemple), on rend celui-ci plus précis et
plus complet. Cette richesse augmentée (du modèle source) rend possible l'obtention d'un modèle
cible (PSM dans la démarche MDA) d'autant plus riche (ayant donc une productivité augmentée)
[KADIMA 2005].
Jacques Barzic
25
Sans entrer dans une description de ce langage (hors du cadre de ce mémoire), voici quelques
éléments caractéristiques.
•
Son application aux modèles UML permet de définir des contraintes sur l'état des
objets modélisés comme sur les données échangées lors de l'évocation des méthodes
[BLANC 2005].
•
OCL ne produit pas d'effet de bord : son rôle n'est pas de modifier une valeur mais de
contraindre à ce que les valeurs soient dans un cadre précis [BLANC 2005].
•
Les contraintes exprimées par OCL doivent se solder par un résultat booleen.
•
Sa situation au niveau du méta-modèle UML lui permet d'être utilisé dans la définition
des méta-modèles (pour les préciser) ou pour assurer du lien entre méta-modèles
[KADIMA 2005].
•
En plus de sa spécification au niveau du méta-modèle, OCL dispose d'une syntaxe
textuelle standard pour s'exprimer. Ceci facilite son utilisation par des outils différents
(ce qui respecte l'objectif de pérennité des modèles).
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 définit l'élément cible de la contrainte : ici, la classe Message.
Les lignes 2 et 3 définissent 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
spécifiés.
Lors de contraintes sur les opérations, OCL peut aussi spécifier des pré-conditions et/ou des postconditions.
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 vérifie que le contact que l'on veut ajouter n'existe pas déjà 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
modèle) : il va décrire le comportement dynamique du modèle.
Jacques Barzic
26
AS est le socle des modèles dynamiques de UML (activité, séquence, machine d'états). Cela offre
une cohérence, porteuse de productivité, entre tous ces modèles [BLANC 2005].
AS peut aussi être utilisé en tant que tel pour enrichir les modèles. Il est complètement spécifié
dans le méta-modèle UML mais il ne dispose pas d'une syntaxe textuelle standard. Cette dernière
caractéristique est un frein à son utilisation dans les outils de modélisation : chaque éditeur doit
spécifier sa propre syntaxe, avec le corollaire de l'incompatibilité entre les différents outils (donc
du manque de portabilité des modèles).
On peut considérer AS comme une abstraction des langages de programmation indépendante
d'un langage donné [KADIMA 2005]. Cela lui donne une puissance potentielle pour être le métamodèle (et pour les modélisations associées) de la génération du code interne aux opérations.
Même si la génération complète de code à partir d'un modèle PIM paraît actuellement peu
réaliste (car complexe à mettre en oeuvre), le chemin est ouvert.
Actuellement, AS est donc plus utilisé au niveau des méta-modèles pour spécifier les
comportements des éléments des modèles associés. Il va, grâce à cela, être un des outils
disponibles pour gérer l'opération de transformation [KADIMA 2005].
5. La plate-forme d'exécution – Platform Description Model (PDM)
Après avoir parcouru la branche située à gauche du cycle en Y de MDA (voir l'Illustration 2) et
avant de procéder à la transformation qui nous mènera vers le modèle spécifique à la plate-forme
d'exécution, il nous faut définir cette plate-forme.
C'est la branche située à droite du Y. On en dégage deux étapes :
1. le choix de la plate-forme et l'obtention de son modèle du point de vue de l'utilisateur
(que nous sommes, dans le cadre d'un projet),
2. la modélisation 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 cohérent de fonctionnalités et
sur laquelle vont s'exécuter les applications. L'intérêt est que l'utilisation d'une plate-forme ne
nécessite pas de connaître comment les fonctionnalités sont réalisées : l'accès se fait par les
interfaces qu'elle présente [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 considérer que les systèmes d'exploitation sont des plates-formes
(Windows, Unix,...).
L'indépendance par rapport à la plate-forme et donc aussi très relative (exemple : une application
Jacques Barzic
27
J2EE, donc son modèle spécifique, peut être considérée comme indépendante de la plate-forme
car pouvant s'exécuter indifféremment sur plusieurs systèmes d'exploitation). Une discussion sur
ce sujet dépasse le cadre de ce mémoire.
L'architecte du projet doit choisir une plate-forme ou faire avec l'existante. Disposant du modèle
indépendant 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 système hétérogène). C'est
cela qui va conditionner l'organisation de la transformation de modèle.
5.2. Modélisation de la plate-forme
Dans l'absolu, la plate-forme, du point de vue du projet, est modélisable : description de ses
fonctionnalités, de son architecture, des modes d'accès à ses fonctionnalités, des interactions
entre les différents éléments 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 méta-modèles (voir définition de la transformation, partie 1 § 2.6).
Et là, un manque évident apparaît : si le méta-modèle ayant servi à l'élaboration du PIM est
connu (UML, OCL,...), l'obtention du méta-modèle du PM est loin d'être acquise. Cela sousentendrait que les éditeurs de plates-formes se mettent d'accord sur un méta-modèle commun...
5.3. On se passe du méta-modèle du modèle de la plate-forme
Pour résoudre ce problème, en attendant une standardisation des méta-modèles 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
28
Cette adaptation part d'un constat : les informations relatives à une plate-forme donnée sont
contenues dans le méta-modèle du PSM. Les règles de transformation seront définies à partir de
ce méta-modèle, en lieu et place de celui du modèle de la plate-forme. La limitation de cette
technique est que la généralisation sera plus restreinte, car faite pour une plate-forme donnée
[BLANC 2005] : il faudra un méta-modèle par plate-forme.
Le méta-modèle du PSM est aussi appelé Platform Description Model (PDM) [KADIMA 2005].
À ce stade, nous disposons d'une représentation indépendante de la plate-forme de notre
application (le PIM), d'une représentation de la plate-forme cible (le PDM) et de leur métamodèles respectifs. Nous allons maintenant pouvoir organiser et procéder à la transformation
vers la représentation spécifique à la plate-forme de notre d'application.
6. La transformation
6.1. Généralités
MDA étant basée sur la manipulation de modèles, le passage de l'un à l'autre (et vice versa) est
une activité centrale de la méthode. L'Illustration 8 présente les différentes opérations de
transformation de modèles que l'on peut trouver dans MDA.
Illustration 8 : Opérations de transformation sur les modèles MDA
[BEZIVIN-BLANC 2002].
Le passage d'un modèle type UML à du code écrit en langage évolué (Java, C++,...) [5] 3, que l'on
considère ici comme un modèle, est déjà bien implémenté dans les outils de modélisation
(génération de squelette d'application).
Les transformations réflexives de modèles (PIM/PIM [1], PSM/PSM [3], Code/Code [6]) seront
effectuées soit lors d'ajouts d'éléments pour représenter des niveaux différents d'abstraction, soit
pour optimiser un modèle lorsqu'une transformation non réflexive est incomplète ou pas assez
précise (raffinage). Il est important de noter que ces transformations réflexives ne sont pas
toujours automatisables [BEZIVIN-BLANC 2002].
3 Sont notés sous cette forme les rappels aux numéros de l'Illustration 8.
Jacques Barzic
29
Les transformations [4] et [7], font partie de l'activité de rétro-ingénierie. Cette dernière fait
partie de la philosophie de MDA et mériterait une étude à elle seule.
La transformation centrale de MDA (et aussi la plus délicate) est le passage du PIM vers le PSM
[2]. Il est temps maintenant de s'y arrêter plus longuement.
6.2. Le passage du PIM au PSM
Nous avons vu comment adapter le cycle en Y pour obtenir un modèle de la plate-forme
d'implémentation (voir § 5.3).
Voici une illustration plus complète de ce cycle. Dans cette section, nous allons décrire 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 développement, nous disposons :
•
du PIM et de son méta-modèle (UML),
•
du méta-modèle du PSM (profil UML4) ou PDM.
Les étapes suivantes vont se dérouler :
•
modélisation des règles de transformation (le mapping),
•
construction d'un modèle intermédiaire (le PIM marqué),
•
exécution de la transformation.
4 Sous-ensemble de UML comprenant des stéréotypes, des tagged-values et des contraintes. Ici le profil sera celui
de la plate-forme d'implémentation (voir compléments § 8 de cette partie).
Jacques Barzic
30
6.2.2 Modélisation des règles de transformation : le mapping
Cette étape consiste à définir les règles de transformation d'un modèle à l'autre. Comme nous
l'avons vu, cette définition se fait au niveau des méta-modèles.
Un exemple
Le passage d'un diagramme de classes UML vers un MCD Merise5.
Illustration 10 - Les classes modélisant un groupe d'apprentis.
Passons sur la sémantique « métier » des éléments, pour illustrer l'idée des règles de
transformation (on pourrait parler de méta-règles) liant les méta-éléments UML et Merise :
•
une classe UML devient une entité Merise,
•
un attribut de classe devient une propriété d'entité,
•
une association devient une association.
L'application de ces trois règles 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,
caractéristiques de la problématique du mapping. Par exemple :
1. Les trois règles donnent une correspondance entre types d'éléments. Ceci permettra
d'automatiser l'opération.
5 Je travaille actuellement dans un Centre de Formation d'Apprentis : ceci explique l'inspiration de l'exemple !
Jacques Barzic
31
2. A contrario, on trouve des attributs de classe qui deviennent de simples propriétés d'entité, et
d'autres qui deviennent (participent à être) l'identifiant d'entité. On doit alors préciser la règle :
« un attribut de classe devient une propriété d'entité ou peut participer à être l'identifiant
d'entité ».
Il ne faudra alors pas éluder les questions : qui, au moment de l'exécution de la
transformation, décidera de la partie de l'alternative à mettre en oeuvre ? Comment cette
décision sera formalisée ?
Généralisation
Actuellement, trois approches permettent la spécification de règles de correspondance [BLANC
2005].
1. Par programmation : on utilise un langage de programmation connu (Java, C++,..) et on
conçoit la transformation comme n'importe quelle application informatique. C'est puissant,
efficace, habituel : c'est, sans doute, encore la méthode la plus utilisée car très outillée. Le
revers est, là encore, la dépendance au langage de programmation.
2. Par template (patron) : on élabore un canevas du modèle cible souhaité et, lors de la
transformation, on remplace les valeurs du canevas par celles du cas d'espèce traité. La
puissance de la méthode dépend de la précision des canevas et, donc, du langage utilisé pour
les définir. Il faut aussi faire attention : un canevas peut devenir un carcan.
3. Par modélisation : sans doute la méthode la plus prometteuse [KADIMA 2005]. Elle ouvre la
voie vers une méta-modélisation des transformations avec les avantages que cela comporte :
pérennité, productivité, indépendance par rapport aux outils et aussi harmonie avec le
paradigme MDA.
La potentialité de l'approche par la modélisation est renforcée par deux faits principaux.
1. Dans le cycle en Y de MDA (voir Illustration 9), le modèle source (le PIM) et le modèle cible
(le PSM) sont issus du même méta-modèle (UML ou profil UML) : cela facilite la métamodélisation des règles de correspondance.
2. Pour aller dans ce sens, l'OMG a défini un méta-modèle standard d'expression des règles de
transformation : QVT (Query/View/Transformation). Ce standard définit un langage de
création de vues sur le modèle, un langage de modélisation de requête et un langage d'écriture
des définitions de transformation. QVT est bien un méta-modèle. Il est conforme au métaméta-modèle MOF (le même que UML), ce qui est porteur pour rendre plus aisée la
collaboration entre les méta-modèles de ce standard.
Jacques Barzic
32
6.2.3 Construction d'un modèle intermédiaire : le PIM marqué
Maintenant que nous disposons des règles de transformation, dans un modèle nommé mapping, il
faut répondre au problème du choix en cas d'alternative inhérente au modèle cible, ici le PSM.
Pour ce faire, on va construire un modèle intermédiaire qui va prendre en compte les choix faits
par le concepteur [BLANC 2005].
On nomme aussi ce modèle « modèle marqué » (Marking Model [OMG-MDA 2003]). Le
principe est de poser des marques sur le modèle indépendant (le PIM) qui prennent en compte à
la fois les règles du modèle mapping et les choix faits par le concepteur. Un profil UML comme
méta-modèle est adapté. Dans notre exemple précédent, il suffirait de marquer les attributs
concernés par le stéréotype <primaryKey> pour que la transformation soit complète.
6.2.4 Exécution de la transformation
Toutes les informations sont alors réunies pour exécuter la transformation proprement dite.
Selon le degré de précision et d'aboutissement des différents modèles construits lors des étapes
précédentes (CIM, PIM, mapping) et de leur méta-modélisation (UML et profils, méta-mapping),
la transformation va avoir un degré d'aboutissement différent.
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 système regardé du point de vue de la plate-forme d'exécution : il couvre
le niveau technique de l'architecture6. Il combine les spécifications contenues dans le PIM avec
les caractéristiques qui spécifient comment ce système peut fonctionner sur la plate-forme cible
[OMG-MDA 2003].
Dans la philosophie MDA, il s'agit d'une modélisation conforme au méta-modèle UML. Elle est
obtenue suite à tout une série de créations et de manipulations de modèles. In fine, il ne reste plus
qu'à générer le code dans le langage qui correspond à la plate-forme choisie, de la même manière
et avec les mêmes outils que dans une démarche classique. L'idée de MDA est d'obtenir un PSM
le plus complet et le plus précis possible, afin d'obtenir aussi le code le plus complet et le plus
précis : le Graal étant d'obtenir le code fini de l'application.
Bien que nous sommes maintenant dans le domaine de la dépendance par rapport à la plateforme, nous allons pouvoir illustrer l'ouverture de MDA en nous appuyant sur l'indépendance du
6 Voir § 4.2.2 de cette partie.
Jacques Barzic
33
PIM. Ce dernier étant conçu dans une logique de composants, qu'est-ce qui empêche [OMGMDA 2003] :
•
de générer notre application (du moins son PSM) pour plusieurs plates-formes
différentes,
•
de découper le PIM global en plusieurs morceaux (composants), de générer autant de
PSM, spécifiques à la même ou à des plates-formes différentes, pour constituer un
système réparti,
•
de faire des transformations en chaîne afin que le PIM puisse s'adapter à différents
niveaux : on fait le PSM pour une machine virtuelle (Java, par exemple) et le même
PIM peut servir à générer le PSM pour un système d'exploitation donné (Windows,
Unix,...),
•
de combiner les mappings afin d'en construire de nouveaux ?
8. À propos des standards utilisés par MDA
8.1. Les autres standards de MDA
8.1.1 CWM (Commun Warehouse Metamodel)
CWM, acronyme que l'on peut traduire par Méta-modèle Commun aux Entrepôts de Données,
est un méta-modèle inspiré de UML. Il est dédié à la modélisation des entrepôts de données.
Promu par l'OMG, il est, bien entendu, conforme au méta-méta-modèle MOF. Il fait partie du
noyaux de standards de MDA, un même titre que UML et MOF (voir le logo MDA, page 3).
Cela veut dire que toute la méthodologie MDA, que nous avons décrite dans ce mémoire pour
UML et les applications classiques, peut s'adapter au domaine spécifique de la modélisation des
données, de leur transformation et de leur présentation7.
Pour en savoir plus, le lecteur consultera, pour une première approche, [KADIMA 2005].
8.1.2 XMI (XML Metadata Interchange)
XMI (Echange de Méta-données en XML) se trouve, lui, dans le deuxième anneau des standards
utilisés par MDA.
XMI est le partenaire de UML. UML se charge de décrire les contenus des modèles 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-même très usité), les modèles dont la
sémantique est basée sur UML. Ce duo permet une transversalité entre les outils ayant le même
7 Trois grandes activités de l'informatique décisionnelle (BI – Business Intelligence)
Jacques Barzic
34
rôle, mais aussi entre les outils agissant aux différents stades du cycle de vie des modèles.
[KADIMA 2005].
Pour plus de détails, le lecteur se référera à la documentation abondante sur le sujet.
8.1.3 Les profils UML
Utilisés, entre autres, dans le cadre des méta-PSM, les profils UML peuvent aussi servir de métamodèles typés UML dans de nombreux autres cas de figure.
Le principe est de préciser la sémantique des éléments de UML en leur ajoutant :
•
des stéréotypes : définissent, dans le méta-modèle, des sous-méta-classes. Ils sont
applicables à tous les éléments du méta-modèle.
•
Des tagged-values (valeurs marquées) : définissent des nouvelles propriétés. Elles
correspondent à un couple nom/valeur.
•
Des contraintes : elles précisent le rôle des éléments de UML. Elles peuvent étendre ou
restreindre la sémantique du modèle 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 systèmes distribués),
Enterprise Distributed Object Computing (EDOC) qui couvre notamment les spécifications de la
plate-forme J2EE,...
Les profils trouvent toute leur utilité lorsque les entreprises les utilisent pour organiser leurs
propres méta-modèles. Les profils UML deviennent alors un outil pour fixer un cadre, une
cohérence, aux modèles produits par les équipes projets d'une même organisation8.
8 Le terme « organisation » peut prendre ici plusieurs représentations : entreprise de création de logiciels,
entreprise en tant que maîtrise d'ouvrage, grand projet,...
Jacques Barzic
35
8.2. En guise de conclusion
En conclusion de cette partie sur la méthodologie 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 différentes technologies utilisées dans la
démarche. Ces liens sont un gage de la pérennité tant recherchée, d'une optimisation du travail
par la réutilisation de résultats de développements achevés. Ils sont aussi garants de la possibilité
d'adaptation aux différentes technologies actuelles et futures, sans pour cela avoir à tout
reconstruire.
Ayant toutes la même racine (MOF), ces technologies facilitent les manipulations de
transformations.
On peut aussi, à ce stade, avancer que MDA permet, par une application ordonnée de standards
connus, de monter d'un cran dans l'abstraction : les règles de correspondances d'un modèle par
rapport à un autre sont spécifiées au niveau des méta-modèles (M2).
Ceci étant, et même si la chevaleresque quête du Graal est porteuse d'élan collectif, il faut faire
Jacques Barzic
36
preuve de réalisme. Nous ne sommes pas au bout de la route vers l'obtention automatique
d'applications entièrement codées (donc opérationnelles) à partir des modèles.
Le travail se situe au niveau des outils logiciels qui se réclament de MDA : la foison d'outils et de
projets qui appliquent cette démarche partiellement, prouve que l'on s'en approche.
Jacques Barzic
37
3ème Partie : les outils pour MDA
1. Généralités
Une des conditions pour l'intégration de la démarche 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 réclament de l'ingénierie des
modèles9, on peut facilement avancer que nous sommes bien en présence d'un mouvement
réaliste.
La complexité relative de la démarche MDA, sa volonté à rassembler de multiples techniques
(modélisation, méta-modélisation, transformation de modèles, génération de code), rendent
difficile la mise au point d'outils qui intègrent la totalité de la démarche. En effet, il faut à la fois
automatiser de nombreuses tâches (déjà complexes prises indépendamment l'une de l'autre) et
respecter plusieurs standards, tout en préservant la souplesse nécessaire de la démarche (et qu'a
sans doute voulu lui conférer l'OMG).
Actuellement, on trouve donc des outils qui n'ont ni la standardisation de MDA, ni sa richesse, ni
souvent non plus l'indépendance complète 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 décrire les outils, qui ne couvrent souvent qu'une partie du cycle MDA (et sont
donc complémentaires), [KADIMA 2005] propose une vision intégrée de l'outil complet autour
d'un référentiel (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 modélisation
On trouve ici deux fonctions.
L'outil de modélisation (d'édition du modèle) proprement dit. De préférence avec une interface
graphique, il permet de tracer les diagrammes conformément à un méta-modèle.
9 Voir [PLANETEMDE.ORG 2006] : liste de plus de 70 outils.
10 Ce terme désigne les plates-formes telles que J2EE, CORBA, .Net (autre terme utilisé : middleware).
Jacques Barzic
38
La modélisation doit aussi permettre le contrôle de la conformité aux règles : celles du métamodèle 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, très attendu, de plugin pour Eclipse nommé
GMF (Graphical Modeling Framework).
Illustration 13 - Intégration d'outils pour MDA [KADIMA 2005].
2.2. Pour les transformations
Ici aussi, nous trouvons deux fonctions.
Il faut pouvoir éditer (modéliser) les règles de transformation. La modélisation de ces
transformations doit à la fois prendre en compte les standards utilisés (méta-modèles, langages)
et les spécificités fixées par l'utilisateur en fonction du cas d'espèce.
Bien entendu, l'outil doit posséder un moteur de transformation qui réalisera effectivement les
transformations.
À titre d'exemple, on peut citer le très prometteur ATL (Atlas Transformation Language) projet
complètement intégré à Eclipse.
2.3. Pour la génération du code
Dans une optique de génération automatique du code (credo de MDA), il faut pouvoir
Jacques Barzic
39
chronologiquement :
1. générer, à partir du modèle, le code conforme au langage (à la plate-forme)
d'implémentation cible : c'est le rôle du générateur de code,
2. enregistrer celui-ci sous une forme partageable entre les différents outils de la chaîne
(format XMI) : c'est le rôle 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 rôle de l'éditeur de code.
La première fonction est à la frontière du dernier modèle (PSM dans la cas de MDA) et de
l'implémentation. Cette fonction est déjà proposée par les outils de modélisation. Certains
éditeurs d'outils ne résistent d'ailleurs pas à réduire la démarche MDA à cette seule génération
automatique de code.
2.4. Pour le référentiel socle
Véritable fédérateur d'outils, le référentiel est le gage d'une réponse intégrée à la démarche MDA.
Il va permettre de concevoir une chaîne d'outils qui pourront ainsi partager leurs artefacts du
début à 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 différents.
Cette architecture permet le partage d'une tâche complexe : la mise au point d'un outil global qui
fait tout. Chaque outil peut ainsi se spécialiser et être un maillon de la chaîne.
La plate-forme de développement devra permettre la manipulation des objets stockés dans le
référentiel, indépendamment des outils de production appartenant aux catégories précédentes.
3. Synthèse
À travers ce rapide zoom sur l'outillage nécessaire à la mise en oeuvre industrielle de MDA, on
peut se risquer à tirer deux enseignements :
•
le processus est plus qu'en marche car les outils intégrés ou modulaires sont déjà
disponibles ou en passe de l'être,
•
même si des plates-formes globales mono éditeur (mais tout de même modulaires)
existent (comme, par exemple, la gamme Atlantic de IBM Rational), la tendance est à
l'agrégation d'outils d'horizons différents autour d'un socle commun (comme, par
exemple, la démarche Eclipse). Les deux exemples cités sont-ils vraiment si étrangers
que cela l'un de l'autre ?
Jacques Barzic
40
Conclusion
1. MDA = nouveau paradigme actif et/ou utopie ?
1.1. Une réponse institutionnelle : les technologies clés pour 2010
Référence : [DGE 2006]
Le monde du développement logiciel est en pleine industrialisation. À l'instar du monde
industriel, il cherche de plus en plus à représenter le réel pour concevoir des outils ou des
produits adaptés à une fonction.
L'ingénierie des modèles (dont fait partie MDA) facilite les procédures de tests et la
généralisation de code. Chaque spécialiste apporte sa plus-value métier et un architecte logiciel
met en musique l'ensemble des briques logicielles.
Les efforts importants de normalisation réalisés ces dernières années (UML, XML,...) doivent se
poursuivre par un effort de recherche et de transfert vers l'industrie. Cela, notamment, dans la
définition de nouveaux modèles, de nouvelles architectures, de nouveaux langages, de nouvelles
méthodes de preuve, de nouvelles méthodes d'analyse de code.
Il est aussi notable que de nouveaux marchés de fournisseurs de composants sont en train de
s'ouvrir et sont largement accessibles à de nouveaux acteurs, notamment au sein des jeunes
entreprises.
La réponse, d'un point de vue institutionnel, incite au développement de la recherche et de
l'économie dans le domaine de l'IDM.
1.2. Une réponse méthodologique : MDA
MDA traite des problématiques liées à la multitude des plates-formes d'exécution, de la manière
de pérenniser 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 modélisation), les techniques de transformations de modèles (voir
[KADIMA 2005]), les standards utilitaires (XML, OCL,...).
Les travaux de standardisation de l'OMG sur MDA ont pour objectif de séparer les
préoccupations « métier » des contraintes techniques et d'infrastructures, tout en permettant la
transformation des modèles et la génération automatique de code. Cette approche apporte des
Jacques Barzic
41
gains de productivité, oblige les développeurs à se préoccuper plus du métier cible du projet et,
en corollaire, permet d'apporter une réponse plus en adéquation avec les besoins des utilisateurs
[KADIMA 2005].
Le cycle de modélisation indépendant de la plate-forme (CIM et PIM), avant de passer à une
spécialisation « mécanique » pour chaque plate-forme cible (PSM), permet d'apporter une
réponse méthodologique à ces préoccupations.
MDA peut donc avoir un impact important sur des enjeux majeurs tels que la transformation des
modèles, la génération à 100% de code à partir des modèles ou, encore, la fédération d'outils
spécialisés dans l'une ou l'autre des tâches du cycle de vie.
Mais, pour éviter les obscurantismes mystiques qui sont la source d'enfermement, il faut être
réaliste : la route n'est pas terminée et des freins existent. Des freins techniques, des freins liés au
manque de maturité de certains standards (cf. XMI et ses différentes versions [BLANC 2005]),
des freins concurrentiels,...
La réponse méthodologique MDA est pleine d'espoir, le processus est plus que démarré (en
croissance et au stade de la diffusion d'après [DGE 2006]), les outils commencent à arriver sur
les « établis ».
1.3. Une réponse organisationnelle : une mutation
Pour obtenir une application qui soit quasi-totalement codée, il faut un modèle spécifique (PSM)
complet et précis et donc un modèle indépendant (PIM) suffisamment complet et précis. Il faut
aussi une modélisation des transformations très aboutie.
Cette modélisation nécessite un long travail (nombreux diagrammes, granulité fine de ces
diagrammes, richesse et précision sémantique de ces diagrammes), avec le souci de pérenniser
les investissements (outillage) et et de capitaliser le travail fourni.
MDA induit un transfert des activités de développement traditionnel (modélisation de
conception, écriture du code - Java, C++,... - de l'application) vers des activités de métamodélisation, de réglage des transformations de modèles. La modélisation analytique, plus
abstraite, reste, elle, la même ou s'étend dans la phase de conception.
Une mutation, ou un glissement des activités, est donc prévisible, tout comme une évolution
éventuelle des compétences nécessaires.
Mais, là, MDA limite le risque : les standards utilisés ont déjà une vie autonome, et MDA n'est
qu'une application nouvelle de ceux-ci. Ils sont donc relativement connus.
En effet, on peut considérer que la création des méta-modèles (généraux ou de transformation) ne
Jacques Barzic
42
relèvent pas des équipes-projets (sauf si c'est cela le projet !). Ils doivent être intégrés aux outils
de production. MDA ne deviendra une réelle pratique des équipes que si elles peuvent s'abstraire
de la complexité de la méthode et, donc, se placer en créateur de modèles. Les modèles seront
contrôlés dans leur conformité aux méta-modèles et seront passés à la moulinette des moteurs de
transformation préconçus et préréglés. Seul un paramétrage restera à réaliser.
La réponse organisationnelle se fait en deux temps :
•
la mise en place opérationnelle de MDA entraîne une mutation d'une partie des
activités de développement,
•
cette mutation est envisageable si les nouveaux outils permettent de s'abstraire des
contraintes de la méthode.
Cela alimente (et la boucle est bouclée) la pertinence des recherches dans le domaine des
techniques, des outils de modélisation et de transformation de modèles (méta-modèles,
langage,...).
2. Café-Philo (ou philosophie de comptoir ?)
Les traits séduisants d'UML, pour ne pas dire ses intérêts, sont la simplicité (le simplisme
parfois) et le coté intuitif de sa représentation graphique.
En partie grâce à cela, UML s'est imposé, dans le monde du génie logiciel, comme un outil de
communication puissant entre les acteurs humains, de cultures différentes, rencontrés 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 à désirer 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 inhérente à une
automatisation.
Certes, et il ne faut pas l'oublier, l'être humain est au deux bouts de la chaîne : il exprime un
besoin et il utilise l'application. Il est aussi derrière la machine pour spécifier les règles de
fonctionnement de la machine.
Mais, pour le débat, 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
43
Bibliographie
Classement par ordre alphabétique de l'abrégé dans chaque famille.
LIVRES
[BLANC 2005] BLANC X., 2005. MDA en action. Ingénierie logicielle guidée par les modèle.
Eyrolles, Architecte logiciel, PARIS, 269 p.
Cet ouvrage, pédagogique, permet une entrée dans la méthode MDA. Sans être un
ouvrage de référence 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 célèbre application
PetStore) permet une approche concrète. Il a été pour moi une base pour l'étude de
MDA.
[DGE 2006] Collectif, 2006. Technologies clés 2010. Les Editions de l'Industrie, Collection
Textes clés, PARIS, 345 p. (http://www.tc-2010.fr/).
Cette publication du Ministère de l’Économie, des Finances et de l’Industrie est le
résultat d'une étude sur les technologies clés pour 2010. Une part y est consacrée aux
technologies de l'information et de la communication. On y trouve, notamment, trois
articles où la modélisation est partie prenante : « Outils et méthodes pour le
développement de systèmes d'information », « Composants logiciels » (cet article fait
directement référence à MDA), « Modélisation, simulation, calcul ».
[FAVRE et al. 2006] FAVRE JM., ESTUBLIER J., BLAY-FORNARINO M., 2006.
L'ingénierie dirigée par les modèles. Au-delà du MDA. Lavoisier - Hermes, CACHAN, 226.
Ce livre est une étude scientifique sur l'IDL. Après une exposition des principes et de la
philosophie de base, il décline selon différents points de vue (le génie logiciel, les platesformes, les langages, les bases de données, le temps réel, la rétro-ingénierie) les apports
possibles de l'IDM. Dans les deux premiers chapitres (ceux que j'ai lus pour la rédaction
de la première partie ce mémoire), il est sympathiquement péjoratif à propos de MDA
(dans un esprit constructif et argumenté). Cet ouvrage, récent, mérite une lecture
approfondie.
[KADIMA 2005] KADIMA H., 2005. MDA Conception orientée objet guidée par les modèles.
DUNOD, Etudes & Développement, PARIS, 232 p.
L'auteur présente la philosophie et les concepts de MDA et ne s'y arrête pas. Après un
approfondissement des techniques de transformation, il décline MDA dans une
méthodologie de génie logiciel, pour terminer sur la description d'une étude de cas
déclinée sur deux plates-formes (EJB et CORBA).
Ouvrage intéressant rédigé par un expert, peut-être difficile d'accès dans le cas d'une
première approche du sujet.
Ce livre a été pour moi un complément par rapport à [BLANC 2005], une autre vue sur
MDA.
[LAROUSSE 1995] Collectif, 1995. Grand Larousse Universel. Larousse, Paris.
Dictionnaire encyclopédique qui m'a servi à recadrer la définition de certains termes
utilisés dans la « littérature » informatique.
Jacques Barzic
44
ARTICLES
[BEVIZIN 2004] BEVEZIN J., 2004. Sur les principes de base de l'ingénierie des modèles.
RSTI, 10/2004, 145-157.
Article de 12 pages qui décrit globalement MDA : son architecture et ses principes.
[BEZIVIN-BLANC 2002] BEZIVIN J., BLANC X., 2002. MDA : Vers un important
changement de paradigme en génie logiciel. Développeur Référence, V.2.16, 1 et 7-11.
Deux articles qui présentent le changement de paradigme lié à MDA, sa portée et ses
limites.
COURS
[BEZIVIN 2003] BEZIVIN J.. Ingénierie des modèles 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
modèle.
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 référence sur l'Ingénierie Dirigée par les Modèles. Site géré 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'encyclopédie Web bien connue.
CITATION DE DÉBUT DE MÉMOIRE
[LESCARBEAU et al. 2003] LESCARBEAU R., PAYETTE M., SAINT-ARMAUD Y.,
2003. Profession : consultant. Gaëtan Morin Editeur, 4ème édition, Monreal (Québec), 333 p.
Ouvrage sur le métier de consultant (comme le titre l'indique clairement) qui propose un
modèle applicable dans ce métier.
Jacques Barzic
Résumé
MDA (Model Driven Architecture) est une démarche pour le développement logiciel qui prône la
modélisation lors de toutes les étapes du cycle de vie des applications. Diffusée par l'OMG (Object
Managment Group), dès l'année 2000, elle est basée sur l'utilisation de standards déjà spécifiés par cette
organisation. Ces dernières années ont vu MDA faire l'objet de recherches méthodologiques, d'évolutions
des standards, de réalisation 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 sociétés de services spécialisées (SSII).
Le présent mémoire, rédigé dans le cadre d'un examen probatoire en informatique du CNAM
(Conservatoire National des Arts et Métiers), fait un point sur cette approche.
Y sont définis les concepts fondamentaux de l'Ingénierie Dirigée par les Modèles (IDM) dont MDA est
une application.
Ensuite les différentes étapes de la méthode, les modèles successifs préconisés (y compris ceux pour la
transformation) sont décrits et situés dans leur rôle respectif.
Une dernière 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 à décider d'une migration des
méthodes dans ce sens, plutôt que de décrire en détail les mécanismes sous-jacents (ce qui a déjà
largement été fait). Pour cette raison, on peut considérer ce mémoire comme un modèle de MDA du
point de vue de ses destinataires.
Mots clés : Model Driven Architecture, ingénierie logicielle, modèle, méta-modèle, transformation de
modèles.
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 Métiers), 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.

Probatoire informatique : Model Driven Architecture (MDA)

Transcription

Documents pareils

R O T A R Y C L U B D E N I C E

magen david adom

R O T A R Y C L U B D E N I C E

TSC Tour 10 - DERNIERE ETAPE ( étape 40) =

Téléphone – Cendrillon

Développement JAVA SOA MDA

convocatoria 2016

orientation, emploi, santé, loisirs

Le mécanicien, un profil hyper recherché