Diagramme de déploiement UML : Mappage du logiciel sur l’infrastructure

Alors que Diagrammes de composants se concentrent sur l’organisation logique de vos modules de code, le Diagramme de déploiement UML comble le fossé avec la réalité. Il répond à la question cruciale : « Où ce code réside-t-il réellement ? »

Ce diagramme est le seul modèle UML dédié à l’environnement d’exécution physique. Il visualise le mappage des artefacts logiciels sur des cibles matérielles, illustrant comment les composants du système sont répartis sur des serveurs, des bases de données, des appareils mobiles et des infrastructures cloud. À l’ère du cloud computing, des microservices et de l’Internet des objets, comprendre cette architecture physique est plus crucial que jamais.

L’anatomie de l’architecture physique

Le but principal d’un Diagramme de déploiement est de montrer la topologie physique du système — le matériel (nœuds) et le logiciel (artefacts) qui s’exécutent dessus.

1. Nœuds : Le matériel et les environnements d’exécution

Le bloc de construction fondamental d’un diagramme de déploiement est le nœud. Les nœuds représentent des ressources informatiques où les artefacts sont déployés pour être exécutés. Ils sont représentés par des boîtes en 3D (cubes).

Les nœuds se présentent sous deux formes principales :

• Nœuds de périphériques : Ceux-ci représentent des ressources matérielles physiques dotées de capacités de traitement.

  • Exemples : Un serveur d’applications, un serveur de base de données, un téléphone mobile, un capteur IoT ou un équilibreur de charge.

• Nœuds d’environnement d’exécution (environnements d’exécution) : Ceux-ci sont des conteneurs basés sur logiciel qui s’exécutent dans un nœud de périphérique et hébergent des types spécifiques d’artefacts. Ils représentent la couche logicielle qui gère les composants déployés.

  • Exemples : Un machine virtuelle Java (JVM), un CLR .NET, un conteneur Docker ou une instance de navigateur web.

2. Artefacts : Le logiciel déployable

Un artefact représente la manifestation physique concrète d’un composant logiciel. Alors qu’un « composant » est un regroupement logique de classes, un « artefact » est le fichier réel qui est installé sur le serveur.

Les artefacts sont généralement représentés par un rectangle avec le mot-clé«artefact»ou par une petite icône de document dans le coin. Ils sont souvent placésà l’intérieurdu nœud pour indiquer où ils sont déployés.

• Exemples : user-service.jar, index.html, database-schema.sql, config.xml, ou payment-api.exe.

3. Chemins de communication : les connexions

Les nœuds rares fois fonctionnent de manière isolée.Chemins de communicationreprésentent les connexions physiques ou les associations entre nœuds, montrant comment ils échangent des informations.

Ils sont dessinés sous forme de lignes pleines reliant deux nœuds. De façon cruciale, ils sont souvent étiquetés avec des stéréotypes pour indiquer le protocole de communication ou le type de réseau utilisé.

• Exemples : «HTTP/HTTPS», «TCP/IP», «JDBC», «RMI», ou «File d'attente de messages».

Visualisation de la topologie

Un diagramme de déploiement typique raconte une histoire de la structure d’exécution du système. Par exemple, une application web classique en trois niveaux pourrait être visualisée comme suit :

1. Niveau client : Un Appareil mobile (nœud) contenant un Application mobile (artefact).

2. Niveau intermédiaire : Un Serveur web (nœud matériel) hébergeant un Conteneur Docker (environnement d’exécution), qui à l’intérieur contient le API Service.jar (artefact).

3. Niveau données : Un Serveur de base de données (nœud matériel) hébergeant un PostgreSQL instance (environnement d’exécution), qui gère le Données utilisateur (artefact).

Relier ces nœuds serait fait à l’aide de lignes étiquetées «HTTPS» (entre l’appareil mobile et le serveur web) et «JDBC» (entre le serveur Web et la base de données).

Pourquoi utiliser un diagramme de déploiement ?

Les diagrammes de déploiement sont indispensables pour les ingénieurs DevOps, les architectes système et les administrateurs réseau.

• Planification du déploiement : Ils servent de carte définitive pour la gestion des versions, en précisant exactement quels fichiers doivent être envoyés sur quels serveurs.

• Analyse des performances : En visualisant la répartition du traitement et les liens réseau, les architectes peuvent identifier les goulets d’étranglement potentiels (par exemple, trop de composants sur un nœud à faible puissance ou des liens réseau lents entre des services très interactifs).

• Modélisation de la sécurité : Ils aident à identifier les risques de sécurité en mettant en évidence quels nœuds sont exposés aux réseaux externes (internet public) et quels autres sont isolés derrière des pare-feu.

• Conception de l’infrastructure comme code (IaC) : Dans les pratiques DevOps modernes, ces diagrammes fournissent le canevas conceptuel pour écrire des scripts Terraform ou CloudFormation afin de provisionner des ressources cloud.

Pour plus d’informations sur UML et la visualisation assistée par l’IA, consultez notre centre de ressources UML.

Cette publication est également disponible en Deutsch, English, Español, فارسی, Bahasa Indonesia, Portuguese, Việt Nam, 简体中文 : liste des langues séparées par une virgule, 繁體中文 : dernière langue.