Le MDA en 2010 – Une vision pragmatique nommée Acceleo– Jérôme Benois (présentation)
par Audrey Neveu
Le but de cette session était de nous présenter l’historique et les apports de la démarche MDA et comment la mettre en oeuvre simplement avec eclipse.
Qu’est ce que le MDA ?
Le Model Driven Architecture voit le jour début 2000, partant du constat qu’à cette époque 2 projets sur 3 sont en dépassement significatif de coût et/ou de délai. La DSI s’interroge sur la façon de diminuer ces coûts, sur la possibilité de capitaliser le savoir faire de ses équipes etc … en bref comment produire mieux avec les mêmes équipes ?
La nécessité de passer par des modèles pour monter en abstraction et mieux communiquer entre les équipes métiers et IT se fait sentir, et UML est retenu pour supporter tout cela.
Plusieurs phases s’enchaînent dans le MDA, chacune s’appuyant sur une partie des modèles proposés par UML :
Et Acceleo dans tout ça ?
Acceleo est un générateur de code basé sur OMG MOF To Text Language, développé par Obeo, partenaire de longue date d’Eclipse, qui permet de traduire rapidement le modèle en code.
Il dispose notamment de modules qui lui permettent de générer du code dans de nombreux langages (java, .c#, Php, Python …). Chaque module est lui même composé de plusieurs templates paramétrant la génération du code, comme par exemple le template generateEntity.
Entièrement intégré à Eclipse, il a l’avantage certain de laisser aux développeurs les facilités auxquelles il est habitué : auto complétion et coloration du code par exemple.
Après la génération du code vient le cycle de maintenance et la génération incrémentale. Celle ci peut se faire de deux façons :
Le constat après plusieurs années de développement
Côté avantages, amélioration de la productivité et meilleure agilité technique et fonctionnelle sont au rendez vous, mais de nombreux inconvénients ont tout de même été relevés, parmi lesquels :
Les leçons tirées de cette expérience
Tout d’abord que l’UML est un langage riche pour représenter le modèle, mais peut être un peu trop. Il existe des diagrammes pour représenter quasiment tout, du modèle aux étapes de développement. Or les diagrammes du PSM par exemple, peuvent rapidement devenir redondant avec le code source. D’où l’envie de privilégier le DSL (Domain Specific Language) que notre speaker résume ainsi : un vocabulaire précis et concis pour une problématique précise. En effet en DSL, tout est centré sur un problème technique ou métier bien particulier.
Autre point important, le modèle doit rester un support de communication et un outil de productivité. Autrement dit les équipes doivent communiquer entre elles : métier et développement doivent interagir fortement afin d’être sûres que chaque partie a bien compris la problématique posée.
Et enfin, garder les générateurs connectés en maintenance et ne pas oublier les bonnes pratiques d’ingénierie (tests automatisés, utilisation de svn/git, build automatique et reproductible, intégration continue, qualimétrie, etc …).
Le futur du MDA : l’ingénierie des modèles
On parle donc désormais d’Ingénierie Dirigée par les Modèles (IDM ou MDE : Model Driven Engineering). La version 2.0 de l’approche MDA se nomme MDD (Model Driven Development), aussi appelé MDSD (Model-Driven Software Development). Côté outils on s’appuie toujours sur la plateforme d’Eclipse. Grâce à Eclipse Modeling Project et son écosystème riche proposant à la fois des outils de développement à partir du modèle (UML entre autre) :
Mettre en oeuvre une démarche modèle pragmatique
Fort de ces constats, reprenons les différentes étapes du MDA pour les faire évoluer :
La démarche recommandée par Jérôme pour cela est :
Pour manipuler ce vocabulaire l’API EMF Java va nous permettre de construire des outils et de faire des imports depuis des sources d’informations existantes.
Pour le construire en revanche, nous disposons de XText, un framework de développement de DSL textuel basé, qui offre de nombreuses fonctionnalités telles que la complétion, la validation, des fonctions d’édition, etc …
Il nous faut ensuite passer du DSL au DSM. DMS est la représentation graphique du modèle. A l’aide d’un framework de notre choix qui sera basé sur Eclipse GMF, nous profiterons d’un environnement dédié, simple à paramétrer pour obtenir des diagrammes de qualité.
Du DSM au point de vue !
L’enjeu du MDA étant de faciliter le dialogue entre les équipes métier et technique comme nous l’avons vu plus haut, le DSM – graphiques – doit être là pour permettre à chacun de retrouver “son point de vue”, tout en dépassant les représentations “sectaires” : l’IT d’un côté, le métier de l’autre. Autrement dit, on doit tendre vers un modèle unique mais abordable par tous.
Conclusion
Pour Jérôme DSL + DSM + Acceleo = approche modèle efficace. Si la théorie est facile à croire, sans pratique il est difficile de se faire un réel avis sur cette autre façon d’envisager la conception.
En continuant à utiliser le site, vous acceptez l’utilisation des cookies. Plus d’informations
Les paramètres des cookies sur ce site sont définis sur « accepter les cookies » pour vous offrir la meilleure expérience de navigation possible. Si vous continuez à utiliser ce site sans changer vos paramètres de cookies ou si vous cliquez sur "Accepter" ci-dessous, vous consentez à cela.
