JUG Summer Camp 2010 : MDA en 2010, une approche pragmatique (5/5)

Pour ce cinquième et dernier article de la série JUG Summer Camp, je vous propose le résumé de la présentation “Le MDA en 2010 : une vision pragmatique”.

Le MDA en 2010, une approche pragmatique

Cette présentation était menée par Jérôme Benois. Jérome est consultant/architecte MDA senior chez Obeo. Il est notamment commiter pour Eclipse Acceleo, sur Eclipse Modeling et EasyAnt.

Historique

Jérome démarre son intervention par un retour sur les origines de l’approche MDA. A la fin des années 90, 80% des projets informatique sont livrés hors délais et 50% sont en dépassement de budget. Beaucoup de responsables informatiques et de chercheurs se demandent alors comment limiter les risques dans la chaine de production du logiciel. Au début des années 2000, c’est donc la naissance de l’approche MDA. Son objectif est simple : pour industrialiser, utilisons des modèles plus abstraits afin de permettre une meilleure communication entre les responsables métiers et l’IT pour ainsi produire du logiciel. Cette approche se base très largement sur l’utilisation d’UML pour la production des modèles.

Étapes d’un projet MDA

Jérome nous présente les étapes pour réaliser un projet informatique avec cette approche :

  1. Modélisation CIM
    Objectif : capter le besoin fonctionnel
    Diagrammes utilisés : Use Case Diagram, Sequence Diagram
  2. Modélisation PIM (modèle indépendant de la plateforme)
    Objectif : obtenir une vue structurelle et dynamique de l’application
    Diagrammes utilisés : Class Diag, Activity Diagram, State Chart, Sequence Diagram
  3. Modélisation PSM (dépendant de la plateforme)
    Objectif : définir les caractéristiques de chaque composant. Ainsi, tel composant devient un EJB, tel autre un moteur de règles JBPM
    Diagrammes utilisés : Class Diag, Component Diag

Générateur de code

Une fois la modélisation PSM validée, encore faut-il pouvoir en obtenir quelque chose d’exploitable : du code source ! C’est ici, que le logiciel Acceleo a fait ses premières armes.

Acceleo

Acceleo est basé sur le standard OMG MOF Model to Text Language (MTL). Cette spécification décrit les méthodes permettant de transformer un modèle en texte pour obtenir, par exemple, du code source ou de la documentation. Acceleo offre un environnement qui permet de configurer les générateurs de code via des templates et donc générer précisément le code source cible. Les fichiers templates sont au format MTL.

