Computing">
[go: up one dir, main page]

0% ont trouvé ce document utile (0 vote)
29 vues23 pages

Chapitre 2 - Le Diagramme Des Cas D'utilisations

Télécharger au format pdf ou txt
Télécharger au format pdf ou txt
Télécharger au format pdf ou txt
Vous êtes sur la page 1/ 23

Chapitre 2

DIAGRAMME DE CAS
1 d’UTILISATION
Axes de modélisation d ’un système
Fonctionnel
(ce que le système FAIT)

• diagramme de cas d’utilisation


•…

Dynamique
(comment le système
EVOLUE)
Statique (ce que le système EST)
• diagramme de séquence
•… • diagramme de classes
•diagramme de déploiement
•… 2
Bien recueillir les besoins
3
 Bien souvent, la maîtrise d’ouvrage et les utilisateurs ne sont pas des
informaticiens.
 Il leur faut donc un moyen simple d’exprimer leurs besoins. C’est précisément
le rôle des diagrammes de cas d’utilisation qui permettent de recueillir,
d’analyser et d’organiser les besoins, et de recenser les grandes
fonctionnalités d’un système.
 Il s’agit donc de la première étape UML, d’analyse d’un système.
 Un diagramme de cas d’utilisation capture le comportement d’un système,
d’un sous-système, d’une classe ou d’un composant tel qu’un utilisateur
extérieur le voit.
 Il scinde la fonctionnalité du système en unités cohérentes,
 Les cas d’utilisation, ayant un sens pour les acteurs.
 Les cas d’utilisation permettent d’exprimer le besoin des utilisateurs d’un système,
 ils sont donc une vision orientée utilisateur de ce besoin, au contraire d’une
vision informatique.
 Compréhensibles par toutes les personnes, même par les non-informaticiens.
Définition
4

 Un cas d’utilisation « raconte » comment on doit utiliser le système


pour atteindre un but particulier

o Il correspond à une fonction du système

o Il décrit les interactions entre le système et les utilisateurs

o Il est exprimé en prose structurée

o Il détermine un contrat à remplir par le système

o Il induit des exigences fonctionnelles applicables au système


et il peut être utilisé pour organiser la spécification
Diagramme de cas d’utilisation
5
 Représente les fonctions du système de point de vue de l ’utilisateur.

Ceci est un cas


relation Cas d’utilisation
d’utilisation
Acteur
Ceci est
un acteur
Ceci est
une relation
 Eléments du diagramme :

o acteur : un rôle joué par une personne, un service, etc. qui interagit avec le
système étudié

o cas d’utilisation : manière spécifique d ’utiliser un système. Image d’une


fonctionnalité attendue, déclenchée en réponse à la stimulation d’un acteur

o relations entre cas d’utilisations et acteurs


Acteurs : diagramme de cas d’utilisation
6
 Un acteur représente un ensemble cohérent de rôles joués vis-à-vis d’un
système
o Exemple : mettre « comptable » plutôt que « madame Mariem ».
 Plusieurs personnes peuvent avoir le même rôle
o exemple : « client » pour une banque
 Tout ce qui est à l’extérieur du système et qui interagit avec le système est
un acteur.

 Acteur humain : il s’agit ici d’un rôle et non d’un acteur identifié.

 Acteur non humain : exemple un logiciel de comptabilité ou d’ERP avec


lequel le système interagit

ou
Acteurs : diagramme de cas d’utilisation
7
 On distingue 4 catégories d ’acteurs:
o les acteurs principaux (ex: usager, client, etc.)
o les acteurs secondaires (ex: opérateur de maintenance, administrateur, etc.)
o le matériel externe (capteurs, imprimantes, périphériques divers, etc.)
o les autres systèmes (serveur central, service ou organisation, etc.)

Circuler à
bicyclette
Cycliste

Un Acteur peut hériter d’autres Acteurs.

Distribuer le
courrier

