Pourquoi un langage de modélisation ?

Dès lors que l'on s'accorde sur l'utilité des modèles, une question se pose assez rapidement : quel langage utiliser pour les exprimer ? Est-il nécessaire de définir un langage commun ?

Avec ou sans patates ?

Nous l’avons vu dans la section précédente : la nécessité de modéliser les entités du monde réel se fait très rapidement ressentir quand on travaille sur des systèmes complexes, notamment lorsqu’il est question d’informatiser un système d’information.

Note – Cette nécessité est par ailleurs bien souvent proportionnelle à la complexité du système : un bidouilleur motivé bricolera plus ou moins efficacement, sans aucune forme de modélisation préalable, un programme qui réalise ce qu’il est censé réaliser. Néanmoins on voit rarement de gros système d’information informatisés et maintenus sans recourir à des modèles formels robustes.

Une fois que les gens ont franchi le cap ou « pourquoi », vient la question du « comment ». Et c’est souvent ici que le bas blesse…

Quel développeur n’a jamais reçu, en guise de spécification, un affreux diagramme composé de « patates » reliées par des lignes à la signification obscure ? Que dites-vous donc de ceci :

Diagramme incompréhensible sans langage de modélisation

Vous n’y comprenez rien ? Moi non plus.

Il y a fort à parier que celui qui l’a dessiné y voyait clair (« j’me comprends, j’me comprends ») au moment où il bouclait son ouvrage. Peut-être même que ses collaborateurs l’ont suivi dans cette expérience ésotérique profonde.

Mais qu’en est-il quelques semaines plus tard ? Qu’en est-il quand on présente ceci à d’autres personnes extérieures au service ou à de nouvelles recrues ? Il n’y comprennent rien, voire pire : ils interprètent les choses comme ils le peuvent pour dégager de fausses informations.

Ne pas réinventer la roue

You don’t have to reinvent the wheel, just attach it to a new wagon. Mark McCormack

Comme dans tous les domaines, et particulièrement en informatique, il y a beaucoup de gens (et pas les plus bêtes !) qui ont réfléchi au problème des langages de modélisation en informatique, notamment en ce qui concerne les systèmes d’information.

Il est toujours tentant, par méconnaissance de l’existant, par égarement ou par fantaisie, d’inventer sa propre façon de faire.

Mais n’oublions pas que notre métier d’ingénieur SI est aujourd’hui un métier d’intégrateur de méthodes et de technologies : les briques existent, il faut savoir les assembler correctement pour construire les plus beaux édifices.

Important – Écrire des modèles avec un langage personnel exotique est rarement une bonne idée : il y a fort à parier que les langages existants dans la communauté soient plus efficaces, plus lisibles et plus cohérents.

Appeler un chat un chat

Le problème numéro un des diagrammes griffonnés par des gens qui n’utilisent pas un langage précis et formellement défini, c’est qu’ils ne représentent pas toujours les choses de la même façon.

Lisez la phrase suivante :

J’ai mis le dans de fritoo. Un peu plus tard, j’ai sorti ce gâteau et nous l’avons mangé. Is was very tasty. Enfin, wir tranken un 01110110 01100101 01110010 01110010 01100101 d’eau.

Difficile à comprendre non ? Pas impossible, mais pas pratique et sujet à erreurs d’interprétation.

En bons ingénieurs IT que vous êtes, vous savez bien que 01110110 01100101 01110010 01110010 01100101 est l’expression binaire des codes ASCII les lettres v, e, r, r, e. Vous savez aussi que « Is was very tasty » est une phrase en langue anglaise, qui se traduit par « C’était très bon », ou encore que « wir trinken » veut dire « nous avons bu » en allemand. En revanche, « fritoo » n’évoque sans doute pas grand chose pour vous… Pour moi non plus. L’auteur de la phrase, lui, devait attacher à ce mot une signification, sans doute « frigo »…

Pour se faire comprendre efficacement, il faut parler le même langage que ses interlocuteurs.

Pour écrire un bon modèle, il faut utiliser un langage que connaissent les professionnels de votre domaine.

Moins d’interprétation

Le fait d’utiliser un langage normé, dont les règles d’expression sont clairement fixées, minimise très fortement la nécessité d’interpréter les choses.

Le problème n’est pas si simple qu’il n’y parait : souvenez-vous, un modèle est une abstraction de la réalité, donc une sorte de parti pris du modélisateur pour rendre compte d’un phénomène ou d’une situation. Dès lors, la notion d’interprétation apparaît…

Mais il est crucial de laisser l’interprétation là où elle doit intervenir, c’est à dire sur le fond des choses. Sur la forme, il ne doit y avoir aucun doute possible.

Einstein, grand modélisateur

Quand Einstein écrit « E = m·c2 » en 1905, imaginez la panique si les mathématiciens et physiciens de l’époque s’étaient demandé « c’est quoi le m ? », ou encore « un petit 2 en l’air comme ça, ça signifie quoi ? Multiplié par 2 ? ».

Bien sûr, ils le savaient. Car le modèle d’Einstein était exprimé dans un langage que maîtrisaient ses pairs. Pour la suite, c’est beaucoup plus compliqué : le fond du problème (le fait qu’en réalité « une particule de masse m isolée et au repos dans un référentiel possède, du fait de cette masse, une énergie E appelée énergie de masse, de valeur donnée par le produit de m par le carré de la vitesse de la lumière »), lui, peut être discuté, interprété, contredit, etc. Mais pas l’expression du modèle.

Plus vite opérationnel

Si vous ne dormez pas encore, vous êtes en train de lire ce support de formation depuis de longues minutes déjà, et, si vous êtes francophone, vous comprenez sans aucun effort tous les mots que j’y emploi.

Vous êtes immédiatement opérationnel pour interpréter tout ceci parce que vous avez été formé à ce langage que partagent environ 274 millions de personnes dans le monde.

Il en est de même pour les langages de modélisation, tels que ceux que l’on utilise dans le monde des systèmes d’information : le fait d’utiliser un langage répandu et standardisé permet de faire en sorte que de nouveaux collaborateurs soient très rapidement opérationnels pour comprendre, mais aussi pour produire eux-mêmes des modèles.

Testez-vous !

Un membre de votre équipe est retissant à apprendre UML et vous suggère, avançant le gains de temps de formation nécessaire, au profit de logigrammes non standardisés. Que lui répondez-vous ?
  • OK pour moi, on gagnera du temps !
  • Non, c’est une mauvaise idée d’utiliser un langage exotique dans un projet industriel.
  • Les logigrammes sont des modèles, par conséquent ils ne servent à rien.
  • Le temps que tu te formes à UML sera regagné puissance x dans les mois à venir au moment d’intégrer de nouveaux collaborateur qui, eux, connaîtront ce standard.
  • L’utilisation d’UML pourrait permettre de construire une base de connaissance (KMS) plus cohérente.
Est-il possible de se comprendre en utilisant un langage exotique ?
  • C’est possible, mais plus compliqué.
  • C’est possible, et tout aussi simple qu’en utilisant un langage universel.
  • C’est impossible.
Il est bien entendu possible de se comprendre en dessinant des patates et des traits entre ces patates… mais c’est moins efficace dans un contexte « industriel » : quand il est question d’éviter les erreurs d’interprétation, d’optimiser les temps de montée en compétence, et de réutiliser les modèles produits, il faut se doter d’un langage universel, cohérent et dont les règles d’utilisation sont précisément fixées.

Commentaires