Ingénierie Dirigée par les Modèles : présentation MDA ( Model Driven Architecture ), mais est ce utilisé dans la vraie vie ?
Partir d'un modèle de concepts métier et transformer ce modèle en d'autres modèles s'affinant progressivement pour arriver finalement à un modèle de code source.
En 2015 l'homme devra encore se plier à la machine.
Depuis longtemps on nous promet pour les applications informatiques de gestion de commencer par modéliser les concepts métier : les processus, les entités, les règles et les éléments d'IHM, puis d'indiquer l'architecture cible et laisser la technique générer le code source Java, .NET, Web, ....
Les enjeux sont de taille. Cela permet de se concentrer sur les aspects métier, l'optimisation et la flexibilité des processus par la mise en place de BPM (Business Management Process), de capitaliser les connaissances comme les règles métier avec un BRMS (Business Rules Management System), de pérenniser le modèle de données métier avec une modélisation optimisée avec UML (Unified Modeling Language).
Aujourd'hui de nombreuses applications vieillotes réalisées à l'ancienne sont rajeunies en changeant les techniques d'IHM, en relookant les écrans dans un style tendance à la Facebook, en développant de nouveaux domaines dans les technologies adoptées par l'industrie IT comme Java ou .NET. Et puis dans 10 ans, on changera tout à nouveaux pour les dernières architectures à la mode.
Quelque soit la plateforme cible (Java, .NET, Web, Google, Mainframe, ...), l'architecture est toujours la même avec les couches : présentation, contrôleur, services métier, injection de dépendances, persistances, SGBDR, moniteur transactionnel, ...
Et pourtant dans chaque projet, on recommence par concevoir et valider l'architecture, à mettre en place la pile de framework correspondant aux couches précédentes et on refait toujours la même chose. Les consultants facturent cher un travail qu'ils ont déjà fait car les solutions sont bien connues et pourraient être automatisées. N'importe quel architecte sait qu'il doit mettre en place par exemple dans une architecture Java classique la persistance avec Hibernate, le workflow écran, l'injection de dépendance, les transactions, les batchs avec Spring, les IHM avec HTML/Javascript/JSF/GWT/ ... etc, etc.
Pourtant fin des années 90 début 2000, les grands éditeurs comme IBM, Sun (racheté par Oracle), Borland (racheté par Micro Focus), Oracle, ... et les organismes de normalisation comme l'OMG (Object Management Group) ont mis au point des solutions. Une des plus prometteuse est MDA (Model Driven Architecture) constituée d'un nombre impressionnant d'autres normes comme UML (Unified Modeling Language), OCL (Object Constraint Language), MOF (Meta Object Facility), XMI (XML Metadata Interchange), QVT (Query View Transformation), ASL (Action Semantics Language), etc, etc.
On part de la vraie vie c'est à dire les objets (par exemple la facture du 26/01 du client Martin), puis on remonte d'un niveau d'abstraction, au niveau modèle (la classe Facture et Client) puis encore plus abstrait avec le méta modèle (on modélise le modèle : Classe, Attribut, Association, ...) puis enfin ça se termine avec le méta méta modèle (tout est objet : Classe).
Depuis des décennies les grands acteurs IT parlent d'outils, de normes et de framework dans le but de générer un maximum de codes.
L'idée la plus alléchante étant à partir d'un modèle métier et indépendant de la technique (CIM Computation Independent Model), de génèrer un autre modèle indépendant d'une plateforme de développement (PIM Plateform Indépendent Model), puis génére un modèle spécifique à une plateforme (PSM Plateform Specific Model) comme Java, .NET, SQL, ... Puis enfin génèrer un modèle de code qui pourra être traduit directement dans un langage informatique standard.
Pour pouvoir transformer des modèles, il faut pouvoir manipuler le méta modèle (MOF) avec un langage (QVT).
Dans l'architecture MDA tout est piloté par les modèles, on trouve aussi la réciproque ADM (Architecture Driven Model) permettant de faire du reverse engineering c'est à dire que les modifications métier (ajout d'un attribut métier par exemple) vont se retrouver dans les modèles PSM, PIM et CIM. On parle alors de round trip (autoriser les transformations inverses).
Tout ceci est très joli sur la papier. L'OMG ne fait que des normes et ne s'occupe pas des implémentations. Elle recherche du reste souvent des partenaires et sponsors pour réaliser ses normes.
Dans la communauté IT pour se démarquer de l'OMG, on utilise souvent l'acronyme MDE (Model Driven Engineering), c'est le seul qui n'a pas été déposé comme marque par l'organisme de normalisation !
Pour que ça marche réellement et que ce ne soit pas juste de la simple génération de code, il faut avoir le méta modèle du PIM avec les classes métier, les services, les éléments d'IHM (liste déroulante, ...), ..., le méta modèle du PSM facilement réalisable par les architectes techniques car il suffit de modéliser les nombreuses instances d'architectures existantes et enfin un transformateur de PIM en PSM.
MDA ne fournit pas d'implémentation qui est complexe, coûteuse et risquée à réaliser. Il faut les méta modèles du PIM et PSM et un transformateur de ces modèles.
Alors serait ce le Saint Graal ?
Apparement non car les gros projets ne l'utilisent pas du tout. Les raisons sont multiples. D'abord le coût d'appropriation des concepts et donc le retour sur investissement. La conjoncture actuelle ne se prête pas à de la recherche et développement. Les solutions proposées par les éditeurs ou par les open sources sont trop variées sans réelles pérennités. Les projets sont contraints par les délais et le budget de plus en plus serré. On a tendance à utiliser les bonnes vieilles méthodes. Le source est déporté sur le PIM qui doit être correctement modélisé et c'est là qu'il y a le principal risque. Comment gérer les itérations lorsqu'on modifie les sources ? Faut il faire des transformations inverses ? Faut il régénérer à partir du PIM ? Quelles sont les réels retours d'expérience avec leur ROI et non pas de la simple génération de codes ou de mise en place de template de codes.
Encore une fois la boucle est bouclée. Les normes sont intéressantes sur la papier, les éditeurs commencent des implémentations prometteuses mais incomplètes et attendent que les grands comptes s'y mettent mais comme il n'y a rien de consistant, sans retours d'expérience et en ces temps économiques non propices aux investissements personne ne veut payer pour les autres. La génération automatique d'applications informatiques à partir de modèles applicatifs n'est pas pour demain, les architectes techniques et les développeurs ont encore de beaux jours devant eux.
"La vie est toujours en devenir, mais il ne faut jamais oublier de la vivre au présent."
Jacques Salomé
Voir aussi :
http://urbanisation-si.wix.com/blog
http://urbanisme-si.wix.com/blog
http://urbanisation-si.wix.com/urbanisation-si
http://urbanisation-si.over-blog.com/
http://rhonamaxwel.over-blog.com/
http://urbanisation-des-si.blogspot.fr/
A découvrir aussi
- Ingénierie Dirigée par les Modèles (IDM) : le tour de passe-passe des transformations de modèles
- Ingénierie Dirigée par les Modèles : didacticiel GMF, ça marche ce truc ?
- Didacticiel ( tutoriel ) Eclipse Sirius ( Obeo Designer Community ) : on peaufine l'éditeur de diagramme
Inscrivez-vous au site
Soyez prévenu par email des prochaines mises à jour
Rejoignez les 757 autres membres