Use Cases : les cas d'utilisations

Sommaire du document

Quelques définitions du Use Case

« ...une façon spécifique d'utiliser le système en utilisant une partie de sa fonctionnalité. [Un use case] constitue une séquence complète d'interaction qui a lieu entre un acteur et le système »
Jacobson, 1992

« ..la spécification de séquences d'actions, pouvant inclure des variantes ou des séquences d'erreur, qu'un système, sous-système ou classe peuvent exécuter en interagissant avec des acteurs extérieurs »
Rumbaugh, 1999

« ...une interaction typique entre un utilisateur et un système informatique ...[qui] capture une fonction d'intérêt pour l'utilisateur ...[et qui] permet d'atteindre un but discret pour l'utilisateur »
Fowler, 1997

« Un use case représente le comportement affiché par le système sous certaines conditions de manière à satisfaire un objectif de l'un des acteurs. »
Fowler, 1997

En clair

Un “Use Case” (en français, « cas d'utilisation »), utilisé pendant la phase d'analyse, est un document qui représente la séquence des événements d'un acteur qui utilise un système pour effectuer une tâche. L'approche consiste à regarder le système à construire de l'extérieur, du point de vue de l'utilisateur et des fonctionnalités qu'il en attend.

Le “Use Case”^[1] est donc une histoire, une situation, représentée en UML [“Unified Modeling Language”^[2]] par un ovale alors que les acteurs sont représentés par des silhouettes.

Le “Use Case”^[1] décrivant une action générale, un scénario d'exécution, il peut être résumé par un verbe.

Système :

La situation est vue comme un système à part entière, dont nous représenterons la frontière par un rectangle. Tout ce qui se trouve à l'intérieur de ce rectangle est considéré comme appartenant au système.

Acteur :

Par acteur, nous désignons toute entité externe au système, mais qui interagit avec lui. Les interactions entre l'acteur et le système se font par le biais d'événements.

Nous ne devons pas considérer l'acteur comme une entité physique, mais bien comme son rôle en relation avec le système. Un acteur peut aussi faire l'objet d'un autre “Use Case”^[1], dans le cas ou il est lui-même un système.

Pour chaque “Use Case”^[1], nous aurons un acteur particulier (“initiator actor”^[4]) qui initialisera le “Use Case”^[1].

Intérêts des Use Cases

Les diagrammes “Use Case”^[1] permettent de :

• modéliser le système;
• déterminer les fonctionnalités du système à travers une vue d'un acteur et de les représenter.

Les cas d'utilisation permettent de forcer l'utilisateur ou l'expert à définir ce qu'il attend du système. La rédaction des “Use Cases” nous permet de détecter des manques dans la description du exigences, ou encore les spécifications.

Un “Use Case” décrit le quoi plutôt que le comment. Nous ne devrions normalement pas retrouver ici des descriptions d'interface utilisateur, des informations sur le fonctionnement interne, des informations liées à des exigences non fonctionnelles.

Identifier les Use Case

Lors d'une “CRC card session” (en français, « session CRC, sorte de jeu de rôle, réunion de communication entre les membres de l'équipe à propos du modèle basé sur le concept de classes »), un "brainstorming"^[8] nous permettra de déterminer nos différents “Use Cases”^[1].

Deux méthodes s'offrent à nous :

• méthode basée sur les acteurs
  • identifier les acteurs
  • pour chaque acteur, identifier les “Use Cases”^[1] qu'il initie, ou auxquels il participe
• méthode basée sur les événements
  • identifier les événements auxquels le système doit répondre
  • relier chaque événement aux acteurs et aux “Use Cases”^[1]

Structure des Uses Cases

Un cas d'utilisation est donc composé des éléments suivants :

