< class="pagetitle">Posts Tagged “MDA”

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 :

Comments Pas de commentaire »

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 ;)

Comments Pas de commentaire »

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.


Comments Pas de commentaire »

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.

Comments 4 commentaires »

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 ! :)

Comments 2 commentaires »

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 ;) ).

Comments 2 commentaires »

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.

Comments Pas de commentaire »

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.

Comments Pas de commentaire »

J’ai participé Vendredi dernier au MD Day dans l’hôtel Hilton près de la tour Eiffel.

Un acronyme a été mis en valeur : DSM (Domain Specific Modeling)

Donc si vous voulez savoir combien de stylos j’ai récupéré, combien de petits fours j’ai mangé, si j’ai réellement rencontré Paris Hilton ou simplement avoir un résumé de la journée, je vous invite à lire la suite.

Cette journée a été organisée par cinq sociétés

  • Lyria
  • Mia-Software
  • Obéo
  • Objecteering
  • Objet direct

Le principe est que chaque société fait une présentation en deux parties. Une partie commerciale suivie par une restitution client.

L’arrivée

Grosse déception dès mon arrivée! Pour ma première visite dans un hôtel Hilton j’étais en droit d’espérer un accueil luxueux par Paris elle-même. Et bien non personne! J’ai même été obligé d’appuyer sur le bouton de l’ascenseur, le groom devait être en RTT…

Présentation du MDA par Xavier Blanc

Xavier Blanc est maître de conférence à Paris VI et l’auteur de “MDA en action” et de “UML2 pour les développeurs”. Il a fait une présentation des concepts du MDA. Une présentation très universitaire mais néanmoins intéressante. Par contre, au moment d’aborder les problèmes de passage à l’échelle, j’ai été étonné par sa notion de “gros modèle”. Il dit travailler sur des modèles de 150 Go. Pour vous donner un ordre d’idée, les modèles d’Eclipse ou de Net Beans font 350 Mo. Mais une de ses phrases explique tout : “Un modèle peut grossir vite si on modélise des vidéos” ok, s’il met ses divx dans RSM on peut vite monter à 150 Go.

Usine Logicielle avec Eclipse par OBeo

Obeo propose un plug-in Eclipse gratuit pour faire de la génération de code depuis un modèle emf de façon très configurable. C’est une petite société nantaise de 18 personnes très dynamiques.

Une personne de l’UNEDIC nous a ensuite présenté leur projet fait en collaboration avec OBeo. Ils ont fait le choix de ne pas utiliser UML mais de définir un DSM basé sur emf et ensuite de réaliser un générateur de code. Un projet de 300 h/j sur 5 mois. Ensuite cet outil a ensuite été utilisé par Unilog pour la réalisation du projet (5000 h/j).

Génération d’IHM par LYRIA

LEONARDI permet de générer des IHM riches ou légères. Leur outil s’appuie sur des fichiers XML pouvant être générés depuis un fichier XMI. Leur présentation ne m’a vraiment pas convaincu, l’outil à première vue est complexe et il y a trop d’étapes pour arriver à l’IHM.

Mais cette première impression est peut être erronée vue l’éloge du produit par EADS. Ils construisent de grosses applications pour leur client. On peut donc noter plusieurs points positifs de leur approche à savoir :

  • La génération multi-clibe d’IHM
  • La génération de tests d’IHM

L’approche MD avec MIA software

Un peu de la même façon qu’OBeo, ils proposent un produit de génération de code et de transformation modèle à modèle. Encore une fois ce transformateur configurable à souhait, même les balises d’insertion de code sont configurables. Ils se basent sur des fichiers XMI générés par la plupart des éditeurs UML du marché.

La SNCF utilise cette solution pour leurs développements et ils en sont très satisfaits même dans un contexte de charge important (1500 messages à gérer par seconde). Pour cela ils on défini un DSM puis des outils de transformation depuis ce modèle. Ils ont aussi développé un “reverse intelligent” pour modéliser et régénérer les applications existantes (aussi bien Java que .NET). Il insiste aussi beaucoup sur leurs outils de validation de modèle.
Ils projettent de migrer de Rasonal Rose vers Magic draw.

La pause déjeûner

Le moment important de la journée ! Une belle table et open bar avec Vodka, whisky et autres alcools forts. Je me jette discrètement sur les petits fours, mais après en avoir avalé 3-4, j’ai commis une grave erreur technique, je me suis fait happé par des commerciaux. Et après 2-3 discussions fort intéressantes mais pas très nourrissantes, plus de petits fours !

La méthode Praxeme

Ca commence très fort avec une belle citation d’Albert Einstein : “Aucun problème ne peut être résolu sans changer le niveau de conscience qui l’a engendré.”. Dominique VAUQUIER créateur et auteur de la méthode Praxeme nous en explique ensuite les principes. Il refait aussi un petit historique sur Merise. Par contre je regrette un peu sa vision Tayloriste du développement.

Objecteering

Philippe Desfray a mis l’accent sur la méthodologie et a rappelé que même si le MDA est une belle avancée, il est inutile si le modèle est faux. Il faut donc aussi travailler sur des outils de vérification de modèle pour s’assurer de sa cohérence.

Le Groupe SMABTP a utilisé Objecteering pour mettre en place sa démarche MDA pour faire du SOA. Ils ont refondu leur SI avec ces outils en se basant sur la méthodologie Praxeme.
Ils utilisent aussi JRules.

Objet Direct

Présentation de leur SSII, c’est les meilleurs, et les plus beaux. Ils ont mis au point le langage D Script pour coder le métier au niveau PIM et générer 100% du code. C’est un PIM exécutable.

La CACEIS (Credit Agricole Caisse d’Epargne Investor Services) a utilisé une approche DDD Domain Driven design pour automatiser leur facturation.

Microsoft

Là aussi de beaux slides qui commencent par une citation de Darwin. Mais vu que le second slide n’avait que des chiffres inintéressants je me suis visual studio (version .NET du verbe éclipser)

Conclusion

Pour commencer un bilan chiffré :

  • 2 stylos
  • 1 magazine mais pas de Tshirt
  • 5 petits fours
  • Zero Paris Hilton
  • 9 femmes, 91 hommes (que fait le gouvernement pour imposer la parité dans notre métier !)

Plus sérieusement cette journée était très enrichissante. J’ai même été étonné de ne pas voir plus de discussions contradictoires. L’auditoire était composé essentiellement de personnes convaincues. J’ai aussi été surpris par le nombre de personnes utilisant des DSM dans leur projet. Et c’est peut être à ce niveau-là qu’il y a des leçons à tirer. UML est trop complexe et c’est pour cela que l’on a du mal à le faire adopter. Si on offre des méta-modèles collant aux besoins des utilisateurs on aura plus de facilité à les faire adhérer aux approches MDA.

Les slides : www.mdday.fr

Comments Pas de commentaire »