JugSummerCamp 2010 : Le MDA en 2010 : une vision pragmatique


Voici un compte rendu de la conférence du JugSummerCamp à propos de MDA. Il s’agit d’une présentation que j’ai apprécié car il s’agit d’un sujet auquel je touche de près ou de loin depuis quelques années, et il m’arrivait de m’interroger sur la pertinence de cette pratique.
Je tenterai de vous retranscrire les notes que j’ai pu prendre durant la conférence, sachant que les slides sont disponibles ici (et la présentation devrait être mis à disposition sur Parleys d’ici quelques temps).

Jérôme Benois, qui travaille chez Obeo, commence tout d’abord par nous dresser un historique du MDA dans les années 2000-2005 (voir un peu après …).
A la fin des années 90, un constat est fait : 2 projets informatiques sur 3 sont en dépassement. Comment capitaliser sur ces problèmes ?

En 2000, l’OMG décide d’industrialiser les développements et crée les standards UML.
L’approche MDA se plug sur UML et définit un certain nombre de transformations à partir d’un diagramme UML :

  • Le CIM : qui sert à capter le besoin et à le représenter sous la forme d’une première abstraction
  • Le PIM : qui rajoute un niveau d’indépendance vis à vis du CIM pour ne pas être adhérent à la technologie/langage cible (ex: On décrit un « composant »)
  • Le PSM : qui va décrire les considérations techniques qu’on va vouloir générer (ex: « un composant » se traduit techniquement par un EJB stateless)

On obtient alors un outillage fait par des développeurs à destination des développeurs.

MDA apporte deux pattern :

  • User-Code Pattern : L’idée est de faire de la génération de code incrémentale avec, dans le code, des zones qui ne seront pas modifiées lors d’une génération.
    Exemple :

    public class UneClasseGeneree {
        /**
          *[begin user code]
          * Une super javadoc super utile ici !
          * [/end user code]
          * La javadoc de méthode au niveau du modèle
          * @param unParam La documentation de unParam au niveau du modèle
          * @return La javadoc du type de retour de la méthode au niveau du modèle
          */
        public Integer uneMethodeGeneree(@NotNull String unParam){
            Integer result = null;
            // begin user code
            // Ici je peux rajouter autant de code que je veux : ce dernier ne sera pas écrasé lors d'une regénération !
            // end user code
            return result;
        }
    }
    

    On peut reprocher un certain nombre de défauts à cette approche :

    • Il faut bien être attentif et ne pas écrire de code en-dehors des sentiers battus (autrement dit : ne commencez pas à coder avant d’avoir pris votre café le matin !)
    • Si on n’est pas d’accord avec ce qui est généré, il est nécessaire de le remonter au plus vite afin de modifier le générateur (plutôt que de modifier les choses soi-même, et de tout perdre lors d’une re-génération)
    • Si vous voulez rajouter une méthode privée dans votre classe, il est nécessaire de bien l’entourer de begin/end user code
    • Le refactoring est très mal géré (renommer/changer le prototype de votre méthode risque d’engendrer des problèmes lors d’une re-génération)
  • Generation Gap Pattern : Séparer, grâce à des patrons de conception (héritage le plus souvent) le code généré du code non Généré. C’est typiquement ce qui est fait dans le projet Liferay où on a 3 niveaux pour chaque entity / service :
    • L’interface (ex: User)
    • L’implémentation de base, générée et écrasée après chaque génération (UserBase implements User)
    • L’implémentation développeur, vide par défaut, mais pouvant être surchargée à la main (UserImpl extends UserBase) et qui viendra populer l’interface à chaque rajout de méthode publique

    J’adhère énormément plus à cette approche qui est beaucoup plus « clean » (mais nécessite un certain outillage et complexifie un peu l’architecture mise en place !)

Le bilan de cette période est fait de plus et de moins :

  • + La productivité s’est améliorée
  • + On obtient une meilleure agilité technique et fonctionnelle
  • – On a une difficulté à maintenir en cohérence les différents modèles avec la réalité (à fortiori en phase de maintenance !)
  • – On a un risque de désynchronisation entre le modèle et le code (à fortiori dès que la phase de conception est terminée !)
  • – Il y a un intégrisme du « tout modèle » alors qu’UML montre clairement ses limites sur certaines problématiques (ex: modélisation d’une algorithmie)

Jérôme poursuit sur les implications que cela a eu sur le MDA d’aujourd’hui. Clairement, UML est trop vaste et trop générique pour pouvoir modéliser un système.
Ce qu’il voit, lui, comme opportunités aujourd’hui, c’est la vague des DSL (Domain Specific Languages) qui fournissent un vocabulaire précis et concis pour représenter une problématique donnée.
D’autre part, il voit bien que le générateur devrait rester connecté en permanence, la génération incrémentale devenant un passage obligé pour garantir une totale synchronisation entre modèle et code.
Enfin, il rappelle que le modèle doit rester, premio, un outil de communication et secondo un outil de productivité (il ne doit pas coûter plus cher que de développer ce qu’il génère à la main !).

Aujourd’hui, selon lui, le MDA prend une nouvelle dimension avec l’ingéniérie des modèle et le MDD (Model Driven Development) : La production du soft est dirigée par le modèle.
Eclipse Modeling Framework (EMF – Top level project dans la fondation eclipse) va nous aider à mettre en place cette démarche.

Le process aujourd’hui tend à se simplifier :
– Le CIM et le PIM deviennent un DSL
– L’architecture cible est décrite via des générateurs qui se basent sur le DSL
– Le PSM est remplacé par le code lui-même