• Un nom : verbe à l'infinitif
• Une description : résumé permettant de comprendre l'intention principale du “Use Case”^[1].
• Un ou plusieurs “initiator actor”^[4]: rôles qui initient le cas d'utilisation (la relation avec le cas d'utilisation est illustrée par le trait liant le cas d'utilisation et l'acteur dans un diagramme de cas d'utilisation).
• Des acteurs secondaires : ceux qui ne font que recevoir des informations à l'issue de la réalisation du cas d'utilisation (Ex : client ou autre système informatique. La relation avec le cas d'utilisation est illustrée de la même manière que pour l'initiator actor).
• Des pré conditions qui décrivent dans quel état doit être le système (l'application) avant que ce cas d'utilisation puisse être déclenché.
• Des scénarii. Ces scénarii sont décrits sous la forme d'échanges d'événements entre l'acteur et le système.
  • nominal : quand il n'y a pas d'erreur
  • alternatif(s) : variante(s) du scénario nominal
  • exception(s) : décrivent les cas d'erreurs
• Des post-conditions qui décrivent l'état du système à l'issue des différents scénarii.
• Des informations sur l'utilisation du cas d'utilisation comme éventuellement une description des besoins en termes d'interface graphique^[9].

High-Level Use Cases

Le cas d'utilisation de haut niveau est une brève description qui nous permet rapidement d'obtenir une vue d'ensemble et de comprendre les fonctionnalités générales.

Les cas d'utilisations de haut niveau sont divisés en trois types, en fonction de leur importance :

• Primaires : les processus les plus importants
• Secondaires
• Optionnels : les processus qui ne doivent pas impérativement être traités.

Exemple de la caisse enregistreuse (Point Of Sale Terminal - POST) :

• “Use Case”^[1] : Acheter des articles.
• Acteurs : le client, la caissière
• Type : primaire
• Description :
  Un client arrive à la caisse avec des articles à acheter.
  La caissière enregistre les produits et encaisse le paiement.
  Le client quitte la caisse avec ses achats.

Expanded Use Case

Après avoir défini nos cas d'utilisations de haut niveau qui représentent l'idée générale, nous pouvons nous pencher sur les « cas d'utilisations détaillés » (en anglais, “Expanded Use Case”).

Cette analyse nous fournira une vue plus détaillée des besoins des processus du Use Case, souvent réalisée comme un échange, une conversation entre les acteurs et le système.

Exemple de la caisse enregistreuse :

• “Use Case”^[1] : Acheter des articles avec du liquide
• Acteurs : le client(initiateur), la caissière
• Type : primaire
• Objectif : enregistrer une vente dont la somme est réglée en liquide
• Description :
  • Un client arrive à la caisse avec des produits à acheter.
  • La caissière enregistre les produits et encaisse le paiement.
  • Le client quitte la caisse avec ses achats.
• Références : Fonctions 1.1, 1.2, 1.3, ...
• Suite d'événements : un tableau qui reprend une colonne par acteur, et permet de déterminer les responsabilités de chaque acteur (chaque action est associée à un acteur).

Diagrammes Use Cases

En UML, les diagrammes use case nous permettent de représenter graphiquement les use cases.

• Les limites du système sont représentées par un rectangle.
• Les acteurs sont représentés par un personnage « en fil de fer », a l'extérieur des frontières du système.
• Les use cases sont représentés par leur nom, au milieu d'un ovale. Nous placerons les use cases à l'intérieur du système.
• Les acteurs sont reliés aux use cases par un trait.
• Les relations entre les use cases sont représentées par des flèches en pointillé, avec la mention “includes” ou “excludes” encadrée par des doubles chevrons (<<...>>).
• Nous pouvons relier les acteurs entre eux par des flèches qui représentent la généralisation (comme en orienté-objet, la spécialisation à l'origine et la généralisation à la destination de la flèche).

Notes

1. ↑^{a,b,c,d,e,f,g,h,i,j,k,l,m} Use Case : correspond à « cas d'utilisation” en français
   
   
2. ↑^a,b,c Unified Modeling Language : correspond à « langage de modélisation unifié” en français
   
   
3. ↑^a,b UML : “Unified Modeling Language” (en français, « langage de modélisation unifié ») Plus d'informations sur UML.
   
   
4. ↑^a,b initiator actor : correspond à « acteur qui initialise le Use Case” en français
   
   
5. ↑ Class Responsabilities Collaborators : correspond à « en" en français
   
   
6. ↑ CRC : "Class Responsabilities Collaborators" (en français, « en »)
   
   
7. ↑ CRC card session : correspond à « session CRC, sorte de jeu de rôle, réunion de communication entre les membres de l'équipe à propos du modèle basé sur le concept de classes” en français
   
   
8. ↑ brainstorming : correspond à « remue-méninges, technique qui favorise la génération d'idées" en français
   
   
9. ↑ interface graphique : Différents courants s'opposent à propos de notes relatives à une interface graphique; certains pensent que l'apport de captures d'écrans du système en place peut aider, d'autres les proscivent formellement. De toute manière, il est impératif de focaliser son attention à ce stade sur l'intention principale et le système vu par les utilisateurs et non le système vu par les développeurs.
   
   
10. ↑ cas d'utilisations détaillés : correspond à “Expanded Use Case » en anglais
    
    

Références

1. OOD01-SU01 : ECIS, Introducing Design Patterns (2004)
2. UML Distilled : Martin Fowler, Kendall Scott, A Brief Guide to the Standard Object Modeling Language. Third Edition (2003)
3. Writing Effective Use Cases : Addison-Wesley (Octobre 2000)
4. IHDCB335 - AMSI : Patrick HEYMANS, Analyse et modélisation des systèmes d'information (2009)

Ces références et liens indiquent des documents consultés lors de la rédaction de cette page, ou qui peuvent apporter un complément d'information, mais les auteurs de ces sources ne peuvent être tenus responsables du contenu de cette page.
L'auteur de ce site est seul responsable de la manière dont sont présentés ici les différents concepts, et des libertés qui sont prises avec les ouvrages de référence. N'oubliez pas que vous devez croiser les informations de sources multiples afin de diminuer les risques d'erreurs.

Structure du document