Les cas d'utilisation et les acteurs interagissent en s'envoyant des signaux. Pour indiquer de telles interactions,
nous utilisons des associations de communication entre les cas d'utilisation et les acteurs. Un cas
d'utilisation a tout au plus une association de communication avec un acteur donné. Un acteur a, lui aussi, une
relation de communication maximum avec un cas d'utilisation donné, quel que soit le nombre de transmissions de signaux.
Le réseau complet de ce type d'associations est une image statique de la communication entre le système et son
environnement.
On ne donne pas de nom aux associations de communication. Comme il ne peut y avoir qu'une seule association de
communication entre un cas d'utilisation et un acteur, il suffit de préciser le point de départ et le point d'arrivée
pour identifier une association de communication donnée.
Une ligne ou une flèche entre un acteur et un cas d'utilisation indique qu'ils interagissent en s'envoyant des signaux.
Chaque fin d'une association de communication est un rôle indiquant le rôle joué par un cas d'utilisation ou par
un acteur dans l'association. Les rôles sont utilisés pour définir les multiplicités et les sens de
l'association (voir ci-dessous).
Chaque rôle d'une association de communication indique la multiplicité de son type, c'est à dire le nombre
d'instances de cet acteur ou de ce cas d'utilisation pouvant être associé à une instance de l'autre cas d'utilisation
ou de l'autre acteur. La multiplicité est indiquée par une expression de texte sur le rôle. L'expression est une liste
séparée par des virgules de plages de nombres entiers. Une plage est indiquée par un entier (la valeur la lus basse),
deux points et un entier (la valeur la plus haute) ; un entier seul est une plage valide, et le symbole "*" indique
"plusieurs", c'est à dire un nombre illimité d'objets. Le symbole "*" seul équivaut à "0..*", c'est à dire à n'importe
quel chiffre, même à aucun ; c'est la valeur par défaut. Un rôle scalaire en option a la multiplicité 0..1.
La multiplicité peut être augmentée avec une contrainte d'unité de temps. Cela a pour but d'établir le nombre
d'instances pouvant être associé, par différentes instances, pendant l'unité de temps. Ces informations sont utiles car
elles nous indiquent si le cas d'utilisation est souvent réalisé et nous renseignent aussi sur le nombre de fois que
chaque instance de l'acteur utilise le cas d'utilisation.
Exemple :
Le cas d'utilisation Effectuer une transaction est utilisé 400.000 fois par jour par les Clients. Chaque Client se sert
du cas d'utilisation deux fois par mois.
Chaque rôle d'une association de communication a une propriété de navigabilité indiquant qui a commencé la
communication dans l'interaction. La navigabilité est indiquée par une pointe de flèche ouverte. Si la
pointe de flèche est dirigée vers un cas d'utilisation, l'acteur à l'autre bout de l'association a commencé
l'interaction avec le système. Si la pointe de flèche est dirigée vers un acteur, le système a commencé
l'interaction avec l'acteur. La navigabilité dans les deux sens est indiquée par une ligne sans pointe de flèche
(deux pointes de flèche surchargent les diagrammes).
La flèche de communication indique l'acteur qui a commencé le cas d'utilisation. Pour chaque flèche de communication,
un message avec accusé de réception est pris en charge. Une ligne sans pointe de flèche implique une communication
bilatérale.
Ne confondez pas la navigabilité avec le flux de données ; elle n'est
utilisée que
pour désigner l'élément ayant commencé la communication. Par exemple, la requête d'un client pour des données est
indiquée par une flèche sur le cas d'utilisation représentant le système, bien que la plupart des données aillent du
système vers le client.
Les acteurs communiquent avec le système en lui envoyant des signaux. Pour bien comprendre le rôle de l'acteur, vous
devez savoir dans quels cas d'utilisation il est est impliqué. Cela est indiqué par les associations de communication
entre l'acteur et les cas d'utilisation.
La multiplicité de l'association indique le nombre d'instances de cas d'utilisation avec lesquelles une instance d'un
acteur peut communiquer au même moment.
Exemple :
Dans le système de la machine de recyclage, à chaque fois qu'une instance de l'acteur Client dépose un article
consigné, il envoie un signal à l'instance associée de cas d'utilisation Recycler des articles. Lorsque l'acteur a
terminé, le cas d'utilisation imprime un reçu. Un Client ne peut communiquer qu'avec une seule instance Recycler des
articles. Cela signifie donc que la multiplicité de l'association est 1. Le reçu imprimé par le système est considéré
ici comme la réponse de l'instance de cas d'utilisation. L'association de communication n'a donc pas besoin de
navigabilité dans l'autre sens.
Un client voulant déposer un article consigné dans une machine de recyclage communiquera avec le cas d'utilisation
Recycler des articles.
Un acteur communique avec des cas d'utilisation pour de multiples raisons, notamment :
-
Pour appeler un cas d'utilisation. L'instance de l'acteur appelle toujours l'instance de cas d'utilisation.
-
Pour demander des données stockées dans le système que le cas d'utilisation extrait et présente à l'acteur.
-
Pour changer des données stockées dans le système en dialoguant avec le système.
-
Pour indiquer que quelque chose s'est produit dans l'environnement du système et que le système devrait y faire
attention.
Un acteur émet un cas d'utilisation. Cependant, une fois commencé, le cas d'utilisation peut communiquer avec plusieurs
acteurs. Vous pouvez utiliser des associations de communication entre le cas d'utilisation et les acteurs pour indiquer
les acteurs avec lesquels le cas d'utilisation communique. La multiplicité de l'association indique le nombre
d'instances d'un acteur avec lesquelles une instance d'un cas d'utilisation peut communiquer au même moment.
Les cas d'utilisation communiquent avec des acteurs pour de multiples raisons, notamment :
-
Si quelque chose de spécial s'est déroulée dans le système que l'acteur devrait savoir.
-
S'il existe plusieurs options pour prendre une décision, un cas d'utilisation peut demander de l'aide à un acteur.
Il est fréquent, mais pas systématique, que le cas d'utilisation attende une réponse lorsqu'il a envoyé un signal à un
acteur. Cela devrait être décrit de manière explicite dans le cas d'utilisation.
Les conventions optionnelles suivantes mettent en évidence l'acteur ayant commencé le cas d'utilisation.
-
La pointe de flèche allant de l'acteur vers le cas d'utilisation
est toujours affichée, même si plus tard le cas d'utilisation commence la communication avec l'acteur. C'est
aussi la seule pointe de flèche allant de l'acteur vers le cas d'utilisation à être affichée.
-
Les pointes de flèches allant du cas d'utilisation vers les acteurs
peuvent être omises ou incluses pour plus de clarté.
|