Geen cache-versie.
Caching uitgeschakeld. Standaardinstelling voor deze pagina:ingeschakeld (code LNG204)Als het scherm te langzaam is, kunt u de gebruikersmodus uitschakelen om de cacheversie te bekijken.
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).
Nederlandse vertaling
U hebt gevraagd om deze site in het Nederlands te bezoeken. Voor nu wordt alleen de interface vertaald, maar nog niet alle inhoud.Als je me wilt helpen met vertalingen, is je bijdrage welkom. Het enige dat u hoeft te doen, is u op de site registreren en mij een bericht sturen waarin u wordt gevraagd om u toe te voegen aan de groep vertalers, zodat u de gewenste pagina's kunt vertalen. Een link onderaan elke vertaalde pagina geeft aan dat u de vertaler bent en heeft een link naar uw profiel.
Bij voorbaat dank.
Document heeft de 23/05/2005 gemaakt, de laatste keer de 31/10/2018 gewijzigd
Bron van het afgedrukte document:https://www.gaudry.be/nl/analyse-usecase.html
De infobrol is een persoonlijke site waarvan de inhoud uitsluitend mijn verantwoordelijkheid is. De tekst is beschikbaar onder CreativeCommons-licentie (BY-NC-SA). Meer info op de gebruiksvoorwaarden en de auteur.
Notes
- ↑a,b UML : “Unified Modeling Language” (en français, « langage de modélisation unifié ») Plus d'informations sur UML.
- ↑ Class Responsabilities Collaborators : komt overeen met « en » en français
- ↑ CRC card session : komt overeen met « 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 : komt overeen met « 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 : komt overeen met “Expanded Use Case” en anglais
Referenties
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)
Deze verwijzingen en links verwijzen naar documenten die geraadpleegd zijn tijdens het schrijven van deze pagina, of die aanvullende informatie kunnen geven, maar de auteurs van deze bronnen kunnen niet verantwoordelijk worden gehouden voor de inhoud van deze pagina.
De auteur Deze site is als enige verantwoordelijk voor de manier waarop de verschillende concepten, en de vrijheden die met de referentiewerken worden genomen, hier worden gepresenteerd. Vergeet niet dat u meerdere broninformatie moet doorgeven om het risico op fouten te verkleinen.
