No cache version.
Caching disabled. Default setting for this page:enabled (code LNG204)If the display is too slow, you can disable the user mode to view the cached version.
Use Cases : les cas d'utilisations
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”1, 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 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 :
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 graphique9.
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).
English translation
You have asked to visit this site in English. For now, only the interface is translated, but not all the content yet.If you want to help me in translations, your contribution is welcome. All you need to do is register on the site, and send me a message asking me to add you to the group of translators, which will give you the opportunity to translate the pages you want. A link at the bottom of each translated page indicates that you are the translator, and has a link to your profile.
Thank you in advance.
Document created the 23/05/2005, last modified the 31/10/2018
Source of the printed document:https://www.gaudry.be/en/analyse-usecase.html
The infobrol is a personal site whose content is my sole responsibility. The text is available under CreativeCommons license (BY-NC-SA). More info on the terms of use and the author.
Notes
- ↑a,b UML : “Unified Modeling Language” (en français, « langage de modélisation unifié ») Plus d'informations sur UML.
- ↑ Class Responsabilities Collaborators : corresponds to « en » en français
- ↑ CRC card session : corresponds to « 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
- ↑ brainstorming : corresponds to « remue-méninges, technique qui favorise la génération d'idées » en français
- ↑ 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.
- ↑ cas d'utilisations détaillés : corresponds to “Expanded Use Case” en anglais
References
OOD01-SU01 : ECIS, Introducing Design Patterns
(2005)- UML Distilled : Martin Fowler, Kendall Scott,
A Brief Guide to the Standard Object Modeling Language. Third Edition
(2003) - Writing Effective Use Cases : Addison-Wesley (October 2000)
-
IHDCB335 - AMSI : Patrick HEYMANS, Analyse et modélisation des systèmes d'information
(2009)
These references and links indicate documents consulted during the writing of this page, or which may provide additional information, but the authors of these sources can not be held responsible for the content of this page.
The author This site is solely responsible for the way in which the various concepts, and the freedoms that are taken with the reference works, are presented here. Remember that you must cross multiple source information to reduce the risk of errors.
