CENTRE RÉGIONAL ASSOCIÉ DE NANTES MÉMOIRE. présenté en vue d'obtenir. l'examen PROBATOIRE. en INFORMATIQUE. par. Jacques BARZIC.

Transcription

1 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.

2 «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 Probatoire informatique : Model Driven Architecture (MDA) 3 Sujet proposé par Claude Belleil claude.belleil@univ-nantes.fr Université de Nantes Le sujet 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.

4 Probatoire informatique : Model Driven Architecture (MDA) 4 Table des matières Le sujet... 3 Index des illustrations... 6 Liste des abréviations... 7 Avertissement... 8 Introduction ère Partie : méta-méta-modèle, méta-modèle, modèle, système, transformation? IDM, au secours!! Généralités à propos de l'idm Les concepts socles de l'idm Le système Le langage Le modèle Le méta-modèle Le méta-méta-modèle La transformation Conclusion ème Partie : Model Driven Architecture, approche pour les architectes fabricateurs? Introduction Le schéma général de MDA Point de vue de l'utilisateur Computation Independent Model (CIM) Objectif Illustration : le «Portillon» Point de vue de l'analyste - Platform Independent Model (PIM) Objectif et standard socle (UML) Organisation et standards complémentaires (OCL, AS) Principe pour la réalisation Les vues de l'architecture couvertes Les modèles pertinents Illustration : le «Portillon» (suite) Les composants Un diagramme de séquence Un composant Rendre plus productif les modèles UML : OCL et AS La plate-forme d'exécution Platform Description Model (PDM) Choix de la plate-forme Modélisation de la plate-forme On se passe du méta-modèle du modèle de la plate-forme La transformation Généralités Le passage du PIM au PSM...29

5 Probatoire informatique : Model Driven Architecture (MDA) Description globale Modélisation des règles de transformation : le mapping Construction d'un modèle intermédiaire : le PIM marqué Exécution de la transformation Point de vue du concepteur Platform Specific Model (PSM) À propos des standards utilisés par MDA Les autres standards de MDA CWM (Commun Warehouse Metamodel) XMI (XML Metadata Interchange) Les profils UML En guise de conclusion ème Partie : les outils pour MDA Généralités Une grille d'analyse des outils Pour la modélisation Pour les transformations Pour la génération du code Pour le référentiel socle Synthèse...39 Conclusion MDA = nouveau paradigme actif et/ou utopie? Une réponse institutionnelle : les technologies clés pour Une réponse méthodologique : MDA Une réponse organisationnelle : une mutation Café-Philo (ou philosophie de comptoir?)...42 Bibliographie... 43

6 Probatoire informatique : Model Driven Architecture (MDA) 6 Index des illustrations Illustration 1 - La pile de modélisation de l'omg (inspiration [BEZIVIN 2003]) Illustration 2 - Le cycle en Y de MDA (inspiration [BEZIVIN 2003]) Illustration 3 - CIM du "Portillon"...20 Illustration 4 - PIM du "Portillon" - Les Composants 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]) 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 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

7 Probatoire informatique : Model Driven Architecture (MDA) 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).

8 Probatoire informatique : Model Driven Architecture (MDA) 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.

9 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 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»?

10 Probatoire informatique : Model Driven Architecture (MDA) 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.

11 Probatoire informatique : Model Driven Architecture (MDA) 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] 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,..).

12 Probatoire informatique : Model Driven Architecture (MDA) 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 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.

13 Probatoire informatique : Model Driven Architecture (MDA) 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 : 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!! Généralités à propos de l'idm Les concepts socles de l'idm Le système Le langage Le modèle 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.

14 Probatoire informatique : Model Driven Architecture (MDA) 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À 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).

15 Probatoire informatique : Model Driven Architecture (MDA) 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.

16 Probatoire informatique : Model Driven Architecture (MDA) 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.

17 Probatoire informatique : Model Driven Architecture (MDA) 17 2 ème Partie : Model Driven Architecture, approche pour les architectes fabricateurs 1? 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].

18 Probatoire informatique : Model Driven Architecture (MDA) 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.

19 Probatoire informatique : Model Driven Architecture (MDA) 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.

20 Probatoire informatique : Model Driven Architecture (MDA) 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].

21 Probatoire informatique : Model Driven Architecture (MDA) Organisation et standards complémentaires (OCL, AS) 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 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] Les modèles pertinents Plusieurs modèles distincts vont collaborer pour constituer le PIM : le diagramme de composants 2 (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.

22 Probatoire informatique : Model Driven Architecture (MDA) 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 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 Les composants Illustration 4 - PIM du "Portillon" - Les Composants

23 Probatoire informatique : Model Driven Architecture (MDA) 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 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.

24 Probatoire informatique : Model Driven Architecture (MDA) 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 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].

25 Probatoire informatique : Model Driven Architecture (MDA) 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.

26 Probatoire informatique : Model Driven Architecture (MDA) 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 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

27 Probatoire informatique : Model Driven Architecture (MDA) 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 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 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]).

28 Probatoire informatique : Model Driven Architecture (MDA) 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.

29 Probatoire informatique : Model Driven Architecture (MDA) 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 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]) 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 UML 4 ) 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).

30 Probatoire informatique : Model Driven Architecture (MDA) 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 Merise 5. 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!

31 Probatoire informatique : Model Driven Architecture (MDA) 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.

32 Probatoire informatique : Model Driven Architecture (MDA) 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 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'architecture 6. 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 de cette partie.

33 Probatoire informatique : Model Driven Architecture (MDA) 33 PIM. Ce dernier étant conçu dans une logique de composants, qu'est-ce qui empêche [OMG- MDA 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 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ésentation 7. Pour en savoir plus, le lecteur consultera, pour une première approche, [KADIMA 2005] 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)

34 Probatoire informatique : Model Driven Architecture (MDA) 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 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 organisation 8. 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,...

35 Probatoire informatique : Model Driven Architecture (MDA) 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

36 Probatoire informatique : Model Driven Architecture (MDA) 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.

37 Probatoire informatique : Model Driven Architecture (MDA) 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èles 9, 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'intergiciel 10. 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 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).

38 Probatoire informatique : Model Driven Architecture (MDA) 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] 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 Pour la génération du code Dans une optique de génération automatique du code (credo de MDA), il faut pouvoir