Diagrammes de composants UML

Un diagramme de composants décrit un système comme un ensemble de pièces remplaçables. Un composant en UML n'est pas n'importe quelle classe : c'est une unité à frontière définie qui pourrait, en principe, être échangée contre une autre implémentation des mêmes contrats sans que rien autour ne s'en aperçoive.

Toute la valeur est dans cette définition. Le diagramme vous force à noter, pour chaque pièce, exactement deux choses : ce qu'elle fournit et ce qu'elle requiert. Ces deux listes sont le contrat de la pièce avec le reste du système, et c'est précisément ce dont vous avez besoin pour planifier une migration, cadrer une réécriture ou décider si une frontière de service est au bon endroit.

La forme boule et douille (ball and socket) est la forme compacte et celle que la plupart des outils tracent par défaut : une sucette qui sort d'un composant est une interface qu'il fournit, une demi-coupe une interface qu'il requiert, et une boule posée dans une douille, les deux branchées ensemble. C'est la même information que les flèches ci-dessus, en moins de place. Prenez celle que vos lecteurs déchiffrent le plus facilement ; restez cohérent au sein d'un diagramme.

Toutes les marques que ce type de diagramme peut porter - les deux notations d'interface, les connecteurs d'assemblage et de délégation, les ports et les quatre stéréotypes qui valent la peine - sont exposées dans les symboles du diagramme de composants.

C'est la question sur laquelle bute tout premier diagramme de composants, et la spécification n'aide pas : UML dit qu'un composant est une unité remplaçable dotée d'un contrat défini et vous laisse entièrement la taille. Bonne réponse pour une norme, inutile devant un tableau blanc ; voici donc la règle de travail.

Un composant, c'est ce que vous pourriez mettre en appel d'offres. Si vous pouvez imaginer tendre à une autre équipe les listes d'interfaces fournies et requises en disant « construisez ça, nous ne regarderons pas dedans », c'est un composant. Si cette remise exigeait une conversation sur les entrailles, la frontière est au mauvais endroit - et c'est là le constat, pas un problème de dessin à contourner.

En pratique cela tombe le plus souvent sur l'un de ces niveaux, et lequel vous dit à quoi sert le diagramme.

• Un service déployable. Un dépôt, un pipeline, une astreinte. La réponse la plus courante pour tout ce qui a été construit ces dix dernières années, et le niveau auquel il vaut la peine de garder le diagramme dans le dépôt.
• Une bibliothèque ou un module. À l'intérieur d'un déployable, quand le débat porte sur la structure interne - quel paquet peut dépendre de quel. Là, un diagramme de paquets dit souvent la même chose à moindre coût.
• Un système entier. Le mainframe, le CRM, le prestataire de paiement. Le niveau du diagramme de contexte, où l'enjeu est ce dont vous dépendez et non la façon dont c'est construit.

Mélanger deux de ces niveaux sur un même diagramme est l'erreur qui produit les diagrammes de composants tentaculaires dont les gens se souviennent. Une image avec trois microservices, une bibliothèque utilitaire et « SAP » dessus, ce sont trois diagrammes superposés, et aucun lecteur ne peut dire quelles boîtes sont des pairs.

La technique de lecture la plus utile consiste à couvrir un composant avec la main. Ce qui reste est son contrat : les interfaces qui y étaient attachées. Si vous pouvez tendre cette liste à une autre équipe en disant « construisez quelque chose qui satisfait ça », le diagramme fait son travail. Sinon - si remplacer le composant exigeait de connaître des choses non dessinées - la frontière est au mauvais endroit, et cela vaut la peine de le savoir avant que quelqu'un n'essaie.

La deuxième technique consiste à suivre les interfaces requises. Chacune est une dépendance que quelqu'un doit satisfaire, et un cycle dans ce graphe est un vrai problème d'architecture qu'un diagramme de composants rend immédiatement visible.

Les deux techniques se voient mieux appliquées que décrites. Cinq diagrammes de systèmes sur lesquels vous avez probablement travaillé - un catalogue partagé, ports et adaptateurs, le remplacement d'un système hérité, un hôte de plugins et un cycle - sont parcourus dans les exemples de diagrammes de composants, chacun avec la question qu'il tranche.

Cinq types de diagrammes sont des rectangles reliés par des traits, et toute la différence tient à ce qu'est un rectangle. Se tromper de type est l'erreur la plus coûteuse disponible ici, car le diagramme aura l'air correct et répondra à une question que personne n'a posée.

La question qui revient le plus est composants contre déploiement, et la séparation est nette une fois énoncée : un composant est une unité logique et un nœud une unité physique. Un composant peut tourner sur quarante nœuds ; un nœud peut héberger une douzaine de composants. Dès qu'une boîte de votre diagramme de composants acquiert une région, un nombre d'instances ou un nom d'hôte, elle a cessé d'être un composant et le diagramme est discrètement devenu deux.

Si vous connaissez C4, son diagramme de conteneurs se situe presque exactement là où un diagramme de composants au niveau du service déployable, et son propre niveau « composant » est un cran plus profond que ce qu'UML entend d'ordinaire. Les vocabulaires ne s'alignent pas : indiquez sur le diagramme lequel vous utilisez, cette ligne de légende évite la plupart des disputes.

Les diagrammes de composants vieillissent bien, ce qui est rare. Les interfaces changent beaucoup plus lentement que le code derrière, si bien qu'un diagramme de composants versionné reste vrai bien plus longtemps qu'un diagramme de classes du même système - et mérite d'autant plus d'être maintenu.

1. Des composants qui sont en réalité des classes. Si cela ne peut pas plausiblement être remplacé indépendamment, ce n'est pas un composant. Utilisez un diagramme de classes.
2. Seules les interfaces fournies dessinées. Les requises portent l'information de dépendance, qui est la moitié la plus utile.
3. Des flèches entre composants sans interface. Une flèche nue dit « dépend d'une manière ou d'une autre », ce que ce diagramme existe précisément pour préciser.
4. Mélanger du déploiement. Serveurs, régions et conteneurs appartiennent à un diagramme de déploiement.
5. Des interfaces nommées d'après le fournisseur. ILedger convient tant qu'il n'y a qu'un grand livre ; dès qu'il peut y avoir deux implémentations, nommez le contrat d'après la capacité, pas d'après le fournisseur actuel.