Exemples de diagrammes de composants

Chaque diagramme ci-dessous emploie les trois mêmes marques, et si vous savez les lire vous savez lire les cinq : un composant est une boîte à icône de prise, une «interface» est une boîte nommant un contrat, et les flèches disent de quel côté de ce contrat se trouve chaque composant. Une flèche en tirets à triangle creux signifie j'implémente ceci. Une flèche en tirets simple signifie j'ai besoin de ceci. Le jeu complet est dans les symboles du diagramme de composants, et le raisonnement derrière la notation dans le guide du diagramme de composants.

Ils sont classés par fréquence d'apparition de la forme plutôt que par complexité. Chacun nomme la question qu'il tranche, car un diagramme de composants qui ne tranche rien est le genre le plus répandu et le moins utile : cinq boîtes, cinq flèches, et aucune affirmation avec laquelle on puisse être en désaccord.

La figure en tête de cet article. Une vitrine web et une application mobile ont toutes deux besoin de données produit ; un service de catalogue les fournit. L'interface est dessinée une fois, entre les deux.

Cette seule boîte est tout l'intérêt de l'exemple. Avant qu'elle existe, les deux clients avaient deux idées différentes de ce que renvoie « le catalogue », et la différence vivait dans celui qui avait été écrit en second. Nommer ICatalog force la question de ce qu'est réellement le contrat, et une fois nommé, une modification de celui-ci est visiblement une modification pour deux consommateurs plutôt qu'une retouche d'un service.

Lisez les flèches et remarquez ce que le coeur de commande ne touche pas. Il ne dépend pas de HTTP et il ne dépend pas de PostgreSQL. Il réalise un contrat et en requiert un autre, et les deux sont des boîtes que n'importe qui aurait pu lui tendre.

C'est la forme que les gens désignent par architecture hexagonale, ports et adaptateurs ou clean architecture, et un diagramme de composants est le moyen le moins coûteux de vérifier si une base de code l'a réellement. Si la boîte du coeur a une flèche pointant vers un composant de base de données plutôt que vers une interface, le motif est un souhait : quelque chose au milieu importe le pilote.

C'est le diagramme à dessiner avant un remplacement, pas après. L'affirmation qu'il porte est précise et testable : tout ce dont le service de commandes a besoin de la facturation est dans IBilling, donc une seconde implémentation de cette interface peut être substituée sans que le service de commandes change.

C'est aussi le moyen le plus rapide de découvrir que l'affirmation est fausse. Si quelqu'un dit « le nouveau service ne sait pas produire les relevés PDF », alors les relevés PDF faisaient partie du contrat et manquent à l'interface, et le diagramme était faux avant la migration. Cette conversation coûte dix minutes au tableau et trois mois en production.

Une fois l'ancienne implémentation partie, supprimez-la du diagramme. Un diagramme de composants qui montre encore le mainframe deux ans après son extinction est la raison pour laquelle les gens cessent de faire confiance aux diagrammes.

Topologiquement, c'est l'exemple trois avec une troisième implémentation, et cette ressemblance mérite qu'on s'y arrête : remplaçabilité et extensibilité sont le même dessin. Ce qui diffère, c'est l'intention. Dans une migration, la réalisation supplémentaire est temporaire ; dans une architecture à greffons, elle est le produit.

La technique de lecture qui paie ici est de masquer la colonne de droite avec la main. Ce qui reste - l'hôte et IExporter- est tout ce qu'un auteur de quatrième exportateur a besoin de savoir. Si la réponse à « puis-je écrire mon propre exportateur ? » exige de lire le source de l'hôte, l'interface est sous-spécifiée, et le diagramme vient de vous le dire.

Deux services, chacun réalisant un contrat dont l'autre a besoin. Rien ici n'est de l'UML illégal et rien sur le diagramme n'est faux - le dessin est une image exacte d'un système qui va être difficile, et c'est précisément ce qu'on veut qu'un diagramme sache dire.

Un cycle entre composants signifie qu'aucun ne peut être compris seul : pas de déploiement indépendant, pas de test en isolation sans un bouchon de l'autre, et le remplacement de l'un doit satisfaire un contrat dont l'autre dépend simultanément. Sur un diagramme de classes, un cycle est une odeur ; entre unités déployables, c'est un risque de planning.

Les correctifs habituels sont visibles sur la même image. Déplacez ce dont Shipping a besoin depuis IOrders vers un événement publié par le service Orders, afin que la flèche devienne à sens unique. Ou extrayez la partie commune dans un troisième composant dont les deux dépendent, ce qui transforme le cycle en convergence et vous ramène à l'exemple un.

Pour en dessiner un contre votre propre système, la version pas à pas est dans comment dessiner un diagramme de composants. Pour l'endroit où ces composants tournent plutôt que pour ce qu'ils se promettent, c'est un diagramme de déploiement.