Qu'est-ce que UML ?

UML est un langage visuel de description des systèmes logiciels. Il vous donne un jeu fixe de formes, de traits et de règles pour qu'un diagramme que vous dessinez signifie la même chose pour quelqu'un qui n'était pas dans la pièce où il a été tracé.

C'est toute la proposition de valeur, et il vaut mieux le dire franchement. Une boîte avec un nom dedans, ce n'est pas UML. Une boîte à trois compartiments, un triangle creux pointant vers une autre boîte et un 1..*au bout d'un trait, c'est UML, et cela dit quelque chose de précis : ce type hérite de celui-là, et une instance du premier est associée à au moins une du second. Quiconque connaît la notation lit cela à l'identique. Voilà ce que vous achetez.

Le langage est maintenu par l'Object Management Group. La version courante est UML 2.5.1, publiée en 2017. Elle descend du travail que Grady Booch, James Rumbaugh et Ivar Jacobson ont fusionné chez Rational au milieu des années quatre-vingt-dix, quand le domaine comptait une cinquantaine de notations concurrentes et aucun moyen de lire la conception d'autrui. L'OMG a adopté UML 1.1 en 1997. La version 2.5 a surtout été un nettoyage : la spécification s'était scindée en volumes « infrastructure » et « superstructure » où peu de gens se retrouvaient, et 2.5 les a repliés en un seul document.

Chaque diagramme UML répond à l'une de deux questions. Les diagrammes de structurerépondent à « de quoi ce système est-il fait ? » : les parties, les types, les machines, et leur agencement. Ils décrivent des choses vraies indépendamment du temps.

Les diagrammes de comportementrépondent à « que fait ce système ? » : les flux, les messages, les états, et l'ordre dans lequel les choses arrivent. Ils décrivent des choses qui ne sont vraies qu'à un instant.

Un diagramme de classes vous dit qu'un Paymenta un montant et un statut. Un diagramme d'états-transitions vous dit qu'un paiement passe de Authorized à Capturedmais jamais l'inverse. Aucun ne peut exprimer ce que dit l'autre, et la plupart des vraies questions réclament un de chaque. Si vous vous surprenez à vouloir montrer une séquence sur un diagramme de classes, c'est le signal qu'il faut dessiner un second diagramme plutôt que de surcharger le premier.

Le comportement comporte un niveau d'imbrication supplémentaire. Quatre des sept diagrammes de comportement - séquence, communication, temps et global d'interaction - sont tous des diagrammes d'interaction, quatre rendus différents d'une même idée sous-jacente : des participants qui échangent des messages. Ils sont interchangeables en principe. En pratique les diagrammes de séquence dominent, parce qu'un axe temporel vertical est ce qu'il y a de plus facile à lire au monde.

Voici tout le langage, au niveau « en ai-je besoin aujourd'hui ? ». Suivez un lien quand la réponse est oui.

En pratique, une bonne majorité de l'UML réel se résume à quatre d'entre eux : classes, séquence, cas d'utilisation et activités. Les dix autres existent parce que quelqu'un en a eu besoin, et trois ou quatre sont réellement excellents quand la situation l'exige : un diagramme d'états pour un cycle de vie, un diagramme de déploiement pour une revue d'infrastructure. Le reste, vous pouvez le lire quand vous le croisez et ne jamais le dessiner.

Partez de la question, pas du diagramme. L'erreur consiste à choisir d'abord un type de diagramme puis à décider quoi mettre dessus : c'est ainsi qu'on se retrouve avec un diagramme de classes de deux cents boîtes que personne n'a jamais lu.

• « Qui s'en sert et pour quoi ? » - diagramme de cas d'utilisation. Le périmètre et les acteurs, avant toute conception.
• « Quels sont les concepts et comment se relient-ils ? » - diagramme de classes. La vue structurelle par défaut.
• « Que se passe-t-il quand on clique sur payer ? » - diagramme de séquence. L'ordre des messages entre participants.
• « Quel est le processus, embranchements compris ? » - diagramme d'activités. Le flux avec décisions et parallélisme.
• « Dans quels états cette chose peut-elle être ? » - diagramme d'états-transitions. Cycle de vie et transitions licites.
• « Qu'est-ce qui tourne où ? » - diagramme de déploiement. Noeuds, artefacts, environnements.
• « Quels sont les services et leurs contrats ? » - diagramme de composants. Interfaces fournies et requises.
• « Comment le code est-il organisé ? » - diagramme de paquetages. Regroupement et dépendances autorisées.

Ce n'est pas un processus.UML ne dit rien sur le moment où modéliser, sur la quantité à modéliser, ni sur qui valide. C'est une notation. Des méthodes comme RUP ont été bâties autour et sont fréquemment confondues avec lui ; vous pouvez employer UML dans n'importe quel processus, y compris aucun.

Ce n'est pas un langage de programmation.Les modèles UML peuvent être assez détaillés pour engendrer du code, et certains outils font exactement cela. La plupart des équipes ne le font pas, et ne devraient pas. La génération de code aller-retour complète est la raison la plus courante de l'effondrement des démarches UML : le modèle devient une seconde copie, moins bonne, du source, que personne ne met à jour.

Ce n'est pas tout ou rien.Rien n'oblige à utiliser les quatorze diagrammes, ni à modéliser chaque classe. Dessiner un seul diagramme de séquence pour trancher un débat sur qui appelle qui est un usage parfaitement légitime d'UML, et probablement le plus précieux.

Ce n'est pas la même chose qu'ArchiMate.Les deux sont des langages de modélisation et se recouvrent assez pour prêter à confusion. UML modélise le logiciel : classes, composants, messages. ArchiMate modélise l'entreprise autour : processus métier, capacités, couches applicative et technologique. Une grande organisation a typiquement besoin des deux, à des altitudes différentes.

La réponse honnête : bien moins que ne l'encourage l'outillage. Un modèle gagne sa place quand il est lu plus souvent qu'il n'est modifié. Trois choses produisent cela de façon fiable.

Modélisez les parties difficiles à tenir en tête. La machine à états du paiement, avec neuf états et deux transitions interdites, vaut un diagramme. Le DTO à trois champs, non.

Modélisez à une seule altitude par diagramme.L'échec le plus courant d'un vrai diagramme de classes est de mélanger concepts du domaine et plomberie du framework sur la même toile. Deux diagrammes, cohérents chacun, valent mieux qu'un seul techniquement complet.

Modélisez ce que vous garderez.Un diagramme dans un jeu de diapositives est un dessin dont la péremption est d'une réunion, et c'est très bien tant que vous savez que c'est cela. Un diagramme dans le dépôt, à côté du code qu'il décrit, est un modèle - et il lui faut un responsable.

Si la notation vous est nouvelle, lisez d'abord l'article sur le diagramme de classes. Il porte la plus grande part du vocabulaire d'UML - généralisation, association, multiplicité, composition - et tous les autres diagrammes de structure réutilisent ces marques. Lisez ensuite l'article sur le diagramme de séquence, qui fait le même travail pour le comportement.

Ces deux-là couvrent l'essentiel de ce qu'on vous demandera jamais de lire. Tout le reste de cette série est écrit pour être pris le jour où vous en avez besoin, dans n'importe quel ordre, et chaque article ne suppose que ces deux-là.