La démarche MDA. Auteur : Projet ACCORD (Assemblage de composants par contrats en environnement ouvert et réparti)*

Transcription

1 La démarche MDA Auteur : Projet ACCORD (Assemblage de composants par contrats en environnement ouvert et réparti)* Référence : Livrable Date : Mai 2002 * : Les partenaires du projet ACCORD sont CNAM, EDF R&D, ENST, ENST-Bretagne, France Telecom R&D, INRIA, LIFL et Softeam. Le projet est conjointement financé par les partenaires et par le RNTL (Réseau National des Techniques Logicielles). Projet RNTL ACCORD Page 1

2 1 Introduction Le Model Driven Architecture (MDA) [Poo01, MDA] est une démarche de développement proposée par l OMG [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) [MM01]. 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. Ce document présente, dans un premier temps, les motivations de l OMG. Il aborde ensuite les différentes étapes de sa mise en oeuvre suivie par la présentation des bases techniques sur lesquelles repose le MDA. Enfin la dernière section résume où en est le travail de l OMG dans cette démarche. 2 Pourquoi le MDA? L OMG voulait faire de CORBA [COR] «LE» middleware, mais 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 (cf figure 1) 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. 3 Mise en oeuvre du MDA La démarche MDA supporte toutes les étapes de développement et standardise les passages de l une à l autre. Elle peut se découper en quatre points (cf figure 2), les points 2 et 4 peuvent être répétés un nombre indéterminé de fois : 1. la réalisation d un modèle indépendant de toute plate-forme appelé PIM pour «Platform Independent Model». 2. l enrichissement de ce modèle par étapes successives. 3. le choix d une plate-forme de mise en oeuvre et la génération du modèle spécifique correspondant appelé PSM pour «Platform Specific Model». 4. le raffinement de celui-ci jusqu à obtention d une implantation exécutable. Dans une démarche MDA, tout est considéré comme modèle, aussi bien les schémas que le code source ou le code binaire. Les deux types de modèles identifiés sont donc les PIM et les PSM Projet RNTL ACCORD Page 2

3 FIG. 1 Le Model Driven Architecture [StOSSG]. Chaque étape correspond à la transformation d un modèle vers un autre (du même type ou non). 3.1 Platform Independent Model (PIM) La première étape du processus MDA consiste à réaliser un modèle indépendant de toutes platesformes (PIM), exprimé en UML. Il existe plusieurs niveaux de PIM mais tous sont indépendants de n importe quelle plate-forme. Le PIM de base représente uniquement les capacité fonctionnelles métiers et le comportement du système, sans dégradations par des considérations technologiques. La clarté de ce modèle doit permettre à des experts du domaine de le comprendre bien mieux qu un modèle d implémentation. Il peuvent ainsi vérifier plus facilement que le PIM est complet et correct. Un autre bénéfice de l indépendance technique de ce modèle est qu il garde tout son intérêt au cours du temps et doit être modifié uniquement si les connaissances ou besoins métiers changent. Les PIM suivants intègrent des aspects technologiques et architecturaux mais toujours sans détails spécifiques à une plate-forme. Ces modèles peuvent, par exemple, contenir des informations sur la persistance, les transactions, la sécurité, etc. Ces concepts permettent de projeter plus précisément le modèle PIM vers un modèle spécifique (PSM). 3.2 Platform Specific Model (PSM) Une fois le PIM suffisamment détaillé, il est projeté vers un modèle spécifique (PSM). Pour obtenir un modèle spécifique, il faut choisir la ou les plates-formes d exécution (plusieurs plates-formes peuvent être utilisées pour mettre en œuvre un même modèle). Les caractéristiques d exécution et les informations de configuration qui ont été définies de façon générique sont converties pour tenir compte des spécificités de la plate-forme. Projet RNTL ACCORD Page 3

