Le 26 novembre 2009 avait lieu la journée du Model Driven organisé notamment par Objet Direct qui m'avait invité.
Je n'ai malheureusement pu assister à toutes les présentations mais le bilan fut plutôt positif et m'a permis de me remettre au gout du jour sur MDA.
Je vais présenter rapidement les présentations qui ont retenu mon attention mais vous pouvez voir les présentations 2009 sur www.mdday.fr dans la rubrique téléchargement.
1ere présentation générale sur le Model Driven Engineering par Jean Bézivin.
Présentation de l’écosysteme « Model Driven » de la génération de code à l'interopérabilité des modèles en passant par la découverte de modèle (e.g. a partir du code).
Pour rappel, Le MDA est basé sur un modèle, un méta modele et des transformations. Dans un cadre encore plus général et haut niveau, on a un système qui est représenté par un modèle lui même conforme à un méta modèle (lui même conforme à un méta méta modèle...).
Le mieux est d'aller voir la présentation vu la complexité de celle-ci il est difficile de la résumer en quelques lignes. De plus personnellement je l'ai trouvé trop éloigné de la pratique.
2ème présentation par Object Direct : moderniser son SI avec MDA
La présentation a porté sur un projet de refonte d'un projet existant fondé sur un Atelier de Génie Logiciel.
Le socle technique de destination choisi se base sur des technos éprouvés : Java, Seam, JSF, Hibernate (@JPA).
Il a fallu construire une Usine de Transformation MDA dont un des principaux objectifs fut de minimiser les risques.
Cette usine de transformation MDA a été divisée en 4 étapes :
- Rétromodéliser à partir de l'existant
- Renormaliser le PSM source en PIM
- Transformer le PIM en PSM cible
- Génerer le code source.
Très positif mais il y a des points difficiles :
- limite à la standardisation du code
- énormément de code à appréhender en une seule fois
- améliorer le caractère itératif du code.
Petit tour dans l'univers dans l'univers .Net avec la 4ème présentation : CodeFluent
L'idée de CodeFluent est :
- de modéliser n'importe quelle application manipulant des données
- de ne pas avoir à gérer les améliorations de l'architecture .Net
- cohérence des couches
- utilisation de briques logicielles
Les cycles de développement sont définis dans l'ordre suivant :
- Phase de conception du modèle ou import
- Phase d'inférence et de génération de code
- Phase de développement et de production
Les fonctionnalités sont nombreuses :
- Modélisation du diagramme de classe
- Intrégration de règle
- fonctionnalité unique de « modélisation dynamique » par des « patterns »
- Vocabulaire de base riche permettant de personnaliser le code généré
- Génération de code performant et propre
- Possibilité de modifier la génération en agissant sur le moteur de template
CodeFluent permet donc de développer n'importe quel type d'application aux normes Microsoft en prenant en construisant un Business Object Modele qui fait office d'interface forteresse avec les parties exterieurs (de l'IHM aux autres produits).
Une présentation démo montre l'intégration puissante avec l'univers Microsoft : génération d'écran sharepoint, synchronisation avec Access ou Excel.
Retour dans le monde Java avec la 5ème présentation : Celerio de la société Jaxio
L'idée est d'exploiter au maximum le modèle métier avec une génération à partir du modèle de données et une configuration de code sur lequel va s'appuyer la couche métier. Il ne reste plus qu’a traiter les cas transverse complexe.
On est dans le domaine des « Opinionated Software » tel Grails, SpringROO qui mette en avant les conventions de structure du projet sur la configuration. Jaxio met aussi une version gratuite de leur outil en ligne avec SpringFuse qui a permis d'avoir un retour sur des milliers de projet.
Enfin la dernière présentation qui fut à mon avis la plus révélatrice à propos de MDA :Model for maintenability, par Andrew Watson, OMG Technical Director
Après une courte présentation des domaines de travail de l'Object Management Group, Andrew Watson s'est lancé dans une argumentation en faveur du MDA que j'ai trouvé plutôt convaincante.
Il a commencé par un historique du métier d'ingénieur dans le cadre du design et de la réalisation des gros projets aéronautiques en prenant l'exemple du Concorde et l'Airbus.
L'utilisation de dessins (alias blue print) qui étaient ensuite retraduits en objet physique était source d'erreurs et nécessitait de nombreuses itérations.
L'utilisation de l'informatique et plus précisément des outils de CAD/CAM a révolutionné ce travail en facilitant la modélisation mais aussi les corrections.
Le constat est qu'actuellement le design logiciel ressemble plus à l'activité historique de l'ingénieurie aéronautique.
MDA prendrait alors la fonction du CAD en introduisant l'informatique pour aider à la réalisation de logiciel (MDA : computer aided manufacturing for IT).
MDA fournit une syntaxe de diagrammes et les outils pour faire ces diagrammes. Cependant la plupart des développements traduisent ces diagrammes en code à la main.
Mais c'est surtout dans la suite où il met en place les arguments principaux en faveur du MDA.
Il se base sur le cout de la maintenance qui représenterait environ 80% du cout du produit.
La maintenance étant définie selon par les standard ISO/IEC 14764 par :
- la correction des problèmes de design
- l'intégration des nouveaux besoins
- l'amélioration des performances
Il en profite pour critiquer les méthodes agiles car, à son avis, elle traite uniquement la création du logiciel pas de sa maintenance (Note pour soi-même : comprendre cette guerre entre prêcheur des méthodes agiles et ceux du MDA).
Il s'appui aussi sur le fait que les technologies changent tout le temps et les systèmes deviennent bloqués dans leur cadre historique, impossible à faire évoluer (cf les nombreux systèmes bancaires en COBOL).
Enfin il nous présente des chiffres liés à des exemples de projets tests réalisés en parallèle avec et sans MDA qui mettent en valeur MDA avec moins de défauts et un temps de développement plus court. Par contre même si Disney fait parti des projets cités en exemple, je resterais prudent vu qu'il est facile de prouver tout et n'importe quoi avec l'utilisation des chiffres de quelques projets :)
Sa conclusion met en avant que les bénéfices du MDA viennent sur le long terme et qu'on ne peut plus prétendre que la technologie actuelle utilisée pour un projet ne sera pas amené à évoluer.
Pour avoir connu de nombreux travaux de maintenance sur différents projets, il est clair que sa démonstration m'attire. Cependant je reste encore prudent face à MDA qui reste, à mon avis, difficile d'utilisation. Je me pose aussi cette question : est-on sur que MDA répond bien à ce besoin de maintenance et d'évolution ?
Voila pour ma journée rapidement résumé et en espérant découvrir mieux les avantages et très certainement aussi les défauts de MDA.
Commentaires