L’approche MDA introduit une approche globale pour le développement des systèmes logiciels. MDA est basée sur l’idée que toute entreprise doit pouvoir bénéficier de ses expériences en accumulant son savoir faire dans un ensemble de modèles. Le savoir faire visé s’étend sur toutes les étapes de la construction d’un système. Cela découle de la remarque qu’une entreprise évolue généralement dans un domaine d’application spécifique en mettant en œuvre des technologies qui évoluent avec une certaine fréquence plus grande que pour le changement des techniques métiers. MDA propose donc d’accumuler ce savoir-faire dans des modèles qui représentent des schémas d’action face à une situation donnée. Par exemple, dans une situation où nous voulons fournir des données météorologiques à partir d’un centre de surveillance vers des unités mobiles, l’expérience montre que la meilleure solution est décrite par le « Remote Method Call Pattern » [Douglass2002] page 363-364 dans le modèle suivant (figure 5.1) :
15
ClientDistant ServeurM étéo ClientBroker Client PortMapper S erverBroker S erver Formateur PortNumber : integer ServiceNumber : integer 1 * * 1 1 1 1 * PortNumber : integer ServiceNumber : integer * 1 * 1
Figure 5.1. Pattern d’appel de méthodes distantes de systèmes pouvant s’élargir.
MDA étend ce principe utilisé pour les Design Patterns pour mettre en place des modèles de haut niveau (ou méta modèles) de systèmes logiciels entiers. Ces méta modèles contiennent donc des éléments de description de systèmes et peuvent contenir plusieurs Design Patterns. Jean Bézivin [Bézivin2004] décrit l’évolution vers le MDD en décrivant les deux relations de base (figure 5.2) qui ont régi la modélisation orientée objet et les deux relations qui régissent la modélisation guidée par les modèles :
Figure 5.2. Relations fondamentales régissant la modélisation orientée objet et la modélisation guidée par les modèles.
Les modèles dans MDA [MDA2003] peuvent être des méta modèles de description ou des méta modèles de transformation. Les méta modèles de description sont le CIM (Computation Independent Model), le PIM (Platform Independant Model) et le PSM(Platform Specific Model) :
• Le CIM : Expression des besoins par un modèle indépendant de la conception.
• Le PIM : En MDA, un PIM (Platform Independent Model) est un modèle d’un haut niveau d’abstraction qui ne prend pas en compte les aspects relatifs aux technologies d’implémentation.
• Le PSM : Le PSM (Platform Specific Model) est un modèle qui décrit la solution technique à réaliser. Il est utilisé pour traduire le PIM en explicitant les technologies mises en œuvre.
Les modèles de transformation: Le passage d’un modèle à l’autre nécessite des procédures de transformations de modèles. Dans MDA, ces procédures sont exprimées par des modèles pour les mêmes raisons qui nous ont amené à utiliser des modèles au lieu du code. En effet on peut considérer une transformation d’un modèle en un autre comme un projet à part entière.
La génération de code et de documentation: Cette génération diffère de la transformation de modèles dans le sens où un document ou du code n’ont pas nécessairement de méta modèle. Ce sont des chaînes de caractères structurées.
L’approche MDA définit alors une chaîne de transformations que l’on veut essentiellement automatisée entre le CIM vers le code et la documentation (figure 5.3). Cette décomposition nous permet de décrire un système en termes de ses fonctionnalités, ce qui encourage la créativité et donne plus de liberté à l’ingénierie. Ceci permet de réutiliser des solutions abstraites (niveau PIM) en changeant le niveau de l’implémentation si la technologie venait à évoluer (par exemple, si une contrainte liée à une source d’énergie venait à changer). On n’aurait alors qu’à modifier la partie relative à cette technologie au niveau PSM et les règles de génération de texte qui suivent.
Toute la difficulté dans la mise en œuvre de MDA et le choix d’un PIM qui puisse non seulement nous amener vers le(s) PSM que nous envisageons d’utiliser mais aussi qui puisse être assez abstrait pour pouvoir être réutilisable et donc pérenne.
Ce sont les experts implémentant MDA qui fournissent le plus grand effort, les développeurs/ingénieurs viennent travailler sur cette plateforme MDA en se concentrant sur la créativité et les aspects conceptuels.
Figure 5.3. MDA process.
Pour décrire nos modèles (CIM/PIM/PSM/…) nous devons disposer de langages standards tels que le langage UML2 qui est préconisé par l’OMG à cette fin ci. Pour les modèles de transformation d’autres langages sont préconisés
[Kleppe2003] page 32. UML est l’un des langages les plus largement acceptés dans la
communauté du génie logiciel et aussi dans d’autres communautés comme celle des systèmes. Il est utilisé pour spécifier des modèles et le nombre d’outils implémentant UML (de manière plus ou moins fidèle) a augmenté de manière fulgurante (plus d’une centaine d’outils). Dans le langage UML, ces modèles (CIM, PIM et PSM) sont décrits par des profiles UML. Dans [Fernandez2004] les auteurs présentent des guidelines pour concevoir des profiles UML ainsi que le rôle des profiles dans la mise en œuvre de MDA. Ces profiles sont utilisés pour guider la conception. Ces profils sélectionnent les éléments de langage et les diagrammes utiles pour notre domaine d’application.
En plus d’un outil UML, il y a besoin d’outils de transformation et de langages de transformation pour pouvoir implémenter des transformations de modèles et des générations de texte. Le meilleur outil devra permettre un accès aisé aux modèles ; une liberté maximale de manipulation de ces modèles permet d’avoir un maximum d’automatisation dans le processus global. Ce qui permettrait de mieux maîtriser le processus de développement et d’améliorer la qualité, les coûts et aident à respecter les délais.
Utiliser UML pour implémenter MDA dans un contexte d’ingénierie système n’est pas trivial. En effet, UML a été construit pour le génie logiciel. Les vues/diagrammes qu’il offre sont donc celles utiles à la spécification de logiciels. Pour l’ingénierie système nous utiliserons SysML.
Finalement nous résumons ici les avantages d’une approche de conception basée sur les modèles. Tout d’abord, cela permet d’offrir un meilleur support de communication inter ou intra équipes. Ce qui diminuera les ambiguïtés et donc facilitera l’intégration des sous-systèmes. Ensuite, elle permet d’accumuler le savoir-faire et de le pérenniser, donc de le réutiliser. Grâce à la facilité de manipulation des modèles cela risque d’être la nouvelle tendance pour la conception de systèmes dans les années à venir.
MDA ne précise pas quel formalisme on doit utiliser pour exprimer des méta modèles. Par contre l’OMG préconise l’utilisation du MOF (Meta Object Facility)
[MOF2006]. Le MOF est donc un formalisme de description de méta modèles. Il est
utilisé entre autres à décrire le méta modèle d’UML. Un méta modèle en réalité ne permet de décrire que la forme des langages et non pas leur sémantique, ce qui constitue une faiblesse majeure. Il en résulte qu’un méta modèle, tel qu’il est défini par l’OMG, ne permet finalement pas de décrire des langages, car un langage est constitué d’une syntaxe et d’une sémantique. C’est de cette approche-ci que découlent toutes les faiblesses d’UML tel que sa non formalité. Ce que l’OMG appelle « precise natural language » dans [UMLinfra2004] reste toujours un langage naturel pouvant être interprété différemment par des personnes différentes et dans des contextes différents :
“The specification uses a combination of languages - a subset of UML, an object constraint language, and a precise natural language to describe the abstract syntax and semantics of the full UML.” [UMLInfra2004] page 21.
Quant aux modèles de transformations de modèles (QVT16 et ATL17), rappelons que dans MDA tout est modèle. Même les transformations des PIM en PSM sont décrites par des modèles. L’OMG propose le langage QVT pour décrire ces modèles de transformations, mais d’autres langages sont développés par d’autres groupes de recherche tels que ATL qui est développé par l’INRIA [ATL2006].