David BROCARD Consultant Indépendant

La compatibilité "Model Driven & Agilité" agite la blogosphère depuis quelques temps.
Revenons un instant sur nos arguments en faveur de l'association de ces deux approches.

MDSD, MDA ?

Tout d'abord nous tentons d'expliquer les racines des réticences récurrentes à l'approche Model Driven...

Le Model Driven est quasi-systématiquement assimilé au MDA alors qu'il existe d'autres approches. Nous n'utilisons pas cette approche et nous la critiquons également.

• La plupart des projets sont de type RUP-MDA-UML utilisant des outils trop généralistes et des profils UML de trop bas niveau
• On ne voit pas vraiment évoluer les solutions sur le marché. Pour nous, le MDA n'est pas mature et suivre les conseils d'un éditeur logiciel est rarement une bonne chose.
• La transformation PIM->PSM rend la démarche quasiment inapplicable, par manque de solution fiables de transformation itératives de modèles et les modèles PSM sont souvent trop techniques
• Les générateurs n'étant pas toujours modifiables, il faut souvent se satisfaire des choix techniques de l'éditeur
• Les modèles imposés sont un frein, trop loin des métaphores adaptées

Notre démarche

De notre côté, nous voyons le Model Driven Software Development comme quelque chose de simple et efficace qui s'appuie sur des modèles décrits par des métaphores adaptées aux processus cognitifs de résolution de problèmes (DSL) et des composants tels que des générateurs, transformateurs et vérificateurs, permettant la capitalisation et la généralisation des savoirs-faire.
Notre démarche est basé sur 3 principes :

• Simplicité : on s'affranchit de la couche PSM : PIM->code
• Adaptation : on utilise des DSL et des générateurs sur mesure
• Agilité : DSL et générateurs sur mesure sont en évolutions constantes

L'orientation "DSL+générateur sur mesure" est fondamentale et n'a été appliquée que par une minorité de projets. Nous mettons en place ce type de démarche MD depuis une dizaine d'années pour des sociétés du secteur bancaire, aéronautique, hospitalier... Nous appliquons cette démarche pour des développements personnels, avec une démarche itérative et incrémentale en développant conjointement l'application et le générateur.

Conception simple, refactoring, livraisons incrémentales

S'il s'agit de savoir si on peut utiliser une démarche de développement itérative et incrémentale avec du MDSD, la réponse est oui, la seule condition est de disposer d'un générateur qui offre la possibilité de créer autant de "zones manuelles" (zones dans lesquelles du code est écrit à la main) que nécessaire dans les fichiers générés.
Notre approche MDSD est top-down à sens unique, Modèle -> Code; On modifie soit le modèle, soit le générateur (soit les deux)‏
Un changement d’architecture technique intervient principalement au niveau du générateur
Un changement de type fonctionnel intervient au niveau du modèle ou du code spécifique
Les changements sont facilités, car automatiquement répercutés partout où cela est nécessaire; ex: renommage de classe, déplacement dans un autre paquetage, etc.

Gestion de configuration, chaîne de production et intégration continue

On peut ensuite s'interroger sur la duplication modèle / code : la réponse est "il n'y a pas duplication", pour différentes raisons :

• Le modèle et le code ne sont pas sur des niveaux d'abstraction équivalents. Le modèle parle (métaphores) des grands principes de l'application (par exemple, des données, des services, des ihms, etc.). Le code représente une solution technique qui respecte les choix de conception exprimés dans le modèle (mais avec un même modèle, si on utilise différents générateurs, on peut générer du code java, C#, différentes implémentations pour solutionner un pb, etc.).
• La question de la duplication se poserait si on générait 100% du code à partir du modèle. C'est rarement le cas, et ce n'est d'ailleurs généralement pas souhaitable. De la même façon que l'établissement de documentations verbeuses et trop rigides est contre agile, la modélisation de toutes les informations permettant une génération à 100% serait fastidieuse et contre productive. Généralement, le taux de génération final se situe entre 70 et 100% selon les types de fichiers.
• Il est vrai qu'il faut choisir soigneusement son outil de modélisation pour que la gestion de configuration des modèles soit bien effective. C'est très important et nombre des modeleurs sur le marché sont faiblards concernant cette fonctionnalité. Plusieurs solutions existent et fournissent une réponse satisfaisante. Toutefois, on va chercher, tout comme le développement "classique" à limiter les interférences des domaines de travail

Modèles et génération de code

Le choix du type d'information qu'on met dans les modèles, et le type d'information qu'on met dans les générateurs est de première importance, et l'approche que nous présentons est bien particulière.

Les modèles décrivent les concepts essentiels de l'application à construire, cad que ce sont tout simplement les Métaphores dont parle l'Agilité. Si on développe une application du type "composants MVC distribués" ou une application type SOA, on fait exister les concepts de haut niveau correspondants (objets métiers, contrôleurs, ihms, services, pages jsp, widget...). Le niveau d'abstraction du modèle est plus haut que le code, cad que par exemple, quand on modélise une <<donnée>> (cad UNE boiboite), on génère derrière plusieurs choses (un fichier hibernate, une interface JAVA, un classe d'implémentation, une classe DAO, un fichier de test JUnit, un fichier de properties, etc.). Autrement dit, le mapping technique "j'ai une donnée Facture, je dois mettre en place tous ces fichiers" qu'on faisait avant "à la main et au cerveau" est rentré une fois dans le générateur et réalisé automatiquement (+ sans erreurs, avec du code de qualité, etc... et sur 70% ou + du code). C'est à la fois évidemment :