Jérôme nous présente ensuite la démarche d’un « bon » générateur de code :

  • La phase préparatoire est d’identifier le vocabulaire manipulé. Cela se fait beaucoup par des réunions de travail avec le client, afin de cerner son vocabulaire fonctionnel.
  • Ensuite vient la création d’un DSL pour représenter ce vocabulaire. Représenter, par exemple, le fait qu’on ait des entités métier (au sens large du terme). Comment manipuler ce vocabulaire ? L’outillage est encore assez confidentiel, mais il est là :
    • L’API EMF Java nous permet de construire ce vocabulaire. Cela reste assez verbeux (c’est du java), et pas du tout communicable avec le client (approche purement technique).
    • Grâce à la définition de mots (au sens syntaxe d’un langage) .. et là on pense tout de suite à des outils pointus que sont flex / bison / antlr => trop compliqués !
    • C’est à ce moment que Jérome nous parle du projet XText qui est un projet de la fondation Eclipse. XText va nous demander de définir, via une syntaxe bien particulière (à apprendre), le dictionnaire de notre langage. En contrepartie, il nous permet de générer un plugin eclipse (qui est ensuite facilement diffusable auprès des équipes) qui fournit un éditeur de texte avec coloration syntaxique, quick fix, complétion … tout ça sur notre dictionnaire de données ! Pour avoir un aperçu rapide de ce qui peut être fait avec XText, ce tutorial permet de se donner des idées…
    • Le niveau au-dessus, c’est l’utilisation du Graphical Modeling Framework (GMF, toujours chez Eclipse) qui nous permet de transformer notre structure XText en quelque chose de graphique (un peu à la manière d’un diagramme de classes stéréotypé). GMF va encore plus loin en nous permettant de mêler le graphique et le textuel : lorsqu’on double clic sur l’une de nos entités, on a un éditeur texte qui nous permet de spécifier les attributs de notre dictionnaire de données.

=> Le mix EMF/GMF nous permet donc très rapidement (la syntaxe du XText ne paraît fondamentalement pas compliquée / verbeuse) d’avoir une partie modeleur spécifique à notre besoin.
Un langage de templating est ensuite mis à disposition pour transformer une photo de notre DSL en un ensemble de fichiers plats. Là encore, le langage de templating est à apprendre.

Enfin, à la question « doit-on partir d’une feuille blanche ? », Jérôme répond que ObeoNetwork met à disposition un certain nombre de ressources permettant de générer du Hibernate, du Spring, du Java EE etc…

Jérôme termine sa présentation sur l’aspect traçabilité dans le modèle/code que leur outil gère chez Obéo. L’idée de cet outillage est de garantir une connexion en permanence du générater de code : ce n’est pas parce qu’on passe en phase de maintenance que le modèle doit être désynchronisé du code !

Il nous a présenté 3 facettes de cet outillage :

  • La possibilité de voir ce que va générer le modeleur (une sorte de « dry run ») permettant de juger des impacts d’une évolution du modèle sur le code existant
  • La possibilité, lors de l’édition du code, de mettre à jour le modèle
  • La détection de modifications en dehors des zones « begin/end user code », et éventuellement le flagging de ces régions avec des commentaires justifiant ces éditions

Mon impression sur la présentation

J’ai beaucoup aimé cette présentation car j’adhère complètement au discours « Le CIM/PIM/PSM, c’est bien, mais qu’est-ce que c’est lourdingue ! ». J’ai bien aimé l’approche DSL qui, en effet, donne l’impression d’être à la fois simple, flexible et complètement en corrélation avec un besoin donné (en tous cas, moi, ça me donne envie d’y jeter un oeil ! Ne serait-ce que par curiosité ;-))

Le speaker était très bien, il a su nous faire des démo « live » (premières démos de la journée lors de la dernière conf pour moi … dommage !) qui, personnellement, m’ont facilité la compréhension de tous les concepts qui étaient présentés.

Si le sujet vous intéresse, je ne saurais que trop vous encourager à visionner la vidéo de cette présentation : vous y apprendrez sûrement des choses que je n’aurais pas su (pu) retranscrire dans ce post.

Publicités

3 Réponses to “JugSummerCamp 2010 : Le MDA en 2010 : une vision pragmatique”

  1. Tweets that mention JugSummerCamp 2010 : Le MDA en 2010 : une vision pragmatique « Frédéric Camblor Dev Blog -- Topsy.com Says:

    […] This post was mentioned on Twitter by Xavier Hanin, Frédéric Camblor. Frédéric Camblor said: JugSummerCamp 2010 : Le MDA en 2010 : une vision pragmatique: http://wp.me/pHZz6-2W […]

  2. Jérôme BENOIS Says:

    Merci pour ce résumé !

    Juste une remarque, il est possible de créer des modeleurs graphiques directement à partir d’EMF. Tu n’es pas obligé de passer par Xtext. Tu choisis de faire l’un ou l’autre ou les deux 🙂

    • Frédéric Camblor Says:

      Merci pour la précision !

      Mais dans une démarche « incrémentale » où on ne mettrait pas tout en place d’un coup, je pense qu’il est quand même plus facile d’y aller en deux temps :
      – Mise en place d’un fichier XText permettant de définir notre grammaire, et également d’avoir un premier générateur de code « pas graphique ». J’estime que cette étape peut être réalisée assez rapidement (une vingtaine d’heures).
      – Mise en place d’un modèle autours de ce XText, comme tu nous l’as présenté au JugSummerCamp.
      J’ai un peu regardé les (rares) tutoriaux dispos sur le net, et là, j’ai l’impression que pour avoir un truc assez chiadé, il faut y mettre les moyens (on va parler, ici, de plusieurs jours, voire plusieurs dizaines de jours).
      Peut-être est-ce que je me trompe ?

      L’avantage du point 2 étant qu’on obtient quelque chose de beaucoup plus « visuel » qui permet de toucher potentiellement des populations beaucoup plus « fonctionnelles ».


Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :