Un espace technologique « moteur » de l’IDM : MDA

Il y a une douzaine d’années, l’intérêt pour l’IDM s’est d’autant plus accru que l’Object Management Group (OMG)¹ a amorcé un changement dans le monde du génie logiciel [Bézivin et al. 2002a] [Bézivin et al. 2002b] [Blanc 2005] [Soley 2004] [Frankel 2003] en structurant et formalisant, notamment par le biais de sa Model Driven Architecture (MDA2) [Blanc 2005] [Kleppe et al. 2004], de nombreuses techniques et pratiques issues de l’IDM. Certains auteurs comme [Gitzel et al. 2004] voient même MDA comme « la plus importante réalisation de l’IDM ».

Par le biais de RFP (Request For Proposal), ou « appel à propositions », auxquelles de nombreux acteurs industriels, académiques et gouvernementaux ont répondu, l’OMG a peu à peu créé un certain nombre de standards et proposé des solutions d’interopérabilité entre ces derniers, ce qui a fortement marqué et influencé les orientations de l’IDM.

Comme nous l’avons déjà mentionné précédemment, l’espace technologique de MDA est clairement orienté-objet. Ceci est dû au fait que MDA, lancée en l’an 2000, succède à l’OMA (Object Management Architecture) (en se plaçant certes à un niveau d’abstraction supérieur). Mais MDA n’a pas abandonné le concept d’objet pour autant, afin entre autres de rester en adéquation avec les pratiques techniques actuelles du génie logiciel (implémentation objet, utilisation massive d’UML) et aussi d’intégrer dans sa nouvelle architecture des

1http://www.omg.org

51 standards nés dans l’OMA, par exemple CORBA (Common Object Request Broker

Architecture) [Siegel 1996]. a) La « pyramide » de MDA

La Figure II-4 montre une pyramide à quatre niveaux d’abstraction qui représente les concepts spécifiques à l’approche MDA de l’OMG : elle est une variante particulière de la Figure II-3.

Utiliser une forme pyramidale permet de donner une indication sur le nombre d’entités pouvant exister sur chaque niveau : le plus bas niveau, M0, comporte une infinité de systèmes, certains d’entre eux ont fait l’objet de processus de modélisation et sont représentés sous forme de modèles (M1). Ces modèles sont spécifiés au moyen de méta-modèles généraux situés en (M2) pouvant être des standards de l’OMG (UML en est l’exemple le plus connu) ou créés pour l’occasion (méta-modèles représentant des Domain Specific Modeling Languages ou DSMLs). La sous-section 2.1.2.d) traite du rôle de ces modèles. Enfin, le méta-formalisme MOF (Meta Object Facility), au niveau M3, joue le rôle de méta-méta-modèle. Il est défini avec ses propres concepts. Même si elles ne sont pas indiquées, les relations de conformation et de représentation entre les niveaux sont analogues à celles de la Figure II-3.

Figure II-4 : La « pyramide » des « niveaux méta » de MDA

(extraite d’un document de Richard Paige présent sur le site de la fondation Eclipse¹) b) MOF : sommet de l’architecture MDA

Le standard le plus important de l’approche MDA est certainement le méta-formalisme MOF2 : il se situe de par sa nature au sommet de l’architecture à « niveaux méta », le niveau M3.

La totalité des méta-modèles standardisés par l’OMG se conforment à MOF, et tout méta-modèle créé dans une optique MDA doit s’y conformer aussi. La version de MOF actuellement en cours est la version 2.4.1. Nous verrons également que tout langage de transformation de modèles se réclamant d’une approche MDA doit se conformer à MOF. Ce méta-formalisme est auto-descriptif, en vertu des principes de l’IDM. Il se subdivise en deux sous-formalismes, EMOF (Essential MOF) et CMOF (Complete MOF). Le premier est une restriction, un sous-ensemble, du second. MOF contient tous les concepts nécessaires à la description de la syntaxe abstraite de méta-modèles au niveau M2, notamment les notions de

1 http://www.eclipse.org/gmt/omcw/resources/chapter04/downloads/MOFLecture.York.ppt 2 http://www.omg.org/spec/MOF/2.4.1

52 classes, d’attributs, d’héritages, d’associations. On retrouve ces concepts dans la spécification du méta-modèle d’UML par exemple, défini dans l’UML 2.4.1 « infrastructure »¹, qui décrit le méta-modèle UML.

Le lien entre ce document décrivant UML d’une part et EMOF et CMOF d’autre part est très étroit : en fait, ces derniers sont issus de la fusion des packages de l’Infrastructure

Library, la bibliothèque dans laquelle sont contenus tous les packages utilisés pour la spécification d’UML dans l’UML infrastructure. En d’autres termes, UML et MOF partagent un cœur commun au niveau des concepts du niveau M2 dont nous parlons un peu plus haut : UML est partiellement défini en termes de MOF, MOF est défini en termes d’UML (via les diagrammes de classes). Pour l’OMG, UML est un standard de l’IDM.

c) Modèles de MDA

Il existe trois types de modèles au centre de l’architecture MDA, liés entre eux par des transformations de modèles :

− le CIM (Computation Independent Model) : un CIM est un modèle indépendant de tout ce qui touche à l’implémentation et même à l’informatique. Les CIM sont des modèles métier (de haut niveau) qui n’ont pas été raffinés (par exemple, des diagrammes UML de cas d’utilisation) ; − le PIM (Platform Independent Model) : un PIM est un modèle de conception

