Le générateur de code produit un ensemble de classes et de fonctions, qui sont intégrées dans le projet de développement. Le développeur complète ensuite le développement, avec des compléments sur les classes générées (les classes partielles ont été en grande partie faites pour cela), et du code qui va appeler les fonctions générées. Du code est nécessaire pour réaliser l'interface entre le code métier, le code généré, et le code technique (constitué la plupart du temps par un Framework).
Le problème est que cette approche vieillit très mal. Les frontières entre le code généré et le code écrit sont floues, fluctuantes avec le temps, et la maintenance est difficile. Il y a un risque fort que les 2 mondes ne cohabitent plus dans une version N+1. Une fois que le code a été généré, le lien avec le modèle est rompu. Et une fois que le lien avec le modèle est rompu, le risque que celui-ci ne soit pas mis à jour est élevé, et le bénéfice du modèle est perdu sur le long terme. Il n'est pas rare qu'un modèle soit utilisé pour les premiers cycles de développement et abandonné par la suite, parce que la maintenance du modèle avec le code écrit est devenu trop complexe.
Le modèle exécutable constitue une autre approche, qui ne repose pas sur un générateur de code et permet d'allier le meilleur des 2 mondes:
-
Capitaliser sur le modèle pour abstraire et structurer l'essentiel de la conception.
-
Garantir la maintenance du lien entre le modèle et l'application, puisque...
Le modèle est l'application, l'application est le modèle
Microsoft a ouvert la voie avec le DSL, qui est une avancée considérable pour unifier le modèle le code exécuté dans l'environnement de développement. En s'appuyant sur une séparation complète du code technique et du code métier, l'approche Aspectize permet d'étendre le modèle à bien plus de concepts que prévus initialement dans le MDA.
Que trouve-t-on dans le modèle ?
-
La logique des données, avec un modèle Entité-Relation, qui va bien au-delà du stockage: règles de validation, champs calculés, données et relations temporaires, le Modèle permet de décrire l'essentiel de la logique de l'application.
- La configuration de l'application et des services: sécurité, log, trace, gestion d'erreurs, tous les services techniques de l'application sont configurables de façon déclarative.
-
Les liens entre l'IHM, le modèle Entité-Relation et les services configurés: avec un modèle de DataBinding et de CommandBinding, l'ensemble de la cinématique de l'application est décrite et non plus codée.
Que reste-t-il en dehors du modèle ?
-
Le code métier, principalement des règles de validation et des règles de calcul. Il s'agit de service stateless, qui peuvent être appelés sur le client ou sur le serveur. Ce code est dépourvu d'appels à des éléments techniques, il s'agit de code pure.
-
L'IHM, ou plutôt la description visuelle de l'IHM, puisqu'il s'agit, pour une Application Web, de fichier HTML et CSS, purement descriptif, ou de contrôles WinForm, dépourvus de la moindre ligne de code.
Comment interagissent le modèle et le code ?
Le modèle est rendu avec le serveur d'applications, qui contient le code technique, générique qui évolue peu. En s'appuyant sur le princide de Hollywood (qui mérite un post à part entière) on inverse la dépendance entre le code technique et le code métier; ce n'est plus le code métier qui appelle le code technique, mais c'est le code technique, celui du serveur d'applications, qui appelle le code métier et interprète le modèle.
On est ainsi affranchi de tout risque de décalage entre, ce qui serait le code généré dans une solution Model Driven standard (mais qui n'en est pas avec le modèle exécutable), et du code spécifique métier écrit par le développeur. La frontière n'est pas définie dans le code métier, mais elle faite une fois pour toute, dans le code technique. Non seulement, cela permet de garantir l'évolution du Système, avec une meilleure réponse aux changements, car le code métier pourra évoluer plus facilement, mais cela élimine tous les appels techniques qui polluent habituellement le code métier, et celui-ci est beaucoup plus lisible et maintenable.
Unifier le modèle pour la conception, le développement et la documentation
En maintenant le Modèle au niveau du RunTime, cela permet d'avoir une vision commune de l'application tout au long de sa durée de vie. Cela facilite sa maintenance, parce que la cohérence entre le modèle et l'application est constamment garantie. Une évolution du Modèle est immédiatement visible sur l'Application, il n'y a pas de rupture pour réconcilier le modèle avec l'application. Cela permet également de faire vivre l'application avec un modèle incomplet, dès le premier jour du projet.
Cela permet également de modifier des paramètres applicatifs à chaud, en agissant directement sur le modèle. Le modèle est non seulement utile pour la conception et le développement, mais également pour l'administration de l'application en production.
Enfin, parce que la documentation applicative est directement issue du modèle, elle peut être générée à partir du RunTime et reflète exactement le fonctionnel de l'application. En permanence, l'information indispensable contenue dans les modèles est accessible. Cela favorise le turn-over inévitable qui arrive tôt ou tard dans les équipes de développement.
Le Model Driven Executable est le chaînon manquant qui fait défaut au Model Driven Architecture. En unifiant modèle de conception et implémentation, il offre de nouvelles perspectives d'agilité et de souplesse. A la place de la génération de code, qui a déjà trouvé ses limites, l'élimination de code est une voie à privilégier pour améliorer considérablement le développement logiciel.