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

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.

Entreprise Architect : La galère

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.