Il existe en fait deux méthodes de génération de code :

  • Génération incrémentale “User-Code Pattern” : on utilise des marqueurs qui permettent au développeur de savoir ce qu’il peut modifier (// debut du code utilisateur puis // fin du code utilisateur)
  • Génération incrémentale “Génération Gap Pattern” : séparation du code généré / du code manuel dans des classes différentes (via des classes abstraites et des classes “utilisateurs” à remplir)

Après ce rappel historique, Jérome nous explique les avantages et les inconvénients de cette vision “fin 2000” du MDA :

  • Avantage : on améliore grandement la productivité (génération initiale du code)
  • Avantage : on peut changer “plus facilement” des éléments techniques et fonctionnels dans l’application
  • Inconvénient : il est très difficile de réussir à maintenir synchroniser les différents modèles
  • Inconvénient : quand le projet entre en phase de maintenance, la tentation est grande de réduire les coûts de modélisation :
    • on n’utilise plus l’outil de génération de code
    • on obtient une dé-synchronisation entre code source et modèle
  • Inconvénient : l’approche “tout modèle” a une connotation trop intégriste

Nouvelle approche en 2010

Jérome explique donc que l’UML est désormais vu comme étant trop vaste et trop générique pour exprimer les métiers de l’informatique de gestion. Par exemple, l’UML n’est pas du tout adapté pour exprimer simplement un algorithme.

Ce qui semble le plus à même de répondre aux problèmes des projets informatiques est ce que l’on appelle les Domain Specific Language (DSL). Un DSL est un vocabulaire précis et concis qui permet de décrire une problématique. Il peut très bien être spécifique à un projet, ce n’est pas grave : l’important est que l’ensemble des équipes puissent se comprendre. Le modèle doit rester un outil de communication et de productivité.

Un DSL n’est pas utilisé seul. Il est inclus dans un projet via une approche de type “ingénierie dirigée par les modèles” (IMDD/MDD). L’ensemble des projets de l’écosystème Eclipse Modeling sont conçus et adaptés à cette approche, le plus important étant Eclipse Modeling Framework (EMF). Le processus est donc pragmatique et simplifié par rapport à une approche “tout UML” :

  • Le CIM et le PIM sont regroupés sous la forme de DSL
  • Le générateur de code se basent sur les DSL
  • Le code source généré sert de PSM
Au sein d’un projet, la démarche devrait être la suivante :
  • Établir un vocabulaire transverse aux équipes dont l’interprétation soit “évidente” pour tous les membres du projet
  • Mettre en oeuvre ce vocabulaire dans des DSL
  • Écrire les templates du générateur de code afin d’obtenir votre architecture cible
Jérome nous présente ensuite les outils à notre disposition pour écrire des DSL :
  • Depuis du code Java, avec l’API EMF. C’est parfois utilisé pour faire de la génération de DSL à partir de code existant.
  • Écrire un parseur maison avec des outils comme Flex, Bison, Yacc ou encore ANTLR. Il faudrait avoir du temps, ce dont nous manquons tous 🙂
  • Eclipse xText : il s’agit d’une surcouche Eclipse à ANTLR qui permet d’exprimer une grammaire sous un format textuel. Voici un exemple de grammaire Type: DataType | Entity;
    DataType: “datatype” name=ID;
    Entity: “entity” name=ID “{” (features+=Feature)* “}”;
    Feature: type=[Type|ID] name=ID;
    .
    Cette grammaire peut être ensuite utilisé pour créer des DSL :
    datatype String
    datatype Bool
    entity Session {
    title: String
    isTutorial : Bool
    }
  • Eclipse Modeling propose également Graphical Modeling Framework qui permet de disposer d’une vue graphique pour l’écriture de la grammaire ainsi que pour la réalisation de DSL (qui sont alors des Domain Specific Model – DSM)

L’utilisation du Graphical Modeling Framework permet de mettre à disposition des utilisateurs, un véritable IDE/modeleur leur permettant de réaliser une modélisation avec leur vocabulaire ! Elle est ensuite directement exploitable par les équipes IT. On peut également proposer un point de vue différent à chaque type d’utilisateur (urbaniste, architecte, moa) ce qui permet de voir les impacts et de faire la traçabilité d’une modification fonctionnelle. Pour la partie génération de code, Acceleo est toujours utilisé. Que ce soit un DSL ou de l’UML, cela reste un modèle et donc Acceleo est capable d’effectuer la transformation vers du code source.

Jérome a ensuite bien anticipé les attentes de l’assistance : et comment faire pour démarrer un nouveau projet ? faut-il toujours partir d’une feuille blanche ? Sa réponse est clairement non : vous n’avez pas besoin (ni intérêt) à repartir de zéro à chaque projet. La communauté Obeo Network est justement là pour fournir des briques de bases et/ou des exemples de DSL, de templates pour le générateur, etc

Pour conclure cette conférence, Jérome insiste sur un point qui me semble un avantage important de cette nouvelle approche, c’est la traçabilité des modifications. En effet, dans le cadre d’une connexion permanente entre le modèle et le code généré, il est possible de proposer des outils qui permettent de détecter les impacts du générateur, de permettre de bypasser les actions du générateur ou encore de produire des rapports sur les fragments de code mort.

Un grand bravo au speaker qui a très bien alterné les séquences théoriques avec des démonstrations bien calibrées. Les supports étaient également de bonne qualité (pas trop chargés, plan bien lisible, etc…).

Bilan

Pour terminer cette série de cinq articles, je tenais à remercier Ippon Technologies pour m’avoir permis de sortir de mon projet actuel pour cette sympathique journée de conférence. Je tiens également à remercier les organisateurs de cette journée : le Poitou-Charente JUG et le sponsor SERLI, une organisation bien ficelée et très professionnelle pour un rendez-vous entièrement gratuit.

Grâce à cette journée de conférence, j’ai réussi à remplir ma TODO-list pour au moins 6 mois 🙂

Tweet about this on TwitterShare on FacebookGoogle+Share on LinkedIn

2 réflexions au sujet de « JUG Summer Camp 2010 : MDA en 2010, une approche pragmatique (5/5) »

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


*