Je suis toujours étonné de lire autant de réticences à propos du MDA. Cette méthode est peut être victime d’une communication trop éloignée des problèmes concrets des développeurs. Alors soyons clairs, moi non plus je ne suis pas en phase avec les grands théoritiens. Deux exemples concrets :
J’ai participé il y a 3 ans à une présentation d’une thèse sur le MDA. J’ai vu pendant 1 heure des séries d’équations pour m’expliquer le principe du MDA. Au final, je n’ai pas vu une ligne de code et je suis sorti avec un beau mal de crâne.
Un autre expert MDA m’a très sérieusement expliqué qu’il passait par 3 à 4 transformations successives pour arriver au code Java. De plus pour lui le principe du “round trip” ne sert à rien car son modèle ne change jamais. Bien sûr son super architecte a pensé à tout et les petits développeurs n’ont pas besoin de réfléchir… On rève..
Si on vous a présenté le MDA de cette façon je comprends mieux vos griefs.
Mais pour moi le MDA c’est :
- Mettre le modèle au centre du pojet.
- Un outil pour produire mieux et plus vite.
- Une façon d’abstraire des mécanismes techniques complexes.
Il faut que le passage du modèle au code soit simple et rapide. Il faut aussi que ce soit le transformateur qui s’adapte au projet et non l’inverse. Là aussi j’ai vu trop d’outils imposer une façon de faire qui rebutait l’équipe de développeurs.
Oui on m’a déjà reproché de faire des PIM orientés Java et c’est aussi pour cette raison que l’on parle maintenant plutôt de MDD Model Driven Developpment. Mais mon objectif n’est pas d’être conforme à 100% avec la définition du MDA rédigée par l’OMG, mais bien de réaliser les trois points notés plus haut.
C’est assez paradoxal de pousser la modélisation UML et de mettre nos beaux modèles au placard lorsqu’ils sont terminés. C’est ça le MDA : s’appuyer sur un modèle pour structurer son développement.
Bulletins (RSS)
Salut Samuel !
Mon petit commentaire au débat dont tu m’as parlé.
Je suis toujours amusé par la confusion mentale qui règne entre les pro du MDA et les pro de l’agilité. Modèle vs Code, Architecte vs Développeur, Développeur métier vs Développeur technique… et j’en passe. On se croirait dans les années 70 quand les Analystes rédigaient le pseudo-code et que les programmeurs transcrivaient cela dans le “langage des machines”. Le débat revient toujours à cette fameuse question d’organisation, de hiérachisation même, inhérente finalement à la difficulté que nous avons à “bâtir” des logiciels. Alors chacun y va de sa “solution”. Les uns “y a qu’a faire des modèles, monter en abstraction et génerer le code”. Les autres : “y a qu’a travailler mieux ensemble sur le code”… Les uns et les autres reconnaissant implicitement que “c’est compliqué de réaliser un logiciel” et là dessus tout le monde est d’accord, hormis peut être les clients (aie !) qui n’étant pas de la partie ne comprennent pas toujours pourquoi on ne pas faire plus vite, moins cher, moins bogué,…
Mais comme le disais déjà en 1975, F.Brooks dans le fameux “mythical man-month”, il n’y a pas de balle d’argent ! Aucune technique, aucun outil, aucune méthode miracle n’existe pour nous sauver. Cette position n’est pas si pessimiste qu’il y paraît, car une fois ce constat admis, on peut progresser.
La grande difficulté de notre industrie - mais devrais parler d’industrie devant tant d’immaturité ? - est quelle produit de l’immatériel. Quelqu’un a t-il dejà vu vraiment un logiciel ? Un cdrom d’installation, une IHM, du code, un modèle, ca oui… mais le logiciel qui est en train de s’exécuter, là, pendant que je tape ces mots ? Non. Nous travaillons à construire des produits qui par “essence” n’en sont pas. Alors, on s’intérese à la “substance” qui va, de près ou de loin, pouvoir matérialiser cette essence. Le problème est qu’un logiciel peut avoir plusieurs représentations substancielles, un peu comme un fantôme qui pourrait prendre plusieurs apparences. Code et modèle sont 2 de ces formes et l’une comme l’autre ne permettent que d’approcher et comprendre l’essence du logiciel.
Alors pourquoi les opposer si ni l’une ni l’autre ne sont la solution ?
Pratiquer la modélisation n’implique pas la rigidité, comme tu l’as expliqué et “l’agilité” n’implique pas l’absence de rigueur.
Comme le montre d’ailleurs Pascal Roques sur ces slides (site Valtech), la plupart des méthodes dites “agiles” n’interdisent pas l’usage de modèles.
Je crois aux modèles si on les développe comme tels (et pas comme des pâles reflets du code, par exemple) car leur seul intérêt est de fournir une représentation très proche de l’essence du logiciel. Dans ce sens, je préfère les approches de modélisations “behavioristes” qui s’intéressent au fonctionnement runtime avant de s’intéresser aux structures de données…Smalltalk plutôt que Merise donc.
Je crois également aux pratiques des méthodes “agiles” si on les utilise avec bon sens (et pas comme des dogmes caricaturaux du développement entre copains, par exemple) car leur intérêt majeur à mes yeux est que tous les acteurs partagent la même vision de l’essence du logiciel.
Modélisation et agilité devraient donc pouvoir se compléter idéalement… on devrait rebaptiser MDA en “Model Driven Agility”
Bonjour Samuel,
Pour moi le MDA atteint des limites rapidement sur 2 points :
- une modèlisation graphique ce qui ne facilite pas l’expression (c’est d’ailleurs pour ça que les langages naturels utilisent des lettres et non des idéogrammes)
- une illisibilité par le client (marketing, etc…) qui est incapable de valider ton modèle métier voir dans discuter seulement avec toi.
C’est pour cela que je pense que le modèle ne doit pas être au centre du projet.
On viendra peut être un jour à définir des méta-modèles métier avec des DSL qui donneront une tournure ‘MDA’ au développement mais l’approche OMG je n’y crois tout simplement pas.
Emmanuel
Encore une fois, je ne prône pas l’approche de l’OMG.
Je n’utilise pas l’UML pour décrire 100% du comportement, mais plutôt la structure et les interactions entre les modules de mon projet.
Si tu trouves que des diagrammes de Use case sont illisibles pour le client, le code l’est encore plus
Oui,
C’est d’ailleurs pour cette raison qu’Agile propose d’utiliser des User Stories ;o) qui elles sont lisibles. Sans compter qu’elles fournissent les bases des tests d’acceptabilité (toujours ça de moins à faire ;o) )et que si on outille bien ses tests (cf outils de type easydb) ou alors si on a un outil du type FUJABA (en vetrsion un peu plus stable ;o) ) on produit un rapport de tests qui définit les scénarii d’utilisation. Ce qui là encore est lisible et peut être validé par l’utilisateur ou le markéting … C’est pour cela que je crois en l’approche BDD qui vient compléter le TDD ‘classisque’.
Emmanuel