jeudi 13 novembre 2008

MODEL-DRIVEN ET AGILITE (MDE2)

Suite à mon précédant billet en réaction à un article sur la démarche de développement piloté par les modèles, je souhaite revenir sur la cohabitation de l'agilité et du MDE. Le développement piloté par les modèles et les démarches agiles sont-ils compatibles? Peut-on envisager un MDE agile? Pourquoi ai-je été si déçu par mon expérience du MDE et si motivé par ma pratique du développement agile?

DÉVELOPPEMENT PILOTE PAR LES MODÈLES


Entendons-nous, par
MDE, je parle d'une démarche de développement où les modèles UML sont les principaux artefacts élaborés et maintenus par les développeurs. Par exemple, le code est généré par transformations de modèles.

MDE ET MANIFESTE AGILE


Pour sonder une éventuelle compatibilité, on peut commencer par se demander si le MDE est compatible des valeurs du Manifeste Agile.

Il me semble que le pilotage par les modèles met fortement l'accent sur les outils. L'éditeur UML, les transformations de modèles et les générateurs de code sont autant d'outils sur le chemin critique du développement. Ces outils particuliers viennent s'ajouter aux incontournables outils tels que le gestionnaire de versions, le compilateur, le framework de test, l'IDE, etc. D'ailleurs, on constate que cette démarche est essentiellement poussée par des vendeurs d'outils. Aussi, le MDE est souvent cité dans le cadre des fameuses "usines logicielles" avec leurs processus fortement automatisés. Tout ceci semble aller à l'encontre de la première valeur du manifeste: "Individuals and interactions over processes and tools
".

Les modèles sont-ils assimilables à un logiciel opérationnel ou à une documentation exhaustive? Par transformations de modèles, on peut générer à la fois une documentation et un logiciel exécutable. Mais, est-ce que ce logiciel exécutable est pour autant un logiciel opérationnel? Le fait qu'une application apporte une valeur opérationnelle est lié au fait qu'il réponde correctement aux besoins des utilisateurs. Cette satisfaction passe souvent par la sanction de tests. Pourtant, il me semble que le test est peu traité par le MDE. Ainsi, je serais tenté d'émettre des réserves sur le fait que le MDE privilégie "Working software over comprehensive documentation".

Enfin, rien dans une démarche pilotée par les modèles ne me semble aller à l'encontre des deux dernières valeurs du manifeste, à savoir
"Customer collaboration over contract negotiation" et "Responding to change over following a plan". De même, les douze principes du Manifeste Agile semblent pouvoir s'appliquer dans le cadre d'un tel développement.

MDE ET SCRUM


Dans la répartition des rôles, dans le cérémonial et dans la démarche de Scrum, je ne vois rien qui soit incompatible avec un développement piloté par les modèles. Scrum porte sur le pilotage du projet alors que le MDE adresse essentiellement les activités techniques. Il me semble qu'il doit être possible de conduire un développement piloté par les modèles avec une démarche Scrum, pour peu qu'on s'assure de livrer un produit opérationnel potentiellement livrable à la fin de chaque itération et pas seulement des modèles.


MDE ET EXTREME-PROGRAMMING


La confrontation du MDE et de XP me semble plus pertinente car les deux démarches adressent les aspects techniques du développement.

XP insiste sur le fait que le code et les tests sont idéalement les seuls artefacts à maintenir. Les autres artefacts doivent être générés à partir du code et des tests. Nous sommes à contrepied de la génération de code. Si le code est au centre du développement, c'est qu'il est primordial. C'est le code qui est transformé en logiciel exécutable ou interprété. C'est aussi le code que l'on déroule sous le débogueur pour les problèmes sérieux.

