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.

Formation Scrum

Xebia organise une formation Scrum de deux jours les 1 et 2 Décembre. C’est Jeff Sutherland en personne qui va officier cette messe.

Je vais participer à cette formation, j’aurai donc l’occasion de vous en faire un retour. Même si je continue à pousser les approches MDA je suis persuadé que l’utilisation des méthodes agiles ne peut être que bénéfique dans nos projets. J’avais déjà parlé du côté agile du MDA dans le poste Le MDA c’est Agile !, je compte bien convertir Jeff au MDA !… Enfin s’il arrive à comprendre mon anglais, c’est pas gagné !

Sur ce sujet je vous invite à lire de récentes discussions :

• http://emmanuelchenu.blogspot.com/2008/11/model-driven-et-agilite.html
• http://www.touilleur-express.fr/2008/11/17/mda-scrum/
• http://www.aubryconseil.com/dotclear/index.php/2008/11/17/496-controverses

Acceleo JEE Module Sprint

Goulwen de l’équipe Acceleo nous propose de participer à l’enrichissement de leur module J2EE. Pour le moment ce module permet de générer une couche de persistance hibernate, des services spring et une partie IHM Web en struts. Si vous avez des idées, vous pouvez les proposer sur la mailing list acceleo-dev@ow2.org.

De mon côté, j’ai proposé la réalisation d’un module de génération d’IHM CRUD (Create Read Update Delete). Dans un premier temps elle sera faite avec struts2 mais la prochaine version sera en flex. Même si je suis conscient que ce type d’IHM générique n’est pas utilisable dans le cadre d’un produit, ça reste un bon outil pour naviguer dans son modèle de données et un bon squelette pour la réalisation de l’IHM cible.

J’ai mis sur SVN un premier exemple de la cible à générer. C’est un module maven, il suffit donc de lancer « mvn jetty:run » pour le tester.

Si vous avez des idées, des propositions ou mieux du temps pour donner un coup de main, contactez moi

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.

Le MDA c’est Agile !

Je viens de lire un article intéressant résumant la soirée Paris JUG d’hier soir.

Et au milieu on peut lire : « non MDA n’est pas une méthode Agile »

Horreur ! Je ne peux donc pas m’empecher de réagir

Bien sur que le MDA aide à être plus agile ! Mais attention, il ne faut pas non plus trop écouter les puristes…
Je ne crois pas non plus à la notion « d’indépendance du langage »… c’est utopique, mais ça permet une certaine abstraction. C’est aussi une absurdité de mettre un fossé entre les développeurs et les architectes. L’architecte va oublier des choses dans le modèle, il faut laisser les développeurs l’aider à le compléter.

Un exemple concret :
Il y a 4 ans j’ai commencé un projet avec des EJB 2 session et entity. Pour les personnes qui n’ont pas la chance de connaitre les EJB 2…. c’est atroce. Pour persister une classe il faut écrire 4 classes Java + des descripteurs xml.
Pour nous simplifier la vie nous avons modélisé notre système sans parler d’EJB. Un modele de haut niveau donc… un PIM.
Ensuite nous avons écrit un transformateur PIM-> PSM EJB 2 (15j de travail )
On génère classe Java + descripteurs EJB + script SQL.

Et la c’était magique !!
1 - A la fin de la phase de modélisation, j’ai appuyé sur UN bouton et j’ai obtenu 100 % de mes squelettes de code Java. Sans aucun codage j’avais un EAR deployable !

Attention ! cet EAR était bien une coquille vide, il est pour moi hors de question de modéliser le comportement. Il restait donc à notre équipe de développeurs à coder les services EJB.
Mais il était déjà deployable, on pouvait donc écrire des JUnits avant d’écrire l’implémentation.

2 - Justement à propos de l’équipe… allez trouver sur le marché des développeurs EJB 2. (pas chers donc débutants…)
Et bien grâce à l’approche MDA nous avons pu prendre des débutants. En effet le coté EJB était transparent au début ils codaient de simples méthodes Java.

Et au fur et à mesure ils sont montés en compétences sur les EJB 2 bien sur.

3 - Notre modèle est en phase avec notre code après 4 ans de dev… qui dit mieux ?

4 - Le MDA est agile !!
C’est une approche qui nous aide à être plus agile car elle facilite les changements.
Ajouter un attribut à un entity, c’est modifier 2 classes Java + un descripteur Java + un script SQL. Soit 4 chances d’oublier une modif ou de faire une erreur.
Avec nos outils MDA : une modif dans le modele + un clic = c’est fini.

Pour finir : la cerise sur le gâteau.
L’année dernière nous avons migré nos EJB 2 vers de l’hibernate. Et bien nous avons juste changé de transformateur MDA… zero modif dans notre code.

C’est pas de l’agilité ça !