Sam High-Tech Blog

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.

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.

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.

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 !

Le mardi 8 Juillet à 20h15 une conférence sur le MDA est organisée au Paris JUG : Pourquoi tout le monde ne fait-il pas du MDA ?

Une très bonne question auquelle va essayer de répondre Grégory Weinbach d’Object Direct. J’ai eu l’occasion de rencontrer Grégory à propos d’Entreprise Architect car Object Direct en est le revendeur officiel en France. Je l’ai aussi vu au dernier MD Day où il présentait une solution mise en place au Crédit Agricole. Après ce premier MD Day il a ouvert un blog sur le MDA : http://mdblog.fr/.

Une autre date à réserver dès mintenant c’est le 25 novembre pour le prochain MD Day justement. Il aura lieu au Toit de la Grande Arche à Paris-La Défense. Les partenaires sont toujours les mêmes et après 6 mois d’utilisation d’Entreprise Architect je suis presque impatient de retrouver l’équipe d’Objecteering (j’ai dit presque.. 6 mois c’est pas assez long pour oublier mes pertes d’OFP et l’utilisation du module multi-user ).

J’avais annoncé la sortie d’Entreprise Architecte 7.1 sur ce blog. Et bien après plusieurs mois d’utilisation mon bilan est mitigé.

Oui EA est très agréable à utiliser et facile à prendre en main. Il est aussi très bien pour générer de la documentation fonctionnelle. Mais dès que l’on cherche à faire des choses plus détaillées pour des spécifications techniques ou pour utiliser le modèle pour faire du MDA, ça devient très dur.

Le gros du problème vient du fait que le meta-modèle d’Entreprise Architecte n’est pas UML2. Il y a bien les nouveaux diagrammes UML2 mais c’est juste pour donner bonne figure.

Par exemple avec EA il est impossible de :

• Mettre des attributs de classe en read only
• Mettre une multiplicité sur les types de retour d’une méthode (array n’est pas une multiplicité)
• Mettre une multiplicité sur les attributs d’une méthode
  
• Mettre une note sur le type de retour d’une méthode
• Gérer les exceptions d’une méthode (nouveauté UML2 : raisedException)
• La Gestion de conf via une base de données est buggée et via SVN elle n’est vraiment pas pratique
• L’export XMI est farfelu (à cause de l’incompatibilité avec UML2)

Le dernier point est de loin le plus important. Non seulement son export XMI n’est pas bon mais en plus il est très lent.

EA est donc un bon outil pour faire de la documentation (c’est toujours mieux que visio ou power point) mais ne vous attendez pas à vous appuyez sur UML2.

Un nouveau projet de plug-in Eclipse pour réaliser un éditeur UML open source a été lancé. C’est en fait une fusion de deux modeleurs open source européens Papyrus et Topcased. Poposition
Les points intéressants à noter :

• Intégration de SysMl
• Utilisation de UML-DI (normalisation d’un format d’échange des diagrammes UML)

En plus de Sébastien Gérard (Leader du projet Papyrus) et de Raphaël Faudou (Leader du projet TopCased), on peut noter la présence d’Etienne Juliot de la société Obeo (editeur de l’outil MDA acceleo). Il faut espérer que sa présence mette en avant les aspects MDA, car malheureusement ce mot est absent de la proposition.

Début prévu pour Juin 2008.

Petit coup de pub pour l’outil MDA d’un collègue : OntoMde.
C’est un moteur écrit en Ruby permettant d’écrire des transformateurs MDA. Stéphane a en plus déjà écrit une belle collection de transformateurs. Par exemple pour générer du Java, des IHM Flex ou bien du JPA.
Le format d’entrée d’ontoMDE est le RDF et bientôt du XMI. Sur le site on peut télécharger des plug-in RSM ou Objecteering pour générer ce format.
L’approche est bonne mais je la trouve un peu élitiste. OntoMDE n’est pas bien outillé et il faut mieux connaitre le méta-modèle UML sur le bout des doigts pour écrire un transformateur.

Sparx Systems vient de sortir la version 7.1 de son modeleur UML.
Entreprise Architect est même beaucoup plus qu’un simple modeleur UML.
Il permet aussi de :

• modéliser ses exigences
• utiliser le profil SysML
• faire une estimation de charge de Use Case
• génération de doc (RTF, html)
• Ecrire des scénarios de tests
• Lancer des JUnit
• Gérer un forum de discussion

Bref, il manque plus qu’il fasse le café!
Par contre ne rêvons pas trop, la plupart du temps, il ne fait que survoler ces fonctions. Et au niveau UML, on peut regretter son manque de rigueur, il est plus proche de visio que d’Objecteering. De plus il ne respecte pas toujours le meta-modele UML 2 (les interfaces ne sont pas des meta-classes, pas de ReadOnly sur les attributs, pas de multiplicité sur les paramètres de retour des opérations…)
Il a l’avantage de réconcilier les allergiques de RSM ou d’Objecteering avec UML.

Pendant le MD-Day 2 outils de génération MDA m’ont paru intéressants, Acceleo de la société Globeo et la suite MIA-Studio de MIA Software.
Je vais essayer de faire une petite comparaison de ces deux outils.
Acceleo
Acceleo est un outil gratuit et Open source du consortium ObjectWeb. Il se présente sous la forme d’un plug-in Eclipse. La transformation modèle vers texte est basée sur la notion de template. L’écriture de ces templates est assez simple grâce à la complession syntaxique et à la touche F3 pour naviguer facilement entre nos templates et nos méthodes.
Une ferme de module permet à différents contributeurs de proposer leur module à la communauté. J’ai essayé le module hibernate et je ne l’ai pas trouvé très complet, je reste donc un peu sur ma faim.
MIA
MIA-Studio est une suite d’outils commerciaux. J’ai plus particulièrement regardé les outils Mia-Generation et Mia-Transformation. MIA-Generation permet la génération de texte (XML, Java, etc..) à partir d’un modèle et MIA-Transformation construit un modèle à partir d’un ou de plusieurs modèles.
Même si ces outils ne sont pas des plug-in eclipse (ils sont écrits en .Net) ils s’intègrent très bien dans celui-ci. On peut donc lancer MIA-Generation depuis un bouton sous eclipse.
L’IHM est assez vieillotte mais néanmoins très efficace, j’ai particulièrement apprécié l’onglet de trace qui permet de voir comment s’est passé l’exécution de la transformation.
Contrairement à Acceleo, MIA base ses transformateurs sur son propre méta-modèle UML et propose des connecteurs pour traduire différents meta-model vers le leur.
Petite synthèse

Même si je trouve l’aspect Open source d’acceleo intéressant, j’ai l’impression que la suite MIA est un peu mieux outillée. Acceleo est très bien pour faire de petits transformateurs depuis un DSL, mais si vous avez un modèle UML et une génération complexe, MIA offre une solution plus complète (mais payante )
MIA Studio
Acceleo