Le remaniement n'est pas pleinement efficace si le code ne peut être modifié directement, car généré. Certes, le modèle peut être remanié, mais cela ne garantit pas un code de qualité. Ne l'oublions pas, c'est le code qui est interprété ou compilé pour produire le logiciel exécutable, pas les modèles. C'est aussi le code qui est débogué. Le débogueur ne s'interface pas avec les modèles. Lorsque les choses finissent fatalement par se compliquer, il faut que les développeurs se plongent dans le code. C'est alors qu'un code remanié prend toute son importance. La suppression des duplications, la simplification du code et le gain en lisibilité résultant du remaniement facilitent l'assimilation du code par les développeurs.

Le cycle très rapide de test, codage et remaniement perd son rythme dynamique s'il faut passer par une étape supplémentaire de génération de code. Le passage très rapide des artefacts principaux au logiciel opérationnel est un fondamental d'XP. L'ajout de l'étape de génération de code va à l'encontre de ce fondamental.

L'intégration continue n'est possible que sur des artefacts pouvant être mergés. Or, comme nous l'avons vécu à nos dépens, à l'inverse du code, les modèles sont des artefacts dangereux à merger. Le développement concurrent et intégré en continue me semble impossible si les modèles sont les artefacts principaux. Ceci est très regrettable car une intégration continue efficace est un sacré atout pour réussir un projet.

Bref, il me semble impossible de conduire un développement piloté par les modèles avec une démarche XP.

MDE ET CODE

Un des avantages fréquemment cités du MDE est la possibilité de s'affranchir du code en élevant de niveau d'abstraction. Mais, il me semble qu'il ne faut pas se leurrer: pour générer du code, il faut saisir dans le modèle tout un tas d'informations non-graphiques utilisées par le générateur pour produire le code. Bref, cela revient presque à coder avec une autre notation.
Et puis, qu'on ne dise pas que les modèles affranchissent le développeur du code: le débogueur ne s'interface pas avec les modèles. Lorsque les problèmes deviennent sérieux, il faut bien en venir au code. A ce moment là, on espère avoir conservé quelques compétences en programmation.

Enfin, pour ce qui est du logiciel opérationnel, il va bien falloir en passer par les tests, même si on édite des modèles. Comment sont implémentés les tests? En code ou en modèles? Et si les tests sont modélisés, comment sont exprimées les assertions? En code.
Bref, je pense qu'il est un leurre de croire que les modèles permettent de s'affranchir du code pour développer une application. Cela est peut être vrai pour l'exemple pédagogique de la machine à café ou pour des applications simples. Le problème est qu'on ne paye pas des professionnels du développement logiciel pour construire des machines à café et des applications simples.

EN CONCLUSION

En fait, je pense qu'un développement piloté par les modèles gagne à être conduit dans une démarche agile, comme Scrum. Ainsi, le projet gagnera en transparence et du logiciel opérationnel sera régulièrement disponible.
Par contre, je ne vois pas ce qu'un projet agile gagne en utilisant les pratiques techniques pilotées par les modèles. Il me semble que centrer le développement sur le code et les tests va dans le sens de la simplification, de l'accélération du développement et de la production d'applications opérationnelles. Bien sûr, cela ne veut pas dire que l'équipe ne modélise pas. Il est très efficace de communiquer à l'aide de modèles utilisant une notation unifiée. Simplement, des marqueurs, des tableaux blancs et des appareils photos peuvent suffire (voir photo).

