Le MDA va-t-il devenir à la mode ?

C’est en effet la question que l’on peut se poser vu le nombre grandissant de conférences sur le sujet. Par exemple pendant le JUG Summer Camp 2010, je l’ai découvert en lisant le résumé sur le blog d’ippon. Je ne l’ai par contre pas vu sur le blog du Touilleur, Nicolas ne doit toujours pas être convaincu

La prochaine ? Le lundi 4 Octobre à Rennes pour le BreizhJug. Soirée MDA & Fodnation Eclipse par Etienne Juliot. J’ai été fier de retrouver un lien vers un de mes articles sur leur page d’annonce

On remarquera que pour ces deux présentations c’est Obeo qui était invité. Leur force est surement d’avoir réconcilié les développeurs avec l’approche MDA en offrant une solution pragmatique et intégrée à Eclipse.

Je vais essayer de participer au BreizhJug le 4, mais ce n’est pas gagné…

MDA Day et Acceleo 3

Je viens de recevoir un email pour annoncer la date du MD Day 2010 : le Jeudi 25 Novembre. C’est à Issy les Moulineaux donc surement chez Microsoft comme en 2009. Ils ratissent large Microsoft, après avoir accueilli le SCRUM User Group pour vendre Visual Studio comme l’outil idéal pour faire du SCRUM, ils vont peut être présenter Visio comme le meilleur modeleur UML du marché. La preuve ? c’est Steve Cook qui fait la Key note d’ouverture, un architecte logiciel de Microsoft de l’équipe Visual Studio, bref super indépendant. Une bonne raison pour bien dormir et arriver à 10h !

Mais plus intéressant, j’ai aussi reçus un mail suite à la sortie d’Acceleo 3 (qui date de juin, je suis en retard…). Si vous utilisiez déjà Acceleo 2, Obeo propose des formations pour vous aider à migrer les :

• 11-12 octobre
• 8-9 novembre
• 6-7 decembre

Contact : obeo

Retour sur l’acceleo day

Vendredi 10 juillet avait lieu à Nantes les Rencontres Mondiales du Logiciel Libre. C’est dans ce cadre qu’Acceleo a choisi d’organiser une journée dédiée à leur outil de transformation M2T.

Etienne Juliot commence cette journée par une présentation de l’outil. Il a reussi à faire une présentation à la fois pour les débutants et pour les plus aguerris en y ajoutant quelques petites astuces bien pratiques. Le reste de la matinée était consacrée aux retours clients. Il y en aura quatre de Capgemini, Atos, Bull et OrangeLabs.  C’est celui d’ Atos qui m’a vraiment marqué et pas forcément dans le bon sens du terme. J’ai été frappé par le fossé qu’ils creusent entre les développeurs et les architectes. Attention je ne stigmatise pas Atos, beaucoup de grands groupes (le mien en premier) partage cette approche et voient l’Architecte comme un dieu dans sa tour d’argent dictant sa loi aux gueux développeurs.

Pour ma part je ne l’approuve absolument pas et la distribution des rôles en scrum me donne raison. En effet en scrum les rôles architecte et développeur n’existent pas. Seul le rôle team compte. L’équipe doit bien sûr être composée d’experts en architecture et en développement mais ils doivent travailler ensemble. Pour moi un bon architecte doit mettre les mains dans le code et un bon développeur doit maîtriser l’architecture et même y contribuer.

Pour revenir à acceleo day, j’ai donc présenté très rapidement comment notre chaîne de génération a évolué avec le temps.

Je me suis bien amusé à le faire et ça a été partagé si j’en crois le premier retour que j’ai pu lire. Retour fait par Cedric Vidal qui avait le créneau le plus dur, celui d’après le repas. Il a fait une très bonne présentation sur le Scaffolding. Technique intéressante qui propose d’enrichir le modèle par une ou plusieurs transformations M2M (Model to Model) avant la génération de code. Ca permet de garder la main sur certains éléments pour les enrichir. L’exemple type est le service CRUD (Create, Read, Update, Delete) d’un entité, c’est intéressant de le générer et de garder le lien avec l’entité tout en l’ayant modélisé pour le compléter et le documenter.

Je n’ai malheureusement pas pu assister à la dernière présentation de Goulwen Le Fur car je devais reprendre la route. Vous pouvez lire ses slides sur leur site.

Journée qui a donc été très enrichissante. C’est toujours intéressant de partager avec d’autres industriels pour comparer nos façons de faire.

Acceleo M2T et Eclipse 3.5

Comme vous le savez Eclipse 3.5 Galileo est sorti le 24 Juin.