4 1 PIM 3 PSM 2 4 FIG. 2 Les étapes d une démarche MDA Comme pour les PIM, il existe plusieurs niveaux de PSM. Le premier, sous forme d un schéma UML, est obtenu directement à partir du modèle PIM, les autres sont obtenus par transformations successives jusqu à l obtention du système exécutable. 3.3 Transformations Il existe quatre types de transformations différentes que nous allons présenter, les trois premières correspondent à ceux que l on trouve dans la démarche générale que nous avons présentée, la dernière doit permettre de récupérer dans un processus MDA des modèles spécifiques Transformation de PIM vers PIM Ces transformations visent à enrichir, filtrer ou spécialiser le modèle pendant le cycle de développement sans nécessiter d informations dépendantes d une plate-forme. Les transformations PIM vers PIM sont généralement utilisées pour le raffinement de modèle Transformation de PIM vers PSM Ces transformations sont utilisées quand le PIM est suffisamment raffiné pour être projeté vers une plate-forme d exécution. Cette projection est basée sur les caractéristiques de cette plate-forme. Ces caractéristiques doivent être décrites à l aide d UML et éventuellement d un profil. Le passage d un modèle de composants logique à un modèle de composants existants comme EJB ou CCM est une transformation PIM vers PSM. Elles permettent d obtenir un modèle spécifique à une plate-forme donnée à partir d un modèle indépendant. Les PSM possibles peuvent être CORBA, Java/EJB, XML/SOAP ou toute autre plate-forme supportée par le MDA (cf figure 3) Transformation de PSM vers PSM Ces transformations s appliquent sur un modèle spécifique et donnent un autre modèle spécifique à la même plate-forme. Elles sont utilisées pour la réalisation et le déploiement de composants. La génération de code, la compilation, la mise en paquetages, l initialisation et la configuration font parties de ce type de transformation. Projet RNTL ACCORD Page 4

5 Domain Facilities {import} PIM Corba Model Java/EJB Model XML/SOAP Model Corba Impl Java/EJB Impl XML/SOAP Impl FIG. 3 Projections multi-plates-formes Transformation de PSM vers PIM Ces transformations doivent permettre d obtenir un modèle indépendant à partir d une implantation existante sur une plate-forme spécifique. Bien que celles-ci ne fassent pas directement partie du processus MDA, elles doivent permettre d intégrer des applications existantes afin de pouvoir les utiliser dans un processus MDA. Ce sont certainement les transformations les plus difficiles à automatiser. Idéalement, le résultat de cette transformation devrait correspondre à la transformation inverse PIM vers PSM. 3.4 Interopérabilité Comme nous l avons dit, un même modèle peut être mis en œuvre sur différentes plates-formes en même temps. Dans ce cas, les différentes parties doivent pouvoir communiquer. De même, il est possible de faire interopérer différentes applications en exprimant leurs relations au niveau PIM. Au moment de la génération des PSM, des modèles de connexions sont générés ce qui permet d obtenir une implantation des ponts d interconnexion au moment de la génération de code. 4 Les bases techniques Au cœur du MDA, se trouvent plusieurs standards importants de l OMG : Unified Modeling Language (UML), le Meta Object Facility (MOF), le XML Metadata Interchange (XMI) et le Common Warehouse Metamodel (CWM). Ces standards définissent l infrastructure du MDA. Ils devront être complétés par des règles de transformation de modèles qui seront standardisées par l OMG. 4.1 Unified Modeling Language (UML) Le langage UML [UMLb, UMLc] permet de modéliser un système indépendamment de toute démarche ou plate-forme, c est donc naturellement qu il est utilisé pour décrire les PIM mais aussi la Projet RNTL ACCORD Page 5

6 PIM A PIM B Corba Model Java/EJB Model Corba Impl Java/EJB Impl Interop Bridge FIG. 4 L interopérabilité entre les plates-formes plupart des PSM. Les spécificités de chaque plate-forme peuvent être modélisées grâce aux mécanismes d extension d UML (stéréotypes, valeurs marquées, contraintes). On peut définir pour chaque système un profil qui regroupe les éléments nécessaires à ses caractéristiques. Le MDA utilisera la version 2.0 d UML [UMLa] qui doit être standardisée prochainement. 4.2 Meta Object Facility (MOF) Le langage MOF [MOF] fournit le standard de méta-modélisation et d échange de constructions utilisées par MDA. Les autres modèles standards de l OMG, comme UML et CWM, sont définis par des constructions MOF, ce qui permet de les relier entre elles. C est également le mécanisme par lequel les modèles sont sérialisés en XMI. Le MOF est un exemple de méta-méta-modèle, ou de modèle du méta-modèle. Il définit les éléments essentiels, la syntaxe et la structure des méta-modèles utilisés pour construire des modèles orientés objet. La spécification MOF fournit les points suivants : Un modèle abstrait d objets MOF génériques et leurs associations. Un ensemble de règles pour exprimer un méta-modèle MOF à l aide d interfaces IDL. Une implantation de ces interfaces pour un méta-modèle donné peut être utilisée pour manipuler une instance de celui-ci (un modèle). Un ensemble de règles sur le cycle de vie, la composition et la fermeture sémantique des éléments d un méta-modèle MOF. Une hiérarchie d interfaces réflexives permettant de découvrir et manipuler des modèles basés sur des méta-modèles MOF dont on ne connaît pas les interfaces. Un intérêt du MOF est qu il permet de faire interopérer des méta-modèles différents. Une application MOF peut manipuler un modèle à l aide d opérations génériques sans connaissances du domaine. 4.3 XML Metadata Interchange (XMI) Le langage XMI [XMI] permet de décrire une instance du MOF sous forme textuelle, grâce au langage extensible Markup Language (XML) du W3C [XML]. XMI définit comment utiliser les balises XML Projet RNTL ACCORD Page 6

