Sommaire

Analyse, Conception des

Systmes Informatiques

Diagrammes de
cas dutilisation
Use Case

Introduction
Acteurs
Cas dutilisation
Relations
Diagramme de cas d utilisation

O. Boissier, SMA/G2I/ENS Mines Saint-Etienne, Olivier.Boissier@emse.fr, Septembre 2004

Introduction

Objectifs

Cas dutilisation
Squences
Collaboration
Classes
Objets
tats/transitions
Activits
Composants
Dploiement

Introduction

Comportement du systme
Dvelopps par Ivar Jacobson.
Description du systme du point
de vue de lutilisateur
Pour mettre en vidence les
services rendus par le systme
Pour fixer le primtre entre le
systme et son environnement

Quelles fonctionnalits doivent tre fournies par le

systme ?
Les cas dutilisation:
Les utilisations du systme ( cas dutilisation)
dutilisation
Les limites (les
les acteurs)
acteurs
Les relations entre les cas et les acteurs ( diagramme de
cas dutilisation).
dutilisation

Les cas dutilisation servent communiquer autant

pour les usagers que pour les concepteurs, pour
spcifier les besoins.
4

Acteurs

Acteurs

Acteurs

Identification (1)

Les acteurs n appartiennent pas au systme,

MAIS ils interagissent avec celui-ci.
Ils fournissent de linformation en entre.
et/ou reoivent de linformation en sortie.

Bien identifier les acteurs admissibles, et valuer

comment ils vont interagir avec le systme.
Les acteurs ne sont pas forcment des personnes.
Possibilit de spcialiser des acteurs partir
dautres acteurs.

Qui est intress par un certain besoin ?

Par qui le systme est utilis dans lorganisation?
Qui bnficiera de lutilisation du systme ?
Qui fournira au systme linformation, qui lutilisera et
qui la maintiendra ?
Qui va supporter et maintenir le systme ?
Quelque chose est il produit automatiquement par le
systme?

Acteurs

Identification (2)

Acteurs

Reprsentation
Dans UML, l acteur est reprsent comme suit :

Acteurs principaux
personnes qui utilisent les fonctions principales du
systme

Acteurs secondaires
personnes qui effectuent des tches administratives ou
de maintenance

Matriel externe

Acteur

tudiant

Le nom de l acteur correspond au rle jou par la

personne
Un acteur a un nom et si possible une description

dispositifs matriels faisant partie du domaine de

l application

Autres systmes
7

Cas dutilisation

Cas dutilisation

Cas dutilisation

Identification

Classe de scnarios :
Modlisant un dialogue entre un acteur et le systme
Reprsentant une fonctionnalit offerte par le systme.

Scnario :
instance dun cas dutilisation
squence de transactions entre le systme et lacteur qui
mne un rsultat tangible pour un acteur.
Un use case comprend au moins deux scnarios: un o
tout se passe bien, et un autre o il y a problme.

Lensemble des cas dutilisation forme toutes les

faons dont le systme pourra tre utilis.
Un Use Case sert a beaucoup de choses : dlimiter le
systme, analyser les besoins, concevoir des
interfaces, distribuer le travail, prparer les tests.

Cas dutilisation

Reprsentation

10

Cas dutilisation

Cas dutilisation vs.

vs. Scnario

Dans UML, le cas dutilisation est reprsent par un

ovale:

cas d'utilisation

Quelles sont les tches de chaque acteur?

Est-ce quun acteur cre, enregistre, modifie,
enlve ou consulte une information dans le
systme?
Quel cas dutilisation sera responsable de
ces tches?
Quels cas dutilisation supportent ou
maintiennent le systme?

Un cas dutilisation est une famille de

scnarios (diag. squence)

Inscription des cours

Un cas dutilisation peut tre dcrit par :

Un nom unique, des acteurs, des conditions dentre, des
flots dvnements (scnarios), des conditions de sortie,
des besoins spcifiques,
11

12

Cas dutilisation

Exemple
Nom : Achat ticket
Acteur : Passager
Condition entre :
Passager devant le
distributeur de ticket.
Passager a
suffisamment dargent
pour acheter le ticket.
Condition de sortie :
Passager a le ticket.

Relations

Relations
Scenario :
1. Passager choisit le
nombre de zones
traverses.
2. Le distributeur affiche la
somme due.
3. Passager insre largent
correspondant au
moins la somme due.
4. Distributeur rend la
monnaie.
5. Distributeur donne le
ticket.

UML dfinit une relation de communication

entre acteur et cas dutilisation.
UML dfinit des types de liens entre les cas
dutilisation pour les structurer :
La relation <<extend>>.
La relation <<include>>
La relation de gnralisation

13

14

Relations

Relation de communication

Gestionnaire

Relations

Relation <<extend>>
Reprsentation de cas

Surveillance
stock

Passager

Achaticke
t

<<extend>>

TimeOut

La participation dun acteur est reprsente par une

ligne solide entre lacteur et le cas dutilisation.
Le sens de la flche indique l initiateur de
l interaction.
Cest la seule relation possible entre un acteur et les
cas dutilisation.

<<extend>>
<<extend>>

PlusDeTicke
t
15

<<extend>>

Annulatio
n

NoChange

exceptionnels ou rarement
appels, extensions de
comportement.
Les flots dvnements
exceptionnels sont factoriss
hors de la squence principale
dvnements pour gagner en
clart
Les Use cases reprsentant
des flots exceptionnels
peuvent tendre plus dun use
case.
Une condition est associe au
cas dutilisation tendue.
La relation <<extend>> est
oriente vers le use case
tendu.
16

Relations

Relation <<include>>

Relation <<generalize>>

<<include>>

Authenticate
with Pwd

