Diagrammes de déploiement UML

Un diagramme de déploiement fait correspondre le logiciel au matériel. C'est le seul diagramme UML qui parle du monde physique - machines, conteneurs, liens réseau - et il répond à une question à laquelle aucun autre ne répond : si cette boîte brûle, qu'est-ce qui cesse de fonctionner ?

C'est aussi le diagramme que réclamera le plus probablement quelqu'un qui n'écrit pas de code. Les revues de sécurité, les plans de reprise après sinistre, les questions de localisation des données et les discussions de coût commencent toutes par « où est-ce que ça tourne, au juste, et qui parle à qui ».

Les diagrammes de déploiement pourrissent plus vite que tous les autres, parce que l'infrastructure change chaque semaine et pas les diagrammes. La façon d'en garder un utile est de le dessiner à la hauteur qui change lentement.

Dessinez la topologie, pas l'inventaire. « Cluster Kubernetes » restera vrai des années. « Trois instances m5.large en eu-central-1b » sera faux au trimestre prochain et appartient au dépôt d'infrastructure as code, le seul endroit où cela peut être juste.

Étiquetez les liens. Un trait qui ne dit rien ne vaut presque rien ; un trait qui dit TCP 5432, HTTPS ou AMQP over TLS est la raison pour laquelle un auditeur sécurité lit le diagramme. Idem pour les frontières de confiance : si un lien quitte votre réseau pour celui de quelqu'un d'autre, dites-le.

Dessinez la multiplicité là où elle compte. Un nœud peut porter une multiplicité comme une classe. Écrire 1..* sur le nœud applicatif et 1 sur la base dit quelque chose de réel sur les modes de défaillance du système.

1. Des chemins de communication non étiquetés.Le protocole et le port sont le contenu. Sans eux, un trait dit seulement « ceux-ci sont connectés ».
2. Des composants dessinés là où vont les artefacts. Les nœuds hébergent des fichiers. Mettez checkout.jar sur le nœud et laissez Checkout au diagramme de composants.
3. Un détail d'instance qui ne peut pas rester vrai. Les noms d'hôtes et les tailles d'instances vont dans le code, pas dans un diagramme.
4. Aucune frontière de confiance. Si certains nœuds sont à vous et d'autres à un tiers, cette distinction est souvent la chose la plus importante de la page.
5. Un diagramme par environnement. Dessinez la production. Notez les écarts dans le texte ; ne dessinez pas quatre diagrammes presque identiques qui vont diverger.