Architecture dirigée par les modèles (MDA)

Le consensus sur UML a constitué un facteur déterminant dans cette transition vers le développement dirigé par les modèles. Suite à l’acceptation du concept de métamodèle comme langage de description de modèle, de nombreux métamodèles ont vu le jour, cha-cun adapté à un domaine spécifique. Afin de standardiser l’élaboration de métamodèles et de garantir leur compatibilité, l’OMG a défini un langage de définition de métamodèle: le métamétamodèle MOF [Gro06]. S’agissant d’un modèle, le métamétamodèle doit éga-lement être défini dans un langage de modélisation. Pour limiter le nombre de niveaux d’abstraction, le métamétamodèle est capable de se décrire lui-même. Cette propriété est appelée la métacircularité.

Figure 3.1 – Pyramide de modélisation de l’OMG [Béz03]

L’organisation de la modélisation de l’OMG est souvent décrite sous la forme d’une pyramide (c.f. figure 3.1). Le monde réel est représenté à la base de la pyramide (niveau M0). Les modèles représentant cette réalité constituent le niveau M1. Les métamodèles permettant la définition de ces modèles (ex : UML) constituent le niveau M2. Enfin, le métamétamodèle, unique et métacirculaire, est représenté au sommet de la pyramide (niveau M3).

L’OMG a défini le MDA (Model Driven Architecture) en 2000 [Sol00] pour promulguer de bonnes pratiques de modélisation et exploiter pleinement les avantages des modèles tels que la pérennité, la productivité et la prise en compte des plateformes d’exécution. Le MDA définit pour cela plusieurs standards importants, notamment UML, MOF et XMI. XMI est un format basé sur XML pour l’échange de métadonnées dont le métamodèle

3.1. Ingénierie dirigée par les modèles (IDM) 55 peut être exprimé avec le MOF.

Le processus de développement de MDA et les différents types de modèles mis en œuvre sont présentés dans la figure 3.2 et expliqués dans ce qui suit. Le premier modèle que MDA définit est un modèle avec un niveau d’abstraction élevé, indépendant de toute technologie d’implémentation. Ce modèle est appelé PIM ou modèle indépendant de la plateforme. Un PIM décrit un système logiciel mais ne montre pas de détails concernant l’utilisation de la plateforme. Un PIM présente à la fois l’intérêt d’être pérenne mais aussi d’être facilement compréhensible par les personnes qui ne sont pas impliquées dans le dé-veloppement. L’étape suivante consiste à transformer le PIM en un ou plusieurs modèles spécifiques à la plateforme. Ces modèles dit PSM sont conçus pour spécifier un système en utilisant des concepts techniques, spécifiques à une technologie d’implémentation don-née. A la différence d’un PIM, un PSM n’a de sens que pour un développeur ayant une connaissance approfondie de la plateforme considérée. Il n’est pas rare aujourd’hui que des systèmes soient capables d’utiliser plusieurs technologies et de fonctionner sur différentes plateformes. Il est donc courant d’avoir plusieurs PSMs pour un PIM donné. La dernière étape du développement repose sur la transformation de chaque PSM en code. Cette transformation est généralement relativement directe étant donné le lien étroit entre le PSM et la technologie d’implémentation. Le MDA définit donc les concepts de PIM, PSM et de code ainsi que les liens entre ceux-ci. Un PIM doit ainsi être créé, puis transformé en un ou plusieurs PSMs, qui sont à leur tour transformés en code.

Figure 3.2 – Processus de développement de MDA

Le PIM, le PSM et le code sont présentés comme des artéfacts associés à chaque étape du cycle de développement. De manière plus générale, chacun représente un niveau d’abs-traction différent dans la spécification du système. La capacité dans MDA de transformer

de manière automatique des PIM en PSM et des PSM en code permet d’augmenter le niveau d’abstraction auquel les développeurs travaillent. Ceci permet de réduire considé-rablement les efforts de développement pour des systèmes complexes.

Le MDA suit la tendance du développement logiciel où le niveau d’abstraction n’a cessé d’augmenter. En effet, celui-ci a commencé avec du code assembleur de bas niveau avant l’introduction de langages de programmation de plus haut niveau tels que C, C++ ou encore Java. MDA monte le niveau d’abstraction encore plus haut en utilisant des modèles graphiques au dessus des langages de programmation.

Pour la définition des modèles de type PIM ou PSM nécessaire à l’approche MDA, l’OMG promeut l’utilisation du langage de modélisation UML bien que d’autres langages soient susceptibles de convenir. Le métamodèle d’UML est défini à l’aide du langage de métamodélisation MOF. Les modèles UML peuvent ainsi être plus facilement manipulés et transformés. Pour permettre la réalisation de modèles spécifiques à un domaine ou à une technologie donnée, l’OMG définit dans MDA le concept de profil UML. Un profil constitue un mécanisme d’extension d’UML. Il s’applique à la spécification, c’est à dire au métamodèle d’UML pour le personnaliser. Cette personnalisation est réalisée à tra-vers l’ajout de nouveaux types d’éléments au langage et éventuellement via l’ajout de contraintes sur les éléments ou leurs relations. Le nouveau langage obtenu par l’applica-tion d’un ou de plusieurs profils peut être utilisé pour construire des modèles. Les modèles obtenus sont des modèles UML car l’application d’un profil conserve la compatibilité avec le métamodèle UML. Le concept de profil permet ainsi de définir de nouveaux langages à partir d’UML, sans pour autant avoir à définir de nouveaux métamodèles.

L’approche MDA apporte des atouts certains pour le développement de systèmes logi-ciels et plus spécifiquement de services composés. Tout d’abord, le travail sur des modèles PIM indépendants de la plateforme isole et protège les développeurs des changements et évolutions des technologies utilisées. En effet, la composition de service est un domaine très actif où les technologies évoluent rapidement. De nombreux langages de composition ont ainsi été proposés tels que XLANG [Tha01], WSFL [Ley01], WSCI [AAF+02], et BPEL [OAS07]. Chacun de ces langages est également concerné par des évolutions qui leur sont propres. BPEL par exemple a connu plusieurs évolutions majeures entre 2002 et 2007 à travers les versions 1.0, 1.1 puis 2.0. En cas d’évolution des technologies, l’approche MDA présente l’avantage de promulguer l’utilisation de modèles pérennes de type PIM qui ne sont pas affectés par ces changements. Seuls les règles de transformation de PIM

3.2. Vérification formelle 57