• plus productif,
• mais cela permet également en modifiant le générateur de répercuter en masse des évolutions techniques très importantes (agilité technique boostée)
• chaque fois que vous développez (agilement) un nouveau type de générateur, vous capitalisez sur quelque chose. Si vous êtes amenés à réappliquer les mêmes choix d'architecture pour un projet, vous aurez un feedback bien plus rapide (les modèles sont simples et parlants (métaphores), donc rapides à rentrer, et la génération produit de l'ordre de 70% du code de l'itération en quelques secondes. Le démarrage du projet est donc largement facilité.
• la démarche découple bien deux pistes de changement qui étaient habituellement intriquées : fonctionnel (modèle) et mapping technique (générateur). La démarche permet donc d'intervenir sur l'un, sur l'autre, ou sur les deux en mm temps, avec le moindre effort et une réflexion orientée autour des concepts haut niveau qui vont bien (les métaphores)

On se fait souvent tout un monde des métamodèles ou des profils UML, et on considère que développer un générateur relève de la R&D. En fait c'est beaucoup plus simple que ça... Développer un profil ou un métamodèle revient à exprimer clairement et donner vie aux concepts de son architecture logique, et développer un générateur de code est un jeu d'enfant avec un outil comme MIA (www.mia-software.com). On peut toujours générer le code dont on a besoin.

On ne génère pas une conception. On applique des patterns de conception (règles de génération) sur des éléments du Modèle (objets métier, services, ihms...). Évidemment, ça veut dire que le gros du travail de conception technique n'est plus réalisé par tout le monde, mais par les personnes qui vont coder les règles de génération correspondantes dans le générateur. Au final, la conception est à la fois une décision prise par le développeur dans son modèle (qui conçoit une solution pour répondre aux histoires utilisateur en utilisant un vocabulaire technique limité au strict nécessaire), et un mapping de conception codé une fois dans le générateur. Il faut aussi noter que généralement le code généré (une classe java admettons) peut s'appuyer sur du code non généré (frameworks maison, hibernate, spring, etc.).

Cycle de vie

Le cycle de vie agile (type Scrum ou XP) est respecté. Finalement, la nouveauté, c'est seulement qu'au lieu de coder directement dans l'application, on code aussi dans le générateur. Avant on avait une tâche "développer mes fichiers hibernate pour Facture et Ligne de Facture", avec MD on a "développer le template de génération du fichier hibernate pour une donnée"). Ca ne prend guère plus de temps et ça n'impacte pas le cycle de vie.

Outils

On objecte souvent que la dépendance aux outils de modélisation et de génération va à l'encontre de la première valeur agile ("Interaction avec les personnes plutôt que les processus et les outils").
Certes, à ce jour, le panel d'outils disponible pour faire du MDSD est plus restreint que les environnements de développement. Mais quand les solutions outillées sont suffisamment diversifiées, elles ne constituent plus un frein ou une trop forte dépendance.
Nous ne demandons qu'à être pragmatique (nous le sommes déjà !) et ne pas dépendre de la promesse d'outils à venir. Certes nous rencontrons aujourd'hui quelques limites avec les outils existants mais ces restrictions nous semblent largement compensées par les avantages dont nous disposons par ailleurs.
C'est pourquoi aujourd'hui nous sommes bel et bien dans une optique de "consolidation" de notre approche et recherchons des environnements propices à cela et des projets, des personnes intéressées.

Conclusions

• Ne jetons pas le bébé MDSD avec l'eau du bain MDA...
• Le MDSD ne nuit pas à l'agilité et peut même la décupler

En présentant notre vision, nous nous attendions à de vives réactions et réticences. Le sujet divise et l'idée de l'incompatibilité des approches Model Driven et de l'Agilité semble l'emporter. Cependant nous demeurons confiant envers la communauté agile car elle est prompte à accueillir le changement avec bienveillance, à comprendre l'intérêt d'utiliser certaines pratiques MD de façon pragmatique, sans remettre en cause sa philosophie de développement agile préférée.
Il faudrait bien entendu aborder d'autres concepts et pratiques agiles pour poursuivre le débat (TDD, standard de codage...)
C'est justement l'objet de la présentation que nous mettons au point actuellement.

David & Romain