Mise en oeuvre du MDA : les différentes étapes de la métamodélisation

Conçu en 2000, MDA est une technique de développement logiciel basée sur l’utilisation massive de modèles pour assurer la séparation des préoccupations, MDA se base sur l’usage de modèles qu’il utilise comme éléments productifs. Il supporte toutes les étapes de développement et standardise les passages des unes aux autres. MDA n’est qu’une approche qui néanmoins peut être suivie par toute méthode de développement logiciel. En effet, appliquer MDA nécessite la définition d’une méthode (qui est alors propre à chaque entreprise). Et hélas MDA ne préconise pas encore de méthode qui pourrait définir clairement quelles sont les bonnes et les mauvaises pratiques. Les méthodes utilisant MDA diffèrent de la diversité des opérations qu’elles proposent et de leur degré d’automatisation. Une méthode simple suivant l’approche MDA pourrait par exemple comprendre les différentes étapes cidessous (cette méthode est décrite dans le guide MDA proposé par l’OMG) :
1. La spécification des exigences du client à travers un modèle appelé CIM (Computation Independent Model)
2. La réalisation d’un modèle indépendant de toute plate-forme appelé PIM (Platform Independent Model).
3. L’enrichissement de ce modèle par étapes successives.
4. Le choix d’une plate-forme de mise en oeuvre et la génération du modèle spécifique correspondant appelé PSM ( Platform Specific Model ).
5. Le raffinement de celui-ci jusqu’à obtention d’une implantation exécutable.
Dans une démarche MDA, tout est basé sur les modèles. L’objectif principal du MDA est l’élaboration de modèles pérennes, indépendants des détails techniques des plates-formes d’exécution actuellement disponibles (J2EE, .Net, PHP ou d’autres). Le but est de permettre une génération automatique d’applications (génération de la totalité du code) afin d’obtenir un gain important en productivité.
La figure 1 fait clairement apparaître les différents niveaux/types de modèles MDA [4].

Modèle d’exigences : CIM (Computation-Independent Model)

Pour construire une nouvelle application, la première chose à faire est de spécifier les exigences du client. MDA préconise l’utilisation des modèles dans cette étape avec comme objectif la création d’un modèle d’exigences de la future application. Un tel modèle doit faire ressortir l’environnement de l’application et alors faire clairement apparaître les services qu’elle offre et les entités externes avec lesquelles elle interagit.
Les modèles d’exigences peuvent être considérés comme des éléments contractuels qui serviront donc de références lorsque l’on voudra s’assurer qu’une application est bien conforme aux demandes des clients (lors des tests de recettage par exemple).
Ils ne doivent pas contenir d’information sur la réalisation de l’application; aucune information concernant les traitements ne doit donc y figurer. Un modèle d’exigences est une entité complexe constituée entre autre d’un dictionnaire, des définitions des processus métiers, des définitions des exigences, des définitions des cas d’utilisation et de la définition d’une vue systémique de l’application. Il est souvent appelé modèle du domaine et pour sa spécification un langage familier aux praticiens du domaine doit être utilisé. Le CIM doit être construit par des gens qui ont une très bonne maîtrise du domaine métier, il joue un important rôle dans la connexion de la vision de ces experts du domaine à celle des concepteurs qui auront à construire le PIM.
MDA ne fait aucune préconisation pour l’élaboration les modèles d’exigences. Des travaux sont actuellement menés pour ajouter à UML les concepts nécessaires pour couvrir cette phase amont.
Les modèles d’exigences sont les premiers modèles pérennes. En effet, une fois les exigences modélisées, celles-ci deviennent une base contractuelle validée par le client de l’application et qui varie peu.

Modèle d’analyse et de conception : PIM (PlatformIndependent Model)

Le PIM est le résultat du travail d’analyse et de conception. L’analyse et la conception forment l’étape où la modélisation est la plus présente. Le PIM est une description d’un système qui fait abstraction des spécificités liées à une plate-forme donnée; Il doit exposer un certain degré d’indépendance par rapport aux plates-formes. Comme pour le CIM, les modèles qui composent le PIM doivent être pérennes.
Le PIM est élaboré à l’aide du CIM par des architectes et concepteurs pour décrire l’architecture de l’application sans faire référence à une implémentation sur une plate-forme spécifique.
Il n’est pas exclu que d’autres langages puissent être utilisés pour la construction des modèles du PIM, mais MDA préconise l’utilisation du langage UML.

Modèle de code : PSM (Platform Independent Model)

