Pourquoi tout le monde ne fait-il pas du MDA ?
Un article de ODcWiki.
 Auteur : gweinbach.
|
Le MDA (Model Driven Architecture), tel que formalisé par l'OMG peine à démarrer réellement. Pourtant, sur le papier, tous les ingrédients du succès sont là :
- Le MDA se focalise sur le besoin utilisateur, dont la mauvaise prise en compte est la principale cause d'échec des projets.
- Le processus outillé du MDA, intrinsèquement agile, améliore l'évolutivité fonctionnelle, et diminue l'effet tunnel.
- L'indépendance vis-à-vis de la technologie pérennise les investissements.
- L'industrialisation du processus diminue les coûts de développement et améliore la qualité.
Séduisant, non ? Le MDA apporte des réponses à pratiquement tous les maux liés au développement informatique (au moins dans le monde de la gestion). La question se pose donc naturellement : pourquoi, aujourd'hui, une part significative des projets n'est-elle pas développée selon les préceptes et avec les outils du MDA ? Et pourquoi ne voit-on toujours pas émerger de grand mouvement de fond qui amènerait les acteurs du marché à se tourner vers ces technos ?
Les raisons sont à la fois multiples et profondes, nous allons le voir. Mais, si vous avez le courage de me lire jusqu'au bout, vous le verrez, aucune n'est rédhibitoire ! L'avenir du développement centré sur les modèles reste ouvert, et, à mon avis, riche de perspectives. Et son présent est déjà plein de succès, à condition d'éviter les écueils que je vais détailler.
PETIT RAPPEL : QU'EST-CE QUE LE MDA ?
Quelle que soit la démarche, un processus de développement informatique produit peu ou prou toujours les mêmes livrables : une expression de besoins utilisateur (ce que doit faire l'application), une analyse fonctionnelle de ces besoins (comment l'application doit les résoudre), une conception technique (comment l'analyse fonctionnelle se décline sur l'architecture technique cible), un code source (implémentation de la conception technique) et enfin, l'application proprement dite, issue de la compilation et de l'intégration du code source.
Classiquement, tous ces livrables, à l'exception du dernier, sont produits manuellement. Le Développement Centré sur les Modèles (Model Driven Development ou MDD) se propose d'automatiser la production de la conception technique et du code source. Le dernier livrable "manuel" devient donc l'analyse fonctionnelle, tout le reste étant produit automatiquement. Cette automatisation est permise par le fait que l'analyse est réalisée sous forme de modèles formels (le plus souvent en UML), interprétable par un programme.
L'OMG a proposé une normalisation d'un tel processus : le MDA. Les spécifications MDA définissent un vocabulaire adapté, des contenus standard pour les livrable, et spécifient les outils à mettre en oeuvre. Attention, on le voit, le MDA n'est que du "paperware" ! Aucun outil, ni surtout, aucun processus de certification n'est fourni. En ce sens, l'utilisation du logo MDA ne garantit pas la conformité aux spécifications. Il n'assure même pas que l'"esprit" du MDA est respecté.
MDA : CIM, PIM, PSM et autres TLA...
L'OMG définit donc un workflow et des livrables :
Le processus métier indépendant de toute automatisation d'où est issue l'expression de besoin est décrit sous la forme d'un "CIM" (Computation Independant Model). L'analyse fonctionnelle détaillée, coeur du processus est concentrée dans le "PIM" (Platform Independent Model), qui, comme son nom l'indique, est strictement indépendant de l'architecture technique et du langage cible. Le "PSM" (Platform Specific Model) est le modèle de conception technique obtenu par transformation du PIM par projection sur l'architecture technique cible. C'est sur ce modèle que s'appuie la génération de code.
Je passe sous silence les MOF, QVT, OCL et autres ASL, mais, on le voit, MDA est un bon réservoir de TLA (Three Letters Acronyms) :-)
Les points clés
Pour résumer, les caractéristiques structurantes du MDA sont :
- L'énergie mise dans le projet (i.e. l'argent, les gens, l'intérêt, les contraintes...) est principalement affectée à la phase d'analyse fonctionnelle détaillée (et non à la phase de développement).
- La complexité fonctionnelle est "concentrée" dans les PIM, la complexité technique est concentrée dans l'outillage de génération/transformation, et dans le framework cible.
- Les PIM sont strictement fonctionnels et constituent le code source de l'application.
- Le cycle de développement est très court et l'approche par transformation/génération permet de confronter très souvent l'utilisateur avec l'application.
Le point le plus important dans ce qui vient d'être dit, c'est cette volonté de traiter explicitement, indépendamment et en profondeur, la complexité fonctionnelle. C'est ce qui fait vraiment la différence et l'intérêt de l'approche. Toutes les autres caractéristiques du MDA en sont les conséquences.
LE MDA AU QUOTIDIEN
Intéressons nous de plus près au MDA, telle qu'il est pratiqué sur les projets.
Le PIM, livrable ultime ?
Théoriquement le PIM est un modèle uniquement fonctionnel (débarrassé des contingences techniques), c'est un modèle objet (c'est-à-dire dans lequel on retrouve à la fois les structures ET les traitements associés).
Dans le PIM on doit retrouver le modèle de TOUTE l'application (puisqu'on doit la générer, dans l'idéal à 100%). On ne peut donc se contenter d'un modèle de domaine mais il doit aussi contenir un modèle applicatif (c'est-à-dire qu'on doit modéliser les entités métier mais aussi les services métier voire les interfaces utilisateurs, les transactions, la navigation…).
En pratique, dans les rares cas où le PIM est réellement un modèle purement fonctionnel, c’est le plus souvent, un « modèle de domaine » réduit au modèle de la base de données, simple support de la persistance, sans aucune méthode métier. C'est quelquefois un embryon de modèle applicatif (souvent très « CRUD »). De temps en temps on y trouve un diagramme d’état pour les enchaînements d’écrans et exceptionnellement, quelques règles de gestion modélisées sous forme de diagramme d’activités ou des tentatives de diagrammes de séquence « boîtes blanches » permettant d’identifier quelques méthodes.
Mais en majorité, le PIM produit est un modèle très technique qui contient en filigrane toutes les informations relatives à l'architecture cible. On y retrouve couramment des éléments tels que "WebService", "Primary Key", "DAO" voire "EJBSession". Pour résumer, les PIM sont souvent des PSM qui n'osent pas dire leur nom ! Et le MDA est réduit à de la génération de code.
MDA vs. Génération de Code
On parle souvent d'"approche MDA" pour mettre une fausse barbe à ce qui est de la bonne vieille génération de code : chaque élément de modèle est injecté dans un template de code plus ou moins malin. On peut parler d'accélérateur de développement, de "wizard", de "cartridge", ou de patron de génération. C'est utile, souvent efficace, mais ça n'a rien à voir avec ce qui a été présenté dans le paragraphe précédent ! En particulier, le modèle source n'a rien de fonctionnel, il est réalisé par le développeur et a contrario, rien n'est fait de particulier pour effectivement travailler en profondeur sur le fonctionnel.
Confondre MDA et génération de code est (volontairement ou non) une vision naïve.
MDA = usine à gaz ?
Quel est, théoriquement, l'avantage décisif d'un processus MDA par rapport à un processus classique : l'application étant générée automatiquement à partir d'un modèle d'analyse, on évite deux étapes lourdes et coûteuses, la conception technique et le développement.
Donc, si la plate-forme de transformation/génération existe par ailleurs (on le verra plus loin, ça n'est ni simple, ni gratuit), on diminue drastiquement la durée et le coût du développement.
C'est vrai si, produire le modèle nécessaire à la génération de l'application est moins coûteux que de concevoir, puis d'écrire le code cible, à la main ! C'est faux s'il est plus difficile et plus compliqué de modéliser l'application que de la développer.
Une des raisons de la méfiance de nombreux experts du développement envers le MDA tient justement à l'écart constaté entre la théorie et la pratique. En réalité la mise en oeuvre d'une plate-forme MDA est souvent :
- Compliquée - Le ticket d'entrée sur une telle plate-forme est souvent très élevé. Il faut maîtriser à la fois le framework applicatif (la sémantique d'UML utilisée), et comprendre les conséquences sur la cible d'un acte de modélisation.
- Difficile - Modéliser correctement implique des compétences finalement assez rares. N'oublions pas que le modèle à produire est équivalent au code généré. Il est donc d'un niveau de complétude et de non ambiguïté élevé. En terme de contenu comme de forme, ça n'est pas un modèle d'analyse "classique" qui est généralement interprété et surtout, complété par un être humain en phase de conception.
- Et surtout inefficace ! La plupart des plates-formes qui génèrent effectivement une application à partir du modèle fonctionnel obligent l'analyste à fournir énormément d'informations, souvent redondantes et, parfois, dans un formalisme inadapté : qui a déjà modélisé un algorithme (réel !) avec un diagramme de séquence sait bien qu'il est plus rapide de le coder. Je ne parle pas de le maintenir !
En clair, les plates-formes MDA sont souvent des usines à gaz. Essayons de comprendre pourquoi.
LE GRAAL DE LA PLATE-FORME MDA
Un point important est la confusion entretenue par les éditeurs entre un outil permettant de faire de la transformation de modèles et de la génération de code, et une plate-forme MDA.
La différence est à peu près la même qu'entre un compilateur Java et un serveur d'application JEE ! Le compilateur est indispensable mais il ne fait (presque !) rien. Et objectivement, il ne permet pas d'écrire ni de faire tourner une application de Facturation ou de Gestion Client.
Et le saut, en terme de travail à fournir, entre l'outil (modeleur amélioré, IDE instrumenté ou outil dédié) et la plate-forme MDA est très important.
Le contenu théorique de la plate-forme
En effet pour que la plate-forme soit opérationnelle, elle doit au minimum intégrer les éléments suivants :
- Une description formelle de chaque niveau de modélisation. Donc au minimum un méta-modèle de PIM (qui fixe le cadre et explicite la sémantique de modélisation, la syntaxe étant généralement celle d'un sous-ensemble d'UML), et un méta-modèle de PSM (qui décrit la cible technique).
- L'implémentation du méta-modèle de PIM dans le modeleur sous forme de Profil UML ou de DSL.
- Un transformateur du PIM vers le PSM
- Des générateurs de code : un par composant du PSM, généralement sous forme de template. Dans ces éléments, deux sont difficiles à construire : le méta-modèle de PIM (appelé aussi "framework applicatif" car il définit le cadre de l'application) et le transformateur "model to model" (PIM vers PSM).
C'est dans ces éléments que réside l"intelligence" du processus MDA et sa valeur ajoutée par rapport à un processus classique. C'est là aussi que réside sa nouveauté. En effet, un méta-modèle technique est, sinon simple, au moins sans surprise : les architectures techniques sont connues (on en trouve des instances dans toutes les applications réalisées à la main). Et le templating est une activité sans beaucoup de valeur ajoutée (et maîtrisée par à peu près tous les développeurs). Rappelons-nous, l'objectif du PIM est de compresser la complexité de l'application. Ca signifie que la "décompression" (la complexité ne s'est pas envolée comme par enchantement) doit se faire dans le processus de transformation et réapparaître dans le PSM et dans le code.
Le PIM doit donc être très "expressif" : chaque élément modélisé contient beaucoup d'information qui sera restituée dans la transformation.
Le PIM doit être complet : on doit pouvoir produire tout (ou presque tout) le PSM à partir de lui.
Pour ces raisons, un bon framework applicatif et un bon transformateur PIM vers PSM sont des constructions difficiles donc coûteuses.
L'intelligence de la plate-forme
Alors, finalement, pourquoi les plates-formes MDA sont-elles, soit inutiles, soit des usines à gaz ?
Parce que justement, le méta-modèle du PIM, celui sur lequel s'appuie l'"analyste/développeur" pour construire l'application, est souvent :
- soit naïf : on ne peut dépasser l'application CRUD,
- soit technique : on modélise le PSM et c'est plus long et plus compliqué que de coder l'application,
- soit bête : c'est le plus dommage, le PIM ne propose pas de comportement "par défaut". La quantité de choses à modéliser est telle qu'on ne compresse plus grand chose dans le PIM et qu'on en vient à regretter de ne pas les avoir codées.
MDA, PAS MORT !
C'est dit : il y a plein de bonnes raisons, aujourd'hui, pour ne pas utiliser MDA :-( Maintenant que le constat, apparemment accablant, est fait, je vais tenter de montrer qu'aucune de ces raisons n'est inhérente au MDA, mais que l'approche est intrinsèquement bonne et que tout n'est qu'un problème de mise en oeuvre. Les solutions existent à tous les problèmes cités. Je vais les présenter point par point.
Les règles de gestion
Comment faire que les règles de gestion et, plus généralement, les méthodes et traitements, soient décrites par l'analyste et fassent partie du PIM ? Une idée naturelle serait de les modéliser. Après tout, n'y a-t-il pas tout ce qu'il faut dans UML pour modéliser un algorithme ? Diagramme d'activités, de séquence (depuis qu'on peut, en UML2, définir conditions et itérations), voire de vue d'ensemble des interactions.
Dans la réalité celui qui a déjà essayé sait que l'approche n'est pas pertinente ! Si on veut pouvoir produire le code cible à partir de ces diagrammes ils doivent être équivalent à du code, c'est-à-dire être complets et extrêmement rigoureux.
Or les diagrammes dynamiques d'UML n'ont pas été faits pour être compilés : ils sont très difficile à maintenir et surtout, leur syntaxe, telle qu'implémentée dans les modeleurs est toujours incomplète et la plupart du temps beaucoup trop laxiste. Pourtant, derrière l'implémentation d'UML se cache un outil qui répondrait aux besoins : ces diagrammes dynamiques s'appuient sur une syntaxe abstraite, ASL (pour Action Semantics Language) qui permet de décrire toute la dynamique associée au modèle statique.
Une syntaxe concrète (i.e. un langage de programmation) associée à ASL suffirait pour non plus modéliser, mais programmer en UML ! C'est ce que certains outils (un peu confidentiels malheureusement) comme D.OM ou Kermeta proposent : une langage de script très intégré au modèle UML, permettant d'écrire le corps des méthodes dans le PIM.
Avantage supplémentaire de l'approche : on peut simuler, et donc tester, ces méthodes avant même de disposer des transformateurs vers la plate-forme cible.
Le modèle applicatif
Qu'est-ce qu'une application de gestion ? Ou plutôt, quels sont ses constituants standards ? Quels services proposent-ils aux utilisateurs ? Comment interagissent-ils entre eux ?
Ces questions, dont les réponses permettent de construire des applications homogènes, faciles à prendre en main et à maintenir, on devrait d'ailleurs y répondre indépendamment de l'approche MDA.
Une fois définis ces "Menus", "Liste paginée", Sélecteur Multi-critères" et autres "Fiche de détail", modéliser l'application devient plus facile. Ces composants définissent la partie applicative du PIM (l'autre partie étant le Domaine constitué des Entités). Pour modéliser à partir de ces composants, un simple profil UML suffit.
Une classe du PIM est stéréotypée <<Entité>> si elle fait partie du Domaine Métier, <<Menu>>, <<Sélecteur multi-critères>> ou autre, si c'est une classe applicative. On est loin des <<Primary keys>> et autres <<EJB Session>> si souvent rencontrés ! La sémantique d'UML est ici fortement spécialisée. Un attribut d'un <<Sélecteur multi-critères>> signifie tout autre chose (l'existence d'un critère de sélection) qu'un attribut porté par une <<Entité>> (qui est une propriété gouvernant l'état de l'entité).
Compresser la complexité
Les composants cités précédemment sont de très haut niveau. En d'autres termes, le fait de stéréotyper une classe avec un élément du framework applicatif lui apporte de multiples comportements par défaut. L'analyste dit beaucoup de choses lorsqu'il crée une telle classe : il y met énormément d'informations.
C'est ce qui rend le MDA, correctement mis en oeuvre, plus simple et surtout plus efficace que de coder les composants précédents. De la même manière qu'un framework technique améliore la productivité du développeur, un (bon) framework applicatif améliore la productivité de l'analyste. Il ne faut pas négliger un autre manière de mettre de l'information dans un modèle : le formalisme Objet permet, nativement, de réduire la combinatoire d'un problème. En particulier le polymorphisme remplace avantageusement les kyrielles de 'if' imbriqués qu'on rencontre très souvent dans le code des Services Métier des applications à "domaine anémique" (le domaine est dit "anémique" lorsque les entités ne portent pas de méthodes et ne sont que le support de la persistance).
Même si les deux points que l'on vient d'aborder ne sont pas nécessairement liés à l'approche MD, on est en plein dans un de ses objectifs : compresser la complexité. "Aggressive defaulting", et modélisation objet sont les deux piliers sur lesquels doit s'appuyer le MDA.
Réalisme et pragmatisme
Pour que le tableau soit complet, il nous faut répondre aux questions concrètes et légitimes que pose la mise en oeuvre du MDA. Les réponses apportées sont issues d'une pratique éprouvée sur de mutiples projets réels.
« Doit-on autoriser la modification manuelle du code ? »
Si on veut être sûr d'éviter le syndrome de l'usine à gaz, il faut poser le postulat suivant : la plate-forme MDA ne génère pas tout. A partir de là la réponse à la question est évidente : oui.
On a alors deux approches : modifier directement le code généré ou le "spécialiser" (dériver le code manuel du code généré).
La spécialisation simplifie le travail de la plate-forme (qui n'a pas besoin de s'occuper de maintenir le code manuel) mais produit un code parfois étrange. En tout état de cause sa structure n'est pas la même que si le code avait intégralement été écrit à la main. Et objectivement, ce n'est pas toujours possible : du SQL, par exemple, n'est pas nativement "spécialisable" !
La modification directe du code généré est traitée dans la réponse à la question suivante.
« Que se passe-t-il si je modifie le code généré ? »
La question sous-jacente est en fait : comment maintenir la cohérence modèle/code dans ce cas ?
Certains outils permettent nativement le "round-trip" PSM/code. Il utilisent deux approches :
- Les "commentaires signifiants" qui délimitent des zones modifiable/modifiées/non modifiables. C'est efficace mais rend le code illisible sans le plug-in de l'IDE adapté. Cela rend surtout le code très fragile : une virgule mal placée dans un commentaire casse le processus.
- L'analyse syntaxique : l'outil est "intelligent" et maintient en mémoire le modèle sous-jacent au code. C'est beaucoup plus élégant mais reste sensible au renommage manuel.
Seul petit problème : en l'absence de round-trip PIM/PSM, ça ne sert pas à grand chose. En effet, ça n'est pas le PSM mais le PIM qui est construit manuellement.
Ce maintien bidirectionnel de la cohérence entre PIM et PSM nécessite pour chaque transformation, d'implémenter son inverse ! Même si les outils les plus puissants le permettent théoriquement, en pratique, personne ne prendra cette peine. C'est beaucoup trop compliqué !
Puisque cette cohérence modèle/code n'est pas garantie, on en vient donc à répondre à la question suivante.
« Comment travailler en itératif si le code généré est modifié ? »
C'est là qu'il faut faire preuve de pragmatisme et accepter que le processus n'est pas aussi parfait qu'on aurait pu le rêver : le code généré est recopié dans un environnement de développement séparé, retouché manuellement et éventuellement fusionné avec une regénération ultérieure. Ca n'est ni plus ni moins que le processus auxquels les gens qui utilisent des Branches dans leur gestion de configuration sont habitués.
« Dois-je gérer le code généré en configuration ou seulement les modèles ? »
La réponse à la question précédente donne déjà la réponse : on doit gérer, les modèles ET le code retouché (ainsi bien évidemment que les profils UML, le framework applicatif, les transformateurs/ générateurs et tout ce qui constitue la plate-forme).
« Quel pourcentage de code est-il raisonnable de générer ? »
Le code sans valeur ajoutée produit habituellement par coper/coller ou par utilisation des wizards de l'IDE doit être intégralement généré.
Concernant le code métier (hors IHM) de 60 à 100% du code peut être produit. La différence tient en l'utilisation ou non d'un langage pour écrire les méthodes métier.
Les IHM peuvent être générées à 100% (hors syndrome du "bouton rouge italique en haut à droite" qu'il faut pouvoir adresser manuellement) si le framework applicatif est riche et complet. La réalité constatée plafonne souvent à 80%.
En dessous de 50%, ça n'est pas du MDA, c'est de la génération "naïve" de code. On n'est pas "centré sur les modèles" mais on reste "centré sur le code". Et on n'atteint pas du tout les objectifs du MDA.
« Quels gains peut-on attendre de l’approche »
La mise en oeuvre réelle des préceptes que j'ai décrits permettent de très gros gains sur :
- La qualité : le code produit est homogène et répond parfaitement aux normes et bonnes pratiques du développement.
- Les performances : toute optimisation est immédiatement utilisée par l’ensemble de la, ou des application(s).
- L’évolutivité fonctionnelle : l’impact d’une évolution fonctionnelle est immédiatement évaluable.
- La pérennité : via une certaine indépendance vis-à-vis de l’évolution de la technique.
- L’acceptabilité des applications : le cycle de développement très court, et la proximité de l'analyste facilitent le feedback utilisateur.
- La productivité : les charges de développement sont maîtrisées et les gains sont substantiels (-30% sur les coûts) une fois la plate-forme MDA opérationnelle (sans négliger le coût de mise en place de la plate-forme qui s'amortit généralement sur le premier projet, voire sur les premiers "Use Cases" si le projet est de taille suffisamment importante).
CONCLUSION
On l'a compris : si tout le monde ne fait pas du MDA c'est d'abord parce que pratiquement personne n'en fait vraiment !
La plupart des processus estampillés MDA n'en respectent pas l'esprit et discréditent l'approche.
Mais des réalisations concrètes existent et viennent démontrer la pertinence du propos si tant est qu'il soit compris et correctement outillé.
