Les approche MDA et IDM

Il s'agit de modéliser les applications que l'on veut créer de manière indépen-dante de l'implémentation cible (niveau matériel ou logiciel). Ceci permet une grande réutilisation des modèles. Les modèles ainsi créés (PIM - Platform Independant Mo-del) sont associés à des modèles de plate-forme (PM -Platform MoMo-del), et transfor-més, pour obtenir un modèle d'application spécifique à la pate-forme (PSM – Platform Specific Model).

Des outils de génération automatique de code permettent ensuite de créer le pro-gramme directement à partir des modèles.

Ces approches permettent de plus de faire évoluer facilement, à partir des modè-les, les applications : le développement d'un nouveau module, quand tous les modèles nécessaires sont disponibles, peut ne pas prendre plus de quelques minutes.

3.2.1 Définition de plateforme

Une plateforme est un ensemble de sous-système et de technologies qui fournis-sent un ensemble cohérent de fonctionnalités à travers des interfaces et des modèles d’utilisateurs spécifiés, qui peuvent être employés par n'importe quelle application soutenue par cette plateforme sans souci pour les détails de la façon dont la fonction-nalité fournie par la plateforme est mise en application.[OMG 03].

3.2.2 L'ingénierie des logiciels (IDM)

L'Ingénierie Dirigée par les Modèles est une approche plus globale et générale que le MDA. Elle cherche à en appliquer les principes et à les généraliser pour tout espace technologique tels l'orienté-objet, les ontologies, les documents XML ou les grammaires de langages. Le MDA peut ainsi être perçu comme un processus spéci-fique de type IDM.

L'IDM repose sur les principes suivants :

A. Capitalisation : les modèles doivent être réutilisables,

B. Abstraction : les modèles doivent être indépendant des technologies de mise en œuvre afin d'adapter la logique métier à différents contextes et de permettre de faire plus facilement évoluer les applications vers de nouvelles technolo-gies,

C. Modélisation : abordée selon une vision productive (pour générer le code final du logiciel pour une technologie de mise en œuvre donnée) par opposition à la traditionnelle vision contemplative (but de documentation, spécification, communication),

D. Séparation des préoccupations : l'IDM s'illustre généralement selon les deux principales préoccupations du métier et de la plateforme de mise en œuvre mais d'autres préoccupations sont possibles.

Pour passer à une vision productive des modèles, il est nécessaire qu'ils soient bien définis ; ce qui amène l’importante notion de méta-modèle. Ainsi, les modèles productifs pourront être manipulés et interprétés via des outils [Laf] répondant aux

besoins de l'approche IDM : définition de méta-modèles, définition de langages, défi-nition de transformations et leur exécution (selon les types de transformations, cette catégorie d'outils peut être amenée à traiter simultanément des méta-modèles diffé-rents, non nécessairement issus des mêmes espaces technologiques), génération de code (considérée comme une transformation de modèles particulière), composition de modèles (appelée tissage de modèles dans certains cas), génération d'environnement graphique de modélisation, vérification de conformité de modèles, spécification de contraintes, etc.

3.2.3 L'approche MDA

Partant du constat de l'évolution continue des technologies et du coût élevé de l'adaptation des applications logicielles à ces technologies, l'OMG proposa le MDA [OMG 04] fin 2000. Le but principal de cette approche est de séparer les parties mé-tier de leur mise en œuvre technologique et ainsi de garantir l'interopérabilité des mo-dèles fonctionnels pour différents choix d'implémentation.

Conceptuellement, le MDA propose trois points de vue, associés à leurs modè-les respectifs : Le CIM, le PIM et le PSM.

3.2.3.1 Le CIM

CIM (Computer Independent Model) correspondant aux modèles du « domaine » (domain/business model) indépendants de toute implémentation informatique et re-censant les besoins des utilisateurs en utilisant le vocabulaire du praticien.

Chapitre 03: La transformation de modèle

3.2.3.2 Le PIM

PIM (Platform Independent Model) correspondant à la spécification de la partie « métier » d'une application, conformément à une analyse informatique cherchant à répondre aux besoins métiers indépendamment de la technologie de mise en œuvre.

3.2.3.3 Le PSM

