Une relation d’association est chemin de communication entre un acteur et un cas d’utilisation et est représenté un trait continu (cf. figure 2.5 ou 2.6).
Lorsqu’un acteur peut interagir plusieur fois avec un cas d’utilisation, il est possible d’ajouter une multiplicité sur l’association du côté du cas d’utilisation. Le symbole * signifie plusieurs (figure 2.6), exactement n s’écrit tout simplement n, n..m signifie entre n et m, etc. Préciser une multiplicité sur une relation n’implique pas nécessairement que les cas sont utilisés en même temps.
La notion de multiplicité n’est pas propre au diagramme de cas d’utilisation. Nous en reparlerons dans le chapitre consacré au diagramme de classes section 3.3.4.
Un acteur est qualifié de principal pour un cas d’utilisation lorsque ce cas rend service à cet acteur. Les autres acteurs sont alors qualifiés de secondaires. Un cas d’utilisation a au plus un acteur principal. Un acteur principal obtient un résultat observable du système tandis qu’un acteur secondaire est sollicité pour des informations complémentaires. En général, l’acteur principal initie le cas d’utilisation par ses sollicitations. Le stéréotype << primary >> vient orner l’association reliant un cas d’utilisation à son acteur principal, le stéréotype << secondary >> est utilisé pour les acteurs secondaires (figure 2.6).
Quand un cas n’est pas directement relié à un acteur, il est qualifié de cas d’utilisation interne.
Il existe principalement deux types de relations :
Une dépendance se représente par une flèche avec un trait pointillé (figure 2.7). Si le cas A inclut ou étend le cas B, la flèche est dirigée de A vers B.
Le symbole utilisé pour la généralisation est un flèche avec un trait pleins dont la pointe est un triangle fermé désignant le cas le plus général (figure 2.7).
Un cas A inclut un cas B si le comportement décrit par le cas A inclut le comportement du cas B : le cas A dépend de B. Lorsque A est sollicité, B l’est obligatoirement, comme une partie de A. Cette dépendance est symbolisée par le stéréotype << include >> (figure 2.7). Par exemple, l’accès aux informations d’un compte bancaire inclut nécessairement une phase d’authentification avec un identifiant et un mot de passe (figure 2.7).
Les inclusions permettent essentiellement de factoriser une partie de la description d’un cas d’utilisation qui serait commune à d’autres cas d’utilisation (cf. le cas S’authentifier de la figure 2.7).
Les inclusions permettent également de décomposer un cas complexe en sous-cas plus simples (figure 2.8). Cependant, il ne faut surtout pas abuser de ce type de décomposition : il faut éviter de réaliser du découpage fonctionnel d’un cas d’utilisation en plusieurs sous-cas d’utilisation pour ne pas retomber dans le travers de la décomposition fonctionnelle.
Attention également au fait que, les cas d’utilisation ne s’enchaînent pas, puisqu’il n’y a aucune représentation temporelle dans un diagramme de cas d’utilisation.
La relation d’extension est probablement la plus utile car elle a une sémantique qui a un sens du point de vue métier au contraire des deux autres qui sont plus des artifices d’informaticiens.
On dit qu’un cas d’utilisation A étend un cas d’utilisation B lorsque le cas d’utilisation A peut être appelé au cours de l’exécution du cas d’utilisation B. Exécuter B peut éventuellement entraîner l’exécution de A : contrairement à l’inclusion, l’extension est optionnelle. Cette dépendance est symbolisée par le stéréotype << extend >> (figure 2.7).
L’extension peut intervenir à un point précis du cas étendu. Ce point s’appelle le point d’extension. Il porte un nom, qui figure dans un compartiment du cas étendu sous la rubrique point d’extension, et est éventuellement associé à une contrainte indiquant le moment où l’extension intervient. Une extension est souvent soumise à condition. Graphiquement, la condition est exprimée sous la forme d’une note. La figure 2.7 présente l’exemple d’une banque où la vérification du solde du compte n’intervient que si la demande de retrait dépasse 20 euros.
Un cas A est une généralisation d’un cas B si B est un cas particulier de A. Dans la figure 2.7, la consultation d’un compte via Internet est un cas particulier de la consultation. Cette relation de généralisation/spécialisation est présente dans la plupart des diagrammes UML et se traduit par le concept d’héritage dans les langages orientés objet.
La seule relation possible entre deux acteurs est la généralisation : un acteur A est une généralisation d’un acteur B si l’acteur A peut être substitué par l’acteur B. Dans ce cas, tous les cas d’utilisation accessibles à A le sont aussi à B, mais l’inverse n’est pas vrai.
Le symbole utilisé pour la généralisation entre acteurs est une flèche avec un trait plein dont la pointe est un triangle fermé désignant l’acteur le plus général (comme nous l’avons déjà vu pour la relation de généralisation entre cas d’utilisation).
Par exemple, la figure 2.9 montre que le directeur des ventes est un préposé aux commandes avec un pouvoir supplémentaire : en plus de pouvoir passer et suivre une commande, il peut gérer le stock. Par contre, le préposé aux commandes ne peut pas gérer le stock.