indépendant des plateformes et des technologies (ce qui lui confère une grande durée de vie), il représente la logique métier à un niveau plus bas que les CIM. Un PIM est spécifié, usuellement, au moyen de diagrammes de classes UML enrichis par des contraintes OCL ;

− le PSM (Platform Specific Model) : un PSM est le modèle le plus raffiné en MDA. Il est utilisé pour générer le code qui sera exécuté sur une ou plusieurs plateformes spécifiques. Souvent, on associe la notion de PSM à la notion de code (le code est assimilé à un PSM particulier).

d) UML, méta-modèle universel ?

Outre ses liens étroits avec l’OMG et MDA (notamment avec MOF) comme nous l’avons vu en b), UML 2.4.1 [Rumbaugh et al. 2005] est aussi et avant tout un formalisme graphique et générique de modélisation : c’est le langage standard pour modéliser tout ce qui touche au monde de l’objet.

UML hérite de trois langages de modélisation célèbres des années 90 : Booch [Booch 1993], OMT (Object Modeling Technique) [Ebert et al. 1994] et OOSE [Jacobson et al. 1999]. Il se situe à un haut niveau d’abstraction et est composé de 13 diagrammes (divisés en 5 catégories) permettant de représenter un système de manière aussi bien comportementale que structurelle. Il est principalement utilisé pour spécifier et documenter des systèmes. Son méta-modèle est, comme nous l’avons dit, fourni par l’OMG.

1http://www.omg.org/spec/UML/2.4.1/

53 Cependant, sa grande généricité peut parfois être un inconvénient, surtout lorsque l’on désire exprimer des concepts très spécifiques à des domaines particuliers. L’OMG préconise deux types de solutions pour résoudre ce problème :

− Utiliser les mécanismes de spécialisation d’UML, en ayant recours à la création de profils (« UML profiles »). Un profil UML respecte toujours le méta-modèle UML, en d’autres termes il ne permet que de restreindre ce dernier, en ajoutant par exemple des contraintes entre des éléments, en ajoutant une représentation graphique pour certains éléments…etc. Il est également possible d’étendre UML, mais toujours en utilisant son méta-modèle comme point de départ ;

− Définir un nouveau langage (et donc un nouveau méta-modèle) à utiliser à la place d’UML, tout en utilisant les mécanismes de définition de langages préconisés par l’OMG (donc en utilisant le méta-formalisme MOF).

La première solution a par exemple été appliquée pour le langage de modélisation open-source et graphique SysML (Systems Modeling Language) proposé par l’OMG¹. Destiné à la spécification, l’analyse, la conception, la vérification et la validation de systèmes, SysML constitue un sous-ensemble d’UML, et il est d’ailleurs souvent défini comme « l’extension d’un sous-ensemble d’UML ». SysML est en fait un profil d’UML 2.0. Il en conserve certains diagrammes, en adapte d’autres, et en abandonne plusieurs. Au total, SysML réutilise 7 diagrammes UML, sur les 13 originellement présents.

La seconde solution est celle que nous avons par exemple utilisée pour définir MetaDEVS (chapitre IV) : elle présente comme avantage de pouvoir redéfinir complètement la syntaxe abstraite (et la sémantique statique avec OCL) d’un formalisme.

Il n’existe pas à proprement parler de solution « type », d’ailleurs en IDM ces deux solutions sont autant employées l’une que l’autre : tout dépend en fait du problème considéré. Nous verrons par exemple dans le chapitre III que la représentation des modèles DEVS peut, selon les approches, se faire au moyen de diagrammes UML ou au moyen d’un formalisme créé spécialement pour cela.

e) OCL

Lors du processus de modélisation, il peut être utile d’avoir la possibilité d’exprimer des contraintes sur les modèles, c’est-à-dire imposer certaines règles sur les attributs ou les relations. Le langage OCL (Object Constraint Language)2 [Richters et al. 2002], dont la version actuellement en cours est la 2.3.1, permet de spécifier des contraintes, notamment sur les modèles UML. Ces contraintes prennent usuellement la forme de préconditions et de post-conditions. Ce langage est sans effet de bord, il permet seulement l’enrichissement des éléments déjà existants. Il s’agit donc d’un « pur » langage de modélisation et non pas d’un langage de programmation.

En tant que spécification officielle de l’OMG, OCL est très lié à UML et MOF : OCL contient un ensemble basé sur le cœur commun à UML et MOF, ce qui permet à ce

1 http://www.omgSysML.org

54 ensemble d’être utilisé avec UML et MOF, alors que la spécification complète d’OCL ne peut être utilisée qu’avec UML. OCL est également compatible avec XMI.

OCL peut-être également utilisé comme un puissant langage de requête (sur des instances de méta-modèles) afin, par exemple, de récupérer, trier, des éléments précis. C’est de surcroît un des rares langages de contraintes qui ne soit pas attaché à une plateforme particulière. Il est de ce fait très populaire dans le monde de l’IDM et en particulier du MDA.

Nous verrons dans la seconde partie de ce travail qu’OCL nous sera utile dans toutes les phases de notre approche, que ce soit au moment de la spécification du méta-modèle MetaDEVS, ou bien pour enrichir des règles lors des transformations M2M et M2T.