Pour ce deuxième épisode, je prends a nouveau une abréviation se terminant enL. Après la STL, voici venir l'UML. Ces deux abréviations n'ont pas même la signification de leur L en commun.

UML signifie Unified Modelling Language. Ce n'est pas le premier langage dans ce domaine, mais il a eu un certain retentissement qui lui a faut remplacer ses prédécesseurs dans beaucoup de domaines.

UML a tous les symptômes d'un faux Graal : sa création a généré beaucoup d'articles, beaucoup de bruit, il y a eu des vagues de formations car « faire un projet en UML », c'était vendeur ; les objecteurs sont apparus qui ne voulaient pas en entendre parler, souvent en ne sachant pas trop de quoi il s'agissait mais soit par principe soit parce que « ils ne faisaient pas comme ça ».

Heureusement, tout cela s'est calmé, les passions se sont calmées et UML s'est installé tranquillement dans le paysage informatique.

Mais qu'est-ce donc que UML et qu'est-ce que ce n'est pas ?

UML est un langage, il permet donc de communiquer. C'est tout. C'est même indiqué dans la plupart des livres ou articles qui le présentent ¹. Derrière la communication, beaucoup de gens ont pensé y voir une technique de conception des programmes, une sorte de machin magique à qui l'on décrirait son programme et qui le validerait, le générerait,... un Graal.

Des méthodes tournent autour de UML et des logiciels permettent effectivement des traitements basés sur de l'UML. C'est ce qui a fait croire qu'UML n'était ce qu'il n'est pas. UML est un langage et il permet de communiquer, je l'ai déjà dit. Ce que je n'ai pas dit, c'est avec qui il permet de communiquer.

Un langage de programmation, par exemple, est fait pour communiquer la pensée du programmeur à la machine via un traducteur (compilateur ou interpréteur).Ce langage peut être lu par un autre programmeur comprenant ce langage particulier et c'est heureux, mais un langage de programmation n'est pas fait pour communiquer des idées d'un programmeur vers un autre programmeur. C'est une des raisons pour lesquels les programmes sont annotés de diverses manières dans un langage naturel.

La machine elle aussi a des langages par lesquels elle peut communiquer des résultats à l'utilisateur. Le langage le plus courant et le plus utilisé est celui de l'interface utilisateur. Tous les systèmes d'exploitation n'utilisent pas les mêmes codes mais dans la grande majorité, les interfaces graphiques parlent toutes un dialecte d'une même grande famille : les boutons changent de couleur lorsque l'on appuie dessus, les informations clignotent lorsqu'on veut attirer l'attention, des « ascenseurs » indiquent la progression de lecture dans un document,...

Revenons à UML. UML est un langage essentiellement graphique. Il est le descendant de toute une série de formalisations, ou tentatives, de petits gribouillis et de schémas que les informaticiens ont toujours fait dans un coin de feuille sur leurs bureaux, dans des réunions sur un tableau blanc ou dans des documentations.

UML a été pensé pour la communication entre informaticiens mais aussi entre informaticiens et machines (via des programmes). La communication entre informaticiens est obtenue par une formalisation de concepts divers de modélisation. L'idée est que si tout informaticien parle UML, alors communiquer sur des idées de modélisation va être facilité.

La communication entre informaticiens et machines, elle, est obtenu parce que la formalisation est précise et peut être traitée automatiquement. La communication est même à double sens : les « dessins » de l'UML étant précisément décrits,ils peuvent être générés par un programme.

Mais alors, où est le problème ?

Puisque l'on peut communiquer avec un programme en UML, des informaticiens ne se sont pas gênés pour l'inclure à leurs programmes. On peut faire beaucoup de choses sympathiques avec UML : générer des classes automatiquement, générer de la documentation, générer du code d'automates,...

Mais il faut bien comprendre que ces programmes, s'ils communiquent en UML, ne sont pas UML. C'est là que s'est situé une partie de l'apparition des réfractaires qui voyaient dans l'apparition de ces programmes des lourdeurs dont ils ne voulaient pas ².

De même, des méthodes de modélisation sont apparues utilisant UML, dont une en particulier proposée par ceux qui proposent UML.Là encore, une confusion s'est créée qui a pu faire croire que parler UML dans un projet, c'est inclure obligatoirement ces méthodes.

Au final ?

UML est un langage et c'est déjà pas mal. Il est utile à connaître lorsque l'on est informaticien. Depuis son apparition, les documents qui parlent UML ne sont plus obligés d'expliquer leur nomenclature. Des informaticiens qui parlent UML peuvent plus facilement travailler et communiquer leurs idées.Les logiciels qui parlent UML se basent sur un supposé acquis de la part de l'informaticien qui l'utilise. C'est un gain appréciable pour démarrer l'utilisation du logiciel.

Mais ce n'est pas le Graal : inclure UML à son projet ne le rendra pas plus beau ni plus stable ni obligatoirement mieux architecturé.