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).