Diagramme de Cas dutilisation
Motivation
Pourquoi les cas dutilisation :
"Un syst me est con u pour les utilisateurs :
" ils savent ce que le syst me doit faire mais pas comment le faire ;
" ils connaissent laspect fonctionnel du syst me.
Le syst me doit donc tre b ti partir des descriptions des
utilisateurs.
Diagramme des cas
dutilisation
Un diagramme de cas dutilisation est mod lis par :
des acteurs qui utilisent le syst me ;
les services offerts par le syst me.
" Int r t des cas dutilisation :
les use cases permettent de d limiter le syst me (les acteurs sont
lext rieur du syst me) ;
ils permettent de lever les ambigu t s du cahier des charges laide dun
formalisme graphique ;
les use cases peuvent servir concevoir les tests puisquils repr sentent
les utilisations nominales du syst me.
Initie le travail d quipe
Lutilisateur et le syst me
Use Case 1
Use Case 2
Services
Utilisateur
Use Case 3
Syst me
Diagramme de cas dutilisation r pond aux questions suivantes :
Quelles sont les t ches principales r alis es par les acteurs (entit s mat riels ou
logiciels externe au logiciel qui entrent en interaction) ?
Les informations manipul es par les acteurs ?
Les informations manipul es par le logiciel ?
Le diagramme contient les acteurs, les cas dutilisation (services)
et les applications.
Diagramme de cas dutilisation
Un diagramme de cas dutilisation :
d crit
le syst me
les acteurs
les cas dutilisation
contient
des descriptions textuelles
Principaux concepts des diagrammes de cas dutilisation
Acteurs
Syst me
Cas dutilisation
Relations (entre cas dutilisation, entre acteurs, entre acteurs
et cas dutilisation)
Le syst me
Le syst me est un ensemble de cas dutilisation
Le syst me ne comprend pas les acteurs.
Nom du syst me
Nom du
syst me
Le syst me
Le syst me est
mod lis par un ensemble de cas dutilisation
vu comme une bo te noire
Le syst me contient :
les cas dutilisation,
mais pas les acteurs.
Un mod le de cas dutilisation permet de d finir :
les fonctions essentielles du syst me,
les limites du syst me,
le syst me par rapport son environnement,
d limiter le cadre du projet !
Acteurs
Un Acteur = l ment externe qui interagit avec le syst me (prend des
d cisions, des initiatives. Il est "actif".)
r le quun "utilisateur" joue par rapport au syst me
Ex. : un client, un guichetier, un responsable maintenance, &
Acteurs
Un acteur est repr sent par:
un petit bonhomme (stick man) avec son nom dessous ou
par un rectangle contenant le mot-cl << actor>> avec son nom dessous ou
Par un m lange de ces 2 repr sentations
<<actor>>
Nom de lacteur
Nom de lacteur
Nom
acteur
acteur humain acteur non humain
Pour les identifier :
Quelles sont les entit s externes au syst me qui interagissent directement avec le syst me
?
Utilit des acteurs
La d finition dacteurs permet
didentifier les cas dutilisation
Ex. : que peut faire un guichetier ? un client ? le directeur ?
de voir le syst me de diff rents points de vues
de d terminer des droits dacc s par type dacteur
de fixer des ordres de priorit entre acteurs
...
Acteurs vs. utilisateurs
Ne pas confondre la notion d'Acteur et de personne
utilisant le syst me:
Une m me personne physique peut jouer le r le de plusieurs acteurs
Ex. : Maurice est un Chef dagence et est aussi un client de la banque.
Plusieurs personnes peuvent jouer un m me r le
Ex. : Paul et Pierre sont deux clients
Un acteur nest pas forc ment un tre humain ex: un
distributeur de billet peut tre vu comme un acteur
Le recensement des acteurs
qComment ?
Par un dialogue avec le client et les utilisateurs ;
en rep rant les fronti res du syst me.
qQui sont-ils ?
Des utilisateurs humains : utilisateurs du logiciel travers son interface graphique,
Advertisement
par exemple;
des p riph riques manipul s par le syst me (imprimantes, capteurs, & ) ;
des logiciels d j disponibles int grer dans le projet : disponibles qui
communiquent avec le syst me gr ce une interface logicielle (API, ODBC, &);
attention ne pas oublier les acteurs qui administrent le syst me ;
un m me utilisateur peut avoir plusieurs r les et tre plusieurs acteurs :
Acteurs
Secr taireEtudiantSyst me de Gestion Scolaire<<acteur>>Imprimante<<acteur>>Site Web de l' tablissementDiff rents types dacteurs
Utilisateurs principaux
ex: client, guichetier
Utilisateurs secondaires
ex: contr leur, directeur, ing nieur syst me, administrateur...
P riph riques externes
ex: un capteur, une horloge externe, &
Syst mes externes
ex: syst mes bancaires
Exemple: une biblioth que
Syst me
biblioth que
Chercheur
Bibliot caire
D partement
Exemple
Client
Exemple
Client
RetirerDeLArgentAu
Distributeur
Banque
Centrale
ConsulterSonCompte
RetirerLes
CartesAval es
Transporteur
DeBillets
Ajouter
DesBillets
Assurer
LaMaintenance
Technicien
DistributeurDeBillet
Acteurs
Mais du point de vue syst me on distingue deux types :
Acteurs principaux
Acteurs secondaires
Acteurs principaux et
secondaires
Acteur principal dun CU
Celui pour qui le CU produit un r sultat observable
A gauche des CU
R le indiqu ventuellement sur lassociation c t acteur : <<principal>>
(valeur par d faut)
Acteur secondaire dun CU
Celui pour qui le CU ne produit pas un r sultat observable par lutilisateur
Souvent sollicit s pour des informations compl mentaires
Peuvent uniquement consulter ou informer le syst me (pas dobjectif part
enti re de la part de lacteur secondaire)
A droite des CU
R le indiqu ventuellement sur lassociation c t acteur : <<secondaire>>
Ex. : syst me dauthentification appel par le distributeur de billets
Cas dutilisation (CU)
Cas dutilisation (CU)
une mani re dutiliser le syst me
une suite dinteractions entre un acteur et le syst me
Correspond une fonction du syst me visible par lacteur
Doit tre utile en soi
Permet un acteur datteindre un but
Regroupe un ensemble de sc narii correspondant un
m me but
Cas dutilisation: d finition
Description dun ensemble de s quences dactions, comportant
ventuellement des variantes, que le syst me ex cute pour produire un
r sultat tangible et qui a de la valeur pour lutilisateur.
Payer cotisation membre
Consulter catalogue
Enregistrer nouvel utlisateur
Emprunter un livre
R server un livre
Cas d'utilisation
Les cas dutilisations
Permettent de mod liser les attentes (besoins) des utilisateurs
Repr sentent les fonctionnalit s du syst me
Suite d v nements, initi e par des acteurs, qui correspond une
utilisation particuli re du syst me
Limage dune fonctionnalit du syst me, d clench e en r ponse la
stimulation dun acteur externe.
Cas d'utilisation
Un cas d'utilisation est repr sent par une ellipse en trait plein,
contenant son nom.
Nom Cas UtilisationRelations entre l ments de base
Relations acteurs <-> cas d'utilisation ?
Relations acteurs <-> acteurs ?
Relations cas d'utilisation <-> cas d'utilisation ?
Relation acteur - cas
d'utilisation
Point de vue besoin: Repr sente la possibilit d'atteindre
un but
Point de vue syst me: Repr sente un canal de
communication
change de messages, potentiellement dans les deux sens
Protocole particulier concernant le cas d'utilisation
consid r
Une relation de
communication
Client
RetirerDeLArgent
AuDistributeur
qAssociation acteur/CU vu comme un canal de communication
qD crit le comportement du syst me vu de l'exterieur
qEchange de messages
Advertisement
Client
RetirerDeLArgent
AuDistributeur
Diagramme de cas
d utilisation
Client
RetirerDeLArgentAu
Distributeur
ConsulterSonCompte
RetirerLes
CartesAval es
Transporteur
DeBillets
Ajouter
DesBillets
Assurer
LaMaintenance
Technicien
DistributeurDeBillets
Relation de communication
acteur-acteur
" Communications externes
non mod lis e
" UML se concentre sur la
description du syst me et
de ses interactions avec
l'ext rieur
Client
Guichetier
ConsulterSonCompte
RetirerDeLArgent
AuDistributeur
RetirerDeLArgent
ParCh que
Syst me
Bancaire
Relation acteur - acteur :
g n ralisation
qLa seule relation entre acteurs est la relation de g n ralisation
Cr erUnCompte
Guichetier
FermerUnCompte
RetirerDeLArgent
DUnCompte
AnnulerUnCompte
Guichetier
EnChef
Cr erUnCompte
FermerUnCompte
RetirerDeLArgent
DUnCompte
AnnulerUnCompte
Guichetier
Guichetier
EnChef
Relation acteur - acteur :
g n ralisation
Un acteur peut tre une sp cialisation d'un autre
acteur d j d fini.
Dans ce cas, on utilise la relation de
g n ralisation/sp cialisation.
Acteur g n ralActeur sp cialis Relations cas d'utilisation - cas d'utilisation
UML d finit trois types de relations standardis es entre cas d'utilisation :
Une relation d'inclusion, formalis e par la d pendance include
Une relation d'extension, formalis e par la d pendance extend
Une relation de g n ralisation/sp cialisation
Les relations entre cas
dutilisation
qLes trois types de relations sont :
qlinclusion (<<include>>)quand le cas source comprend le cas destination ;
qlextension (<<extends>>) quand le cas source ajoute optionnellement son comportement
au cas destination.
qla g n ralisation quand le cas enfant est une sp cialisation du cas parent ;
Exemple de relations entre cas d'utilisation :
inclusion, extension et sp cialisation
include
include
RetirerDeLArgent
extends
S'Identifier
include
Transferer
DeLArgent
extends
RetirerDeLArgent
AvecDiff r
RetirerDeLArgent
RetirerDeLArgent
RetirerDeLArgent
AuDistributeur
Relation d'inclusion
A inclut B : le cas A inclut obligatoirement le comportement d finit par
le cas B; permet de factoriser des fonctionnalit s partag es
Le cas d'utilisation point par la fl che (dans notre cas B) est une sous
partie de l'autre cas d'utilisation (A, dans notre exemple).
<<include>>ABRelation d'inclusion
Les cas d'utilisation "D poser de
l'argent", "Retirer de l'argent", "Effectuer
des virements" et "Consulter solde"
incorporent de fa on explicite le cas
d'utilisation "S'authentifier", un endroit
sp cifi dans leurs encha nements.
<<include>><<include>><<include>><<include>>Retirer de l'argentD poser de l'argentEffectuer des virementsConsulter soldeS'authentifierRelation d'inclusion
Remarques
La relation include na pour seul objectif que de factoriser une partie de
la description dun cas dutilisation qui serait commune dautres cas
dutilisation.
Le cas dutilisation inclus dans les autres cas dutilisation nest pas
proprement parl un vrai cas dutilisation car il na pas dacteur
d clencheur ou receveur d v nement. Il est juste un artifice pour faire
Advertisement
de la r utilisation dune portion de texte.
Relation d'extension
Le CU source (B) ajoute, sous certaines conditions, son comportement
au CU destination (A)
En dautres termes, le CU B peut tre appel au cours de lex cution du
CU A
Le comportement ajout sins re au niveau dun point dextension
d finit dans le CU destination
<<extend>>BAPoint d'insertionRelation d'extension
Le cas d'utilisation de destination peut fonctionner tout seul, mais il
peut galement tre compl t par un autre cas d'utilisation, sous
certaines conditions.
On utilise principalement cette relation pour s parer le comportement
optionnel (les variantes) du comportement obligatoire.
Relation d'extension
Exemple :
Au moment de l'authentification, il se peut que le guichet retire la carte.
<<extend>>Retenir la carteS'authentifierRelations dinclusion VS
d'extension
La relation extend" montre une possibilit d'ex cution d'interactions
qui augmenteront les fonctionnalit s du cas tendu, mais de fa on
optionnelle, non obligatoire,
La relation "include" suppose une obligation d'ex cution des
interactions dans le cas de base.
Relation d'h ritage
Il peut galement exister une relation d'h ritage entre cas d'utilisation.
Cette relation exprime une relation de sp cialisation/g n ralisation au
sens classique.
Relation d'h ritage : Exemple
Dans un syst me d'agence de voyage, un acteur
"Touriste" peut participer un cas d'utilisation de
base qui est "R server voyage", qui suppose par
exemple, des interactions basiques au comptoir
de l'agence. Une r servation peut tre r alis e
par t l phone ou par Internet.
Relation d'h ritage : Exemple
On voit qu'il ne s'agit pas d'une relation "extend", car la
r servation par Internet n' tend pas les interactions ni les
fonctionnalit s du cas d'utilisation "R server voyage".
Les deux cas d'utilisation "R servation voyage" et
"R server voyage par Internet" sont li s : la r servation
par Internet est un cas particulier de r servation.
De fa on g n rale en objet, une situation de cas
particulier se traduit par une relation de
g n ralisation/sp cialisation.
Relation d'h ritage : Exemple
Reserver voyageR server voyage par t l phoneR server voyage par InternetRelations entre cas
dutilisation
R sum
Les cas peuvent tre structur es par des relations :
A inclut B : le cas A inclut obligatoirement le comportement d finit par
le cas B; permet de factoriser des fonctionnalit s partag es
A tend B : le cas A est une extension optionnelle du cas B un certain
point de son ex cution.
A g n ralise B : le cas B est un cas particulier du cas A.
Description de l'interaction
Client
RetirerDeLArgent
AuDistributeur
Description du dialogue
"
"
via une description textuelle
ou
via des diagrammes de
s quences "syst mes"
L laboration des cas
dutilisation
qLes use cases peuvent tre d crits sous la forme de flots d v nements
de diff rentes fa ons :
Le distributeur affiche un message daccueil
demandant un client dintroduire sa carte
bancaire ;
" le client introduit sa carte bancaire ;
" le distributeur demande le mot de passe de la
carte ;
" ...
Sc nario
Pour d crire ou valider un CU
Un sc nario est un exemple :
une mani re particuli re dutiliser le syst me &
& par un acteur particulier &
& dans un contexte particulier.
cas dutilisation = ensemble de sc narios
sc nario = une ex cution particuli re dun CU
Exemples de sc narios
Appel t l phonique
Sc nario : le num ro appel est occup
L'appelant d croche le t l phone
L'appelant commence composer le num ro
L'appelant termine de composer le num ro
La tonalit "occup e" commence sonner
L'appelant raccroche le t l phone
Sc nario : le num ro appel n'est pas occup
L'appelant d croche le t l phone
L'appelant commence taper le num ro
L'appelant termine de taper le num ro
Le t l phone commence sonner
L'appel d croche
La conversation se d roule
L'appel raccroche le t l phone
L laboration des cas dutilisation
qUn cas dutilisation est g n ralement d crit par plusieurs sc nario :
qRegroupe une famille de sc narios dutilisation (cas nominal, alternatives, exceptions)
qEst une abstraction du dialogue syst me/utilisateurs qQuand un acteur interagit avec le
syst me:
qLe cas dutilisation instancie un
sc nario
Retirer
DeLArgent
Advertisement
AuDistributeur
Exemple de sc nario
SCENARIO
" Paul ins re sa carte dans le distributeur d103
" Le syst me accepte la carte et lit le num ro de compte
" Le syst me demande le code
" Paul tape 1234
" Le syst me indique que ce n est pas le bon code
" Le syst me affiche un message et propose de recommencer
" Paul tape 6222
" Le syst me affiche que le code est correct
" Le syst me demande le montant du retrait
" Paul tape 5000 Euros
" Le syst me v rifie s il y a assez d argent sur le compte
"...
Description Textuelle des cas
dutilisation
qIl nexiste pas de norme (UML) tablie pour la description textuelle des cas
dutilisation.
qG n ralement, on y trouve pour chaque cas dutilisation :
" son nom,
" un bref r sum de son d roulement,
"
le contexte dans lequel il sapplique,
"
les acteurs quil met en jeu,
" une description d taill e :
"
le d roulement nominal de toutes les interactions,
les cas n cessitant des traitements dexception,
les effets du d roulement sur lensemble du syst me,
"
"
" des contraintes,
" etc.
Description des cas
dutilisation
Sommaire didentification
Titre : &&&&&&.. Type : &&&&&&&
R sum :&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
Acteurs :
Date de cr ation : Date de mise
jour :&&&&&&&&&&&&&
Version : Auteur(s) :
Description des Encha nements :
Pr conditions :
Sc nario nominal :
1.
2.
&
Encha nements alternatifs / Exceptions:
A1&
A2&
Contraintes
&.
Exemple de
description d taill e d un CU
Pr condition :
Le distributeur contient des billets, il est en attente d une
op ration, il nest ni en panne, ni en maintenance
Retirer
DeLArgent
AuDistributeur
D but : lorsqu un client introduit sa carte bancaire dans le
distributeur.
Fin : lorsque la carte bancaire et les billets sont sortis.
Postcondition :
Si de l argent a pu tre retir la somme dargent sur le
compte est gale la somme d argent quil y avait avant,
moins le montant du retrait. Sinon la somme d argent sur le
compte est la m me quavant.
Exemple de
description d taill e d un CU
Retirer
DeLArgent
AuDistributeur
D roulement normal :
(1) le client introduit sa carte bancaire
(2) le syst me lit la carte et v rifie si la carte est valide
(3) le syst me demande au client de taper son code
(4) le client tape son code confidentiel
(5) le syst me v rifie que le code correspond la carte
(6) le client choisi une op ration de retrait
(7) le syst me demande le montant retirer
&
Variantes :
(A) Carte invalide : au cours de l tape (2) si la carte est
jug e invalide, le syst me affiche un message d erreur,
rej te la carte et le cas d utilisation se termine.
(B) Code erron : au cours de l tape (5) ...
Exemple de
description d taill e d un CU
Retirer
DeLArgent
AuDistributeur
Contraintes non fonctionnelles :
(A) Performance : le syst me doit r agir dans un d lai
inf rieur 4 secondes, quelque soit laction de l utilisateur.
(B) R sistance aux pannes : si une coupure de courant ou
une autre d faillance survient au cours du cas d utilisation,
la transaction sera annul e, l argent ne sera pas distribu .
Le syst me doit pouvoir red marrer automatiquement dans
un tat coh rent et sans intervention humaine.
(C) R sistance la charge : le syst me doit pouvoir g rer
plus de 1000 retraits d argent simultan ment
...