Quelle forme pour mon modèle ?

Quelle forme pour mon modèle ?

Après avoir défini dans un précédent article ce qu’est un modèle, cet article s’intéresse à la forme concrète qu’il va prendre et les langages qui peuvent être utilisés pour le construire. Pour au final conclure sur l’outil essentiel du concepteur : l’abstraction.

Dans tout langage il y a une syntaxe et une grammaire (le signifiant) permettant de déduire le sens du message (le signifié). Dans le cas de mon modèle, cette description du langage utilisé s’appelle le méta-modèle. Le code source d’un langage de programmation est une forme particulièrement détaillée de modèle avec une grammaire et une sémantique associées à cette grammaire très précise — le méta-modèle du langage — permettant l’exécution de ce dernier. D’ailleurs, l’évolution des spécifications de méta-modèle comme par exemple BPMN vers toujours plus de précision vise au final à permettre cette exécution du modèle (au prix cependant d’une complexité accrue).

Graphique ou texte ?

Le langage utilisé pour décrire le modèle peut être textuel ou graphique, mais en fait je considère que les modèles purement textuels ou purement graphiques sont quasi-inexistants, un modèle est toujours un mélange entre une forme graphique et une forme textuelle.

Il suffit de regarder un modèle UML et du code source dans un environnement de développement moderne pour se rendre compte que :

• Le diagramme UML est constitué en majorité de texte structuré dans des formes graphiques
• Le code source dans un environnement de développement moderne contient des éléments graphiques (coloration syntaxique, graisse de certains mots-clés) et une organisation spatiale (l’indentation du code source est une organisation hiérarchique)

Regardez les deux photos suivantes de loin et vous vous rendrez compte de la similitude entre ces deux représentations.

Ainsi, les deux représentations sont des hybrides textuel/graphique et la force de l’une ou l’autre des formes tient plus à l’expressivité, et donc aux contraintes de la grammaire sous-jacente, qu’à la représentation graphique particulière. De même, la force du langage naturel des êtres humains provient des règles de grammaire et des possibilités infinies de constructions et d’associations que cela permet. Le succès de l’approche des Domain Specific Language (DSL) tient à mon avis de cette expressivité du texte et du langage plus familière à l’être humain que la représentation graphique.

Graphique ET texte

« Un modèle : Deux représentations » : la bijection entre la représentation textuelle et graphique afin de basculer d’une représentation à l’autre est maintenant possible, par exemple telle que conçue dans XText . Voir à ce sujet le livre « DSL Engineering « , en préparation, qui détaille ces aspects et ne parle pas volontairement d’UML. Ainsi, les représentations textuelles d’architecture logicielle émergent depuis un moment.

De même je vous parie que, dans quelques temps, les représentations textuelles d’un système d’informations vont apparaitre et cohabiter avec les représentations graphiques. Cela va de pair avec le déclin d’UML, accompagné parfois d’un certain intégrisme, c’est pour cela que certains reviennent à l’essentiel : « boxes and lines » de M. Feathers, « Is Design dead ? » de M. Fowler ou l’Agile Modeling de S. Ambler. En résumé : les modèles traditionnels UML évoluent vers plus de « texte » avec les DSL mais également vers plus de simplicité.

Les environnements de développement évoluent également pour prendre en compte cet aspect visuel du code source et des les liens entre différentes parties du code : Code Bubble, environnement graphique qui représente les « bouts de code » liés entre eux, est un excellent exemple qui préfigure à mon avis l’avenir des environnements de développements.

En conclusion, les deux approches quant à la forme d’un modèle : textuel (code source ou DSL) et graphique (UML, etc.), évoluent pour prendre en compte le meilleur des deux mondes. Les approches hybrides ayant ma préférence. Ces modèles graphiques sont donc très complémentaires d’un code source et permettent de masquer des détails qui sinon surchargeraient le modèle.

L’abstraction

Cependant, à mon sens l’essentiel n’est pas dans la représentation mais dans ce qui est représenté. Ainsi, l’outil intellectuel fondamental du concepteur est l’abstraction.

De manière générale, l’abstraction est l’acte consistant à isoler certaines caractéristiques communes à plusieurs objets. En informatique, c’est également le procédé consistant à masquer les détails d’implémentations d’un composant (objet, système), ce qui renvoie à la notion d’encapsulation et donc d’interface.

Le nombre magique : 7

Je trouve utile de rappeler qu’un cerveau humain ne peut manipuler aisément que 7 éléments à la fois : le fameux nombre magique 7, en référence au célèbre papier de recherche en psychologie par G. Miller (en fait, d’après des recherches récentes il parait que c’est moins… 3 ou 4 éléments). Ainsi parmi tous les constituants d’un système, qu’il soit d’information ou logiciel, chaque représentation ou vue doit s’en tenir au strict minimum : 7 éléments voir moins. Il est donc nécessaire de se concentrer sur l’essentiel et ainsi représenter le système par couches d’abstractions afin de procéder du général au particulier et pouvoir ainsi raisonner grâce à notre modèle. Un modèle est constitué de plusieurs diagrammes qui sont autant de vue de tout ou partie du même système. J’ai ainsi l’habitude de préconiser l’organisation du modèle dans l’outil de modélisation en allant du général au particulier : la structure du domaine métier qui s’organise en différents modules avant les classes, les macro processus avant les processus, etc.

Exemple

C’est ainsi qu’en urbanisation nous allons trouver les fameuses couches métier, fonctionnelle, applicative et technique. Sans oublier le modèle du domaine qui pose les concepts utilisés dans chacunes de ces couches.

Conclusion

En résumé, un modèle peut avoir de multiples représentations, texte ou graphique, chacune associée à un niveau d’abstraction particulier : avec souvent un niveau élevé d’abstraction pour un modèle avec une forme graphique, détaillé pour un modèle avec une forme textuelle (le code source). Cependant ces lignes sont mouvantes, les DSL permettant un haut niveau d’abstraction avec une forme textuelle. Néanmoins ma pratique de la conception et du développement de logiciel m’amène à penser que des modèles graphiques permettent de visualiser, appréhender et communiquer beaucoup plus facilement la structure et le comportement d’un système. Tout cela tient bien sûr de la finalité et du contexte d’utilisation du modèle — son usage — ce qui fera l’objet d’un prochain article.