1. Pour décrire un scénario d’utilisation d’un cas, il faut considérer le système comme une boîte noire et ne pas chercher à montrer des objets au cœur du système. Rappel : un cas d’utilisation est une grande fonction du système vue par un acteur ; il ne faut donc pas faire figurer la structure interne d’un système (c’est le rôle du diagramme de classes). À la figure 3.54, le système est représenté par une seule ligne de vie appelée Bibliothèque.
Remarque :
Quand un diagramme de séquence décrit un cas d’utilisation, le for malisme strict d’UML (la syntaxe des messages par exemple) est plus libre.
La description d’un scénario par un diagramme de séquence n’empêche pas de décrire le cas sous forme textuelle (voir chapitre 1), ce qui permet de faire figurer des renseignements supplémentaires (pré- et post-conditions, contraintes…).
2. Le diagramme de la figure 3.55 complète le diagramme précédent (figure 3.54) en incluant la vérification de contraintes. Si une contrainte n’est pas vérifiée, les événements qui suivent cette contrainte sont invalides. De plus, la séquence doit impérativement se terminer par les deux messages « décrémenter le nombre d’exemplaires dans la biblio- thèque » et « attribuer l’exemplaire à l’adhérent » à cause de l’utilisation de l’opérateur assert.
Le formalisme des diagrammes de séquence est très riche. Souvent, il est possible de représenter des scénarios de plusieurs façons. Au lieu d’utiliser des opérateurs d’assertion, il est possible de recourir à des opérateurs d’alternative.
La figure 3.56 présente une troisième solution qui utilise un opérateur d’option (l’opérateur d’option opt est identique à un opérateur d’alternative, mais avec un choix unique).
La figure 3.56 utilise l’opérateur negative pour indiquer que les messages sur lesquels il s’applique sont invalides.
