Le diagramme “scénario”
Un diagramme scénario[1] est constitué d'évènements[2] mettant en jeu des objets de plusieurs classes, et cités dans un ordre chronologique. Son objectif n'est pas de représenter le réel d'une façon exhaustive. C'est un document d'analyse pour mieux cerner l'enchaînement des événements[2] d'une fonction qui a été par exemple esquissée dans un use case[3].
On le représente par une sorte de diagramme à barres :
Les concepts de classe[4] et d'objet[5] sont ceux du modèle statique, et les objets en proviennent.
Ils sont représentés par une barre verticale en trait épais.
Un nouveau concept et une spécialisation de ce concept interviennent :
événement et message.
Comme son nom l'indique, l'événement[2] est une action brusque, qui n'a pas de durée, comme un ordre envoyé par un acteur[6] extérieur au système, ou un message[7] diffusé par un objet du système, l'émetteur.
Cet ordre est obligatoirement donné à un objet du système, le récepteur. Le récepteur peut réagir ou non à cet ordre. Cela dépend du contexte. L'effet qui peut en résulter est soit le renvoi d'un autre message (la transmission de l'ordre à d'autres objets), soit l'exécution d'une action ou soit un changement de l'état de l'objet qui a réagi à l'événement.
Il y a bien évidemment analogie avec les langages à objets[5] : l'événement correspond à une méthode. Un objet d'une classe qui reçoit une demande d'exécution d'une méthode peut soit l'accepter si elle figure dans la liste des méthodes autorisées pour sa classe, soit la refuser dans le cas contraire. L'objet renvoie alors un message d'erreur à l'émetteur.
UML[8] fait une distinction subtile entre un message[7], qui est obligatoirement émis par un objet d'une classe, et un événement[2], qui englobe toutes les formes et tous les émetteurs, y compris les acteurs.
Chaque évènement[2] porte un nom, et il est représenté par un vecteur orienté, en trait mince.
Illustrons un diagramme scénario[1] par une fonction banale et apparemment simple sur un chantier : couler un poteau en BA. Le contexte est précisé : on utilise un coffrage-outil métallique, dont on doit gérer les permutations. La base de données du bâtiment doit être capable d'accueillir l'information nécessaire pour des exploitations à toutes les étapes de la vie du bâtiment. Et la période du chantier est la plus critique et la plus riche. La fonction ne détaille les classes d'objets et les évènements que dans le but de d'identifier les postes analytiques d'un quantitatif estimatif. L'objet « grue » intègre le grutier et son coût.
Au niveau de granulométrie[9] requis, même si un événement semble prendre un certain temps, il peut être considéré comme nul : prendre, déposer, vider ... ou bien on considère que l'événement est l'ordre de commencer une tâche : tracer. Sous entendu, le chef d'équipe donne l'ordre aux ouvriers de l'équipe de commencer à tracer.
L'échelle du diagramme du scénario ne tient pas compte des durées. Exemple : vibrer le béton se fait juste après, et même pendant le coulage, tandis que démonter le coffrage ne se fait pas avant 21 jours.
Le débutant peut être hésitant sur l'émetteur et le récepteur d'un événement. Par exemple, pour exprimer le fait que la grue saisit une armature (sur le lieu de stockage) pour la déposer (sur une dalle) sur la localisation d'un poteau, ne doit-t-on pas relier l'objet grue à armature, puis grue à poteau ? (ce qui n'a pas été fait ici).
On verra plus loin, avec le concept plus précis de transition[10], que l'on peut qualifier l'événement.
Par ailleurs, à la vue de ce diagramme, on pressent que le poteau en construction passe par plusieurs état[11] ...
Par ailleurs, on imagine aussi que l'équipe 3 ne va pas se tourner les pouces pendant 21 jours avant de démonter le coffrage du poteau A14.
