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 !

Modelio, un nouveau modeleur ?

Je viens de tomber sur le site web d’un nouveau modeleur UML2 Modelio.

Au premier screenshot, j’ai comme une impression de déjà vu. Dans le About on peut lire « Modeliosoft is the result of 20 years of experience in OO modeling » et « Based in Paris ». Une boîte qui a 20 ans d’experience dans la modélisation à Paris, c’est étrange de ne pas la connaître !

En fait non ce n’est pas un nouveau modeleur, c’est une nouvelle version d’objecteering « rebrandée ». Alors il y a de gros changements, notament au niveau prix des licences, mais la base est la même. C’est plutôt une bonne chose car leur Meta-modèle est très bon et leurs diagrammes sont bien faits depuis la version 6. On m’a aussi confirmé que Philippe Desfray était derrière Modelio ce qui est très rassurant et gage de qualité.

Je n’ai toujours pas pu télécharger la version gratuite, mais dès que je l’ai je vous en fait un retour. Je me pose déjà pas mal de questions :

• Comment gérer le versionning et le multi-user (SVN est supporté)
• Comment écrire une transformation de modèle

La première bonne nouvelle c’est que le langage J n’est plus utilisé ! On peut enfin écrire des transformateurs en Java.

Affaire à suivre donc. Je suis quand même étonné de ne voir aucune référence à Objecteering sur le site de modeliosoft. Fini aussi le logo avec la tour Eiffel. Une vrai volonté de tourner la page de la mauvaise réputation d’objecteering et peut-être une ouverture à l’international.

Certifié SCRUM et UML

Comme je l’avais annoncé, après deux jours de formation SCRUM avec Jeff Sutherland en personne, j’ai été certifié SCRUM Master. C’est un titre un peu pompeux et il faut plus le voir comme un « permis de conduire », c’est après l’avoir mis en pratique qu’on le maitrise vraiment.

Et ce matin j’ai passé la certification IBM 834 « Object Oriented Analysis and Design – Part 2″ avec succés. C’est surtout la partie UML de la certification IBM qui m’intéresse.

Au premier abord, ça peut paraitre étrange de mettre RUP et SCRUM côte à côte. Mais si on regarde de plus près SCRUM n’apporte pas de solution pour bien faire l’analyse et le design de son application.

Je ferai un retour plus important sur la formation SCRUM très bientôt.

Acceleo 2.3

La version 2.3.0 d’Acceleo est sortie vendredi dernier !
On peut noter les principales nouveautés :

• Compatibilité Eclipse 3.4
• Recherche de référence des templates
• Support partiel des EOperations
• Acceleo indépendant du bridge
• Compatibilité EA 7

Liste complète des nouveautés

Vu que j’ai participé à la mise en place du bridge pour Entreprise Architect, je peux vous confirmer qu’il fonctionne bien pour les diagrammes de classes. Par contre, Acceleo a oublié d’indiquer que cela ne fonctionne qu’avec la version 7.1 Build 830. Comme EA a la mauvaise habitude de modifier son export XMI régulièrement, faites bien attention d’avoir la bonne version.

Acceleo est un très bon produit open source pour faire des transformations M2T (Modele to Texte) parfaitement intégré à Eclipse. Et à propos d’Eclipse, Obeo (la société développant Acceleo) vient de passer au statut de « Strategic member » de la fondation Eclipse.

Le MDA c’est quoi ?

Je suis toujours étonné de lire autant de réticences à propos du MDA. Cette méthode est peut être victime d’une communication trop éloignée des problèmes concrets des développeurs. Alors soyons clairs, moi non plus je ne suis pas en phase avec les grands théoritiens. Deux exemples concrets :

J’ai participé il y a 3 ans à une présentation d’une thèse sur le MDA. J’ai vu pendant 1 heure des séries d’équations pour m’expliquer le principe du MDA. Au final, je n’ai pas vu une ligne de code et je suis sorti avec un beau mal de crâne.

Un autre expert MDA m’a très sérieusement expliqué qu’il passait par 3 à 4 transformations successives pour arriver au code Java. De plus pour lui le principe du « round trip » ne sert à rien car son modèle ne change jamais. Bien sûr son super architecte a pensé à tout et les petits développeurs n’ont pas besoin de réfléchir… On rève..

Si on vous a présenté le MDA de cette façon je comprends mieux vos griefs.

Mais pour moi le MDA c’est :

• Mettre le modèle au centre du pojet.
• Un outil pour produire mieux et plus vite.
• Une façon d’abstraire des mécanismes techniques complexes.

Il faut que le passage du modèle au code soit simple et rapide. Il faut aussi que ce soit le transformateur qui s’adapte au projet et non l’inverse. Là aussi j’ai vu trop d’outils imposer une façon de faire qui rebutait l’équipe de développeurs.

Oui on m’a déjà reproché de faire des PIM orientés Java et c’est aussi pour cette raison que l’on parle maintenant plutôt de MDD Model Driven Developpment. Mais mon objectif n’est pas d’être conforme à 100% avec la définition du MDA rédigée par l’OMG, mais bien de réaliser les trois points notés plus haut.

C’est assez paradoxal de pousser la modélisation UML et de mettre nos beaux modèles au placard lorsqu’ils sont terminés. C’est ça le MDA : s’appuyer sur un modèle pour structurer son développement.