3  Cas d’utilisation

Les cas d’utilisation sont des documents textuels décrivant l’interaction entre un système (un logiciel à développer) et un ou plusieurs acteurs (les utilisateurs ou systèmes externes). Le cas d’utilisation décrit plusieurs scénarios, mais, en général, il y a un scénario principal happy path représentant ce qui se passe le plus souvent et lorsqu’il n’y a pas d’anomalie.

Les cas d’utilisation sont une manière de documenter les fonctionnalités (les exigences fonctionnelles).

Note

D’autres méthodologies de développement peuvent déterminer les besoins avec les récits utilisateur (user stories), qui sont généralement plus courts et moins prescriptifs que des cas d’utilisation. Par exemple, dans un récit utilisateur, on ne spécifie pas un ordre d’interactions entre l’acteur et le système. Une raison pour ne pas spécifier autant de détails est que ça peut changer beaucoup (surtout au début du projet). Voir cette discussion sur stackexchange.com pour en savoir plus sur les différences entre ces méthodologies.

La théorie sur comment écrire les cas d’utilisation ne fait pas partie de ce manuel (voir le chapitre 6 ).

La notation UML inclut les diagrammes de cas d’utilisation, qui sont comme une table des matières pour les fonctionnalités d’un système.

3.1 Exemple : le jeu Risk

Nous décrivons un cas d’utilisation à l’aide d’un exemple concernant le jeu Risk.

Cinq dés utilisés dans le jeu Risk. « Risk Dice » (CC BY 2.0). Par Fuhrmanator.

Selon « Risk ». 2019. Wikipédia. (accédé le 9 décembre 2019) :

L’attaquant jette un à trois dés suivant le nombre de régiments qu’il désire engager (avec un maximum de trois régiments engagés, et en considérant qu’un régiment au moins doit rester libre d’engagements sur le territoire attaquant) et le défenseur deux dés (un s’il n’a plus qu’un régiment). On compare le dé le plus fort de l’attaquant au dé le plus fort du défenseur et le deuxième dé le plus fort de l’attaquant au deuxième dé du défenseur. Chaque fois que le dé du défenseur est supérieur ou égal à celui de l’attaquant, l’attaquant perd un régiment ; dans le cas contraire, c’est le défenseur qui en perd un.

Alors, nous proposons les étapes (les interactions entre les acteurs et le système) pour ce scénario :

3.1.1 Scénario : Attaquer un pays

  1. Le Joueur attaquant choisit d’attaquer un pays voisin du Joueur défenseur.
  2. Le Joueur attaquant annonce combien de régiments il va utiliser pour son attaque.
  3. Le Joueur défenseur annonce combien de régiments il va utiliser pour la défense du pays attaqué.
  4. Les deux Joueurs jettent le nombre de dés selon leur stratégie, choisie aux étapes précédentes.
  5. Le Système compare les dés, élimine les régiments de l’attaquant ou du défenseur selon les règles1 et affiche le résultat.

Les Joueurs répètent les étapes 2 à 5 jusqu’à ce que l’attaquant ait éliminé tous les régiments du pays attaqué, l’attaquant n’ait plus suffisamment de régiments pour attaquer, ou l’attaquant ne veuille plus attaquer.

  1. Le Système indique le résultat de l’attaque, y compris un changement de contrôle du pays attaqué si nécessaire.

3.1.2 Scénarios alternatifs (ou extensions)

Les compléments du scénario principal (ce qui se passe le plus souvent) sont les scénarios alternatifs, qui comprennent souvent la plus grande partie du texte de cas d’utilisation. Ils indiquent tous les autres cas ou branchements éventuels, ce qui peut représenter beaucoup de fonctionnalités d’un logiciel complet. Par exemple, un client ou une cliente veut payer avec Bitcoin (le logiciel doit supporter ce cas moins fréquent). Un autre exemple est lorsque la validation de carte de crédit échoue lors d’un paiement.

Les scénarios alternatifs sont documentés dans une section du cas d’utilisation à ce propos. On spécifie les étapes du scénario de base auxquelles il peut y avoir un branchement. Dans l’exemple du jeu Risk, lors d’une attaque, le Joueur attaquant peut décider spontanément d’annuler son attaque. Il ne pourra pas l’annuler une fois que les dés sont lancés. Alors on peut spécifier le scénario alternatif « 2-3a », pour indiquer que ça commence à partir des étapes 2 et 3 du scénario principal et que c’est le premier (« a ») scénario alternatif pour ces étapes :

Scénarios alternatifs :

2-3a. Le Joueur attaquant décide d’annuler son attaque.

  1. Le Système indique que le Joueur attaquant a annulé.
  2. Fin du cas d’utilisation

3.1.3 Diagramme de cas d’utilisation

La figure 3.1 est un exemple de diagramme de cas d’utilisation.

Un diagramme de cas d’utilisation n’étant qu’une sorte de table des matières des fonctionnalités, il ne montre qu’une faible partie des détails trouvés dans le texte de chaque cas d’utilisation. Le diagramme ne peut donc remplacer la documentation textuelle.

Sur la figure 3.1, le cas d’utilisation « … » signifie qu’il y a d’autres cas d’utilisation à spécifier concrètement, c’est-à-dire tous les autres cas d’utilisation du jeu, par exemple pour distribuer les régiments à chaque tour, etc.

Le cas d’utilisation Démarrer n’est pas normalement indiqué dans un diagramme. C’est une astuce pédagogique proposée par Larman (2005), car il faudra concevoir et coder ce scénario, bien qu’il ne soit pas une fonctionnalité connue par l’utilisateur.

Système...Attaquerun paysDémarrerJoueur

Figure 3.1: Diagramme de cas d’utilisation. (PlantUML)

  1. Pour faire un cas d’utilisation plus facile à comprendre, on fait abstraction des règles ici.↩︎