7 pour représenter un modèle MOF en XML. Les méta-modèles MOF sont décrits par des DTDs (XML Document Type Definitions) et les modèles traduits dans des documents XML conformes à leur DTD correspondante. XMI résout beaucoup de problèmes rencontrés lorsque l on veut représenter des objets et leurs associations sous forme textuelle. De plus, puisque XMI est basé sur XML, les méta-données (tags) et les instances (elements) sont regroupées dans le même document, ce qui permet à une application de comprendre les instances grâce à leurs méta-données. Le XMI est le format d échange standard entre les différents outils MDA. 4.4 Common Warehouse Metamodel (CWM) Le CWM [CWM] est le standard de l OMG pour les techniques liées aux entrepôts de données. Il couvre le cycle de vie complet de modélisation, construction et gestion des entrepôts de données. Le CWM définit un méta-modèle qui représente les méta-données aussi bien métiers que techniques qui sont le plus souvent trouvées dans les entrepôts de données. Il est utilisé à la base des échanges de méta-données entre systèmes hétérogènes. Le CWM comprend actuellement un certain nombre de méta-modèles concernant les entrepôts de données (représentation des données, analyse, gestion). Les méta-modèles de données permettent de modéliser des ressources comme les bases de données relationnelles, les bases de données orientées objets. Une couche d analyse du CWM définit des méta-modèles pour les transformations de données, OLAP, la visualisation, la nomenclature et le data-mining. Une couche de gestion est constituée de méta-modèles représentant les processus standards, la journalisation et la planification des activités. Finalement, le méta-modèle de base définit les services et éléments communs, comme les types de données, les projections vers les types de systèmes, les clés et index, les expressions et le déploiement de programmes à base de composants. Le CWM représente une démarche d échange de méta-données entre systèmes logiciels [Tol00]. Les échanges de méta-données sont formulés en terme de modèles de données qui correspondent à un ou plusieurs méta-modèles CWM. Un logiciel exporte ses méta-données avec un modèle de leurs structures interne dans un format du CWM. Symétriquement, un logiciel importe des méta-données à l aide d un modèle CWM et les traduit dans son format interne. L ensemble des méta-modèles du CWM est assez complet pour modéliser un entrepôt de données dans son ensemble. Il est possible à l aide d outils CWM de générer une instance d entrepôt de données à partir de son modèle. 4.5 Transformations de modèles Les techniques de transformation de modèles sont donc au coeur du MDA. L OMG doit pouvoir les formaliser et les standardiser pour garantir la compatibilité entre les outils MDA. Afin de pouvoir générer le code fonctionnel, il est également possible d enrichir les modèles PIM avec un langage d actions. De plus, les modèles peuvent être accompagnés de contraintes en OCL (Object Constraint Language) afin de vérifier leur validité tout au long du processus. A terme, l OMG souhaite pouvoir automatiser la plus grande partie de ces transformations. Projet RNTL ACCORD Page 7