Une des nouveautés est l’intégration d’Acceleo M2T directement dans la version « Eclipse Modeling Tools ».
Je n’ai pas passé beaucoup de temps à l’essayer, mais on peut déjà noter plusieurs grosses améliorations. Bien sur la plus importante est le changement de langage de script. On passe d’un format spécifique Acceleo à du MTL standard défini par l’OMG pour les transformations Model to Text.

Je vais plus me focaliser sur les nouveautés au niveaux outillage.

Installation facile

Avant je n’avais jamais réussit à installer Acceleo sur mon Eclipse via leur update site. Il y avait toujours des problèmes avec les versions d’emf, uml2… J’ai perdu beaucoup de temps et le seul moyen de le faire fonctionner rapidement était de récupérer leur package Eclipse+Acceleo.

Cette fois j’ai installé un Eclipse 3.5 vierge et via l’update site de Galileo je peux installer Acceleo 0.8. Au moment de l’installation il m’a installé toutes les dépendances nécessaires (emf…) En 5 minutes ça marche. Seul petit hic, il ne tire pas les dépendances vers le plugin uml2 et l’exemple ne fonctionne pas sans. Mais si vous avez téléchargé la version « Eclipse Modeling Tools » tout fonctionne sans passer par l’update.

Exécution en standAlone

Même si cette fonctionnalité existe depuis la version 2.4.0 d’Acceleo, on note maintenant la disparition complète des chaines de lancement Acceleo. Pour générer notre code on peut donc utiliser au choix :

• Du Java
• Une tache ant
• Un runner Eclipse

Il ne manque plus qu’un plug-in Maven 2, mais vu que l’équipe d’acceleo utilise plus ivy que Maven il faudra peut être le réaliser nous-même.

Debug

Je gardais le meilleur pour la fin, il est enfin possible de mettre des points d’arrêt dans nos templates. Ca marche très bien et on peut facilement naviguer dans notre model comme on le fait avec des objets en debug Java.
C’était le gros manque au niveau outillage d’Acceleo, c’est maintenant très bien fait.

Une grosse évolution très intéressante d’Acceleo donc. Je suis même étonné qu’il n’y ait pas plus d’infos à ce propos sur leur site Web. Ils sont trop occupés à préparer l’Acceleo Day du 10 Juillet peut être Journée annoncée sur la page d’acceuil d’Eclipse, la classe !

Le PSM est-il toujours utile ?

Pendant plus de 4 ans nous avons travaillé sur un projet avec un outillage MDA en utilisant le mécanisme suivant pour générer du code :

Sur le papier nous respections bien les concepts MDA avec une séparation du modèle abstrait de haut niveau (le PIM) et un autre spécifique à nos contraintes techniques (le PSM).

Mais si on regarde de plus près on trouve dans notre PIM des informations liées à nos choix technologiques que l’on ajoute grâce à un profil (stéréotype finder, tagged value sql_name, etc). A quoi sert notre PSM du coup ? Comme notre modeleur offrait une solution de génération de code Java, nous pensions intéressant de l’utiliser. Nous avons donc réalisé un transformateur modèle vers modèle pour construire un PSM collant aux besoins du générateur Java. Dans les faits le PSM nous a aussi permis de pallier à certains bugs de ce générateur en modifiant à la main le PSM pour obtenir du code Java correct. Mais notre PSM est une image un pour un du code java. 

Lorsque je montre cela à nos experts MDA, j’ai le droit systématiquement au discours : « Samuel t’as tout faux, il faut séparer les concepts. Regarde comment il faut faire »

Effectivement sur le papier c’est une bonne idée. Il faut mettre les bonnes informations au bon niveau.

La première question que je pose à cette personne c’est : « Dis moi, ça fait combien de temps que tu n’as pas écrit une ligne de code ? »

C’est bien beau de philosopher sur MDA, mais on oublie vite la finalité : mieux produire du code. Si à chaque modification de modèle il faut faire trois transformations, c’est inutilisable ! Pour moi, dix secondes et deux clicks c’est le maximum acceptable par une équipe de développement pour passer du modèle au code. Si on met plus de temps ou s’il y a plus d’étapes l’outil est inexploitable.

C’est dans l’optique d’avoir moins d’étapes et de simplifier notre chaine de développement que nous utilisons maintenant une transformation Modèle vers Texte.

Vous remarquerez que je n’utilise plus le mot PIM pour ne plus me faire taper sur les doigts Mais même si notre modèle n’est pas vraiment un PIM, il ne colle pas non plus au code et on peut s’appuyer dessus pour générer une belle documentation de haut niveau.