Le PSM est produit par transformation du PIM pour lequel il constitue une sorte d’implémentation par rapport à une plate-forme donnée. Si le PIM se limite à l’illustration de l’architecture métier de l’application, le PSM s’occupe quant à lui de la réalisation du système (le PIM) sur une plate-forme spécifique. Selon le niveau de détails d’implémentation qu’il contient, un PSM peut contenir toutes les informations nécessaires à la réalisation du PIM sur une plate-forme d’exécution spécifique (Exemple les informations relatives à la manipulation des fichiers, l’authentification, les descripteurs de déploiement, et toute autre forme de spécification sur la configuration).
La tâche d’élaboration du PSM revient aux développeurs et testeurs pour qui il sert de base pour la génération du code de l’application.
MDA propose, entre autre, l’utilisation de profils UML pour l’élaboration des PSM. Un profil UML est une adaptation du langage UML à domaine particulier. Par exemple, le profil UML pour EJB est une adaptation de UML au domaine des EJB. Dans sa politique d’extension de UML, l’OMG a déjà standardisé un certain nombre de profils UML (le profil UML pour CORBA par exemple). Les modèles PSM font le lien avec les plates-formes d’exécution. Ils sont essentiellement productifs et ne sont pas forcément pérennes. En effet leur rôle est principalement de faciliter la génération de code et ils dépendent intrinsèquement de la plate-forme pour lesquelles ils sont définis.

Transformation de modèles

Il existe plusieurs types de transformations différentes [5] que nous allons présenter, les quatre premières correspondent à ceux que l’on trouve dans la démarche générale que nous avons présentée.

Transformation de CIM vers PIM

Les modèles PIM doivent en théorie être au moins partiellement générés à partir des CIM afin que des liens de traçabilité y soient établis.

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èles.

Transformation de PIM vers PSM

Ces transformations sont utilisées quand le PIM est suffisamment raffiné. Elles permettent une implémentation du système sur une plate-forme d’exécution. Cette implémentation est basée sur les caractéristiques de cette plate-forme.

Les techniques de base

Un formalisme de modélisation : le MOF (Meta Object Facility)

Les approches classiques de génie logiciel placent les composantes ou les objets comme éléments de première importance. Les modèles sont des citoyens de première classe pour le MDA qui préconise la modélisation de toutes les informations relatives au cycle de vie de l’application à construire. De là est née le besoin de trouver une bonne structuration de tous les modèles à produire, et c’est pour cela que le MDA a défini la notion de formalisme de modélisation. Tout modèle doit donc être défini selon un formalisme bien déterminé; par exemple le formalisme UML est préconisé par le MDA pour l’expression des modèles d’analyse et de conception.
Un formalise de modélisation définit les concepts ainsi que les relations entre eux nécessaires à l’expression de modèles dans le domaine considéré. Par exemple, le formalisme UML d’expression des modèles d’analyse et de conception définit, entre autres, les concepts de classe, d’objet et d’associations avec la relation précisant qu’un objet est l’instance d’une classe [5].
L’expression des liens de traçabilité ainsi que des transformations entre modèles est alors assurée par la définition des liens entre les différents concepts de différents formalismes.
Dans cet ordre d’idées, MDA préconise de modéliser les formalismes de modélisation! Cela induit, selon la logique définie précédemment, l’obligation de définir un autre formalisme pour exprimer les modèles de formalismes de modélisation : un métaformalisme, et les modèles qu’il permet d’exprimer sont appelés des métamodèles, qui deviennent analogues aux formalismes de modélisation.
Il est naturel, en suivant cette logique définie par MDA de penser à un métamétaformalisme permettant d’exprimer des métaformalismes, et puis à un métamétaméta…formalisme et ainsi de suite mais MDA a fait en sorte que le métaformalisme soit son propre formalisme et alors seuls trois niveaux sont nécessaires : modèles, formalismes de modélisation (aussi appelé métamodèles), métaformalisme (ou métamétamodèles). L’unique métaformalisme existant est le MOF (Meta Object Facility).
Le MOF définit un langage abstrait, une infrastructure pour la spécification, la construction et la gestion de métamodèles. Il encourage donc la consistance dans la manipulation des modèles dans toutes les phases de l’utilisation de MDA
Plusieurs versions du standard MOF ont successivement existé, chacune correspondant à une façon précise de faire des métamodèles. Nous allons découvrir, dans les parties suivantes, les deux plus récentes versions de ce standard.

MOF1.4

Pour la version 1.4, un métamodèle a une structuration semblable à la structuration orientée objets: il est défini sous forme de classe (Class ou métaclasse) et les modèles qu’il structure sous forme d’objets (ou métaobjets) instances de cette classe. Les concepts de base de MOF1.4 sont [7]:
MétaClasse : Une métaclasse permet de définir la structure de métaobjets. Un ensemble de métaobjets constitue un modèle. Une métaclasse contient des métaattributs et des métaopérations.
DataType : Un type de donnée permet de spécifier le type non objet d’un métaattribut ou d’un paramètre d’une métaopération.
MétaAssociation : Une métaassociation permet de spécifier une relation binaire entre deux métaclasses.
MétaPackage : Un métapackage permet de regrouper sous un même espace de nommage différents éléments d’un métamodèle.
La figure 2 représente une partie de ce que pourrait être un diagramme de classes représentant MOF1.4.
L’unique métamétamodèle MOF modèle s’auto définit; il est son propre métamodèle.