Facteur
CAS D ’UTILISATION Identification (1)
8
 Un cas d’utilisation représente un processus de « haut niveau » se déroulant de
bout en bout et incluant plusieurs étapes successives.
 Ce n’est pas une opération élémentaire ou une transaction.

 Un cas d’utilisation peut être vu comme une collection de scénarios décrivant


différentes façons d’utiliser le système pour atteindre un même but (avec ou
sans succès).

 Un cas d’utilisation ne se décompose pas en « sous-cas d’utilisation ».


CAS D ’UTILISATION Identification (2)
9
 Les cas d ’utilisation correspondent
o aux principales tâches de chaque acteur
o à une valeur ajoutée pour l ’utilisateur
o à des fonctionnalités ou à des services attendus
o à des opérations sur les données du système
o à des anomalies ou des cas particuliers.
 Un cas d ’utilisation doit être simple (description de 1 ou 2 pages maximum).
 Le nombre d ’acteurs en relation avec un cas d ’utilisation ne doit pas être
trop important.
 2 activités qui s ’enchaînent toujours font généralement partie du même cas
d’utilisation.

 La difficulté majeure est de trouver le bon niveau d’abstraction.


CAS D ’UTILISATION Description caractéristique
10
 La description d’un cas d’utilisation

o débute par une phrase du type

« Ce cas d’utilisation est déclenché quand

<un acteur> <adresse un stimulus au système> …»

o privilégie les interactions entre les acteurs et le système

o s’attache prioritairement à la séquence des événements qui conditionnent


les interactions (flux nominal)

o se termine lorsque le but est atteint ou dans une situation d'exception.

 Si cette description est impossible, c’est probablement parce que l’objet


considéré n’est pas vraiment un cas d’utilisation …
CAS D ’UTILISATION Construction
11
1) Identifier les acteurs (Qui utilise le système )

2) Identifier grossièrement les cas d ’utilisation essentiels.

3) Identifier les cas d ’utilisation exceptionnels.

4) Décrire chaque cas d ’utilisation en quelques phrases.

5) Elaborer un diagramme.

6) Vérifier que tous les besoins identifiés ont été alloués à un cas
d ’utilisation.

7) Recenser les principaux scénarios pour chaque cas d ’utilisation.


CAS D ’UTILISATION: Niveaux de description
12

•Général •Détaillé
 Brève description  Description précise et
structurée
 3-5 phrases
 Description des
alternatives
Calculer un itinéraire

Titre: Calculer un itinéraire


Acteur: Usager
Description: Ce cas d’utilisation commence lorsque
l’usager se connecte au système pour obtenir un
itinéraire à suivre. Il précise son lieu de départ et
son lieu d’arrivée ainsi que les paramètres de
calcul. Le système lui fournit une chronologie des
étapes à suivre pour atteindre la destination dans
les conditions souhaitées.
Relations entre cas d’utilisation
13
Communication – exprime le fait que l ’acteur participe à la
réalisation d ’un cas d ’utilisation . C ’est la seule relation qui
peut exister entre un acteur et un cas d ’utilisation. Consommateur
Payer

Généralisation - un cas d ’utilisation « enfant » hérite du


Payer
comportement et de la sémantique du cas d ’utilisation parent

Régler par chèque Régler par CB

Relation « Include » – Une relation « include » du cas


d ’utilisation A vers le cas d ’utilisation B signifie que le flot <<include>>
d ’événements de A contient une séquence d ’événements
qui correspond à B. Régler par CB Composer Code

Relation « Extend » – Une relation « extend » du cas


d ’utilisation A vers le cas d ’utilisation B signifie que le flot
<<extend>>

d ’événements de A peut intervenir, de façon facultative, Remplir ordre et montant Régler par chèque

pendant le déroulement de B. B spécifie un comportement automatiquement

