Les diagrammes UML que les architectes utilisent encore

Ce qu’est UML, et où il en est aujourd’hui

Le langage de modélisation unifié (UML) est un langage graphique généraliste qui sert à décrire la structure et le comportement des logiciels. Il est né de la fusion, chez Rational Software au milieu des années 1990, des méthodes de Grady Booch, James Rumbaugh et Ivar Jacobson, et a été adopté comme norme en 1997 par l’Object Management Group (OMG), un consortium de normalisation du secteur. UML 2.0 (2005) a été une révision majeure. La version actuelle est UML 2.5.1, publiée par l’OMG en décembre 2017 ; la version antérieure, UML 2.4.1, a aussi été publiée par l’ISO sous la référence ISO/IEC 19505 (2012). La spécification définit quatorze types de diagrammes, répartis entre les diagrammes de structure (comme les diagrammes de classes, de composants et de déploiement) et les diagrammes de comportement (comme les diagrammes d’activité, d’états-transitions et de séquence).

La réputation d’UML a beaucoup changé. À la fin des années 1990 et au début des années 2000, il était présenté comme la base du développement dirigé par les modèles, dans lequel des modèles détaillés seraient transformés en code. Cette ambition a largement échoué en dehors de domaines spécialisés, et beaucoup d’équipes associent UML à des processus lourds et à des diagrammes que personne ne lisait. Lorsque Marian Petre a interrogé 50 développeurs professionnels pour une étude présentée à ICSE 2013, 35 ont déclaré ne pas utiliser UML du tout, et la plupart des autres l’utilisaient de façon sélective et informelle ; la plupart des équipes dessinent des boîtes et des lignes informelles plutôt que de l’UML strict. Pourtant, une poignée de types de diagrammes UML restent les meilleurs outils disponibles pour certaines questions, en particulier les questions de comportement dans le temps, et leur notation est largement comprise. Un architecte n’a pas besoin des quatorze types de diagrammes ; il lui en faut peut-être six, utilisés à dessein.

Cette section présente ces six types, chacun avec un petit exemple tiré de la plateforme de livraison de repas utilisée tout au long de ce chapitre. Elle suppose acquis le vocabulaire C4 de la section 4.3 ; les deux se combinent bien, avec C4 pour la vue d’ensemble structurelle et UML là où la précision sur les interfaces, les interactions ou les états est rentable.

Croquis, plan détaillé ou langage de programmation

UML Distilled de Martin Fowler (3e édition, Addison-Wesley, 2003) et ses essais de la même année distinguent trois façons d’utiliser UML, une classification à laquelle Steve Mellor est parvenu de son côté. Comme croquis, UML est utilisé de façon informelle et sélective pour communiquer des idées : sur un tableau blanc avant d’écrire du code (croquis prospectif) ou pour expliquer une partie d’un système existant (croquis rétrospectif). Seuls les éléments importants apparaissent, la notation est suivie de façon approximative, et le diagramme est souvent jeté. Fowler le résume lui-même ainsi : l’exhaustivité est l’ennemie de la compréhensibilité.

Comme plan détaillé, UML sert à produire des modèles complets et précis que quelqu’un d’autre implémente, ou qui sont générés à partir du code existant pour le documenter intégralement ; le but est l’exhaustivité, et des outils sont généralement nécessaires. Comme langage de programmation, le modèle UML est suffisamment détaillé pour être compilé en code exécutable, ce qui est l’objectif de l’architecture dirigée par les modèles (MDA). Ce mode survit dans quelques niches de l’embarqué et des systèmes critiques pour la sûreté, souvent au moyen de profils et d’outils spécialisés, mais il ne s’est pas généralisé.

Pour les architectes, le mode croquis est la règle et le mode plan détaillé l’exception. La question utile pour chaque diagramme est : qui le lira, et quelle décision ou quelle compréhension soutient-il ? Un diagramme de séquence esquissé pour s’entendre sur la gestion des échecs de paiement est précieux, même s’il ignore la moitié de la notation. Un modèle de classes complet d’un service de 200 classes, maintenu à la main, ne l’est généralement pas.

Diagrammes de composants : les parties et leurs interfaces

Un diagramme de composants UML montre les parties modulaires d’un système et, surtout, leurs interfaces. Sa notation caractéristique est la « boule et douille » : un petit cercle au bout d’une tige (une interface fournie, que le composant offre) et un demi-cercle (une interface requise, qu’il a besoin qu’un autre lui fournisse). Quand une boule s’emboîte dans une douille, les deux composants sont reliés par cette interface. Les dépendances sont des flèches en pointillés, éventuellement libellées avec un stéréotype comme «use».