reprsente un
comportement
factoris pour
rutilisation

Passager

AchatCarte

Authenticate
Authenticate
with Card

AchatTicket
<<include>>

<<extend>>

Orientation

<<extend>>

<<include>> vers le
use case utilis

Un cas dutilisation
peut prciser un
cas dutilisation
plus gnral.

La relation est
oriente du cas
dutilisation
spcialis vers le
cas dutilisation
gnral

(pas parce que cest

une exception)

<<include>>

RecueilArgen
t

Relations

Le use case Authenticate est un

use case de haut niveau qui
dcrit en termes gnraux le
processus dauthentification

Annulation

NoChange

17

18

Relations

Exemple

Diagramme Cas dutilisation

Diagramme de cas dutilisation

extends
Request Catalog

Place Order

<<include>>

<<include>>

Systme

<<include>>
Supply Customer
Data

Order Product

Arrange Payment

Pay Cash

Fonctionnalits
incluses

Use case de haut

niveau dcrivant
les capacits de
paiement

Selon la
demande du
client
(condition
dextension)

cas
dutilisation X
ActeurA
cas
dutilisation Y

Pay with card

19

ActeurB

20

Diagramme Cas dutilisation

Diagramme de cas dutilisation

Diagramme Cas dutilisation

Intrts
Analyse

exprime

comprend

Usager

Conception et
Implantation

Test

Analyste

Cas dutilisation

Les cas dutilisation servent de continuit

vrifie

implante

conoit

Programmeur

Capture, clarifie
et valide les cas
dutilisation.

Testeur

Implante les cas

dutilisation.

Vrifie que les

cas dutilisation
sont satisfaits.

Architecte
21

22

Diagramme Cas dutilisation

Construction

Diagramme Cas dutilisation

ATTENTION !

Dans un premier temps identifier les cas

dutilisation et les acteurs.
Dcrire ensuite un cas dutilisation en crivant des
scnarios sous la forme de texte ainsi que de
diagrammes dinteractions.
Faire un sommaire des scnarios principaux et des
cas dutilisation.
Sassurer finalement de la cohrence.
23

Les cas d utilisation ne sont qu une vue

externe et non un contrleur procdural
Le logiciel est souvent structur d une
manire totalement diffrente des cas
d utilisation
Les cas d utilisation ne sont qu une certaine
vision du logiciel !
Ils servent spcifier les besoins.
24

Exo 1 :

Exo 2 :

Lapplication doit permettre deux joueurs de faire une

partie de Puissance 4. On joue avec un tableau (cf. Fig).
Rgles du jeu : deux joueurs (jaune et rouge) jouent chacun
leur tour. A chaque coup, ils peuvent mettre une de leurs
pices dans une des colonnes du tableau qui nest pas
encore pleine. La pice tombe dans la case la plus basse
qui nest pas encore occupe dans la colonne. Ds quun
joueur a align soit horizontalement, verticalement ou en
diagonale, 4 de ses pices, il a gagn. Si aucun joueur ny
parvient et que le tableau est rempli, la partie est nulle.

Le systme gre un ensemble (une petite base de

donnes) de mots de passe et de noms dutilisateur
associs une application.
Le systme permet deffectuer quatre oprations savoir la
cration, la suppression, la modification et la recherche de
mots de passe dans la base.
La base se prsente comme un fichier crypt. Ainsi, celui-ci
doit tre dcrypt et r-encrypt chaque traitement.
Lutilisateur doit fournir la clef correspondante. Celle-ci est
donne une seule fois au lancement de lutilitaire qui la
mmorise jusqu la fin du traitement.

44

45

Exo 4 : Gestion des malades

dans un cabinet mdical

Exo 3 :

Un mdecin doit pouvoir

Systme de gestion de bibliothque qui doit

permettre des personnes dadhrer,
demprunter des livres. Linscription est
annuelle. Une personne non abonne ne
peut pas emprunter de livres. Un abonn
peut tout moment dcider de rsilier son
abonnement.

Crer des dossiers mdicaux de patients, les modifier,

les consulter et les supprimer, Crer des ordonnances,
les modifier, les imprimer et les supprimer, Crer et
modifier des instructions lattention du secrtariat,
Crer et modifier les informations sur le patient
(informations non mdicales)

Un secrtaire doit pouvoir

46

Crer et modifier les informations sur le patient

(informations non mdicales), diter une feuille de soin,
Imprimer un rcpiss lors de lencaissement dun
paiement, etc.

48

Exo 5 :

Lorsque le navigateur cre une applet, la mthode init() est

automatiquement appele. Le dveloppeur place dans cette mthode les
instructions d'initialisation et, en particulier, la prise en compte dventuels
paramtres. Juste aprs l'appel de init(), la mthode start() est
automatiquement appele. La mthode stop() est galement
automatiquement appele quand la page HTML contenant l'applet disparat
(changement de page par exemple) ou quand le navigateur est iconifi. Le
fait de stopper une applet suspend son excution, l'applet est dite alors en
sommeil et pourra tre ractive par un appel sa mthode start(). Les
mthodes start() et stop() peuvent tre appeles plusieurs fois. La mthode
paint(), est sollicite chaque fois que l'applet est dcouverte. Elle reoit en
argument un contexte graphique g, instance de classe Graphics, spcialis
dans des oprations de dessin. Lorsque le navigateur arrive en fin de vie (fin
de la tche d'excution lie la fermeture par l'utilisateur du navigateur par
exemple), la mthode destroy() est automatiquement appele. C'est ici que
le dveloppeur place le code ncessaire la libration de ressources
partageables comme, par exemple, la fermeture de fichiers ou la
dconnexion une base de donnes. Le garbage collector peut alors faire
son office.
49