Le Model Driven Development (MDD)
ELEPHANT technologies est l’ESN locale à taille humaine spécialisée sur 3 métiers : le développement, le test et le pilotage et autour de 2 expertises l’IoT et le Digital.
Aujourd’hui, retrouvez Pierre notre elephantgénieur, qui nous explique comment le Model Driven Development révolutionne le processus de création d’un logicie.
On peut être tenté, à l’ouverture de notre tout nouveau lego, d’essayer de le faire sans la notice. Notre ego prend alors le dessus et on se lance dans ce défi. Mais après plusieurs heures, force est de constater que la voiture que l’on souhaitait construire ne ressemble pas vraiment au résultat escompté. On est alors forcé de se rabattre sur la notice nous indiquant la marche à suivre.
Et bien en programmation, c’est à peu près la même chose. On a souvent une vague idée de ce que l’on souhaite faire mais il arrive que l’on décide de directement se lancer dans le développement, tout en promettant que la documentation (la notice) sera faite « dès que l’on aura du temps ». Le projet arrive alors à son terme, le produit est fini et personne n’a écrit la moindre documentation. Si bien que le fonctionnement de notre code devient encore plus mystérieux que la cité perdue de l’Atlantide.
Heureusement le Model Driven Architecture tend à éviter cela. Cette approche, inventée en 1989 par l’OMG (Organisation Management Group) consiste à créer des modèles capturant l’essence même du logiciel que l’on veut concevoir. Tout y est soigneusement modélisé et avec le plus de détails possibles, des exigences fonctionnelles, aux détails architecturaux.
Ces modèles vont alors nous permettre de directement générer notre code à l’aide d’outils et dans le langage de notre choix, réduisant alors de manière considérable le temps normalement alloué à la partie développement. Plusieurs langages de modélisation sont disponibles pour réaliser lesdits modèles : l’UML, le XML ou encore le SysML mais le plus répandu et utilisé reste l’UML.
L’UML : Un langage universel
L’Unified Modeling Langage, ou UML, n’est pas un langage de programmation mais un langage de modélisation visuelle commun et dont la création et les règles sont également une création de l’OMG.
Le proverbe « Une image vaut mille mots » décrit parfaitement la mentalité derrière ce langage : celui-ci n’est là que pour permettre de décrire visuellement et de manière universelle un système à l’aide de différents diagrammes. Ils se déclinent en deux grandes catégories : les diagrammes UML structurels, qui sont là pour décrire les différentes composantes de notre système, et les diagrammes UML comportementaux, qui vont décrire l’ensemble des actions et des scénarios possibles. Les différents diagrammes possibles sont les suivants :
Diagrammes UML structurels :
-
Diagramme de classes
-
Diagramme de composants
-
Diagramme de déploiement
-
Diagramme de structure composite
-
Diagramme d’objets
-
Diagramme de paquetages
-
Diagramme de profil
Diagrammes UML comportementaux :
-
Diagramme de temps
-
Diagramme d’aperçu des interactions
-
Diagramme de communication
-
Diagramme état-transitions
-
Diagramme de cas d’utilisation
-
Diagramme de séquence
-
Diagramme d’activités
Pour découvrir plus en détails les différents diagrammes, je vous conseille de lire l’article de lucidchart.
Je pense donc je modélise
Penchons-nous maintenant sur la définition de ce qu’on appelle un modèle en MDD. Un modèle est une représentation abstraite et formelle de notre logiciel.
Comme nous l’avons vu précédemment, les diagrammes UML vont nous aider à décrire les différents aspects et composantes de notre système, allant des exigences fonctionnelles aux détails de notre architecture, en passant par la description du matériel utilisé ou encore les différents utilisateurs.
C’est donc l’ensemble de ces éléments qui vont composer notre modèle et renforcer notre compréhension de celui-ci. Plus ils seront détaillés et plus notre système sera proche du résultat voulu et imperméable à toute défaillance.
Du concept au code :
Une fois notre architecture complétée, nous allons pouvoir spécifier la plateforme souhaitée puis générer le code associé et adapté à celle-ci : Il est par exemple possible de spécifier l’OS sur lequel le logiciel va tourner, l’architecture (64 bits, 32 bits ou moins) et même des « coding rules » qui seront appliqués au code généré.
Cette étape peut être réalisée à l’aide d’outils (tel que Simulink ou Rhapsody) et nous permet d’avoir un logiciel généré et prêt à l’emploi. L’un des avantages de générer notre code avec des modèles est que l’on peut imaginer générer, en complément du code, une documentation complète et détaillée ou même des tests permettant de faire valider ce code ainsi que notre système modélisé. On peut également imaginer générer une simulation fidèle de notre système pouvant être utilisé pour tester ce dernier.
Ainsi, le MDD nous permet d’avoir un modèle que l’on va pouvoir faire évoluer au fil des différentes itérations et nous donner une certaine robustesse face au changement en enlevant les difficultés que l’on peut avoir lors d’un développement plus traditionnel. En effet, vu que ce modèle permet de réduire drastiquement le temps nécessaire à l’écriture et la réécriture du code, nous avons donc plus de temps pour penser notre système dans les moindres détails.
Mais cette force est également l’une de ses faiblesses. Bien que tout changement via une modification de l’architecture se fera sans difficulté, le code généré lui, n’est absolument pas malléable. Tout changement après génération peut se révéler très compliqué.
Enfin, la qualité du code généré dépendra de l’algorithme utilisé (et donc de la qualité de ce dernier) mais également de la qualité du modèle réalisé. Créer des modèles détaillés et fiables demande une grande compréhension et un fort niveau de connaissances dans le domaine d’application du système modélisé, ainsi ce genre d’approche n’est le plus souvent indiqué qu’auprès des profils seniors et expérimentés et peut être déroutant voir inefficace avec des profils juniors.
En conclusion :
Le MDD est une approche qui, pour bien des raisons, n’a pas su séduire un large public mais qui convient parfaitement dans des cas nécessitant une forte rigueur. Et bien que certains aient considéré cette méthode comme « dead on arrival » celle-ci continue, doucement mais sûrement, à évoluer. Peut-être même que la force de l’Intelligence Artificielle permettra d’améliorer et populariser cette approche ?
Sources
https://opus.bibliothek.uni-augsburg.de/opus4/frontdoor/deliver/index/docId/45281/file/45281.pdf