C’est exactement ce qui intéresse les architectes quand ils veulent montrer le sens des dépendances et la possibilité de remplacer une partie. Dans l’exemple, le composant Commandes ne dépend pas directement du prestataire de paiement ; il requiert une interface PaymentPort, qu’implémente un adaptateur de paiement distinct. C’est l’inversion des dépendances et la logique ports et adaptateurs du chapitre 3 rendues visibles : changer de prestataire de paiement signifie écrire un nouvel adaptateur, et non modifier Commandes. Un diagramme de composants C4 peut montrer les mêmes parties, mais il ne distingue pas les interfaces fournies des interfaces requises.

Diagrammes de déploiement : nœuds et artefacts

Un diagramme de déploiement UML montre l’infrastructure physique ou virtuelle et ce qui s’exécute dessus. Ses éléments sont des nœuds, dessinés sous forme de boîtes en trois dimensions, qui sont des ressources de calcul : un «device» comme un téléphone ou un serveur, ou un «executionEnvironment» comme un système d’exploitation, un environnement d’exécution de conteneurs ou un cluster Kubernetes ; les nœuds peuvent être imbriqués. Les artefacts, dessinés sous forme de rectangles avec une icône de document et le stéréotype «artifact», sont les fichiers physiques déployés : un JAR, une image de conteneur, un paquet d’application mobile, un fichier de configuration. Les lignes entre les nœuds sont des chemins de communication, libellés avec des protocoles.

Les diagrammes de déploiement sont des vues d’allocation au sens du SEI (section 4.2). Ils répondent aux questions de l’équipe d’exploitation : où s’exécute chaque partie, en combien de copies, dans quelle région, quels chemins réseau existent. Le diagramme de déploiement de C4 couvre le même terrain avec une notation moins formelle ; l’un ou l’autre convient, pourvu qu’il y en ait un par environnement important et qu’il montre les réplicas, les services managés et les frontières réseau.

Diagrammes de séquence : qui appelle qui, et dans quel ordre

Si les architectes ne gardent qu’un seul diagramme UML, c’est généralement le diagramme de séquence. Il montre comment des participants interagissent dans le temps pour un scénario. Les participants apparaissent en haut, chacun avec une ligne de vie verticale en pointillés ; le temps s’écoule vers le bas. Un fin rectangle sur une ligne de vie, l’activation (spécification d’exécution), montre quand ce participant est occupé à traiter un message.

Les pointes de flèche ont un sens. Un message synchrone, pour lequel l’émetteur attend une réponse, a une ligne continue et une pointe de flèche pleine. Une réponse a une ligne en pointillés et une pointe ouverte. Un message asynchrone, pour lequel l’émetteur continue sans attendre, a une ligne continue et une pointe ouverte. Bien les représenter compte pour l’architecture : que le service des commandes attende le prestataire de paiement, ou qu’il publie et passe à la suite, détermine sa latence, ses modes de défaillance et son couplage (voir la section 0.6).

Les fragments combinés ajoutent le flux de contrôle : une boîte libellée alt, avec des sections gardées séparées par une ligne en pointillés, montre des alternatives (if/else), opt montre une partie facultative, loop une répétition et par des sections parallèles. Utilisez-les avec parcimonie ; un diagramme de séquence avec des boucles et des alternatives imbriquées, c’est du code mal dessiné. Dessinez un diagramme par scénario important, y compris les scénarios d’échec, car c’est là que se joue l’essentiel de la réflexion architecturale.

Diagrammes d’états-transitions : cycles de vie et règles

De nombreux objets métier ont un cycle de vie : une commande, un paiement, un abonnement, un sinistre d’assurance. Un diagramme d’états-transitions le décrit avec précision. Les états sont des rectangles aux coins arrondis ; un cercle plein marque le pseudo-état initial et un cercle pointé l’état final. Les transitions sont des flèches libellées event [guard] / action : l’événement (event) qui déclenche la transition, une condition de garde (guard) facultative qui doit être vraie, et une action facultative exécutée au passage. Les états peuvent avoir des comportements internes, comme entry / notify restaurant.

Les machines à états relèvent de l’architecture plus souvent qu’on ne le pense. Le cycle de vie de commande ci-dessous est partagé par plusieurs services : le service des commandes en est propriétaire, les services d’affectation et de notifications réagissent à ses transitions, et le personnel du support peut en déclencher certaines. S’accorder sur les états et les transitions autorisées, dans un seul diagramme, évite toute une catégorie de bugs dans lesquels un service pense qu’une commande est annulée alors qu’un autre lui affecte un livreur. Le diagramme fait aussi apparaître des questions que le texte cache : une commande peut-elle être annulée une fois en cours de livraison ? (Ici, non : il n’existe aucune transition de cet état vers Annulée.) Un remboursement est-il une action sur une transition ou un cycle de vie distinct ?

Diagrammes d’activité : flux de travail et parallélisme

