Diagramme de séquence UML : Visualisation du temps et des interactions

Le diagramme de séquence UML est un outil essentiel pour comprendre le comportement dynamique d’un système. Il modélise la manière dont les objets interagissent entre eux et l’ordre dans lequel ces interactions ont lieu, en mettant l’accent sur leflux ordonné des messages. Il est essentiel pour définir les cas d’utilisation, documenter les appels d’API et suivre les flux de transactions complexes.

Ce tutoriel vous guidera à travers les éléments fondamentaux et les techniques de modélisation du diagramme de séquence.

Structure et objectif fondamentaux

Un diagramme de séquence est organisé selon deux axes :

1. Axe horizontal :Montre les participantsobjets (ou acteurs, classes et composants).
2. Axe vertical (axe du temps) :Représente l’écoulement du temps, en descendant. Les messages envoyés plus bas sur le diagramme ont lieu plus tard dans la séquence.

Le but est de répondre à la question :« Dans ce scénario spécifique (cas d’utilisation), dans quel ordre ces objets échangent-ils des informations pour atteindre le résultat souhaité ? »

Éléments fondamentaux d’un diagramme de séquence

Pour modéliser une séquence, vous avez besoin de trois éléments fondamentaux : les lignes de vie, les messages et les barres d’activation.

A. Lignes de vie (participants)

Une ligne de vie représente un participant unique — un objet, une instance ou une classe — dans l’interaction.

• Notation :Une boîte rectangulaire en haut du diagramme contenant le nom de l’objet, avec une ligne pointillée verticale s’étendant vers le bas.
• Syntaxe :
  • NomParticipant (si l’objet est une instance, par exempleutilisateur)
  • NomInstance : NomClasse (par exempleauthService : AuthenticationService)
• But : La ligne pointillée indique l’existence du participant au fil du temps dans le cadre de la séquence.

B. Messages (Interaction)

Les messages sont les flèches horizontales tracées entre les lignes de vie. Ils représentent la communication entre objets, telles que les appels de méthode, les signaux ou les requêtes API.

Types de messages :

Type de message	Notation	Description
Appel synchrone	Ligne pleine avec une flèche remplie	L’expéditeur attend une réponse avant de continuer. Cela déclenche un Barre d’activation sur la ligne de vie du destinataire.
Réponse/Retour	Ligne pointillée avec une flèche ouverte	La réponse à un appel synchrone, indiquant le retour du contrôle à l’expéditeur. Cela ferme généralement la barre d’activation.
Message asynchrone	Ligne pleine avec une flèche ouverte	L’expéditeur n’attend pas de réponse et continue son exécution immédiatement. Courant dans les architectures orientées événements.
Appel auto	Flèche qui revient sur la même ligne de vie	Un objet appelant l’une de ses propres méthodes.
Message trouvé	Flèche partant d’une extrémité et touchant une ligne de vie	L’expéditeur du message est inconnu ou hors du cadre du diagramme (par exemple, un déclencheur externe).

C. Barres d’activation (spécification d’exécution)

La barre d’activation (appelée aussi focus de contrôle) est un mince rectangle vertical tracé au-dessus d’une ligne de vie.

• Notation : Un rectangle vertical plein sur une ligne de vie.
• But : Il désigne la période pendant laquelle un objet effectue activement une opération (c’est-à-dire que sa méthode est en cours d’exécution) ou attend une réponse synchrone. Il commence lorsque un message synchrone est reçu et se termine lorsque le message de réponse est envoyé.

Modélisation de la logique et du flux de contrôle

Pour modéliser une logique métier complexe, vous utilisez des fragments (ou des boîtes) pour encadrer des sections du diagramme.

A. Fragments combinés

Les fragments combinés vous permettent de modéliser la logique conditionnelle, la répétition et les étapes facultatives. Les fragments les plus courants incluent :

1. Alternatif (alt) : Utilisé pour si-sinon logique. Le fragment est divisé par une ligne pointillée, et chaque section inclut une condition (un « gardien ») entre crochets. Un seul chemin peut être emprunté.
   • Exemple : [si les identifiants de l'utilisateur sont valides] et [sinon / identifiants invalides].
2. Optionnel (opt) : Utilisé pour un si instruction. L’interaction à l’intérieur du fragment est facultative et s’exécute uniquement si la condition (gardien) est vraie.
   • Exemple : [si l'utilisateur a des articles dans son panier].
3. Boucle (loop) : Utilisé pour la répétition. Le gardien spécifie la condition d’itération (par exemple, [pour chaque article] ou [tant que (tentatives < 3)]).
4. Référence (ref) : Utilisé pour modulariser le diagramme en faisant référence à une séquence d’interaction définie dans un autre diagramme de séquence distinct. Cela empêche les diagrammes de devenir trop encombrés.
5. Critique (crit) : Utilisé pour indiquer une section qui ne doit pas être interrompue, souvent utilisé pour modéliser des processus concurrents.

Exemple de modélisation étape par étape

Modélisons un processus simplifiéProcessus de paiement de l’utilisateur en utilisant les éléments principaux :

Étape	Action	Type de message
1.	L’utilisateur clique sur « Paiement ».	Appel synchrone
2.	Le frontend valide le panier.	Appel auto (sur le frontend)
3.	Le frontend demande le traitement du paiement.	Appel synchrone
4.	La passerelle de paiement vérifie les fonds.	Appel synchrone
5.	La passerelle de paiement retourne « Succès ».	Message de retour
6.	Le frontend envoie un message asynchrone au service Inventaire pour réduire le stock.	Message asynchrone
7.	Le frontend envoie un message synchrone au service Commande pour finaliser la commande.	Appel synchrone
8.	Le service de commande retourne « ID de commande ».	Message de retour
9.	Le frontend affiche une page de confirmation.	Message de retour (à l’utilisateur)

Modélisation de la logique (fragment alternatif)

Pour gérer l’échec, nous utilisons unAlternatif fragment :

1. Placez leVérification de la passerelle de paiement (étape 4 et 5) à l’intérieur d’unalt fragment.
2. La première section est protégée par[Succès]. Cette section contient les étapes 6, 7, 8 et 9.
3. La deuxième section, séparée par une ligne pointillée, est protégée par[Échec]. Cette section contient un nouveau message synchrone :paymentService -> frontend : retourner « Échec du paiement » et le frontend affiche une page d’erreur.

Résumé des bonnes pratiques pour les diagrammes de séquence

• Restez concentré : Un seul diagramme de séquence devrait généralement modéliser un seul cas d’utilisation ou une seule opération atomique (par exemple, « Connexion », « Ajouter un article au panier »). UtilisezFragments de référence pour les sous-processus.
• Libellez clairement les messages : Utilisez des phrases verbales pour les messages, reflétant les noms de méthodes ou les points d’entrée d’API (par exemple,processPayment(montant, jeton)).
• Identifiez correctement les participants : Différenciez entre le Acteur (entité externe) et le Objet (composant ou instance du système interne).
• Le temps coule vers le bas : Assurez-vous que les messages sont ordonnés de manière cohérente du haut vers le bas.
• Utilisez des fragments pour le contrôle : Évitez de dessiner des nœuds de décision complexes ou des boucles à l’intérieur du flux de messages lui-même ; utilisez alt, opt, et loop des fragments.

Pour obtenir plus de détails sur UML et ses méthodes de visualisation pilotées par l’IA, rendez-vous sur notre centre de ressources UML.

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