Dans ce cas il faut par contre réécrire un générateur Java. Mais le gros avantage est que ce générateur va répondre à 100% de vos exigences en terme de règle de codage et de formatage. De plus si l’outil de transformation est bien fait il offre de bonnes boites à outils (transformer une opération UML en signature de méthode Java par exemple). Si réécrire ce générateur est plus rapide et plus facile à maintenir qu’un tranformateur Modèle vers Modèle, cette méthode est plus intéressante. Et pourquoi utiliser des mécanismes complexes pour résoudre un problème simple ?

Concrètement nous avions presque 15 000 lignes de code J à maintenir juste pour notre transformateur Modèle vers Modèle, nous avons maintenant moins de 3 000 lignes de scripts acceleo pour générer le même code Java.

Donc aux vues de notre utilisation, avoir un modèle PSM n’apporte rien. Notre PSM c’est le code Java, après tout c’est un modèle comme un autre

Premier test de Modelio

Après avoir passé quelques heures à tester Modelio je vous en fais un petit retour. 

Installation

La première bonne nouvelle est qu’il est possible d’avoir sur un même poste plusieurs versions différentes de Modelio. J’ai installé la version Free et la version Java sur mon poste sans problème. Bien-sûr un projet créé avec la version Java n’est pas utilisable avec la version free (l’inverse est possible par contre).

L’empreinte mémoire est assez faible (100Mo). Ca reste raisonnable. Par contre l’ouverture et la création de projet est vraiment lent et le fichier contenant le modèle est déjà gros même vide.

Utilisation

La première chose que je remarque c’est la disparition de la barre action gauche au niveau du modèle Explorer.

A la place il faut utiliser les menus pop-up du click droit comme avec l’éditeur de modèle emf d’Eclipse. C’est vraiment dommage et je trouve que l’on perd beaucoup de temps pour construire un modèle.

Ensuite il manque toujours une aide à l’édition sur les diagrammes au niveau de la création des liens entre item (association, dépendances et autre). Je parle de cette petite flèche qui apparait en haut à droite de l’élément d’un diagramme lorsque la souris est au dessus et qui permet de créer une association ou un autre type de lien avec un autre item. RSM et EA le propose depuis pas mal de temps et je m’y suis bien habitué.

Attention aussi à la gestion du delete, maintenant lorsqu’on supprime un élément d’un diagramme, il est aussi supprimé sur modèle.

Génération Java

Une des nouveautés est l’utilisation d’annotation Java5 pour remplacer les marqueurs en commentaire.

C’est plus lisible, mais il faut accepter d’être dépendant d’un jar medelio. L’utilisation des annotations n’est possible qu’en mode « Round Trip », lorsque l’on passe en mode « Model Driven » on revient sur une utilisation de commentaires Java.

La gestion des attributs d’une classe Java ne semble pas vraiment pratique. A partir du moment où un attribut est noté privé, les méthodes get et set de celui-ci apparaissent comme par magie ! (en fonction de son mode d’accès quand même). C’est très troublant. On peut bien sûr les effacer mais à la moindre modification de l’attribut elles réapparaissent ! L’avantage est de pouvoir customizer le code java des getter et setter, ce qui était impossible avec Objecteering. Par contre maintenant le modèle est vraiment une représentation du code à l’identique. Je ne suis pas très fan de cette approche, je préfère avoir un modèle assez haut niveau (un PIM si on veut) qui peut se mapper sur mon code (le PSM du coup). 

Par contre les produits de génération n’existent plus. On ne peut configurer qu’un seul répertoire de génération de code. Donc maintenant un projet UML = un projet Java. C’est très génant si comme moi vous représentez plusieurs couches de votre application dans un seul modèle mais que chaque couche a son propre projet java.

Conclusion

Mes premiers essais sont assez mitigés, les nouveautés de Modelio sont loin de compenser les fonctions retirées d’objecteering (produit de génération, barre d’action etc…).

Au niveau UML 2, rien à dire, le méta-modèle est bon. Modelio contrôle bien la validité du modèle. Pour moi c’est un plus. Même si des outils comme EA où on peut faire tout et n’importe quoi paressent plus simples à prendre en main, au final ils engendrent souvent des modèles inutilisables. 

Par contre le plus grave aujourd’hui est que l’import XMI ne fonctionne pas et il n’y a même pas d’export XMI. Sans export XMI, le modèle est emprisonné dans Modelio. Pour moi il est hors de question d’utiliser un outil sans avoir une solution pour exploiter le modèle avec d’autres outils de transformation de modèle ou de génération de code (comme Acceleo par exemple). J’ai fait cette erreur avec Objecteering 6 qui n’avait pas d’export XMI, on ne m’y remprendra pas !

J’attends toujours de tester la partie MDA et multi-user avec SVN de Modelio. Mais il faut attendre la version entreprise en Mars-Avril pour ça.

Affaire à suivre donc !