Un diagramme d’activité est un organigramme à la sémantique précise. Les rectangles aux coins arrondis sont des actions ; les losanges sont des décisions (avec des gardes sur les flux sortants) et des fusions ; les barres épaisses sont des bifurcations, qui divisent un flux en flux parallèles, et des jonctions, qui attendent tous les flux entrants avant de continuer. Les partitions, souvent appelées couloirs (swimlanes), montrent qui ou quoi exécute chaque action. Une boucle doit repasser par un losange de fusion : deux flux dessinés directement vers une même action signifieraient que l’action attend les deux, comme une jonction.

Les architectes utilisent les diagrammes d’activité pour les processus métier et les flux de travail qui couvrent plusieurs parties d’un système, en particulier lorsque le parallélisme et les responsabilités comptent. L’exemple montre que la préparation du repas et l’affectation d’un livreur se déroulent en parallèle, que l’affectation boucle jusqu’à ce qu’un livreur accepte, et que la remise attend les deux. Cela soulève immédiatement une question d’architecture : que se passe-t-il si aucun livreur n’accepte dans les vingt minutes alors que le repas est prêt ? Le diagramme rend la lacune visible ; la réponse pourrait être une transition de délai d’expiration (timeout), une étape de compensation ou une modification du cycle de vie de la commande. Les flux de travail de longue durée de ce type sont souvent implémentés sous forme de sagas ou de workflows orchestrés, traités au chapitre 6.

Diagrammes de classes, avec parcimonie : le modèle de domaine

Le diagramme de classes est le diagramme UML le plus connu, et celui que les architectes devraient utiliser avec le plus de parcimonie. Dessiner à la main chaque classe d’un service, c’est le mode plan détaillé sous sa forme la moins utile : le diagramme est périmé en quelques semaines, et le code dit la même chose plus précisément. Là où les diagrammes de classes méritent leur place, c’est pour le modèle de domaine : un petit diagramme des concepts métier clés, de leurs attributs et de leurs relations, dont les développeurs, les chefs de produit et les experts du domaine peuvent discuter ensemble. Dans les termes de la conception pilotée par le domaine (chapitre 5), il capture le langage omniprésent d’un contexte délimité.

L’essentiel tient en peu de choses. Une boîte de classe a un nom, des attributs et éventuellement des opérations. Une ligne simple est une association, éventuellement nommée, avec des multiplicités à chaque extrémité (1, 0..1, 0..*, 1..*). Un losange plein marque une composition : les parties appartiennent à exactement un tout et ne lui survivent pas, comme les lignes de commande appartiennent à une commande. Un triangle creux marque une généralisation (héritage) et une ligne en pointillés à pointe ouverte une dépendance. Les multiplicités portent de vraies décisions de conception : Order 1 to 0..1 Delivery dit qu’une commande a au plus une livraison, ce qui exclut de répartir une grosse commande entre deux livreurs. Si le métier pouvait vouloir cela, c’est sur le diagramme que la question apparaît.

Quand UML est excessif, et quand la précision compte

UML est excessif quand le public ne le connaît pas et que la question n’en a pas besoin : un diagramme de contexte C4 communique mieux avec des dirigeants qu’un diagramme de cas d’utilisation UML, et un croquis au tableau blanc est l’outil qui convient pour une discussion de conception qui sera terminée en une heure. Il est excessif quand on maintient à la main des diagrammes qui pourraient être générés, et quand on impose une notation stricte dans un croquis dont le but est d’explorer. L’observation de Fowler, selon laquelle la précision ajoutée dans UML 2 sert surtout les utilisateurs des modes plan détaillé et langage de programmation et alourdit la tâche de ceux qui font des croquis, reste valable.

La précision paie quand un malentendu coûte cher. Les interfaces entre entreprises en sont le cas le plus clair : quand l’entreprise de livraison de repas s’intègre à un prestataire de paiement ou au système de commande d’une grande chaîne de restaurants, chaque partie développe à partir de la description de l’autre et ne découvre les incohérences qu’en test ou en production. Un diagramme de séquence précis du flux de paiement, avec les délais d’expiration (timeouts), les nouvelles tentatives, les clés d’idempotence et les webhooks, joint à la spécification d’interface, est une assurance peu coûteuse. Les secteurs réglementés et critiques pour la sûreté (dispositifs médicaux, ferroviaire, aéronautique, automobile, certains systèmes financiers) exigent souvent une documentation de conception que les auditeurs peuvent suivre des exigences jusqu’à l’implémentation ; l’UML formel, ou son cousin d’ingénierie système SysML, y est courant. Les règles de concurrence et de cycle de vie partagées par plusieurs équipes, comme les états de commande ci-dessus, profitent d’une notation qui oblige à énoncer chaque transition. Enfin, le développement externalisé ou distribué, où les personnes qui implémentent une conception ne peuvent pas facilement interroger son auteur, a besoin de descriptions qui laissent moins de place à l’interprétation.