16 commentaires:

  1. Je suis bin d'accord avec la conclusion et je dirai même plus, une équipe agile contrairement à ce que l'on croit a plus de probabilité de modéliser qu'un équipe 'traditionnelle'. J'en veux pour preuve les résultats des études du Doctor Dobb's Journal présentées par Scott Ambler (dont une traduction française est présente ici).
    Désolé pour l'auto-promotion;o)

    RépondreSupprimer
  2. Ton billet est très bien argumenté (comme souvent !).
    Je me pose également cette question de la compatibilité entre MDE et agilité depuis pas mal de temps, et je partage tes réflexions.
    Quand on part des leitmotivs : "The model is the code" (MDE) et "The code is the model" (XP), on se dit qu'on aura bien du mal à réconcilier les 2 approches !

    Pascal

    RépondreSupprimer
  3. Très bonne analyse !
    Et si même Emmanuel (ehsavoie) pousse les approches MDE, champagne ! ;)

    J'en profite pour te remercier Emmanuel (Chenu cette fois :) pour ton excellent doc "Pratiques d'équipe" sur lequel je me suis appuyé pour utiliser SCRUM sur un projet (Le NIKO NIKO a beaucoup plu !).

    Samuel

    RépondreSupprimer
  4. Oulà, ne me fais pas dire ce que je n'ai pas dit Samuel, je suis resté un sale cow-boyz codeur dans l'âme ;o). Mais même moi je sais reconnaitre la nécessite d'un minimum de modélisation (et ça ce n'est pas peu dire). Je dirai même plus: "The code is the model and the code is the documentation (with the tests)" mais le tableau blanc ça aide bien qu'en même et produire de la doc aussi (mais bon je ne parle pas de cet affreux outil du nord des USA produisant des binaires propriétaires).

    RépondreSupprimer
  5. Notre équipe ne partage pas tout à fait ce point de vue
    Nous avons une expérience plus réussie de la cohabitation MD / Agile, pour plein de raisons que nous évoquerons bientôt.
    En attendant, voici notre vision, elle est différente de la plupart des démarches MD :
    ici

    Mais il est vrai que :
    - le succes du MD Agile est conditionné par l'outil
    - la problématique des merges aussi, meme si cela ne tient que parce que les modeleurs actuels n'ont pas encore la fonctionnalité adéquate (mais certainement bientôt)

    @+

    RépondreSupprimer
  6. Je suis très intéressé par ta prochaine présentation au SigmaT que je ne manquerai pas !

    Je ne demande qu'à être convaincu, car je suis un fervent partisan de la modélisation depuis une vingtaine d'années ... Mais c'est vrai que les outils commerciaux m'ont souvent déçu par leur lourdeur et leur côté "propriétaire".

    Pascal

    RépondreSupprimer
  7. Malheureusement, comme je l'ai mis en commentaire en fin de post, la prez sera pour une prochaine fois !
    En attendant, nous cherchons des environnements industriels pour "officialiser" nos idées & pratiques.
    Alors si vous êtes intéressés ou si vous connaissez des projets candidats, n'hésitez pas à m'en parler !

    Merci

    RépondreSupprimer
  8. Le problème est d'une démarche de développement me semble pragmatique que si elle est basée sur des faits. La promesse d'outils à venir (comme le merge de modèles) ne me semble pas pragmatique.
    L'exemple du merge de modèles n'est pas anodin, car cela conditionne une intégration continue fluide des développements basés sur les modèles. Néanmoins, je reste bien sûr à l'écoute d'autres arguments.

    Sinon, ces 2 billets ont eu quelques réactions sur les blogs. Vous pouvez notamment lire:
    http://www.aubryconseil.com/dotclear/index.php/2008/11/17/496-controverses
    ou
    http://www.touilleur-express.fr/2008/11/17/mda-scrum/

    RépondreSupprimer
  9. Un autre réaction: http://agilitateur.azeau.com/post/2008/11/19/Agilit%C3%A9%2C-mod%C3%A9lisation-et-m%C3%A9ta-programmation

    RépondreSupprimer
  10. Le comique de la situation actuelle sur la capacité d'intégrer de la modélisation dans un développement agile, c'est quand même cette nécessité d'avoir les bons outils disponibles.
    La première valeur du manifeste agiles n'est pas la plus simple à expliquer et à comprendre.

    RépondreSupprimer
  11. Sans même parler d'agilité mais juste de développement logiciel je suis d'accord avec le dernier post à savoir qu'il est beaucoup plus 'naturel' d'exprimer les détails d'un programme avec un langage textuel plutôt qu'avec des images. Les images représentent mieux les concepts généraux. J'en veux pour preuve l'évolution de l'écriture: des idéogrammes vers les alphabets. Pour moi on va plus vers des langages de haut niveau de type DSL qui permettront de modéliser et que l'on transformera ensuite en code exécutable.

    RépondreSupprimer
  12. Bonjour,
    Je voudrais vous faire part de mon expérience :
    - Tout d'abord, vous parlez de l'aspect propriétaire des modeleurs. Fort heureusement il existe des langages d'échange comme le XMI! Ensuite, nombre de modeleurs tendent à se baser sur l'implémentation Eclipse du métamodèle UML (qui n'est pas terrible! sic), Eclipse EMF. Ainsi, un modèle peut être chargé depuis nombre de modeleurs différents. Ce constat m'amène à la conclusion que la première valeur du manifeste Agile est respectée.

    - A mon avis, le problème se situe plus du coté des outils de génération de code, qui eux utilisent leur propre langage. Mais cela n'est aucunement bloquant puisque les scripts de génération permettent de générer plusieurs projets. Et donc de devenir très vite rentables!

    - Ensuite, vous dites que la démarche MDE n'aborde que peu les tests?! Tout dépend de qui code les scripts de génération. Il est tout à fait possible de générer le code des tests.

    - Ensuite, le merge de modèle EXISTE déjà, il suffit d'utiliser les bon outils (MagicDraw entre autres). Et c'est grace à de tel outils que nous sommes désormais capable de faire de l'intégration continue sur les modèles.

    - La plupart des générateurs de code disponibles sur le marché (Mia Génération, Acceleo, ...) permettent la génération incrémentale du code (c.a.d qu'il n'est pas nécessaire de tout modéliser avant de générer, on peu procéder par ITERATIONS, oh! du SCRUM!)

    - La société pour laquelle je travaille dispose d'une équipe de R&D sur le MDE et les méthodes agiles, dont je fais partie, cette société est une société d'envergure nationale (environ 100 000 employés, et surement autant de clients par jour). Nous disposons de notre propre DSL, qui nous permet de ne pas surcharger le modèle d'informations, et donc de ne pas "coder" dans le modèle comme ce qui est dit dans l'article.
    Nous générons en général plus 70% des applications, que ce soit du j2ee, ejb, cxf, junit, mocks, dbunit, spring, struts 1, struts 2, hibernate 1, hibernate 2, hibernate 3, c#, nunit, .net2, .net3.5, oracle, db2, bouchonnage "maison", ...
    Tout cela pour vous dire qu'il n'y a aucune contraintes permettant la conjugaison des métohdes agiles et du développement piloté par les modèles.

    Par contre je pense qu'il faut nécessairement un DSL adapté et un modeleur supportant les merges.

    Si le temps me le permet je m'efforcerais à faire un article détaillé sur le sujet.

    Cordialement,

    Xavier

    RépondreSupprimer
  13. Personne n'évoque les DSL (domain spécific language). C'est une sorte d'intermédiaire entre le MDE et le codage classique, sauf qu'on ne perds pas les avantages du codage (si l'IDE supporte le DSL).
    Du coup on a une manière de programmer plus agile, mais qui demande un niveau d'abstraction (et donc d'expertise) supérieur...

    RépondreSupprimer
  14. Ce commentaire a été supprimé par un administrateur du blog.

    RépondreSupprimer
  15. Ce commentaire a été supprimé par un administrateur du blog.

    RépondreSupprimer
  16. Model-Driven et Agilité sont 2 approches qui oeuvre en synergie …
Je travaille effet sur une approche qui vise à produire des spécifications formelles métier « testable » ET « exécutable ». La spécification formelle métier est constitué d’une part d’un modèle métier (exprimé en OWL) et d’autre part de règles métiers (exprimé en SWRL).
    Cette spécification formelle métier est « testable » avant même de produire la moindre ligne de code => Agilité
    Cette spécification formelle métier est « exécutable » et permet de générer 100% d’une API métier en mode « Zéro Bug » => Model-Driven
    La génération de code est rendu possible par la plateforme Odase (http://www.odaseontologies.com/odase-platform/)
    Cf un court article sur le sujet : http://bit.ly/2mDrcJ3

    RépondreSupprimer