Qu’est-ce qu’un diagramme de séquence ?
Un diagramme de séquence est un diagramme comportemental diagramme UML qui détaille comment les opérations logicielles sont effectuées au fil du temps. En tant que standard fondamental de la spécification du langage de modélisation unifié (UML), il modélise l’ordre chronologique précis selon lequel les objets, processus ou microservices échangent des messages. En représentant les lignes de vie verticalement et les interactions séquentielles horizontalement, ce type spécifique type de diagramme UML permet aux ingénieurs logiciels et aux architectes système de visualiser clairement des séquences complexes d’appels d’API, des échanges de données réseau et des limites des transactions de base de données avant d’écrire du code de production.
Avec VPasCode, vous n’avez pas à passer des heures à aligner des flèches parallèles, à allonger les lignes de message ou à déplacer les boîtes englobantes pour faire de la place à une nouvelle étape. Notre moteur de mise en page calcule dynamiquement toute la grille temporelle au fur et à mesure que vous tapez vos scripts déclaratifs en texte brut.
Guide de syntaxe fondamentale : éléments et constructions
Pour concevoir un diagramme de séquence UML fonctionnel et conforme aux normes dans PlantUML, vous devez maîtriser les déclarations de composants, les styles des flèches de message, les lignes de vie et les structures de contrôle logiques.
1. Déclarer les participants UML et leurs formes
Par défaut, les composants de ce diagramme UML héritent d’une forme de boîte carrée standard. Toutefois, vous pouvez modifier l’archétype visuel de vos entités afin de donner aux lecteurs un contexte architectural immédiat sur les limites de votre système en utilisant des mots-clés UML spécifiques :
acteur Client
borne "Passerelle API" comme Passerelle
contrôle Contrôleur
données "PostgreSQL" comme DB
2. Flèches de message et synchronicité
Le style de vos lignes et têtes de flèches établit le protocole de communication exact qui a lieu à travers vos pipelines d’infrastructure selon les normes des diagrammes UML :
- Demande synchrone (bloquante) : Indiqué par une ligne pleine et une tête de flèche pleine. L’expéditeur attend une réponse :
A -> B - Message asynchrone (non bloquant) : Indiqué par une ligne pleine et une tête de flèche ouverte fine. L’expéditeur transmet les données et poursuit immédiatement :
A ->> B - Réponse / Valeur de retour : Indiqué par une ligne pointillée et une tête de flèche ouverte :
B --> A
3. Gestion des lignes de vie (activation et désactivation)
Pour éviter que vos composants n’aient l’air de barres plates, vous devez montrer explicitement quand un processus consomme activement des threads CPU ou une capacité de mémoire. Utilisez les marqueurs activer et désactiver marqueurs, ou utilisez la syntaxe raccourcie d’incrémentation en ligne (++ / --):
Passerelle -> Contrôleur ++ : "processPayment()"
Contrôleur --> Passerelle -- : "retourner reçu"
4. Blocs logiques : alternatives, boucles et parallèles
La logique métier complexe (telles que les branches if/else, les nouvelles tentatives sur la base de données ou les threads d’exécution parallèles) doit être encapsulée dans des limites de cadre global structurées appelées fragments combinés dans la spécification du diagramme UML :
- Logique conditionnelle (alt / else) : Modélise les branches conditionnelles.
Plantuml Edit Plantuml in VPasCode
alt condition réussie A -> B : "Continuer la demande" sinon état d'erreur A -> B : "Lancer le code d'erreur" fin
- Boucles de répétition (loop) : Modélise les itérations, les nouvelles tentatives ou les blocs de traitement de file d’attente jusqu’à ce qu’une condition soit satisfaite.
Plantuml Edit Plantuml in VPasCode
boucle jusqu'à ce que la file d'attente soit vide Travailleur -> File d'attente : "Récupérer la tâche suivante" fin
- Exécutions parallèles (par) : Les modèles séparent les opérations s’exécutant simultanément sur des threads indépendants.
Plantuml Edit Plantuml in VPasCode
par Exécuter des processus parallèles A -> ServiceDeJournalisation : "Écrire les analyses de traçage" sinon A -> BD : "Valider les données du profil client" fin
Meilleures pratiques pour des séquences propres
- Regrouper les messages à l’aide de séparateurs : Utilisez deux signes égal (“
== Votre phase ==) pour diviser une séquence massive d’authentification à paiement en étapes logiques distinctes. - Utilisez le numérotage automatique : Placez la directive
autonumberdirectement sous@startuml. Cela force l’environnement de travail à insérer des entiers d’étape sur chaque flèche, rendant les revues de code beaucoup plus faciles. - Gardez les réponses propres : Évitez d’écrire de longues phrases descriptives sur les flèches de retour (
-->). Au lieu de cela, indiquez simplement quel objet de données brut ou code HTTP revient (par exemple,"201 Créé Jeton").
Exemples réels de diagrammes de séquence PlantUML
Exemple 1 : Boucle d’authentification de microservice (blocs Alt et lignes de vie)
Ce squelette gère une séquence de sécurité standard où un client s’authentifie auprès d’une passerelle, mettant en évidence des lignes de vie explicites et un cadre de résultat conditionnel alternatif dans un format de diagramme UML standard.
@startuml
autonumber
acteur Utilisateur
borne "Application Web" comme App
contrôle "Service d'authentification" comme Auth
Utilisateur -> App ++ : "Soumettre les identifiants"
App -> Auth ++ : "POST /v1/auth"
alt #LightGreen Connexion réussie
Auth --> App : "200 OK (Jeton JWT)"
App --> Utilisateur : "Afficher le tableau de bord"
sinon #LightPink Identifiants invalides
Auth --> App : "401 Non autorisé"
App --> Utilisateur : "Afficher une notification d'erreur"
fin
désactiver Auth
désactiver App
@enduml
Analyse syntaxique : Le autonumber balise gère automatiquement les numéros de 1 à 5. Le alt et sinon blocs sont complétés par des drapeaux de couleur hexadécimale personnalisés (par exemple, #LightGreen) pour ajouter une mise en évidence visuelle immédiate des chemins d’exécution réussis par rapport aux échecs. Le ++ jetons assure que les lignes de vie restent actives pendant le bloc d’appel réseau.
Exemple 2 : Traitement avancé des commandes (boucles, parallèles et séparateurs)
Ce canevas d’architecture d’entreprise modélise un système de paiement robuste qui répartit les tâches entre des travailleurs parallèles, exécute des écritures dans la base de données et dépend d’une boucle de synchronisation avec un système externe.
@startuml
autonumber
borne "API de paiement" comme API
database "Base de données des commandes" comme DB
contrôle "File d'attente des travailleurs" comme Queue
borne "Stripe" comme Stripe
== Phase 1 : Validation du registre des transactions ==
API -> DB ++ : "Écrire la commande en attente"
DB --> API -- : "ID de commande confirmé"
== Phase 2 : Paiement et traitement asynchrone ==
API -> Stripe ++ : "Facturer le compte client"
Stripe --> API -- : "Paiement autorisé"
par Opérations en arrière-plan parallèles
API -> Queue ++ : "Publier l'événement 'Order_Placed'"
désactiver Queue
sinon
API -> DB ++ : "Mettre à jour l'état en 'Payé'"
désactiver DB
fin
boucle Tentatives jusqu'à 3 fois en cas d'échec réseau
API -> API : "Ping du webhook de synchronisation des notifications"
fin
API --> Client : "Retourner HTTP 200 (Succès)"
@enduml
Analyse syntaxique : Le == les séparateurs divisent la mise en page en phases opérationnelles distinctes. Le par bloc sépare proprement le chemin de la flèche de message en deux chemins horizontaux distincts, illustrant que la publication d’événements et les mises à jour d’état de la base de données se produisent simultanément sans se bloquer mutuellement. La flèche auto-référente (API -> API) représente parfaitement une boucle de fonction interne locale.