Le MDA en 2010, une approche pragmatique
Cette présentation était menée par Jérôme Benois. Jérome est consultant/architecte MDA senior chez Obeo. Il est notamment commiter pour Eclipse Acceleo, sur Eclipse Modeling et EasyAnt.
Historique
Jérome démarre son intervention par un retour sur les origines de l’approche MDA. A la fin des années 90, 80% des projets informatique sont livrés hors délais et 50% sont en dépassement de budget. Beaucoup de responsables informatiques et de chercheurs se demandent alors comment limiter les risques dans la chaine de production du logiciel. Au début des années 2000, c’est donc la naissance de l’approche MDA. Son objectif est simple : pour industrialiser, utilisons des modèles plus abstraits afin de permettre une meilleure communication entre les responsables métiers et l’IT pour ainsi produire du logiciel. Cette approche se base très largement sur l’utilisation d’UML pour la production des modèles.
Étapes d’un projet MDA
Jérome nous présente les étapes pour réaliser un projet informatique avec cette approche :
Une fois la modélisation PSM validée, encore faut-il pouvoir en obtenir quelque chose d’exploitable : du code source ! C’est ici, que le logiciel Acceleo a fait ses premières armes.
Acceleo est basé sur le standard OMG MOF Model to Text Language (MTL). Cette spécification décrit les méthodes permettant de transformer un modèle en texte pour obtenir, par exemple, du code source ou de la documentation. Acceleo offre un environnement qui permet de configurer les générateurs de code via des templates et donc générer précisément le code source cible. Les fichiers templates sont au format MTL.
Il existe en fait deux méthodes de génération de code :
Après ce rappel historique, Jérome nous explique les avantages et les inconvénients de cette vision “fin 2000” du MDA :
- Avantage : on améliore grandement la productivité (génération initiale du code)
- Avantage : on peut changer “plus facilement” des éléments techniques et fonctionnels dans l’application
- Inconvénient : il est très difficile de réussir à maintenir synchroniser les différents modèles
- Inconvénient : quand le projet entre en phase de maintenance, la tentation est grande de réduire les coûts de modélisation : - on n’utilise plus l’outil de génération de code
- on obtient une dé-synchronisation entre code source et modèle
- Inconvénient : l’approche “tout modèle” a une connotation trop intégriste
Jérome explique donc que l’UML est désormais vu comme étant trop vaste et trop générique pour exprimer les métiers de l’informatique de gestion. Par exemple, l’UML n’est pas du tout adapté pour exprimer simplement un algorithme.
Ce qui semble le plus à même de répondre aux problèmes des projets informatiques est ce que l’on appelle les Domain Specific Language (DSL). Un DSL est un vocabulaire précis et concis qui permet de décrire une problématique. Il peut très bien être spécifique à un projet, ce n’est pas grave : l’important est que l’ensemble des équipes puissent se comprendre. Le modèle doit rester un outil de communication et de productivité.
Un DSL n’est pas utilisé seul. Il est inclus dans un projet via une approche de type “ingénierie dirigée par les modèles” (IMDD/MDD). L’ensemble des projets de l’écosystème Eclipse Modeling sont conçus et adaptés à cette approche, le plus important étant Eclipse Modeling Framework (EMF). Le processus est donc pragmatique et simplifié par rapport à une approche “tout UML” :
- Le CIM et le PIM sont regroupés sous la forme de DSL
- Le générateur de code se basent sur les DSL
- Le code source généré sert de PSM
Pour conclure cette conférence, Jérome insiste sur un point qui me semble un avantage important de cette nouvelle approche, c’est la traçabilité des modifications. En effet, dans le cadre d’une connexion permanente entre le modèle et le code généré, il est possible de proposer des outils qui permettent de détecter les impacts du générateur, de permettre de bypasser les actions du générateur ou encore de produire des rapports sur les fragments de code mort.
Un grand bravo au speaker qui a très bien alterné les séquences théoriques avec des démonstrations bien calibrées. Les supports étaient également de bonne qualité (pas trop chargés, plan bien lisible, etc…).
Grâce à cette journée de conférence, j’ai réussi à remplir ma TODO-list pour au moins 6 mois 🙂
