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).
Deutsche Übersetzung
Sie haben gebeten, diese Seite auf Deutsch zu besuchen. Momentan ist nur die Oberfläche übersetzt, aber noch nicht der gesamte Inhalt.Wenn Sie mir bei Übersetzungen helfen wollen, ist Ihr Beitrag willkommen. Alles, was Sie tun müssen, ist, sich auf der Website zu registrieren und mir eine Nachricht zu schicken, in der Sie gebeten werden, Sie der Gruppe der Übersetzer hinzuzufügen, die Ihnen die Möglichkeit gibt, die gewünschten Seiten zu übersetzen. Ein Link am Ende jeder übersetzten Seite zeigt an, dass Sie der Übersetzer sind und einen Link zu Ihrem Profil haben.
Vielen Dank im Voraus.
Dokument erstellt 23/05/2005, zuletzt geändert 31/10/2018
Quelle des gedruckten Dokuments:https://www.gaudry.be/de/analyse-usecase.html
Die Infobro ist eine persönliche Seite, deren Inhalt in meiner alleinigen Verantwortung liegt. Der Text ist unter der CreativeCommons-Lizenz (BY-NC-SA) verfügbar. Weitere Informationen auf die Nutzungsbedingungen und dem Autor.
- ↑a,b UML : “Unified Modeling Language” (en français, « langage de modélisation unifié ») Plus d'informations sur UML.
- ↑ Class Responsabilities Collaborators : entspricht « en » en français
- ↑ CRC card session : entspricht « 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 : entspricht « 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 : entspricht “Expanded Use Case” en anglais
Referenzen
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)
Diese Verweise und Links verweisen auf Dokumente, die während des Schreibens dieser Seite konsultiert wurden, oder die zusätzliche Informationen liefern können, aber die Autoren dieser Quellen können nicht für den Inhalt dieser Seite verantwortlich gemacht werden.
Der Autor Diese Website ist allein dafür verantwortlich, wie die verschiedenen Konzepte und Freiheiten, die mit den Nachschlagewerken gemacht werden, hier dargestellt werden. Denken Sie daran, dass Sie mehrere Quellinformationen austauschen müssen, um das Risiko von Fehlern zu reduzieren.
