Diagramme comportemental — Dynamique

Diagramme
de Séquence

Modélise les interactions entre objets dans le temps. Répond à : "Comment les objets collaborent-ils ?"

Rôle du Diagramme

Le diagramme de séquence décrit le comportement dynamique d'un scénario précis : quels objets s'envoient quels messages, dans quel ordre.

L'axe vertical représente le temps (de haut en bas)
L'axe horizontal représente les participants (objets/acteurs)
Idéal pour documenter un cas d'utilisation en détail
Fait le lien entre les diagrammes de classes et de cas d'utilisation
📌

Un diagramme de séquence = un scénario. Pour modéliser plusieurs scénarios, créer plusieurs diagrammes (scénario principal, alternatifs).

:Client :Serveur :Base login(user, pass) verifier(user) ok : bool token : String t1 t2 t3 t

Éléments de Base

ÉlémentNotationDescription
Participant / Lifeline :Classe Rectangle en tête + ligne de vie pointillée vers le bas. Notation : nomObjet:NomClasse
Acteur Bonhomme — utilisateur ou système externe qui initie les interactions
Barre d'activation Rectangle fin sur la lifeline — indique la période pendant laquelle l'objet est actif (exécute du code)
Message synchrone Flèche pleine — l'émetteur attend la réponse avant de continuer
Message asynchrone Flèche ouverte (bâtons) — l'émetteur n'attend pas (ex : notification, event)
Message de retour Pointillés + flèche — valeur de retour d'une méthode (souvent facultatif si évident)
Message de création :Obj Flèche pointillée vers la tête du nouveau participant — «create»
Destruction Croix (×) en bas de la lifeline — l'objet est détruit

Lignes de Vie (Lifelines)

Chaque participant a une ligne de vie : la tête (rectangle) identifie l'objet, la ligne pointillée matérialise son existence dans le temps.

Notation de la tête

NotationSignification
:ClasseObjet anonyme de type Classe
objet:ClasseObjet nommé de type Classe
objetObjet dont la classe n'est pas précisée
:«actor»Acteur (bonhomme)
💡

Le nom est souligné dans la tête pour signifier qu'il s'agit d'une instance (pas d'une classe).

:Utilisateur :Panier p1:Produit acteur anonyme nommé

Types de Messages

Les messages représentent les appels de méthodes ou signaux envoyés entre participants.

TypeFlècheUsage
Synchrone→ pleineAppel de méthode standard — bloquant
Asynchrone→ ouverteEvent, notification — non bloquant
Retour-- - → pointillésValeur retournée après exécution
Création-- - → pointillésInstanciation d'un objet («create»)
Auto-message→ boucleObjet qui s'envoie un message à lui-même
📌

Le message de retour est souvent omis quand la valeur retournée est évidente ou non pertinente pour le scénario.

:A :B methode() self.calc() resultat notifier() ⟶ async sync retour async

Barres d'Activation

Une barre d'activation (rectangle fin) sur une lifeline indique que l'objet est en train d'exécuter du code.

Commence quand l'objet reçoit un message
Se termine quand il renvoie le contrôle à l'appelant
Deux barres superposées = récursion
Facultatives mais recommandées pour la lisibilité
💡

Les barres montrent visuellement qui a le contrôle à chaque instant. Elles rendent les dépendances de contrôle très claires.

:A :B :C operation1() getData() data résultat

Fragments Combinés

Les fragments structurent les interactions pour exprimer conditions, boucles et alternatives.

Fragment
Opérateur
Signification
Alternatif
alt
Branches conditionnelles (if/else) — condition entre [ ]
Optionnel
opt
Exécuté seulement si la condition est vraie (if sans else)
Boucle
loop
Répétition — loop(min, max) ou loop [condition]
Parallèle
par
Interactions concurrentes / parallèles
Critique
critical
Section atomique — ne peut pas être interrompue
Référence
ref
Référence vers un autre diagramme de séquence
Négatif
neg
Représente une interaction invalide ou interdite

Fragment alt

:Client :AuthService login(user, pass) alt [identifiants valides] token : String [identifiants invalides] erreur : String [else]

Fragment loop

:System :Capteur demarrer() loop(1,*) [capteurActif] lireValeur() valeur : float traiter(valeur)

Création & Destruction d'objets

Un objet peut être créé ou détruit pendant le scénario, pas seulement au début.

Création : flèche pointillée vers la tête du nouveau participant, stéréotype «create»
La tête du participant apparaît à la hauteur où il est créé (pas en haut)
Destruction : croix (×) en bas de la lifeline, stéréotype «destroy»
La lifeline s'arrête à la croix
:Factory :Produit «create» initialiser() ok «destroy»

Exemple Complet — Authentification

Scénario complet avec acteur, fragment alt, messages synchrones, retours et fragment opt.

:Utilisateur :InterfaceWeb :AuthController :UserService :Database saisirCredentiels() seConnecter(user, pass) validerIdentite(user, pass) findByUsername() user : User alt [mot de passe valide] token : String token : String rediriger(tableau) [mot de passe invalide] erreur : AuthException erreur : String afficherErreur() opt [loggingActif] loggerTentative(user, ok)

Messages Spéciaux

Message réflexif

Un message qu'un objet s'envoie à lui-même — appel interne, méthode privée ou récursivité. Représenté par une flèche qui revient sur la même lifeline.

