Accéder au contenu principal

Retour Model Driven Day 2009

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

Posts les plus consultés de ce blog

Summary of 'Words are windows, Introduction to nonviolent communication' by Marshall Rosenberg

Summary of 'Words are windows, Introduction to nonviolent communication' by Marshall Rosenberg “Words are windows” is an introduction to non violent communication (abbreviated as NVC). Marshall Rosenberg presents in this book the process that allows us to communicate more serenely with others as well as with ourselves. This mode of communication allows us to become more and more caring, authentic, and empathic with others. It can therefore be used in all interactions of everyday life: as a couple, with our children, at work … NVC is proving to be a very effective way to manage conflicts, and also to better identify our own needs. At the source of Non Violent Communication NVC has 4 four key components: Observation – specific facts/data, no evaluation/judgment Feeling – state how we feel (many failure modes here) Need – the need underlying this feeling Request – must be specific action to address need First we observe what is really happening in a given situatio

Summary of 'Clean Architecture' by Robert C. Martin

Summary of 'Clean Architecture' by Robert C. Martin Uncle Bob, the well known author of Clean Code, is coming back to us with a new book called Clean Architecture which wants to take a larger view on how to create software. Even if Clean Code is one of the major book around OOP and code design (mainly by presenting the SOLID principles), I was not totally impressed by the book. Clean Architecture leaves me with the same feeling, even if it’s pushing the development world to do better, has some good stories and present robust principles to build software. The book is build around 34 chapters organised in chapters. Programming paradigm After some introduction, there is an overview of three paradigm of programming: structured programming which imposes discipline on direct transfer of control object oriented programming which imposes discipline on indirect transfer of control functional programming which imposes discipline upon assignment Uncle Bob tells us

Le développeur incompétent est un mythe

Sous ce titre complètement arbitraire et très clairement provocateur, je vais passer un contre pied aux derniers articles que j'ai lus sur le métier de développeur. Par exemple : http://patricelamarche.net/2011/05/24/lincomptence-des-dveloppeurs/  http://blogs.codes-sources.com/tja/archive/2011/10/04/etre-un-bon-d-veloppeur-c-est-aussi-une-question-d-attitude-personnelle.aspx  Ça tombe bien c'est juste avant la soirée du Paris JUG sur le métier de développeur ! Et comme on se plaint que les présentateurs ne sont pas de vrais (?) développeurs, je vais en profiter pour donner mon avis. Alors voila, d'après ces articles, un bon développeur connait ses fondamentaux. Ok soit mais quelle est cette liste de fondamentaux ?  Chez certains, c'est les maths et l'algorithmie pure, d'autres c'est C++ par coeur et savoir retourner une chaine de caractère en moins de 3 instructions et une seule allocation mémoire, d'autres c'est Java JEE, ses 100 jsr et fra