8 5 Où en est l OMG? 5.1 Les profils UML Le profil CORBA, déjà défini par l OMG, permet de représenter un modèle spécifique (PSM) pour le middleware CORBA. D autres profils sont en cours de standardisation : Le profil EDOC (Enterprise Distributed Object Computing) [EDO] qui doit permettre de définir un système d information d entreprise à base de composants. C est grâce à ce profil que les PIM composants d entreprise doivent être définis. Le profil EAI (Enterprise Application Integration) [EAI] pour les systèmes faiblement couplés, il permet de représenter les communications asynchrones et les envois de messages, quelque soit la plate-forme (PIM). Le profil Scheduling [SCH] pour l ordonnancement, typiquement utilisé pour la modélisation des applications temps réels, quelque soit la plate-forme (PIM). D après l OMG, ces profils devraient être disponibles prochainement. 5.2 Les services L OMG a repris pour les services systèmes du MDA ceux qui avaient été définis pour CORBA : collection, concurrence, temps, évènement, externalisation, nommage, licence, cycle de vie, notification, persistance, propriété, requête, relation, sécurité, vendeur, transaction. L OMG doit maintenant décrire ces services pour qu ils puissent être utilisés dans un modèle PIM. Concernant les services métiers, seulement deux documents sont actuellement disponibles (dans le domaine de la médecine), il reste encore beaucoup de travail à effectuer avant d obtenir une réelle valeur ajoutée mais, d après l OMG, cette section devrait représenter d ici quelques mois la plus grande partie des spécifications du MDA. 5.3 Les implantations du CWM En plus d être un support pour la réalisation d applications selon le MDA, le CWM est aussi un bon exemple de sa mise en œuvre. En effet, en définissant des méta-modèles indépendants pour les données et en permettant leurs projections vers des systèmes existants, le CWM suit la démarche du MDA. De plus, il existe déjà plusieurs mises en oeuvre. Les entreprises suivantes développent ou utilisent le CWM : Dimension EDI [EDI], leur but est de développer un dépôt de méta-données pour un système d interrogation intelligent. La plus grande partie de son développement est basé sur le CWM. Oracle Corporation [ORA], les produits Oracle (Oracle Repository et Oracle8i) permettent l échange de données avec d autres produits conformes au CWM. UBS [UBS], UBS utilise le CWM pour migrer ses données vers de nouveaux environnements à base de composants, dans le domaine de la finance. Meta Integration Technology Inc [MIT], le Meta Integration Model Bridge (MIMB) développé par cette société est certainement l une des implantations du CWM les plus poussées.... Projet RNTL ACCORD Page 8

9 6 Conclusion Grâce à son architecture de méta-modèlisation, le MDA devrait apporter un important gain de productivité en permettant de capitaliser les efforts à tous les niveaux. Il n existe pas de plate-forme universelle. Celle-ci peut dépendre du matériel, du réseau, des équipes de développement ou de ce qui est déjà en place au niveau de l entreprise. De ce fait, le meilleur environnement de développement doit permettre de choisir la plate-forme cible après avoir modélisé l application, et passer de l une à l autre relativement facilement. De plus, il doit être possible d interopérer avec toutes les plates-formes quelle que soit celle qui a été choisie, afin de pouvoir tirer parti des avantages qu elles offrent. C est l ambition du MDA. Références [COR] [CWM] [EAI] [EDI] [EDO] [MDA] [MIT] [MM01] CORBA/IIOP Specification, http :// Data Warehousing, CWM and MOF Resource Page, http :// UML Profile for Event-based Architecture in Entreprise Application Integration, http ://cgi.omg.org/docs/ad/ pdf. Dimension EDI, http :// UML Profile for Enterprise Distributed Object Computing, http ://cgi.omg.org/docs/ad/ pdf. OMG Model-Driven Architecture Home Page, http :// Meta Integration Technology Inc, http :// Joaquin Miller and Jishnu Mukerji. Model Driven Architecture (MDA) http ://cgi.omg.org/docs/ormsc/ pdf, July Architecture Board ORMSC. [MOF] Meta-Object Facility (MOF), version 1.4, http :// [OMG] [ORA] [Poo01] [SCH] Object Managment Group Home Page, http :// Oracle Corporation, http :// John D. Poole. "Model-Driven Architecture : Vision, Standards And Emerging Technologies". ECOOP 2001, Workshop on Metamodeling and Adaptive Object Models, April UML Profile for Scheduling, Performance and Time, http ://cgi.omg.org/docs/ad/ pdf. [StOSSG] Jon Siegel and the OMG Staff Strategy Group. Architesture" "Developing in OMG s Model-Driven Projet RNTL ACCORD Page 9

10 [Tol00] [UBS] [UMLa] [UMLb] ftp ://ftp.omg.org/pub/docs/omg/ pdf. Object Management Group White Paper. D. Tolbert. "CWM : A Model-Based Architecture for Data Warehouse Interchnage". Workshop on Evaluating Software Architectural Solution 2000, University of California at Irvine, May http :// UBS, http :// UML 2.0 Infrastructure RFP, http :// UML Resource Page, http :// [UMLc] Unified Modeling Language (UML), version 1.4, http :// [XMI] XML Metadata Interchange (XMI), version 1.2, http :// [XML] Extensible Markup Language (XML), http :// Projet RNTL ACCORD Page 10