Diagramme de séquence

1. Choisir un scénario et un niveau de détail

Une séquence représente des échanges entre participants pour un scénario donné. Le temps se lit généralement du haut vers le bas. Les participants sont disposés horizontalement ; cette position ne représente ni une hiérarchie ni une distance physique.

Une séquence système montre un acteur et le système considéré comme une boîte noire. Une séquence de conception ouvre cette boîte : interface, service applicatif, objets métier et dépôts peuvent y apparaître. On évite de mélanger les deux niveaux sans explication.

Pour UC-04, la séquence de conception utilise Client, Portail, ServiceDevis et DepotDevis. Le service coordonne l’opération ; l’objet Devis protège ses règles métier ; le dépôt permet de retrouver et de conserver les données. Ce découpage est une proposition pour l’étude, pas une obligation imposée par UML.

2. Lignes de vie, exécutions et messages

Une ligne de vie identifie un participant puis se prolonge par une ligne verticale discontinue. Une barre d’exécution indique une période pendant laquelle un comportement s’exécute. Sa longueur ne correspond à une durée mesurée que si une échelle ou des contraintes temporelles sont précisées.

Un appel synchrone se termine par une pointe pleine ; l’émetteur attend le retour de l’appel. Un message asynchrone possède une pointe ouverte ; l’émetteur peut continuer sans attendre la fin du traitement demandé. Un retour est généralement représenté par un trait discontinu avec une pointe ouverte. Il peut être omis s’il n’apporte rien à la lecture.

Une flèche dirigée vers la même ligne de vie représente un appel interne au participant. La création fait commencer une ligne de vie au message de création ; la destruction peut être signalée par une croix. On ne détruit pas artificiellement un objet simplement parce qu’un écran est fermé.

3. Déroulement de l’acceptation

1. Le client transmet une confirmation concernant une référence et une version.
2. Le portail appelle ServiceDevis.accepter(reference, clientId).
3. Le service demande au dépôt de charger le devis et les données utiles.
4. Le service contrôle l’accès ; le devis contrôle son statut et sa date de validité.
5. La transaction vérifie l’unicité de la version acceptée et enregistre le changement.
6. Le service renvoie le résultat au portail, qui affiche la confirmation.
7. La notification est programmée après validation de la transaction.

La vérification de R2 et l’enregistrement doivent résister à deux requêtes simultanées. Un simple contrôle effectué longtemps avant l’écriture peut laisser deux confirmations concurrentes passer. Une contrainte adaptée et une transaction cohérente font partie des décisions de conception à documenter.

Le schéma présente le scénario nominal sous forme condensée. Les opérations internes de contrôle et la notification différée sont précisées ici pour que l’absence de ces détails dans la figure ne soit pas interprétée comme leur suppression.

4. Fragments combinés : alt, opt, loop et par

Un cadre alt contient des alternatives séparées, munies de gardes comme [devis valable] et [else]. Les conditions doivent rendre le choix compréhensible. opt exprime un comportement exécuté seulement si sa garde est vraie, sans deuxième branche explicite.

loop décrit une répétition, avec une condition et éventuellement des bornes. Une relance de notification peut être limitée à trois tentatives avec un délai entre elles. Une boucle sans condition d’arrêt explique mal ce qui doit se produire en cas de panne persistante.

par permet de décrire des opérandes pouvant progresser en parallèle ; il n’impose pas un ordre global entre tous leurs messages. Un cadre ref référence une interaction définie ailleurs. Il permet de réutiliser « Vérifier l’autorisation » sans recopier son détail dans chaque figure.

alt
  [devis envoyé et non expiré] : enregistrer l’acceptation
  [else] : renvoyer le motif du refus
opt [notification à transmettre]
  programmerEnvoi()

5. Erreurs, concurrence et temps

Une garde doit être contrôlée par le participant qui dispose de l’information fiable. Le fait qu’un bouton soit désactivé dans le navigateur ne protège pas une opération appelée directement. Le service doit vérifier l’identité, les droits et la version des données.

Après un délai d’attente réseau, le client peut ignorer si l’accord a été enregistré. Une nouvelle requête peut alors renvoyer le résultat existant, au lieu de doubler l’opération. On précise aussi si une erreur de notification doit être affichée au client ou gérée dans un mécanisme de reprise.

Une contrainte comme {réponse attendue en moins de 2 s} exprime un objectif à mesurer dans un contexte défini. L’écart vertical entre deux flèches n’est pas une preuve de performance. Pour les traitements asynchrones, la réception d’un message et la fin du travail sont deux événements différents.

6. Relire une séquence avec le modèle de classes

Chaque opération appelée sur un objet doit correspondre à une responsabilité compréhensible. Si Devis reçoit envoyerSMS(), on peut se demander si le domaine ne dépend pas trop d’une infrastructure particulière. Un contrat CanalNotification clarifie cette dépendance.

La séquence doit aussi pouvoir se dérouler avec les liens et informations disponibles. Comment le service retrouve-t-il le propriétaire ? Comment distingue-t-il deux versions ? Si une réponse exige une donnée absente du modèle, on complète ce modèle au lieu de laisser une flèche mystérieuse.

Scénarios illustrés : comparer les situations

Comparer acceptation et expiration

La garde de la branche de succès regroupe les conditions nécessaires. La seconde branche illustre précisément le refus pour expiration. Les autres motifs de refus, comme un propriétaire incorrect, demanderaient une branche ou une interaction complémentaire.

Répondre à une confirmation répétée

Le client peut recommencer parce qu’il n’a pas reçu une réponse réseau. Le serveur retrouve alors l’accord existant. Le dessin rend visible la différence entre deux requêtes reçues et une seule décision métier persistée.

Exercices corrigés