Exemples de diagrammes de séquence UML

Lisez le diagramme ci-dessus comme deux histoires partageant un début. Tout ce qui est au-dessus du cadre alt arrive dans les deux cas ; à l'intérieur, exactement un compartiment s'exécute, et les gardes entre crochets disent lequel. C'est ce qu'un diagramme de séquence fait et qu'une liste numérotée d'étapes ne peut pas faire, et c'est pourquoi ce flux est le premier exemple standard.

Le détail à copier est dans la branche d'échec. Elle ne se contente pas de renvoyer une erreur : elle envoie d'abord record(failure)au journal des tentatives, tracé avec une pointe ouverte parce que rien ne l'attend. Un diagramme dont le chemin d'échec est une seule flèche étiquetée "erreur" est un diagramme qui n'a pas réfléchi au chemin d'échec - et l'exigence de limitation que tout le monde découvre trois semaines plus tard vit exactement dans cette branche.

Deux choses ici n'apparaissent pas sur un premier diagramme de séquence. La garde du fragment loop nomme à la fois une borne et une condition - [3 times, while transient] - parce qu'une boucle sans borne est un diagramme qui promet une panne, et qu'une boucle sans condition ne dit pas ce qui l'arrête plus tôt.

L'autre est backoff(), un message de Checkout vers lui-même, tracé comme une flèche qui quitte une ligne de vie et y revient. Les auto-appels valent d'être dessinés exactement quand le délai ou la décision fait partie de l'histoire - ici c'est toute la raison pour laquelle la seconde tentative réussit - et valent d'être omis quand il s'agit de travail interne ordinaire.

Notez aussi ce qui n'est pas là : aucune réponse en tirets après markPaid(orderId). Le magasin de commandes répond, bien sûr, mais la réponse ne porte rien sur quoi ce flux raisonne, et dessiner chaque réponse est la façon dont un diagramme de six messages intéressants en devient un de douze.

C'est l'exemple que presque personne ne dessine, et celui qu'il vaut le plus la peine d'avoir. Chaque flèche est asynchrone - trait plein, pointe ouverte - et il n'y a pas un seul retour en tirets. Le service de commandes publie et passe à la suite ; l'entrepôt et le service d'e-mail reçoivent chacun l'événement, et rien sur ce diagramme ne dit lequel des deux termine en premier, parce que rien dans le système ne le dit non plus.

Dessiner ce flux avec des pointes pleines et des réponses serait un autre système : un où la publication bloque jusqu'à ce que les deux consommateurs aient tourné, ce qui est précisément la propriété qu'un courtier existe pour supprimer. La notation les distingue, et cette distinction vaut plus ici que partout ailleurs en UML.

Pour la méthode plutôt que les exemples, lisez comment dessiner un diagramme de séquence ; pour la notation complète, l'article sur le diagramme de séquence.