PSM (Platform Specific Model) correspondant à la spécification d'une applica-tion après projecapplica-tion sur une plate-forme technologique donnée.

3.2.4 L'architecture d'MDA

MDA est une Architecture à 4 niveaux d'abstraction (Figure 3.3):

A. Le niveau M0: Niveau de modélisation des données réelles, composé des in-formations que l’on souhaite modéliser. Exemple (Niveau du monde réel). B. Le niveau M1: Composé de modèles d’informations (PIM, PSM).

-58-Figure 3.2: Illustration OMG du MDA [OMG 04]

– Modèle UML

– Tout modèle est exprimé dans un langage unique dont la définition est fournie explicitement au niveau M2

C. Le niveau M2: Composé de langages de définition des modèles d’informa-tions = Métamodèles

– Le métamodèle UML

• Décrit dans le standard UML,

• Définit la structure interne des modèles UML.

D. Le niveau M3: composé d’une unique entité: langage unique de définition des métamodèles

– Méta-métamodèle ou MOF 3.2.5 Les outils d'MDA

Pour obtenir une telle efficacité, plusieurs outils conceptuels sont mis à disposi-tion. La technologie MDA (Model Driven Architecture) est supportée par l'OMG (Ob-ject Management Group), qui propose également UML (Unified Modeling Language) et Corba (Object Request Broker).

Ces outils sont :

A. UML, largement utilisé par ailleurs, qui permet une mise en œuvre aisée de MDA en offrant un support connu.

B. XMI, (XML Metadata Interchange), qui propose un formalisme de structuration des documents XML de telle sorte qu'ils permettent de re-présenter des méta-données d'application de manière compatible.

C. MOF, (Meta Object Facility), spécification qui permet le stockage, l'ac-cès, la manipulation, la modification, de méta-données. Le MOF permet une unification de l’expression des méta-modèles, qu’ils soient ensuite utilisés comme profils UML ou non[OMG 04].

D. CWM, base de données pour méta-données.

L'OMG n'a pas jugé utile de standardiser un processus associé à ces outils. Leur rôle est de répondre aux besoins des utilisateurs de manière générique, et non de pro-poser de solutions définitives pour certains types d'applications précises.

Un processus de génie logiciel exploitant les possibilités de MDA a cependant été proposé : le 'Model-Driven Software Development'[mdsd].

3.2.6 La transformation des modèles dans l'approche MDA

La transformation de modèle MDA se fait par mapping entre un modèle initial et un modèle cible. Chaque modèle doit être décrit par un méta-modèle, qui recense les caractéristiques de ce modèle. Le mapping est alors définit comme une traduction entre le méta-modèle initial et le méta-modèle cible. La figure 3.5 présente le prin-cipe de la transformation.

Figure 3.4: Les outils d'MDA [Favre]

Figure 3.5: Le principe de la transformation des modèles dans l'approche MDA

On distingue deux types de mappings : les mapping verticaux, qui changent le niveau d'abstraction, et les mapping horizontaux, qui le conservent.

A. Les mappings verticaux: On en distingue deux sortes :

 Mappings de modèle d'analyse vers le modèle d'implémentation (ou mappings de raffinement). Ils permettent de préciser le modèle de l'application, en fonc-tion de l'implémentafonc-tion souhaitée. Souvent, un seul modèle initial suffit. Par-fois, des contraintes sont nécessaires (sinon le modèle cible est incomplet), ou bien plusieurs modèles sont utilisés comme source.

 Mappings d'abstraction. C'est la transformation inverse. Elle permet une meil-leure compréhension du code (reverse engineering), ou la migration d'une plate-forme vers une autre.

B. Les mappings horizontaux: On en distingue trois sortes:

 Mappings de représentation. On l'utilise pour passer d'un format à un autre, le second disposant de plus d'outils de manipulation et de représentation. Peu utile s'ils ne sont pas réversibles.

 Mappings d'optimisation, pour améliorer la performance.

 Mappings de reconstruction, pour améliorer la maintenabilité et la lisibilité du code.

Les mappings sont réalisés soit par des règles générales, soit par corrélation, c'est à dire par appariement de propriétés du modèle source avec des propriétés du modèle cible.