Comment dessiner un diagramme de séquence UML

Écrivez le scénario sous forme de phrase avant de dessiner quoi que ce soit."Un client réserve une chambre qui est disponible" est un scénario. "Réservation" n'en est pas un : c'est un cas d'utilisation, qui couvre toutes les exécutions, y compris celles qui échouent, et un diagramme qui essaie d'être toutes à la fois est celui qui finit à quatre-vingts messages. Si votre phrase contient le mot "ou", vous avez deux scénarios ou un fragment alt, et il faut trancher avant de continuer.

Listez ensuite les participants que ce scénario touche réellement, et placez-les de gauche à droite dans l'ordre où il les atteint. L'acteur est le plus à gauche. Quatre ou cinq est la plage de travail ; si vous en avez sept, deux au moins sont des détails d'implémentation sur lesquels le flux ne raisonne pas, et les supprimer ne perdra rien dont un lecteur avait besoin.

Dessinez l'exécution où tout fonctionne, de haut en bas, sans aucun fragment. C'est le diagramme en tête d'article, et il est fini en tant que travail même s'il ne l'est pas en tant que diagramme : l'ordonnancement est réglé, et c'est la partie coûteuse.

Deux conventions portent l'essentiel du sens. L'étiquette d'un message est une opération avec ses arguments, pas une description : isFree(dates, roomType)dit au lecteur ce que le destinataire doit offrir, là où "vérifie la disponibilité" lui raconte une histoire qu'il connaissait déjà. Et toute réponse est en tirets : une flèche pleine qui revient est un second appel, et cela veut dire autre chose.

Les barres d'activation sont optionnelles en UML 2.5.1 et valent la peine d'être tracées. Elles sont la seule chose du diagramme qui montre qu'un appel synchrone bloque son appelant pendant tout l'échange imbriqué en dessous, ce qui est généralement le fait que le diagramme a été dessiné pour établir.

C'est seulement maintenant qu'on ajoute les fragments, un à la fois, en demandant à chacun : cette branche change-t-elle ce que le lecteur doit construire ? Une branche qui renvoie une erreur et s'arrête le fait rarement, et se consigne mieux dans le texte du cas d'utilisation. Une branche qui fait un autre travail - comme proposer des dates alternatives ci-dessus - le fait toujours, et sa place est sur le diagramme.

Enroulez le cadre autour de l'endroit où les chemins divergent, pas autour de tout le diagramme. L'alt ci-dessus commence après le retour du verdict de disponibilité, parce que tout ce qui précède est commun aux deux issues ; un cadre autour des neuf messages serait techniquement légal et ne dirait rien au lecteur sur l'endroit où se trouve la décision.

Puis arrêtez-vous à un écran. Ce n'est pas une recommandation souple : un diagramme de séquence existe pour rendre un ordre visible d'un coup d'oeil, et un diagramme qu'il faut faire défiler y a renoncé tout en gardant le coût. Quand un flux ne tient pas, coupez-le à une couture naturelle, nommez chaque moitié et renvoyez de la première à la seconde par un fragment ref - ou dessinez au-dessus de l'ensemble un diagramme global d'interaction.

Trois flux terminés dont s'inspirer : les exemples traités.