Cas d'utilisation

Étude fonctionnelle :

L'analyse des besoins repose en grande partie sur l'étude des cas d'utilisation (use case en anglais).
L'approche par les cas d'utilisation permet d'appréhender le domaine à automatiser de l'extérieur, du point de vue de l'utilisateur et des fonctionnalités attendues.

Un cas d'utilisation correspond à une fonctionnalité d'un système logiciel permettant de produire un résultat (une utilisation). Chaque cas est basé sur un scénario décrivant les interactions entre utilisateur et système.

Représentation :
Un cas est décrit par une phrase indiquant son utilisation, et représenté dans une ellipse

Un acteur est une entité externe au système, interagissant avec lui, et ayant un rôle particulier. Un acteur peut être une personne physique, un groupe de personnes, ou une entité dématérialisée (comme un système par exemple).

Représentation :
L'acteur est nommé et représenté par un personnage

Une association est un lien entre un acteur, et un cas d'utilisation : elle caractérise l'utilisation.
L'association peut dans certains cas, porter des cardinalités sur chacunes de ses branches.

Une extension est une association entre 2 cas d'utilisation : elle est utilisée si un cas d'utilisation A peut être complété, ou étendu par un autre B, éventuellement sous certaines conditions. Dans ce cas, le cas B étend le cas A.

L'extension est représentée par une flèche mentionnant le stéréotype «extend»

Dans l'exemple suivant, le client aura la possibilité de vérifier la disponibilité des produits, au moment de passer sa commande. La vérification de disponibilité sera dans ce cas une extension possible du passage de commande.

L'inclusion est utilisée à partir du moment où un cas d'utilisation A met en oeuvre ou utilise un autre cas B. Dans ce cas, B est une extension de A.
Dans l'exemple qui suit, passer une commande nécessite de sélectionner au moins 1 produit.

L'inclusion est représentée par une flèche mentionnant le stéréotype «include»

La généralisation permet de mettre en oeuvre l'héritage entre cas d'utilisation. On dira qu'un cas A généralise un autre cas B, à condition que B soit un cas particulier (spécifique) de A.

Dans l'exemple suivant, le use case Passer une commande fournisseur est un cas particuliers de Passer une commande.

La généralisation peut également être utilisée entre acteur. Elle est utilisable lorsqu'il existe un héritage des rôles, et permet de montrer qu'un acteur hérite de l'accès aux fonctionnalités d'un autre.

Le Client hérite de Guest, et peut lui aussi consulter un produit.

Les packages permettent de regrouper un ensemble de cas d'utilisation ou d'acteurs.

La généricité peut être utilisée lorsqu'un ensemble de cas d'utilisation permettent de manipuler des instances de classe différentes, correspondant donc à des fonctionnalités différentes.

1. Identification des acteurs
2. Identification des cas d'utilisation
3. Identification des relations entre acteurs et cas d'utilisation
4. Recherche des liens entre cas d'utilisation
5. Représentation du diagramme des cas d'utilisation

Un cas d'utilisation UC correspond à une utilisation du logiciel, il doit permettre d'obtenir un résultat.

Ce résultat sera parfois obtenu à partir de plusieurs manipulations de l'utilisateur pouvant correspondre à des US (histoires d'utilisateur).

Une UC peut donc correspondre à une série d'US. Dans l'analyse par les US, le grain est plus fin que dans l'analyse par les UC.

Les US facilitent une approche AGILE dans la mesure où le travail à effectué sera plus détaillé, et moins conséquent pour chacune des tâches fonctionnelles à mettre en oeuvre.

• cas d’utilisation en UML