La démarche MDA

Défini par l'Object Management Group et formalisé en 2001, le MDA - Model Driven Architecture est inspiré des approches définies notamment par Shlaer et Mellor (OOA, Object Oriented Analysis), et trouve ses fondations au sein d'un ensemble de constats qui font l'unamimité dans l'industrie du logiciel :

• UML est un langage efficient pour la modélisation des systèmes d'information
• Une bonne modélisation UML est génératrice de gains en temps de développement, en évolutivité et en maintenance de l'applicatif cible
• La correction et la complétude d'un ensemble de modèles UML sont des propriétés difficiles à valider, car les modèles, essentiellement graphiques, ne sont pas exécutables
• La modélisation ne résoud pas en soi les problèmes suivants :
• les écarts fréquents entre l'applicatif résultant et les besoins réels du client,
• le coût important des phases de codage et de test,
• le coût important du développement de l'utilisation et de la maintenance des frameworks (J2EE, .NET, ou frameworks propriétaires)

Les auteurs d'UML dès son origine, ont souligné l'intérêt de produire un modèle d'analyse complet, indépendant de la cible technique, et qui représente un modèle « pivot », au sens où il est le point commun des différentes cibles techniques d'une application donnée.

Aussi, de nombreuses entreprises ont défini des processus de production du logiciel qui intègrent l'obtention d'un modèle d'analyse type MDA, i.e. qui possède les bonnes propriétés décrites dans le MDA : complétude, consistance, indépendance vis à vis de la cible technique.

Cependant beaucoup d'entre elles ont observé, pour la phase de production des modèles d'analyse UML, un retour sur investissement très mitigé : les phases de conception puis d'implémentation, qui consistent à transposer les modèles d'analyse en une solution exécutable spécifique à une plateforme cible, conduisent systématiquement à invalider certains modèles d'analyse ; la cause essentielle réside dans la réelle difficulté que l'on a à valider des modèles UML, sans pouvoir les exécuter, ou simuler leur exécution.

Se pose alors le problème de la correction et de la maintenance des modèles d'analyse, de la gestion de l'impact sur les modèles de conception, sur le code, les tests et les phases de validation, et bien sûr de l'intérêt d'un investissement sur une phase d'analyse généralement lourde (typiquement 20 à 25% du coût total d'un projet), qui ne conduit pas à des livrables valides.

De cet ensemble de limites est né le MDA. De façon très résumée, le MDA se propose d'adresser les problèmes suivants :

• la correction et la complétude des modèles UML (utilisation de la simulation, i.e. de prototypes pour la validation fonctionnelle avec le client)
• la maintenance de la cohérence entre code et modèles UML (utilisation de règles de transformation de l'ensemble des modèles validés vers le code)
• la réduction des coûts de développement (utilisation de la génération de code)

Les modèles fondamentaux : le PIM et le PSM

La démarche MDA dissocie deux livrables fondamentaux :

• Le « Platform Independent Model » - PIM - qui est le modèle UML d'analyse de l'application considérée. Il possède les caractéristiques suivantes :
• Complet fonctionnellement
• Indépendant de la cible technique
• Validé par simulation
• Le « Platform Specific Model » - PSM - qui est le modèle de conception détaillée de l'application. Il possède les caractéristiques suivantes :
• Dépendant de la cible technique (framework, langages et OS notamment)
• Généré depuis le PIM ; par des règles de transformation spécifiques à une plateforme cible

MDA et les phases d'un projet

On retrouve avec MDA les phases habituelles d'un projet : spécification, analyse, conception, implémentation et test. Nous détaillons ci-dessous les liens entre les livrables UML au sein du MDA.

Dans le schéma ci-dessus figurent :

• La spécification et l'analyse : la particularité des modèles de spécification et d'analyse MDA est qu'ils sont validés par un outil de simulation ; l'objectif de cette phase est d'obtenir la complétude fonctionnelle du modèle (le risque d'erreur dans les modèles est très réduit car la vérification et la validation ont lieu sur des prototypes générés, et non sur des diagrammes UML).
• La conception du générateur : elle consiste à définir le mapping entre le modèle d'analyse - PIM et le modèle dépendant de la plateforme cible - PSM (par exemple J2EE). En pratique cette phase consiste très souvent à décliner un générateur existant pour modifier la cible de génération (pour passer de J2EE à .NET, ou à un framework propriétaire par exemple).
• L'implémentation : le générateur produit l'ensemble du code dit « métier », le code spécifique au framework cible, et très souvent la couche de présentation (IHM). Il ne génère pas le code non fonctionnel qui utilise des APIs techniques hors du champ du framework. Ce code représente typiquement 5 à 10% maximum de l'ensemble du code d'une application ; et pour des raisons de coût de développement, on le produit à la main (il est souvent possible de le coder dans le générateur si le taux d'utilisation du code généré le justifie).

Bien que ne figurant pas ici, il est à noter que la phase habituelle de tests unitaires, d'intégration et fonctionnels, est présente mais considérablement minimisée par le fait que le code critique réside dans les 5/10% écrits à la main ; le code généré est lui beaucoup moins exposé aux bugs techniques.