facultatif
Relation d’inclusion
14
 Un cas A inclut un cas B si le comportement décrit par le cas A inclut le
comportement du cas B : le cas A dépend de B.
 Lorsque A est sollicité, B l’est obligatoirement, comme une partie de A. Cette
dépendance est symbolisée par le stéréotype << include >>
 Les inclusions permettent essentiellement de factoriser une partie de la
description d’un cas d’utilisation qui serait commune à d’autres cas
d’utilisation.
 Les inclusions permettent également de décomposer un cas complexe en
sous-cas plus simples.
Relation d’extension
15
 Un cas d’utilisation A étend un cas d’utilisation B lorsque le cas d’utilisation A
peut être appelé au cours de l’exécution du cas d’utilisation B.
 Exécuter B peut éventuellement entraîner l’exécution de A : contrairement à
l’inclusion, l’extension est optionnelle. Cette dépendance est symbolisée par le
stéréotype << extend >> .
 L’extension peut intervenir à un point précis du cas étendu. Ce point s’appelle
le point d’extension.
mot clef (stéréotype)

<<extend>> Rechercher
demande de remplacement Extension points
de chaque occurrence trouvée • définition du remplaçant: avant début
Remplacer
de recherche
• substitution: à chaque occurrence
trouvée
Condition d’extension

Points d’extension
Relation de généralisation
16
 Un cas A est une généralisation d’un cas B, si B est un cas particulier de A.

 Cette relation de généralisation/spécialisation est présente dans la


plupart des diagrammes UML et se traduit par le concept d’héritage
dans les langages orientés objet
Relations entre acteurs
17

La seule relation possible entre deux acteurs est la généralisation : un acteur A est
une généralisation d’un acteur B si l’acteur A peut être substitué par l’acteur B.
Dans ce cas, tous les cas d’utilisation accessibles à A le sont aussi à B, mais
l’inverse n’est pas vrai.
Comment recenser les cas d’utilisation
18
 L’ensemble des cas d’utilisation décrit exhaustivement les exigences fonctionnelles
du système.
 Chaque cas d’utilisation correspond à une fonction métier du système, selon le
point de vue d’un de ses acteurs
(exemple du distributeur de billet : Retirer de l’argent ou Distribuer de l’argent ).
 Aussi, pour identifier les cas d’utilisation, il faut se placer du point de vue de
chaque acteur et déterminer comment et surtout pourquoi il se sert du système.
 Il faut éviter les redondances et limiter le nombre de cas en se situant à un bon
niveau d’abstraction.
 Nommez les cas d’utilisation avec un verbe à l’infinitif suivi d’un complément en
vous plaçant du point de vue de l’acteur, et non pas de celui du système.
 Dans tous les cas, il faut bien garder à l’esprit qu’il n’y a pas de notion temporelle
dans un diagramme de cas d’utilisation.
Exemple 1
19
Exemple 2
20
 Une agence de voyages organise des voyages où l’hébergement se fait en
hôtel. Le client doit disposer d’un taxi quand il arrive à la gare pour se rendre à
l’hôtel
 Certains clients demandent à l’agent de voyages d’établir une facture
détaillée. Cela donne lieu à un nouveau cas d’utilisation appelé « Etablir une
facture détaillée». Comment mettre ce cas en relation avec les cas existants
 Le voyage se fait soit par avion, soit par train. Comment modéliser cela

Réserver une Réserver Réserver un


chambre d’hotel un taxi billet de train

Organiser un
voyage
Agent de
voyage
Exemple 2 (Correction)
21
22 Exemple 3

 Distributeur de billets

 Déterminer les cas d'utilisation d'un distributeur de billets. On


considère les scénarios où un client désire retirer de l'argent en
euros ou en dollars. Il faut traiter la situation où le stock de billets est
insuffisant. On s'intéresse également à la procédure d'identification
(de la carte et du client).
23 Exemple 3 (Correction)

Vous aimerez peut-être aussi