Modélise un appel de méthode interne
Génère une activation imbriquée sur la même lifeline
Ex : self.calculerTVA() appelé pendant calculerTotal()
:Commande calculerTVA()

Messages perdus et trouvés

Permettent de modéliser des interactions avec des entités dont on ne représente pas la lifeline complète dans le diagramme.

TypeNotationSignification
Message perdu Envoyé mais destination non représentée
Message trouvé Reçu mais origine non représentée
📌

Ces notations sont utiles pour représenter des interactions avec des systèmes tiers, des événements asynchrones ou des signaux matériels sans alourdir le diagramme avec toutes les lifelines.

Lien avec les Autres Diagrammes

Le diagramme de séquence ne s'utilise pas en isolation — il est le pont entre la structure statique et les besoins fonctionnels.

→ Issu du

Diagramme de Cas d'utilisation

Chaque diagramme de séquence réalise un cas d'utilisation. Le scénario nominal et les scénarios alternatifs deviennent les fragments alt.

↔ Complète le

Diagramme de Classes

Les participants sont des instances des classes. Les messages correspondent aux méthodes. Concevoir un diagramme de séquence révèle souvent des méthodes manquantes dans les classes.

vs Diagramme de

Communication

Le diagramme de communication montre les mêmes interactions mais met l'accent sur les liens entre objets (pas la chronologie). Les messages y sont numérotés. Le diagramme de séquence est préféré car la chronologie est généralement cruciale.

💡

Workflow recommandé : Cas d'utilisation → description textuelle du scénario → Diagramme de séquence → découverte des méthodes → mise à jour du Diagramme de classes. Ce cycle itératif affine les trois diagrammes ensemble.

Quand utiliser ce Diagramme ?

Le diagramme de séquence est particulièrement adapté dans plusieurs contextes.

Analyse des exigences

Illustrer comment les acteurs interagissent avec le système pour valider les besoins fonctionnels avec le client.

Conception détaillée

Spécifier comment les objets collaborent pour implémenter un cas d'utilisation, en mettant en lumière les appels de méthodes.

Documentation

Documenter le comportement dynamique d'un système existant pour faciliter la maintenance et l'onboarding de nouveaux développeurs.

Validation d'architecture

Vérifier que l'architecture logicielle supporte les scénarios fonctionnels, détecter les dépendances problématiques ou les goulots d'étranglement.

Debug & Analyse

Reconstituer un bug en modélisant la séquence d'appels. Identifier où la chaîne se rompt ou quels objets manquent de méthodes.

Génération de tests

Servir de base pour générer automatiquement des cas de tests fonctionnels — chaque fragment alt est un cas de test potentiel.

Erreurs Courantes

Ces pièges sont fréquents et nuisent à la lisibilité ou à l'exactitude du diagramme.

Ne pas respecter la chronologie

Le diagramme se lit de haut en bas. Un message placé plus haut est toujours antérieur. Ne pas respecter cet ordre crée une confusion sur la séquence réelle.

Surcharger un seul diagramme

Trop d'objets ou de messages rendent le diagramme illisible. Règle : 1 diagramme = 1 scénario. Créer plusieurs diagrammes pour les scénarios alternatifs.

Confondre synchrone et asynchrone

Une flèche pleine (→) implique que l'émetteur attend la réponse. Une flèche ouverte (→) signifie qu'il continue sans attendre. Les confondre fausse l'interprétation du comportement.

Omettre les conditions dans les fragments

Un fragment alt sans condition entre crochets est ambigu. Toujours préciser la garde : [solde suffisant], [else].

Ne pas utiliser les fragments combinés

Tenter de représenter des conditions ou boucles sans fragments (avec des commentaires textuels) rend le diagramme non standard et difficile à interpréter.

Oublier la création et destruction

Si un objet est créé ou détruit pendant le scénario, il faut le représenter explicitement. Une lifeline qui commence en haut implique que l'objet existait avant le scénario.

Lire un Diagramme → Coder en Python

Chaque élément du diagramme de séquence correspond à une construction Python.

Élément UMLPython
Participant :ClasseVariable de type Classe
Message objet.methode()Appel de méthode
Message retourValeur de retour return x
Fragment altStructure if / else
Fragment optStructure if condition
Fragment loopBoucle for ou while
«create»obj = Classe()
«destroy»del obj
Message asynchroneThread / async-await

Scénario de connexion traduit

Python
class AuthController:
    def __init__(self):
        self.user_service = UserService()  # «create»

    def se_connecter(self, user, password):
        # validerIdentite(user, pass)
        user_obj = self.user_service.valider(user, password)

        if user_obj:          # alt [valide]
            token = self._generer_token(user_obj)
            return token
        else:               # alt [invalide]
            raise AuthException("Identifiants invalides")

class UserService:
    def valider(self, user, password):
        # findByUsername(user) → Database
        db = Database()
        user_obj = db.find_by_username(user)
        if user_obj and user_obj.check_pass(password):
            return user_obj
        return None

Résumé

📐 Éléments

Rectangleparticipant
— — —lifeline
activation
×destruction

↔ Messages

→ pleinsynchrone
→ ouvertasynchrone
- -→retour
- -→ tête«create»

📦 Fragments

altif / else
optif seul
loopboucle
parparallèle
refréférence

✅ Conseils

1 diag1 scénario
Tempsde haut en bas
Acteurà gauche
Retourspointillés