Je viens de lire un article intéressant résumant la soirée Paris JUG d’hier soir.
Et au milieu on peut lire : “non MDA n’est pas une méthode Agile”
Horreur ! Je ne peux donc pas m’empecher de réagir 
Bien sur que le MDA aide à être plus agile ! Mais attention, il ne faut pas non plus trop écouter les puristes…
Je ne crois pas non plus à la notion “d’indépendance du langage”… c’est utopique, mais ça permet une certaine abstraction. C’est aussi une absurdité de mettre un fossé entre les développeurs et les architectes. L’architecte va oublier des choses dans le modèle, il faut laisser les développeurs l’aider à le compléter.
Un exemple concret :
Il y a 4 ans j’ai commencé un projet avec des EJB 2 session et entity. Pour les personnes qui n’ont pas la chance de connaitre les EJB 2…. c’est atroce. Pour persister une classe il faut écrire 4 classes Java + des descripteurs xml.
Pour nous simplifier la vie nous avons modélisé notre système sans parler d’EJB. Un modele de haut niveau donc… un PIM.
Ensuite nous avons écrit un transformateur PIM-> PSM EJB 2 (15j de travail )
On génère classe Java + descripteurs EJB + script SQL.
Et la c’était magique !!
1 - A la fin de la phase de modélisation, j’ai appuyé sur UN bouton et j’ai obtenu 100 % de mes squelettes de code Java. Sans aucun codage j’avais un EAR deployable !
Attention ! cet EAR était bien une coquille vide, il est pour moi hors de question de modéliser le comportement. Il restait donc à notre équipe de développeurs à coder les services EJB.
Mais il était déjà deployable, on pouvait donc écrire des JUnits avant d’écrire l’implémentation.
2 - Justement à propos de l’équipe… allez trouver sur le marché des développeurs EJB 2. (pas chers donc débutants…)
Et bien grâce à l’approche MDA nous avons pu prendre des débutants. En effet le coté EJB était transparent au début ils codaient de simples méthodes Java.
Et au fur et à mesure ils sont montés en compétences sur les EJB 2 bien sur.
3 - Notre modèle est en phase avec notre code après 4 ans de dev… qui dit mieux ? 
4 - Le MDA est agile !!
C’est une approche qui nous aide à être plus agile car elle facilite les changements.
Ajouter un attribut à un entity, c’est modifier 2 classes Java + un descripteur Java + un script SQL. Soit 4 chances d’oublier une modif ou de faire une erreur.
Avec nos outils MDA : une modif dans le modele + un clic = c’est fini.
Pour finir : la cerise sur le gâteau.
L’année dernière nous avons migré nos EJB 2 vers de l’hibernate. Et bien nous avons juste changé de transformateur MDA… zero modif dans notre code.
C’est pas de l’agilité ça !
Bulletins (RSS)
L’intérêt que tu trouves à MDA, c’est justement celui qu’apporte les frameworks applicatifs (au sens très large: j’y inclue les classes helper sont des débuts de framework). Je ne parle pas des frameworks Spring, JSF & Co, mais bien du framework que tu finirais par développer toi-même, dans le cadre de ton/tes projets.
La grosse différence, c’est que tu n’es pas obligé de le faire *a priori*. Si tu n’as pas d’intérêt à avoir un framework, eh bien tu n’en fais pas et tu économises l’énergie. Si tu réalises qu’il te faut un, tu peux le construire progressivement, itération par itération, selon tes besoins réels (et non anticipés).
Avec MDA, tu es obligé de dépenser cette énergie a priori pour construire ta plateforme. Si le projet est annulé (une chose fréquente, tout de même), ou si tu t’es complètement trompé dans la plateforme, tu perds tout cet investissement.
J’ajoute que MDA ne t’aide pas à adapter la technologie aux besoins de chaque projet. Si par hasard un projet n’a besoin que de POJO plutôt que d’EJB, ou s’il souhaite tirer partie d’une technologie récente, MDA ne t’apporte rien, en tout cas pas plus qu’un framework construit progressivement, de façon pragmatique.
C’est pour cela que moi, et beaucoup d’autres, considérons que le MDA n’est pas agile. C’était le sens de ma question sur le refactoring agressif à la suite de l’intervention de Grégory.
J’ai l’impression que nous n’avons pas la même définition du MDA.
J’utilise des transformateurs MDA simples et souples. Pour donner un ordre d’idée nous venons d’en finir un avec Accelo en moins de 10 jours.
).
Ce transformateur répond à mes besoins actuels, mais je vais le faire évoluer progressivement (par itération
Pour moi un projet = un transformateur, car chaque projet a des besoins/habitudes spécifiques.
Je ferai un post plus complet pour expliquer plus clairement ma vision du MDA pragmatique.