7466 Chap01 PDF

a pit re 1
C
c h
Diagramme de cas
dutilisation
UML permet de construire plusieurs modles dun systme : certains montrent le systme
du point de vue des utilisateurs, dautres montrent sa structure interne, dautres encore en
donnent une vision globale ou dtaille. Les modles se compltent et peuvent tre assem-
bls. Ils sont labors tout au long du cycle de vie du dveloppement dun systme (depuis
le recueil des besoins jusqu la phase de conception). Dans ce chapitre, nous allons tudier
un des modles, en loccurrence le premier construire : le diagramme de cas dutilisation.
Il permet de recueillir, danalyser et dorganiser les besoins. Avec lui dbute ltape danalyse
dun systme.
2010 Pearson Education France UML2, 3e dition Benot Charroux, Aomar Osmani, Yann Thierry-Mieg
Livre.indb 9 11/05/10 11:21:35

1. Limportance
L de bien recueillir
UML 2
les
l besoins
Le dveloppement dun nouveau systme, ou lamlioration dun systme existant, doit
rpondre un ou plusieurs besoins. Par exemple, une banque a besoin dun guichet
automatique pour que ses clients puissent retirer de largent mme en dehors des heures
douverture de la banque. Celui qui commande le logiciel est le matre douvrage. Celui
qui ralise le logiciel est le matre duvre.
Le matre douvrage intervient constamment au cours du projet, notamment pour :
dfinir et exprimer les besoins ;
valider les solutions proposes par le matre duvre ;
valider le produit livr.
Le matre duvre est, par exemple, une socit de services en informatique (SSII). Il a
t choisi, avant tout, pour ses comptences techniques. Mais son savoir-faire va bien
au-del. Au dbut du projet, il est capable de recueillir les besoins auprs du matre
douvrage. Le recueil des besoins implique une bonne comprhension des mtiers
concerns. Raliser un logiciel pour une banque, par exemple, implique la connaissance
du domaine bancaire et lintgration de toutes les contraintes et exigences de ce mtier.
Cette condition est ncessaire pour bien cerner les cas dutilisation exprims par le client
afin dapporter les solutions adquates.
Chaque cas a ses particularits lies au mtier du client. Le recueil des besoins peut
soprer de diffrentes faons. Cela dit, il est recommand de complter le cahier des
charges par des discussions approfondies avec le matre douvrage et les futurs utilisa-
teurs du systme. Il convient galement dutiliser tous les documents produits propos
du sujet (rapports techniques, tude de march) et dtudier les procdures adminis-
tratives des fonctions de lentreprise qui seront prises en charge par le systme. La ques-
tion que doit se poser le matre duvre durant le recueil des besoins est la suivante :
ai-je toutes les connaissances et les informations pour dfinir ce que doit faire le
systme
y ?
2. Le
L diagramme de cas
dutilisation
d
2.1. Les cas dutilisation
Parlons prsent dUML et voyons quelle aide il peut apporter lors du recueil des
besoins. UML nest quun langage et il ne sert ici qu formaliser les besoins, cest--dire
les reprsenter sous une forme graphique suffisamment simple pour tre comprhen-
sible par toutes les personnes impliques dans le projet. Noublions pas que bien souvent,
le matre douvrage et les utilisateurs ne sont pas des informaticiens. Il leur faut donc un
10
Livre.indb 10 11/05/10 11:21:35

Chapitre 1 Diagramme de cas dutilisation
moyen simple dexprimer leurs besoins. Cest prcisment le rle des diagrammes de cas
dutilisation. Ils permettent de recenser les grandes fonctionnalits dun systme.
Exemple
La figure 1.1 modlise une borne interactive qui permet daccder une banque. Le systme
modliser apparat dans un cadre (cela permet de sparer le systme modliser du monde
extrieur). Les utilisateurs sont reprsents par des petits bonshommes, et les grandes fonction-
nalits (les cas dutilisation) par des ellipses.
Figure 1.1 frontire du sujet Borne interactive dune banque nom du sujet
Diagramme
de cas dutilisation
modlisant une borne Retirer argent cas dutilisation
acteur
daccs
une banque.
Effectuer un virement
Client Consulter comptes
association
Lensemble des cas dutilisation contenus dans le cadre constitue un sujet . Les petits
bonshommes sont appels acteurs . Ils sont connects par de simples traits (appels
associations ) aux cas dutilisation et mettent en vidence les interactions possibles
entre le systme et le monde extrieur. Chaque cas modlise une faon particulire et
cohrente dutiliser un systme pour un acteur donn.
Dfinition
Un cas dutilisation est une manire spcifique dutiliser un systme. Les acteurs sont lextrieur
du systme ; ils modlisent tout ce qui interagit avec lui. Un cas dutilisation ralise un service de
bout en bout, avec un dclenchement, un droulement et une fin, pour lacteur qui linitie.
Notation et spcification
Un cas dutilisation se reprsente par une ellipse (figure 1.2). Le nom du cas est inclus dans lel-
lipse ou bien il figure dessous. Un strotype (voir la dfinition ci-aprs), peut tre ajout option-
nellement au-dessus du nom, et une liste de proprits place au-dessous.
Un cas dutilisation se reprsente aussi sous la forme dun rectangle deux compartiments : celui
du haut contient le nom du cas ainsi quune ellipse (symbole dun cas dutilisation) ; celui du bas
est optionnel et peut contenir une liste de proprits (figure 1.3).
Un acteur se reprsente par un petit bonhomme ayant son nom inscrit dessous (figure 1.1) ou
par un rectangle contenant le strotype acteur avec son nom juste en dessous (figure 1.4). Il est
recommand dajouter un commentaire sur lacteur pour prciser son rle.
Figure 1.2 et 1.3

strotype Nom du cas
Reprsentations dun
Nom du cas
cas dutilisation. Liste de proprits
Liste de proprits
11
Livre.indb 11 11/05/10 11:21:35

UML 2
Figure 1.4 Rle de lacteur

Autre reprsentation
dun acteur. acteur
Nom de lacteur
La figure 1.4 reprsente un acteur par un rectangle. UML utilise aussi les rectangles
pour reprsenter des classes, et plus gnralement des classeurs. Pour autant, la notation
nest pas ambigu puisque le strotype acteur indique que le rectangle dsigne un
acteur. Les strotypes permettent dadapter le langage des situations particulires.
Dfinition
Un strotype reprsente une variation dun lment de modle existant.
un niveau dabstraction plus lev, UML permet de reprsenter tous les cas dutilisa-
tion dun systme par un simple rectangle. La figure 1.5 montre comment un tel rectan-
gle peut remplacer tous les cas dutilisation de la figure 1.1.
Figure 1.5
Borne interactive dune banque
Reprsentation des cas
dutilisation un niveau
dabstraction lev.
Le rectangle de la figure 1.5 est appel classeur .

Dfinition
Un classeur est un lment de modlisation qui dcrit une unit comportementale ou structu-
relle. Les acteurs et les cas dutilisation sont des classeurs. Tout au long de ce livre, on retrouvera
le terme classeur car cette notion englobe aussi les classes, des parties dun systme, etc.
Notation
Un classeur se reprsente par un rectangle contenant ventuellement des compartiments (la
figure 1.6 montre comment il est possible de faire figurer explicitement des cas dutilisation dans
un classeur).
Figure 1.6
Les compartiments dun
classeur.
Retirer argent
Consulter comptes
12
Livre.indb 12 11/05/10 11:21:35

2.2. Relations entre acteurs et cas dutilisation
Un acteur peut utiliser plusieurs fois le mme cas dutilisation.
Exemple
La figure 1.7 montre un internaute qui tlcharge plusieurs morceaux de musique sur Internet.
Figure 1.7 Logiciel de tlchargement

Association avec
multiplicit.
Tlcharger une musique
*
Internaute
Le symbole * qui signifie plusieurs est ajout lextrmit du cas et sappelle une
multiplicit. Plusieurs valeurs sont possibles pour la multiplicit : exactement n scrit
tout simplement n, m..n signifie entre m et n, etc. Prciser une multiplicit sur une rela-
tion nimplique pas ncessairement que les cas sont utiliss en mme temps.
2.3. Relations entre cas dutilisation

Pour clarifier un diagramme, UML permet dtablir des relations entre les cas dutilisa-
tion. Il existe principalement deux types de relations : les dpendances strotypes et la
gnralisation/spcialisation. Les dpendances strotypes sont des dpendances dont
la porte est explicite par le nom du strotype. Les strotypes les plus utiliss sont
linclusion et lextension.
La relation dinclusion. Un cas A est inclus dans un cas B si le comportement dcrit
par le cas A est inclus dans le comportement du cas B : on dit alors que le cas B
dpend de A. Cette dpendance est symbolise par le strotype inclut. Par exemple,
laccs aux informations dun compte bancaire inclut ncessairement une phase
dauthentification avec un mot de passe (figure 1.8).
La relation dextension. Si le comportement de B peut tre tendu par le comporte-
ment de A, on dit alors que A tend B. Une extension est souvent soumise condi-
tion. Graphiquement, la condition est exprime sous la forme dune note. La figure
1.8 prsente lexemple dune banque o la vrification du solde du compte ninter-
vient que si la demande de retrait dargent dpasse 20 euros.
La relation de gnralisation. Un cas A est une gnralisation dun cas B si B est un
cas particulier de A. la figure 1.8, la consultation dun compte bancaire via Internet
est un cas particulier de la consultation. Cette relation de gnralisation/spcialisa-
tion est prsente dans la plupart des diagrammes UML et se traduit par le concept
dhritage dans les langages orients objet.
Les inclusions permettent aussi de dcomposer un cas complexe en sous-cas plus simples.
Exemple
la figure 1.9, le modlisateur a jug que la vente dun article par correspondance est un problme
complexe et quil est important de faire apparatre dans le modle une dcomposition en sous-cas.
13
Livre.indb 13 11/05/10 11:21:35

UML 2
Notation et spcification
Une dpendance se reprsente par une flche pointille. Un strotype est souvent ajout au-
dessus du trait.
Le strotype inclut indique que la relation de dpendance est une inclusion (figures 1.8 et 1.9).
Le strotype tend indique une extension (figure 1.8). Lextension peut intervenir un point
prcis du cas tendu ; ce point sappelle le point dextension ; il porte un nom, qui figure dans un
compartiment du cas tendu sous la rubrique point dextension , et est ventuellement asso-
ci une contrainte indiquant le moment o lextension intervient. Une extension est souvent
soumise une condition (indique dans une note attache la flche pointille).
Le symbole utilis pour la gnralisation est une flche en traits pleins dont la pointe est un
triangle ferm. La flche pointe vers le cas le plus gnral (figure 1.8).
Figure 1.8
Relations entre
Retirer argent
cas dans un
diagramme de cas
dutilisation.
Point dextension : inclut
vrificationSolde {aprs
avoir demand le
montant} inclut
tend Sauthentifier
Client
Vrifier le solde
Condition : {si montant > 20 euros}
Point dextension : vrificationSolde
inclut
Consulter comptes
Consulter sur Internet
Figure 1.9 Systme de vente par correspondance

Relations entre cas
pour dcomposer
un cas complexe. Vrifier la disponibilit
de larticle
inclut
Passer une commande
inclut
Prpos aux
commandes
Vrifier la solvabilit du client
Un cas reli un autre cas peut ne pas tre directement accessible un acteur (figure 1.9).
Un tel cas est appel cas interne .
14
Livre.indb 14 11/05/10 11:21:35

Dfinition
Un cas dutilisation est dit interne sil nest pas reli directement un acteur.
Les relations entre cas ne sont pas obligatoires. Elles permettent de clarifier et denrichir
les cas dutilisation. Par exemple, la figure 1.8, rien nempche de regrouper les cas
Consulter comptes et Consulter sur Internet en un seul cas. Cependant, indiquer
ds la phase de recueil des besoins quil y a des cas particuliers apporte une information
supplmentaire pertinente. La question se poser est : faut-il la faire figurer dans le
diagramme de cas dutilisation ou la prendre en compte plus tard ? La rponse cette
question ne sera pas toujours la mme selon le contexte du projet.
Remarque
Attention lorientation des flches : si le cas A inclut B on trace la flche de A vers B, mais si B
tend A, la flche est dirige de B vers A.
2.4. Relations entre acteurs

La seule relation possible entre deux acteurs est la gnralisation : un acteur A est une
gnralisation dun acteur B si lacteur A peut tre substitu par lacteur B (tous les cas
dutilisation accessibles A le sont aussi B, mais linverse nest pas vrai).
Exemple
La figure 1.10 montre que le directeur des ventes est un prpos aux commandes avec un pou-
voir supplmentaire (en plus de pouvoir passer et suivre une commande, il peut grer le stock).
Le prpos aux commandes ne peut pas grer le stock.
Figure 1.10 Systme de vente par correspondance

Relations entre
acteurs.
Passer une commande

inclut
Suivre une commande Rechercher article

Prpos aux inclut
commandes
inclut
Grer le stock
Directeur
des ventes
Notation
Le symbole utilis pour la gnralisation entre acteurs est une flche en traits pleins dont la
pointe est un triangle ferm. La flche pointe vers lacteur le plus gnral.
15
Livre.indb 15 11/05/10 11:21:35

UML 2
2.5. Regroupement des cas dutilisation en paquetages

UML permet de regrouper des cas dutilisation dans une entit appele paquetage . Le
regroupement peut se faire par acteur ou par domaine fonctionnel. Un diagramme de
cas dutilisation peut contenir plusieurs paquetages et des paquetages peuvent tre inclus
dans dautres paquetages.
Dfinition
Un paquetage permet dorganiser des lments de modlisation en groupe. Un paquetage peut
contenir des classes, des cas dutilisations, des interfaces, etc.
Exemple
la figure 1.11, trois paquetages ont t crs : Client, Stock et Support. Ces paquetages contien-
nent les cas dutilisation du diagramme de la figure 1.10 (Client contient les cas Passer une
commande et Suivre une commande , Stock contient le cas Grer le stock , tandis que le
cas Rechercher article est inclus dans le paquetage Support.
Figure 1.11 Dpendance
Regroupement des Client entre paquetages
cas dutilisation en qui reflte
paquetage. linclusion des
cas dutilisation.
Support
Stock
En tant que langage, UML est soumis des rgles de nommage quil faut strictement
respecter : pour accder au contenu de paquetages imbriqus les uns dans les autres, il
faut utiliser des deux-points comme sparateur des noms de paquetage. Par exemple, si
un paquetage B inclus dans un paquetage A contient une classe X, il faut crire A::B::X
pour pouvoir utiliser la classe X en dehors du contexte des paquetages.
3. M
Modlisation des besoins
avec
a UML
3.1. Qui sont les acteurs ? Comment les identifier ?
Les principaux acteurs sont les utilisateurs du systme. Ils sont en gnral faciles rep-
rer. Cest le matre douvrage qui les dsigne. Chaque acteur doit tre nomm, mais atten-
tion, pour trouver son nom, il faut penser son rle : un acteur reprsente un ensemble
cohrent de rles jous vis--vis dun systme. Ainsi, pour un logiciel de gestion de paie,
16
le nom correct dun acteur est Comptable plutt que Mme Dupont. Plusieurs personnes
Livre.indb 16 11/05/10 11:21:35

peuvent avoir le mme rle. Cest le cas des clients dune banque par exemple. Il ny aura
alors quun seul acteur. Rciproquement, une mme personne physique peut jouer des
rles diffrents vis--vis du systme et donc correspondre plusieurs acteurs.
En gnral, les utilisateurs ne sont pas difficiles trouver, mais il faut veiller ne pas
oublier les personnes responsables de lexploitation et de la maintenance du systme. Par
exemple, un logiciel de surveillance qui limite les accs un btiment doit avoir un
administrateur charg de crer des groupes de personnes et leur donner des droits dac-
cs. Il ne sagit pas ici des personnes qui installent et paramtrent le logiciel avant sa mise
en production, mais des utilisateurs du logiciel dans son fonctionnement nominal.
En plus des utilisateurs, les acteurs peuvent tre :
des priphriques manipuls par le systme (imprimantes, robots) ;
des logiciels dj disponibles intgrer dans le projet ;
des systmes informatiques externes au systme mais qui interagissent avec lui, etc.
Pour faciliter la recherche des acteurs, on peut imaginer les frontires du systme. Tout
ce qui est lextrieur et qui interagit avec le systme est un acteur ; tout ce qui est
lintrieur est une fonctionnalit du systme que le matre duvre doit raliser.
Un cas dutilisation a toujours au moins un acteur principal pour qui le systme produit
un rsultat observable, et ventuellement dautres acteurs ayant un rle secondaire. Par
exemple, lacteur principal dun cas de retrait dargent dans un distributeur automati-
que de billets est la personne qui fait le retrait, tandis que la banque qui vrifie le solde
du compte est un acteur secondaire. En gnral, lacteur principal initie le cas dutilisa-
tion par ses sollicitations.
Dfinition
Lacteur est dit principal pour un cas dutilisation lorsque le cas dutilisation rend service
cet acteur. Les autres acteurs sont dits secondaires . Un cas dutilisation a au plus un acteur
principal, et un ensemble ventuellement vide dacteurs secondaires.
Un acteur principal obtient un rsultat observable du systme tandis quun acteur secondaire
est sollicit pour des informations complmentaires.
3.2. Comment recenser les cas dutilisation ?

Il ny a pas une faon unique de reprer les cas dutilisation. Il faut se placer du point de
vue de chaque acteur et dterminez comment il se sert du systme, dans quels cas il
lutilise, et quelles fonctionnalits il doit avoir accs. Il faut viter les redondances et
limiter le nombre de cas en se situant au bon niveau dabstraction (par exemple, ne pas
rduire un cas une action).
Exemple
Considrons un systme de rservation et dimpression de billets de train via des bornes inter-
actives situes dans des gares. En prenant pour acteur une personne qui souhaite obtenir un
billet, on peut obtenir la liste suivante des cas dutilisation :
rechercher un voyage ;
rserver une place dans un train ;
acheter son billet.
17
Livre.indb 17 11/05/10 11:21:35

Lensemble des cas dutilisation doit couvrir exhaustivement tous les besoins fonction-
UML 2
nels du systme. Ltape de recueil des besoins est souvent longue et fastidieuse car les
utilisateurs connaissent lexistant et nont quune vague ide de ce que leur apportera un
futur systme ; en outre, le cahier des charges contient des imprcisions, des oublis, voire
des informations contradictoires difficiles extraire. Llaboration du diagramme de
cas dutilisation permet de pallier ces problmes en recentrant le systme sur les besoins
fonctionnels et ce, ds le dbut du projet.
On peut se demander pourquoi adopter un point de vue fonctionnel, et non technique ?
Trop souvent, par le pass, les logiciels taient techniquement trs labors sans pour
autant satisfaire les utilisateurs. Avec les diagrammes de cas dutilisation, on se place clai-
rement du ct des utilisateurs. Le ct technique nest pas oubli mais abord diffrem-
ment : les besoins sont affins lors de lcriture des spcifications on parle de spcifications
techniques des besoins (voir la section Description textuelle des cas dutilisation ).
Remarque
Il ne faut pas faire apparatre les dtails des cas dutilisation, mais il faut rester au niveau des
grandes fonctions du systme. La question qui se pose alors est de savoir jusqu quel niveau
de dtails descendre ? Si le nombre de cas est trop important, il faut se demander si on a fait
preuve de suffisamment dabstraction. Le nombre de cas dutilisation est un bon indicateur de
la faisabilit dun logiciel.
Il ne doit pas y avoir de notion temporelle dans un diagramme de cas dutilisation. Il ne faut pas
se dire que lacteur fait ceci, puis le systme lui rpond cela, ce qui implique une raction de
lacteur, et ainsi de suite. Le squencement temporel sera pris en compte plus tard, notamment
dans la description dtaille des cas (voir section 3.3).
Lintrt des cas dutilisation ne se limite pas au recueil des besoins. La description des cas dutili-
sation peut servir de base de travail pour tablir les tests de vrification du bon fonctionnement
du systme, et orienter les travaux de rdaction de la documentation lusage des utilisateurs.
3.3. Description des cas dutilisation

Le diagramme de cas dutilisation dcrit les grandes fonctions dun systme du point de
vue des acteurs, mais nexpose pas de faon dtaille le dialogue entre les acteurs et les
cas dutilisation.
Exemple
Lexemple de la figure 1.12 ne permet pas de savoir ce qui entre et ce qui sort du logiciel ban-
caire : le retrait dargent se fait-il en euros ou en dollars ? Dans quel ordre les oprations sont-el-
les effectues ? Faut-il choisir le montant du retrait avant de choisir le compte dbiter, ou bien
linverse ? Tous ces dtails sont des lments de spcification. Spcifier un produit, cest le dcrire
de la faon la plus prcise possible.
Figure 1.12 Gestion dune banque

Diagramme de cas
dutilisation pour une
banque. Retirer argent
Guichetier Consulter compte Systme

central
18
Livre.indb 18 11/05/10 11:21:35

Les spcifications peuvent tre divises en deux catgories selon quelles sont fonction-
nelles ou techniques. Les spcifications fonctionnelles concernent les fonctions du sys-
tme, la fonction de retrait dargent par exemple, tandis que les spcifications techniques
permettent de prciser le contexte dexcution du systme. Par exemple, le logiciel qui
gre la distribution des billets doit tre compatible avec tel ou tel systme dexploitation,
ou encore, un retrait dargent doit se faire en moins de 5 secondes.
Les spcifications fonctionnelles dcoulent directement du diagramme de cas dutilisa-
tion. Il sagit de reprendre chaque cas et de le dcrire trs prcisment. En dautres ter-
mes, vous devez dcrire comment les acteurs interagissent avec le systme.
Exemple
partir du diagramme de cas dutilisation de lexemple prcdent, la figure 1.13 montre une
faon de dcrire les interactions entre le guichetier et le systme. On y voit clairement apparatre
une squence de messages.
Le graphisme utilis fait partie du formalisme des diagrammes de squence (voir chapitre 3).
Figure 1.13
sd Retirer argent
Description dun
cas dutilisation
par une squence
de messages. : Systme
Guichetier Systme
central
Saisie du numro de compte client
Demande de validit du compte
Compte valide
Demande type dopration
Retrait despces de 200 euros
Demande de dbit du compte
Compte dbit
Autorisation de dlivrer les 200 euros
Les diffrentes faons de dcrire les cas dutilisation

UML nimpose rien quant la faon de dcrire un cas dutilisation. Au lieu dutiliser une
squence de messages, il est possible dutiliser les diagrammes dactivits dUML (voir cha-
pitre 5). Cette libert de choix peut tre droutante, mais comme UML est cens pouvoir
modliser tout type de systme, une manire unique de dcrire un cas ne suffirait pas.
Remarque
Une des forces de la notation UML est de proposer de nombreux types de diagrammes qui met-
tent en avant des aspects diffrents dune description. Ainsi, le modlisateur peut utiliser le type
de diagramme qui lui parat le plus adapt pour reprsenter son problme (et sa solution), tout
en restant dans la norme.
19
Livre.indb 19 11/05/10 11:21:36

UML 2
Description textuelle des cas dutilisation

Bien que de nombreux diagrammes dUML permettent de dcrire un cas, il est
recommand de rdiger une description textuelle car cest une forme souple qui
convient dans bien des situations. Une description textuelle couramment utilise se
compose de trois parties, comme le montre lexemple suivant. La premire partie
permet didentifier le cas. Elle doit contenir :
le nom du cas ;
un rsum de son objectif ;
les acteurs impliqus (principaux et secondaires) ;
les dates de cration et de mise jour de la description courante ;
le nom des responsables ;
un numro de version.
La deuxime partie contient la description du fonctionnement du cas sous la forme dune
squence de messages changs entre les acteurs et le systme. Elle contient toujours une
squence nominale qui correspond au fonctionnement nominal du cas (par exemple, un
retrait dargent qui se termine par lobtention des billets demands par lutilisateur).
Cette squence nominale commence par prciser lvnement qui dclenche le cas (luti-
lisateur introduit sa carte bancaire par exemple) et se dveloppe en trois points :
Les pr-conditions. Elles indiquent dans quel tat est le systme avant que se droule
la squence (le distributeur est aliment en billets par exemple).
Lenchanement des messages.
Les post-conditions. Elles indiquent dans quel tat se trouve le systme aprs le
drouement de la squence nominale (une transaction a t enregistre par la ban-
que par exemple).
Parfois la squence correspondant un cas a besoin dtre appele dans une autre
squence (par exemple quand une relation dinclusion existe entre deux cas dutilisa-
tion). Signifier lappel dune autre squence se fait de la faon suivante : appel du cas
X , o X est le nom du cas.
Les acteurs ntant pas sous le contrle du systme, ils peuvent avoir des comportements
imprvisibles. La squence nominale ne suffit donc pas pour dcrire tous les comporte-
ments possibles. la squence nominale sajoutent frquemment des squences alternati-
ves et des squences dexceptions. Ces deux types de squences se dcrivent de la mme
faon que la squence nominale mais il ne faut pas les confondre. Une squence alternative
diverge de la squence nominale (cest un embranchement dans une squence nominale)
mais y revient toujours, alors quune squence dexception intervient quand une erreur se
produit (le squencement nominal sinterrompt, sans retour la squence nominale).
Exemple
Dans le cas dun retrait dargent, des squences alternatives se produisent par exemple dans les
situations suivantes :
Le client choisit deffectuer un retrait en euros ou en dollars.
Le client a la possibilit dobtenir un reu.
Une exception se produit si la connexion avec le systme central de la banque qui doit vrifier la
validit du compte est interrompue.
20
Livre.indb 20 11/05/10 11:21:36

La survenue des erreurs dans les squences doit tre signale de la faon suivante : appel
de lexception Y o Y est le nom de lexception.
La dernire partie de la description dun cas dutilisation est une rubrique optionnelle.
Elle contient gnralement des spcifications non fonctionnelles (ce sont le plus souvent
des spcifications techniques, par exemple pour prciser que laccs aux informations
bancaires doit tre scuris). Cette rubrique contient aussi dventuelles contraintes
lies aux interfaces homme-machine (par exemple, pour donner la possibilit daccder
tous les comptes dun utilisateur partir de lcran principal).
Description dun retrait dargent

Identification
Nom du cas : retrait despces en euros.
But : dtaille les tapes permettant un guichetier deffectuer lopration de retrait deuros de-
mand par un client.
Acteur principal : Guichetier.
Acteur secondaire : Systme central.
Date : le 18/02/2005.
Responsable : M. Dupont.
Version : 1.0.
Squencement
Le cas dutilisation commence lorsquun client demande le retrait despces en euros.
Pr-conditions
Le client possde un compte (donne son numro de compte).
Enchanement nominal
1. Le guichetier saisit le numro de compte client.
2. Lapplication valide le compte auprs du systme central.
3. Lapplication demande le type dopration au guichetier.
4. Le guichetier slectionne un retrait despces de 200 euros.
5. Lapplication demande au systme central de dbiter le compte.
6. Le systme notifie au guichetier quil peut dlivrer le montant demand.
Post-conditions
Le guichetier ferme le compte.
Le client rcupre largent.
Rubriques optionnelles
Contraintes non fonctionnelles
Fiabilit : les accs doivent tre extrmement srs et scuriss.
Confidentialit : les informations concernant le client ne doivent pas tre divulgues.
Contraintes lies linterface homme-machine
Donner la possibilit daccder aux autres comptes du client.
Toujours demander la validation des oprations de retrait.
La squence nominale, les squences alternatives, les exceptions, etc., font quil existe
une multitude de chemins depuis le dbut du cas jusqu la fin. Chaque chemin est
appel scnario . Un systme donn gnre peu de cas dutilisation, mais, en gnral,
beaucoup de scnarios.
21
Livre.indb 21 11/05/10 11:21:36

UML 2
Remarque
Parfois, les utilisateurs ont du mal dcrire un cas sous une forme textuelle. Il est alors judi-
cieux de se servir dune autre forme de description, en utilisant un organigramme ou encore
en construisant des maquettes des interfaces homme-machine. Le dessin, mme sommaire, de
laspect des crans des interfaces permet de fixer les ides ; il offre une excellente base pour la
discussion avec le matre douvrage, qui le considre comme plus parlant .
Conclusion
Les phases de recueil des besoins et dcriture des spcifications sont longues et fasti-
dieuses. Mais quand elles sont bien menes, elles permettent de lever toutes les ambigu-
ts du cahier des charges et de recueillir les besoins dans leurs moindres dtails. Les
spcifications permettant dapprofondir les besoins (on parle dailleurs juste titre de
spcifications techniques des besoins), la frontire entre ces deux notions est floue.
Il nest pas question ce moment de la modlisation de limiter les besoins. Du ct du
matre duvre, la tendance est les limiter des fonctionnalits essentielles, tandis que
le matre douvrage, et surtout les utilisateurs, ont tendance en exprimer bien plus quil
nest possible den raliser. Le matre duvre doit faire preuve ici de patience et mener
la phase de spcifications de tous les besoins jusqu son terme. Cest ce moment seu-
lement, que des priorits sont mises sur les spcifications. Le matre duvre tente alors
dagencer les besoins de faon cohrente et fait plusieurs propositions de solutions au
matre douvrage, qui couvrent plus ou moins de besoins. UML ne propose rien pour
mettre des priorits sur les spcifications.
Le diagramme de cas dutilisation est un premier modle dun systme. Que savons-
nous sur le systme aprs avoir cr ce diagramme ? Sur le systme lui-mme, en interne,
pas grand-chose vrai dire. Cest encore une bote noire larchitecture et au mode de
fonctionnement interne inconnus. Donc, a fortiori, ce stade, nous ne savons toujours
pas comment le raliser. En revanche, son interface avec le monde qui lentoure est par-
tiellement connue : nous nous sommes placs du point de vue des acteurs pour dfinir
les spcifications fonctionnelles. Il faut sattarder un instant sur lexpression partielle-
ment connue pour mesurer les limites du modle des cas dutilisation. Les spcifica-
tions fonctionnelles disent ce que le systme doit faire pour les acteurs. En dautres
termes, nous connaissons prcisment ce qui entre et ce qui sort du systme, mais, en
revanche, nous ne savons toujours pas comment raliser cette interface avec lextrieur.
Lobjectif de cette phase de la modlisation est donc de clairement identifier les fronti-
res du systme et les interfaces quil doit offrir lutilisateur. Si cette tape commence
avant la conception de larchitecture interne du systme, il est en gnral utile, quand la
rflexion est suffisamment pousse, de poser les bases de la structure interne du sys-
tme, et donc dalterner analyse des besoins et bauche des solutions envisages.
Aux spcifications fonctionnelles sajoutent des spcifications techniques qui peuvent
tre vues comme des exigences pour la future ralisation.
Le prsent chapitre se poursuit par une srie de problmes corrigs. Le chapitre 2, quant
lui, prsente le diagramme des classes, qui permet de modliser la structure interne
22 dun systme.
Livre.indb 22 11/05/10 11:21:36

Problmes et exercices
La construction dun diagramme de cas dutilisation dbute par la recherche des frontires
du systme et des acteurs, pour se poursuivre par la dcouverte des cas dutilisation. Lordre
des exercices suit cette progression. Llaboration proprement dite dun diagramme de cas
dutilisation est illustre par plusieurs exercices. Ce chapitre se termine par des tudes de
cas de complexits croissantes.
Exercice 1 : Identification des acteurs et recensement

de cas dutilisation simples
Considrons le systme informatique qui gre une station-service de distribution

dessence. On sintresse la modlisation de la prise dessence par un client.
1. Le client se sert de lessence de la faon suivante. Il prend un pistolet accroch
une pompe et appuie sur la gchette pour prendre de lessence. Qui est lacteur
du systme ? Est-ce le client, le pistolet ou la gchette ?
2. Le pompiste peut se servir de lessence pour sa voiture. Est-ce un nouvel acteur ?
3. La station a un grant qui utilise le systme informatique pour des oprations de
gestion. Est-ce un nouvel acteur ?
4. La station-service a un petit atelier dentretien de vhicules dont soccupe un
mcanicien. Le grant est remplac par un chef datelier qui, en plus dassurer la
gestion, est aussi mcanicien. Comment modliser cela ?
Solution
11. Pour le syst

systme informatique qui pilote la station-service, le pistolet et la gchette sont
des priphriques matriels. De ce point de vue, ce sont des acteurs. Il est nanmoins
ncessaire de consigner dans le systme informatique ltat de ces priphriques : ds
quun client prend le pistolet par exemple, le systme doit informer le pompiste en indi-
quant le type dessence choisi. Pistolet et gchette doivent donc faire partie du systme
modliser. Ici, nous sommes face deux options contradictoires : soit le pistolet et la
gchette sont des acteurs, soit ils ne le sont pas. Pour lever cette ambigut, il faut adopter
le point de vue du client. Le client agit sur le systme informatique quand il se sert de
lessence. Laction de se servir constitue une transaction bien isole des autres fonction-
nalits de la station-service. Nous disons donc que Se servir est un cas dutilisation.
Le client, qui est en dehors du systme, devient alors lacteur principal, comme le
montre la figure 1.14. Ce cas englobe la prise du pistolet et lappui sur la gchette. Ces
priphriques ne sont plus considrs comme des acteurs ; sils ltaient, la modlisa-
tion se ferait un niveau de dtails trop important.
Le client est donc lacteur principal du systme. Or, bien souvent, le pompiste note
le numro dimmatriculation du vhicule du client dans le systme informatique. 23
Livre.indb 23 11/05/10 11:21:36

Le client doit alors tre modlis deux fois : la premire fois en tant quacteur, et la
seconde, lintrieur du systme, pour y conserver un numro dimmatriculation.
Figure 1.14 Station-service
Le client comme acteur
du cas
Se servir . Se servir
Client
2. Un acteur est caractris par le rle quil joue vis--vis du systme. Le pompiste, bien
qutant une personne diffrente du client, joue un rle identique quand il se sert de
lessence. Pour le cas Se servir , il nest pas ncessaire de crer un acteur suppl-
mentaire reprsentant le pompiste.
3. La gestion de la station-service dfinit une nouvelle fonctionnalit modliser. Le
grant prend le rle principal ; cest donc un nouvel acteur (figure 1.15).
Deux acteurs
pour deux rles.
Se servir
Client
Grer la station
Grant

4. La station offre un troisime service : lentretien des vhicules. Le systme informa-
tique doit prendre en charge cette fonctionnalit supplmentaire. Un nouvel acteur
apparat alors : le mcanicien. Le grant est prsent un chef datelier qui est un
mcanicien ayant la capacit de grer la station. Il y a ainsi une relation de gnralisa-
tion entre les acteurs Mcanicien et Chef datelier (figure 1.16) signifiant que le chef
datelier peut, en plus dassurer la gestion, entretenir des vhicules.
Relation
de gnralisation entre
acteurs. Se servir
Client
Entretenir des vhicules
Mcanicien
Grer la station
Chef
datelier
24
Livre.indb 24 11/05/10 11:21:36

Exercice 2 : Relations entre cas dutilisation
Quel est le dfaut du diagramme prsent la figure 1.17 ?

Figure 1.17
Exemple Station-service
dun diagramme
erron.
Dcrocher le pistolet Appuyer sur la gchette Reposer le pistolet Payer
Client
Solution
Il ne ffautt pas introduire de squencement temporel entre des cas dutilisation (cette
notion apparat lors de la description des cas). De plus, il est incorrect dutiliser un trait
plein pour relier deux cas. Cette notation est rserve aux associations entre les acteurs
et les cas.
Exercice 3 : Relations entre cas dutilisation cas internes
Choisissez et dessinez les relations entre les cas suivants :

1. Une agence de voyages organise des voyages o lhbergement se fait en htel. Le
client doit disposer dun taxi quand il arrive la gare pour se rendre lhtel.
Figure 1.18 Agence de voyages
Diagramme
incomplet des cas Rserver une
Rserver un taxi Rserver un billet de train
dutilisation chambre dhtel
dune agence
de voyages.
Organiser un voyage
Agent de
voyages
2. Certains clients demandent lagent de voyages dtablir une facture dtaille.

Cela donne lieu un nouveau cas dutilisation appel tablir une facture
dtaille . Comment mettre ce cas en relation avec les cas existants ?
3. Le voyage se fait soit par avion, soit par train. Comment modliser cela ?
25
Livre.indb 25 11/05/10 11:21:36

Solution
11. Le modlisa
modlisateur a considr que lorganisation dun voyage est trop complexe pour
tre reprsente par un seul cas dutilisation. Il la donc dcompose en trois tches
modlises par les trois cas dutilisation Rserver une chambre dhtel , Rserver
un taxi et Rserver un billet de train . Ces trois tches forment des transactions
suffisamment isoles les unes des autres pour tre des cas dutilisation. De plus, ces
cas sont mutuellement indpendants. Ils constituent des cas internes du systme car
ils ne sont pas relis directement un acteur.
Figure 1.19
Agence de voyages
Relations
dinclusion Rserver une
Rserver un taxi Rserver un billet de train
entre cas chambre dhtel
dutilisation.
inclut inclut inclut
Organiser un voyage
Agent de
voyages
2. Ltablissement dune facture dtaille se fait uniquement sur demande du client. Ce

caractre optionnel est modlis par une relation dextension entre les cas Organiser
un voyage et tablir une facture dtaille . Lextension porte la condition la
demande du client .
Figure 1.20 Agence de voyages
Relation
dextension Rserver une
entre cas chambre dhtel Rserver un taxi Rserver un billet de train
dutilisation.
Organiser un voyage
Agent de
Points dextension :
voyages
tablirUneFacture
Condition : { la demande du
client} tend
Point dextension : tablirUneFacture
tablir une facture dtaille
3. Il y a maintenant deux cas particuliers : le voyage se fait en train ou en avion. Ces cas
particuliers sont modliss par les cas Rserver un billet de train et Rserver un
billet davion . Ceux-ci sont lis un cas plus gnral appel Rserver un titre de
26 transport .
Livre.indb 26 11/05/10 11:21:36

Figure 1.21
Agence de voyages
Relation de
gnralisation Rserver une Rserver un titre
entre cas Rserver un taxi de transport
chambre dhtel
dutilisation.
Organiser un voyage
Agent de Points dextension :

voyages tablirUneFacture
Condition : { la demande du client} Rserver un billet Rserver un billet

Point dextension : tablirUneFacture de train davion
tend
tablir une facture dtaille
Exercice 4 : Identification des acteurs, recensement

des cas dutilisation et relations simples entre cas
Modlisez avec un diagramme de cas dutilisation le fonctionnement dun distribu-

teur automatique de cassettes vido dont la description est donne ci-aprs.
Une personne souhaitant utiliser le distributeur doit avoir une carte magntique
spciale. Les cartes sont disponibles au magasin qui gre le distributeur. Elles sont
crdites dun certain montant en euros et rechargeables au magasin. Le prix de la
location est fix par tranches de 6 heures (1 euro par tranche). Le fonctionnement
du distributeur est le suivant : le client introduit sa carte ; si le crdit est suprieur ou
gal 1 euro, le client est autoris louer une cassette (il est invit aller recharger
sa carte au magasin sinon) ; le client choisit une cassette et part avec ; quand il la
ramne, il lintroduit dans le distributeur puis insre sa carte ; celle-ci est alors dbi-
te ; si le montant du dbit excde le crdit de la carte, le client est invit rgulariser
sa situation au magasin et le systme mmorise le fait quil est dbiteur ; la gestion
des comptes dbiteurs est prise en charge par le personnel du magasin. On ne sint-
resse ici qu la location des cassettes, et non la gestion du distributeur par le per-
sonnel du magasin (ce qui exclut la gestion du stock des cassettes).
Solution
L seull acteur
Le t est le client.
Lacquisition dune carte et sa recharge ne se font pas via le distributeur : il faut aller au
magasin. Ces fonctions ne donnent pas lieu des cas dutilisation. 27
Livre.indb 27 11/05/10 11:21:36

Il ne faut pas faire apparatre un squencement temporel dans un diagramme de cas
dutilisation. On ne fait donc pas figurer les tapes successives telles que lintroduction
de la carte puis le choix dune cassette, etc. Ce niveau de dtails apparatra quand on
dcrira les cas dutilisation (sous forme textuelle par exemple). Dans un diagramme de
cas dutilisation, il faut rester au niveau des grandes fonctions et penser en termes de
transactions (une transaction est une squence doprations qui fait passer un systme
dun tat cohrent initial un tat cohrent final).
Il ny a donc que deux cas : Emprunter une vido et Restituer une vido (figure 1.22).
Figure 1.22 Magasin de location de cassettes vido
Diagramme de cas
dutilisation dun
distributeur de Emprunter une vido
cassettes vido.
Client Restituer une vido
Nom de lacteur Rle

Client Reprsente un client du magasin de location de cassettes vido.
Pour dcrire le cas Emprunter une vido , imaginons un scnario possible. Le client
introduit sa carte. Il doit ensuite pouvoir choisir une vido. Quels sont les critres de
choix ? Lnonc ne prcise pas ces critres. Ce problme arrive frquemment en situa-
tion relle.
Le matre douvrage dans un projet informatique de cette ampleur est bien souvent le
propritaire du magasin de location. Il sait rarement rdiger un cahier des charges. Cest
le rle du matre duvre dobliger le matre douvrage bien formuler ses besoins.
Choisir une vido peut tre complexe : la recherche se fait-elle par genres, par titres ou
par dates de sortie des films en salles ? Si la recherche se fait par genres, quels sont-ils ?
Rechercher un film semble plus complexe quon ne limaginait au premier abord. De
plus, cette fonctionnalit peut tre isole de la location proprement dite, qui concerne
plutt la gestion de la carte. Ces remarques incitent crer le cas supplmentaire
Rechercher une vido . Lemprunt dune vido inclut sa recherche. Une relation din-
clusion intervient donc entre les cas Emprunter une vido et Rechercher une vido ,
comme le montre la figure 1.23.
Figure 1.23 Magasin de location de cassettes vido
Diagramme de cas
dutilisation complt
par la recherche dune Emprunter une vido
vido. inclut
Rechercher une vido

Client Restituer une vido
28
Livre.indb 28 11/05/10 11:21:36

ce point de la modlisation, deux remarques simposent :
Le succs dUML en tant que langage de modlisation sexplique, entre autres, par le
fait quil oblige le modlisateur poser les bonnes questions au bon moment ; la
modlisation vient peine de commencer que dj des questions se posent. Il faut
cependant veiller rester au niveau du recueil des besoins et des spcifications et ne
faire aucun choix de conception du systme. Il faut se contenter de dcrire les fonc-
tions du systme sans chercher savoir comment les raliser.
Le problme des critres de recherche a conduit une rvision du diagramme de cas
dutilisation. Cet aller-retour sur les modles est ncessaire. Chacun deux apporte
des informations complmentaires qui peuvent remettre en cause les modles exis-
tants. Une fois tous les modles tablis, la modlisation sera alors aboutie.
Exercice 5 : Description dun cas dutilisation
Dcrivez sous forme textuelle les cas dutilisation Emprunter une vido et
Rechercher une vido du diagramme prsent la figure 1.23. La recherche dune
vido peut se faire par genres ou par titres de film. Les diffrents genres sont action,
aventure, comdie et drame. Quand une liste de films saffiche, le client peut trier les
films par titres ou par dates de sortie en salles.
Solution
Avant de prse
prsenter la solution, donnons quelques indications :
Tous les cas dutilisation dun systme doivent tre dcrits sous forme textuelle (dans
la suite de ce chapitre, nous omettrons ventuellement de le faire pour des raisons de
place ou dintrt).
Quand une erreur (exception) est dtecte dans un cas, une squence derreurs est
active (par exemple, voir la squence E1 dans la description suivante). La squence
nominale nest pas reprise et le cas sinterrompt aussitt.
Description du cas Emprunter une vido

Identification
Nom du cas : Emprunter une vido .
But : dcrire les tapes permettant au client du magasin demprunter une cassette vido via le
distributeur automatique.
Acteur principal : Client.
Acteur secondaire : nant.
Date de cration : le 31/12/2004.
Date de mise jour : le 1/1/2005.
Version : 1.1.
Squencement
Le cas dutilisation commence lorsquun client introduit sa carte.
29
Livre.indb 29 11/05/10 11:21:36

Description du cas Emprunter une vido (suite)
Pr-conditions
Le client possde une carte quil a achete au magasin.
Le distributeur est aliment en cassettes.
Enchanement nominal
1. Le systme vrifie la validit de la carte.
2. Le systme vrifie que le crdit de la carte est suprieur ou gal 1 euro.
3. Appel du cas Rechercher une vido .
4. Le client a choisi une vido.
5. Le systme indique, daprs la valeur de la carte, pendant combien de temps (tranches de 6
heures) le client peut garder la cassette.
6. Le systme dlivre la cassette.
7. Le client prend la cassette.
8. Le systme rend la carte au client.
9. Le client prend sa carte.
Enchanements alternatifs
A1 : Le crdit de la carte est infrieur 1 euro.
Lenchanement dmarre aprs le point 2 de la squence nominale :
3. Le systme indique que le crdit de la carte ne permet pas au client demprunter une vido.
4. Le systme invite le client aller recharger sa carte au magasin.
La squence nominale reprend au point 8.
Enchanements dexception
E1 : La carte introduite nest pas valide.
2. Le systme indique que la carte nest pas reconnue.
3. Le distributeur jecte la carte.
E2 : La cassette nest pas prise par le client.
7. Au bout de 15 secondes le distributeur avale la cassette.
8. Le systme annule la transaction (toutes les oprations mmorises par le systme sont
dfaites).
E3 : La carte nest pas reprise par le client.
9. Au bout de 15 secondes le distributeur avale la carte.
10. Le systme consigne cette erreur (date et heure de la transaction, identifiant du client, iden-
tifiant du film).
E4 : Le client a annul la recherche (il na pas choisi de vido).
Lenchanement dmarre au point 4 de la squence nominale :
Post-conditions
Le systme a enregistr les informations suivantes :
La date et lheure de la transaction, la minute prs : les tranches de 6 heures sont calcules
la minute prs.
Lidentifiant du client.
Lidentifiant du film emprunt.
Le distributeur doit fonctionner 24 heures sur 24 et 7 jours sur 7.
La vrification de la validit de la carte doit permettre la dtection des contrefaons.
Contrainte lie linterface homme-machine
Avant de dlivrer la cassette, demander confirmation au client.
30
Livre.indb 30 11/05/10 11:21:36

Description du cas Rechercher une vido
Identification
Nom du cas : Rechercher une vido .
But : dcrire les tapes permettant au client de rechercher une vido via le distributeur automa-
tique.
Acteur principal : nant (cas interne inclus dans le cas Emprunter une vido ).
Acteur secondaire : nant.
Date de cration : le 31/12/2004.
Version : 1.0.
Squencement
Le cas dmarre au point 3 de la description du cas Emprunter une vido .
Enchanement nominal (le choix du film se fait par genres)
1. Le systme demande au client quels sont ses critres de recherche pour un film (les choix
possibles sont : par titres ou par genres de film).
2. Le client choisit une recherche par genres.
3. Le systme recherche les diffrents genres de film prsents dans le distributeur.
4. Le systme affiche une liste des genres (les choix possibles sont action, aventure, comdie
et drame).
5. Le client choisit un genre de film.
6. Le systme affiche la liste de tous les films du genre choisi prsents dans le distributeur.
7. Le client slectionne un film.
Enchanements alternatifs
A1 : Le client choisit une recherche par titres.
2. Le client choisit une recherche par titres.
3. Le systme affiche la liste de tous les films classs par ordre alphabtique des titres.
La squence nominale reprend au point 7.
Enchanements dexception
E1 : Le client annule la recherche.
Lenchanement peut dmarrer aux points 2, 5 et 7 de la squence nominale :
Appel de lexception E4 du cas Emprunter une vido .
Post-conditions
Le systme a mmoris le film choisi par le client.
Contraintes lies linterface homme-machine
Quand une liste de films saffiche, le client peut trier la liste par titres ou par dates de sortie en
salles.
Le client peut se dplacer dans la liste et la parcourir de haut en bas et de bas en haut.
Ne pas afficher plus de 10 films la fois dans la liste.
31
Livre.indb 31 11/05/10 11:21:36

Exercice 6 : Relations dextension entre cas dutilisation,
regroupement de cas dutilisation en paquetages
Modlisez laide dun diagramme de cas dutilisation un systme informatique de

pilotage dun robot distance.
Le fonctionnement du robot est dcrit ci-aprs.
Un robot dispose dune camra pour filmer son environnement. Il peut avancer et
reculer grce un moteur lectrique capable de tourner dans les deux sens et com-
mandant la rotation des roues. Il peut changer de direction car les roues sont direc-
trices. Il est pilot distance : les images prises par la camra sont envoyes vers un
poste de tlpilotage. Ce dernier affiche lenvironnement du robot sur un cran. Le
pilote visualise limage et utilise des commandes pour contrler distance les roues
et le moteur du robot. La communication entre le poste de pilotage et le robot se fait
via des ondes radio.
Solution
Le systme
L t informatique
i f est compos de deux sous-systmes :
le sous-systme du robot ;
le sous-systme du poste de tlpilotage.
Do lide de faire deux diagrammes de cas dutilisation un par sous-systme et de
placer chaque diagramme dans un paquetage. La figure 1.24 montre deux paquetages :
un pour le sous-systme du robot et un pour le sous-systme du poste de pilotage. La
relation de dpendance entre les paquetages signifie que le systme de pilotage utilise le
robot.
Figure 1.24
Robot Systme de pilotage
Reprsentation du
systme de tlpilotage
dun robot par des
paquetages.
Commenons par modliser le robot. Ses capteurs (camra, moteur et roues) sont
lextrieur du systme informatique et ils interagissent avec lui. Ils correspondent a
priori la dfinition dacteurs. Reprenons chaque capteur pour ltudier en dtail :
Le systme doit demander la capture dune image la camra et raliser la capture.
La camra est donc un acteur associ un cas dutilisation appel Capturer ima-
ges (figure 1.25).
Le sens de rotation du moteur peut tre command. Le moteur est lacteur ; il est
associ un cas appel Commander le moteur .
32
Livre.indb 32 11/05/10 11:21:37

La direction des roues peut tre modifie, do la cration du cas dutilisation
Commander la direction reli lacteur Direction.
Pour pouvoir envoyer les images au poste de pilotage et recevoir les commandes en
retour, il faut un capteur supplmentaire, metteur/rcepteur dondes radio. Le systme
informatique ne va pas se charger denvoyer et de recevoir des ondes radio cest le rle
des priphriques dmission et de rception mais il doit soccuper du transcodage des
images pour les envoyer via des ondes. Le systme informatique doit-il raliser lui-mme
ce transcodage ou bien les fonctions de transcodage sont-elles fournies avec les priph-
riques ? Pour rpondre cette question, il faudrait raliser une tude de march des
metteurs/rcepteurs radio. Cela dpasse le cadre de cet ouvrage. Considrons que le
systme informatique intervient, ne serait-ce que pour appeler des fonctions de transco-
dage. Cela constitue un cas dutilisation. Deux flots dinformations distincts doivent
tre envoys au poste de pilotage : des images et des commandes. Cette dernire remar-
que incite crer deux cas dutilisation : un pour mettre des images ( Envoyer les
images ) et un pour recevoir les commandes ( Recevoir les commandes ). En outre,
selon lutilisation du robot, la transmission des images seffectue plus ou moins vite : si
les dplacements du robot sont rapides par exemple, la transmission doit ltre aussi. Ces
contraintes de ralisation font partie des spcifications techniques du systme. Elles doi-
vent figurer dans la description textuelle du cas dutilisation. Sur le diagramme de cas
dutilisation, il est possible de placer une relation dextension entre les cas Envoyer les
images et Capturer images , en indiquant comme point dextension quel moment
de la capture et quelle frquence sont envoyes les images.
Nom de lacteur Rle

Camra Permet de capturer des images de lenvironnement du robot.
Direction Permet de diriger les roues du robot.
Moteur Permet de faire avancer ou reculer le robot.
metteur Permet denvoyer des ondes radio.
Rcepteur Permet de recevoir des ondes radio.
33
Livre.indb 33 11/05/10 11:21:37

Figure 1.25 Systme de contrle dun robot
Diagramme de cas
dutilisation du robot. Capturer images
Points dextension :
envoiImage
Camra
Condition : {ds quune image tend
complte a t capture}
Point dextension : envoiImage
Envoyer les images
metteur
Recevoir les commandes
Points dextension :
- commandeMoteur Rcepteur
- commandeDirection
Condition : {ds quune Condition : {ds quune commande

commande concerne le moteur} concerne la direction}
Point dextension : commandeMoteur Point dextension : commandeDirection
tend tend
Commander le moteur Commander la direction
Moteur Direction
Intressons-nous prsent au sous-systme de pilotage. La figure 1.26 prsente le dia-

gramme de cas dutilisation, qui se dduit sans problme du diagramme prcdent.
Nom de lacteur Rle

Pilote Reprsente un pilote qui agit sur les commandes distance.
metteur Permet denvoyer des ondes radio.
Rcepteur Permet de recevoir des ondes radio.
34
Livre.indb 34 11/05/10 11:21:37

Figure 1.26 Systme de pilotage dun robot
Diagramme de cas
dutilisation du Recevoir des images
systme de pilotage.
Points dextension :
afficheImage
Rcepteur
Condition : {ds quune image
complte a t reue} tend
Point dextension : afficheImage
Afficher les images
Tlpiloter
Pilote
Points dextension :
envoiCommande
Condition : {ds quune commande

a t manipule par le pilote}
Point dextension : envoiCommande tend
Envoyer des commandes
metteur
Exercice 7 : Relations entre acteurs, extensions conditionnelles

entre cas dutilisation
Modlisez laide dun diagramme de cas dutilisation une mdiathque dont le

fonctionnement est dcrit ci-aprs.
Une petite mdiathque na quune seule employe qui assume toutes les tches :
la gestion des uvres de la mdiathque ;
la gestion des adhrents.
Le prt dun exemplaire dune uvre donne est limit trois semaines. Si lexem-
plaire nest pas rapport dans ce dlai, cela gnre un contentieux. Si lexemplaire
nest toujours pas rendu au bout dun an, une procdure judiciaire est dclenche.
Laccs au systme informatique est protg par un mot de passe.
Solution
L mdiathque
La di th nemploie quune employe. Nanmoins, un acteur est dtermin par le
rle quil joue vis--vis du systme modliser. Ici, lemploye a deux rles essentiels :
35
Livre.indb 35 11/05/10 11:21:37

le rle de bibliothcaire qui gre les uvres ainsi que les adhrents ;
le rle de gestionnaire des contentieux ayant les connaissances juridiques suffisantes
pour dclencher des procdures judiciaires.
Ces rles sont modliss par deux acteurs : Bibliothcaire et Gestionnaire des conten-
tieux. Un gestionnaire de contentieux est un bibliothcaire avec pouvoir. Les acteurs
correspondants sont relis par une relation de gnralisation (figure 1.27). Ainsi, lac-
teur Gestionnaire des contentieux peut utiliser les cas associs lacteur Bibliothcaire.
A contrario, lacteur Bibliothcaire ne peut pas utiliser les cas relatifs la gestion des
contentieux.
Jusqu prsent la mdiathque fonctionne avec une seule employe. Si, lavenir, plu-
sieurs employs devenaient ncessaires, le systme informatique pourrait fonctionner
avec deux groupes dutilisateurs : un premier groupe dont le rle serait limit celui des
bibliothcaires et un deuxime groupe susceptible de grer les contentieux en plus
davoir un rle de bibliothcaire. Lauthentification du groupe auquel appartient un uti-
lisateur du systme doit tre contrle par un mot de passe. La gestion des mots de passe
requiert la prsence dun administrateur du systme. Pour UML, peu importe si cette
personne fait partie ou non du groupe des bibliothcaires ou des gestionnaires de
contentieux. Comme un nouveau rle apparat dans le systme, cela justifie la dfinition
dun acteur supplmentaire : Administrateur. Tous les cas dutilisation lis aux acteurs
incluent la procdure dauthentification matrialise par le cas Sauthentifier .
Dans le diagramme, la gestion des adhrents et la gestion des emprunts sont spares :
Grer les adhrents consiste ajouter, supprimer ou modifier lenregistrement
dun adhrent dans la mdiathque, tandis que Grer les emprunts consiste prter
des exemplaires aux adhrents dj inscrits.
La gestion des contentieux a deux degrs dalerte :
Un exemplaire na pas t rendu au bout de trois semaines.
Un exemplaire na toujours pas t rapport au bout dun an.
Cela correspond deux fonctionnalits distinctes puisque, dans le deuxime cas seule-
ment, il faut dclencher une procdure judiciaire. Nous reprsentons cela par deux cas
dutilisation : Grer les contentieux et Dclencher une procdure judiciaire . Ces
deux cas sont lis par une relation dextension soumise la condition si le retard
dpasse un an .
Nom de lacteur Rle

Reprsente un bibliothcaire. Il gre les uvres, les adhrents
Bibliothcaire
et les emprunts.
Gestionnaire des
Reprsente un bibliothcaire qui peut grer les contentieux.
contentieux
Administrateur Reprsente un gestionnaire des droits daccs au systme.
36
Livre.indb 36 11/05/10 11:21:37

Figure 1.27 Une mdiathque
Diagramme de cas
Grer les inclut Rechercher
dutilisation dune
mdiathque. uvres les uvres
inclut
Grer les
adhrents inclut
inclut Sauthentifier
Bibliothcaire
Rechercher
les adhrents inclut
inclut
inclut
Grer les Grer les comptes
emprunts utilisateurs
Administrateur
Grer les contentieux
Points dextension :
Gestionnaire des procdureJudiciaire : {pas
contentieux chaque fois que le gestionnaire
utilise le cas mais
une fois par mois}
Condition : {si plus dun an de retard}
Point dextension : procdureJudiciaire tend
Dclencher une
procdure judiciaire
Exercice 8 : Identification des acteurs, recensement des cas

dutilisation internes et relation de gnralisation entre cas
Modlisez laide dun diagramme de cas dutilisation le systme informatique qui

gre la distribution dessence dans une station-service. Le fonctionnement de la dis-
tribution de lessence est dcrit ci-aprs.
Avant de pouvoir tre utilise par un client, la pompe doit tre arme par le pom-
piste. La pompe est ainsi apprte, mais ce nest que lorsque le client appuie sur la
gchette du pistolet de distribution que lessence est pompe. Si le pistolet est dans
son tui de rangement et si la gchette est presse, lessence nest pas pompe. La
distribution de lessence un client est termine quand celui-ci remet le pistolet
dans son tui. La mesure de lessence distribue se fait par un dbitmtre.
Quatre types de carburants sont proposs : diesel, sans plomb avec un indice doc-
tane de 98, sans plomb avec un indice doctane de 95, et plomb.
Le paiement peut seffectuer en espces, par chque ou par carte bancaire. En fin de
journe, les transactions sont archives.
Le niveau des cuves ne doit pas descendre en dessous de 5 % de la capacit maxi-
male. Sinon les pompes ne peuvent plus tre armes.
37
Livre.indb 37 11/05/10 11:21:37

Solution
P
Pour un systme
t complexe, il vaut mieux se concentrer sur les fonctions essentielles puis
passer aux cas moins importants.
Identification des principaux acteurs et recensement des cas
dutilisation essentiels
Lacteur principal est videmment le client. Il utilise le systme pour obtenir de lessence.
Il est associ au cas dutilisation Se servir . Rappel : dans un diagramme de cas duti-
lisation, on ne dtaille pas la squence des oprations. Par exemple, le type dessence
choisi sera pris en compte quand on dcrira le cas.
Imaginons le fonctionnement de la pompe : lessence ne peut tre distribue que si la
pompe est arme ; le client prend un pistolet ; sur le pupitre du pompiste est indiqu le
type dessence choisi ; le pompiste arme la pompe en appuyant sur un bouton de son
pupitre, ce qui initialise la pompe.
Ainsi, le cas Se servir doit inclure larmement de la pompe. Deux solutions sont
possibles :
La premire utilise un cas unique (Se servir), et deux acteurs (Client et Pompiste),
comme le montre la figure 1.28.
Figure 1.28
Se servir de lessence : Se Servir
solution avec un cas
unique. Client Pompiste
La deuxime solution met en uvre deux cas : Se servir et Armer pompe

(figure 1.29).
Figure 1.29
Se servir de lessence : inclut
Se Servir Armer pompe
solution avec deux cas.
Client Pompiste
Larmement de la pompe est indispensable, sinon lessence ne peut tre distribue, do la

relation dinclusion entre les cas Se servir et Armer pompe . Larmement de la
pompe se fait en une seule action pour le pompiste : celle darmer la pompe en appuyant
sur un bouton. La description de larmement se rsume donc une squence trs som-
maire dactions. Faut-il alors reprsenter cela par un cas dutilisation ? Largument qui fait
pencher pour le maintien du cas Armer pompe est que larmement est une opration
bien isole des autres fonctions : il sagit dinitialiser la pompe et donc de piloter des pri-
phriques (mcaniques, lectroniques). Vu sous cet angle, larmement est suffisam-
ment complexe et bien isol des autres fonctions pour en faire un cas (figure 1.31).
Le pompiste est un acteur secondaire du cas Armer pompe (cest un cas interne pour
lequel le pompiste est consult). Larmement de la pompe nest possible que si le niveau
de la cuve est suffisant. Un dtecteur de niveau (priphrique externe au systme infor-
38
matique) est ncessaire. Ce priphrique est reprsent par lacteur Capteur niveau
Livre.indb 38 11/05/10 11:21:37

cuve pour armement . Il est secondaire car linformation sur le niveau de la cuve ne lui
est pas destine. Si le niveau est trop bas, cest le pompiste qui doit en tre inform. Il
saura ainsi ce qui empche larmement de la pompe. La vrification du niveau de la cuve
est importante pour le systme. De plus, cette opration constitue une transaction bien
isole des autres fonctions (il sagit de contrler un priphrique matriel). Cest la rai-
son pour laquelle on dcide de crer un cas Vrifier niveau cuve pour armement .
Pour transmettre le niveau de la cuve au pompiste, il faut relier lacteur Pompiste au cas
Vrifier niveau cuve pour armement . Le pompiste est inform que le niveau est trop
bas, mais la vrification doit tre automatique pour que les pompes soient ventuelle-
ment bloques. Une relation dinclusion intervient donc entre les cas Armer pompe
et Vrifier niveau cuve pour armement (figure 1.31).
Recensement des cas de moindres importances
Aprs avoir trouv les principaux cas, il est temps de se consacrer ceux de moindre
importance. Il ne faut pas oublier de couvrir tous les besoins et ne pas hsiter intro-
duire des cas auxquels le matre douvrage na pas pens. Il validera ou pas le modle a
posteriori.
Lnonc naborde pas le problme du remplissage des cuves dessence. Cette opration
est ralise par une entreprise tierce de livraison dessence. Elle doit cependant tre
consigne dans le systme informatique de la station-service. Une solution consiste
alerter le pompiste ds que le niveau des cuves descend au-dessous dun certain seuil. Ce
deuxime seuil, appel seuil de remplissage des cuves , doit tre suprieur au seuil des
5 % de lnonc (celui qui empche les pompes dtre armes). Quand il est atteint, le
pompiste prvient lentreprise de livraison dessence de sorte viter de tomber au seuil
des 5 %. Si la station-service est sur une autoroute, la livraison dessence doit tre garan-
tie 24 heures sur 24. Il faut peut-tre contacter la socit de livraison automatiquement
sans passer par lintermdiaire du pompiste ds que le niveau devient trop bas. Le
capteur du niveau de remplissage est reprsent par un acteur appel Capteur niveau
cuve pour remplissage (figure 1.31). Il est associ au cas Vrifier niveau cuve pour
remplissage , lui-mme associ lacteur Pompiste.
Abordons prsent le problme du paiement. De concert avec le matre douvrage, le
matre duvre imagine un fonctionnement possible du systme : ds que le client rac-
croche le pistolet, le montant payer est calcul ; il saffiche sur le pupitre du pompiste ;
le client qui vient payer indique son mode de paiement (espces, chque ou carte ban-
caire) ; le pompiste slectionne le mode de paiement choisi. partir de l, les cas
divergent :
Pour un paiement en espces, le pompiste encaisse le montant demand, puis valide
la transaction, qui est mmorise dans le systme informatique (le montant, la date
de la transaction et le mode de paiement sont conservs).
Si le paiement se fait par chque, ce dernier est rempli automatiquement, puis le
pompiste lencaisse. La transaction est mmorise dans le systme informatique (en
plus de la date, du montant et du mode paiement, sont conservs les rfrences dune
pice didentit ou le numro dimmatriculation du vhicule).
Pour un paiement par carte bancaire, la banque de la station-service ralise une tran-
saction avec la banque du client. Les seules informations conserver dans le systme
39
Livre.indb 39 11/05/10 11:21:37

informatique de la station-service sont le montant, la date de la transaction et le
mode de paiement.
Comment reprsenter cela dans un diagramme de cas dutilisation ? Une premire solu-
tion (prsente la figure 1.31) consiste crer un cas gnral appel Payer , et trois
cas particuliers relis par une relation de spcialisation au cas Payer . Chacun des trois
cas reprsente un mode de paiement.
Une autre solution (prsente la figure 1.30) repose sur un cas, Payer , qui se droule
jusquau choix du mode de paiement, puis, selon le type de paiement, un des trois modes
est activ ( Payer en espces , Payer par chque ou Payer par carte bancaire ). Ces
trois cas sont typiquement des extensions du cas Payer , o lextension est soumise
condition.
Figure 1.30 Payer
Utilisation
de relations dextension Points dextension :
- paiementEspce,
pour modliser - paiementParChque
le paiement. - paiementParCarteBancaire
{les trois extensions sexcluent mutuellement et
une extension intervient au tout dbut du
paiement}
Condition : {si le client choisit de payer Condition : {si le client
par carte bancaire} choisit de payer en espce}
Point dextension : paiementParCarteBancaire Point dextension :
paiementEnEspce
tend tend tend
Payer par carte bancaire Payer en espces
Condition : {si le client choisit de

payer par chque}
Payer par
Point dextension : paiementParChque
chque
Ces deux solutions sont possibles. Il est difficile de dire laquelle est la meilleure. La suite
de lexercice se fonde arbitrairement sur la reprsentation avec des relations de gnrali-
sation (figure 1.31). Le modlisateur se retrouve rgulirement face ce dilemme. La
rponse est souvent la mme : peu importe la faon de modliser un systme du moment
que le modle est correct un modle est correct sil montre une solution qui satisfait le
matre douvrage ainsi que les futurs utilisateurs du systme.
Aboutir une modlisation correcte
Il faut prendre le temps dlaborer le diagramme de cas dutilisation, bien quil soit gn-
ralement simple btir, afin dviter les a priori qui peuvent conduire une modlisa-
tion errone.
la relecture du fonctionnement du paiement tel quil est dcrit prcdemment, le
pompiste devient lacteur principal du cas de paiement. Cest un peu surprenant car on
pourrait croire au premier abord quil sagit du client. Or, la seule fois o le client inter-
vient directement sur le systme informatique de la station-service est quand il saisit
son numro de carte bancaire. Toutes les autres situations ncessite lintervention du
40
Livre.indb 40 11/05/10 11:21:37

pompiste. Attardons-nous un instant encore sur le paiement par carte bancaire. Il faut
de toute vidence faire figurer un acteur supplmentaire qui reprsente la banque, car
elle interagit avec le systme sans en faire partie. Cest un acteur secondaire qui est
sollicit uniquement pour confirmer le bon droulement de la transaction. Quel est le
rle de cet acteur ? Le plus souvent, les solutions de paiement par carte bancaire sont
disponibles cls en main sur le march. Elles incluent un lecteur de cartes ainsi quun
logiciel pour le piloter. Le matre duvre doit proposer plusieurs solutions prsentes
sur le march au matre douvrage, et ventuellement une solution propritaire si
aucune solution du march ne lui convient. Le matre douvrage dcidera. Dans le cadre
de cet exercice, dfaut de pouvoir dialoguer avec un matre douvrage, nous choisis-
sons lachat dune solution cls en main pour le paiement par carte bancaire. Dans ce
cas, le client, lorsquil saisit le code de sa carte, ninteragit plus directement avec le sys-
tme informatique de la station-service. Ainsi, quel que soit le mode de paiement, tout
passe par lintermdiaire du pompiste. Le client nest donc pas un acteur du systme.
Le calcul automatique du montant payer peut se faire ds que le client raccroche le
pistolet (ce qui intervient la fin du cas Se servir ). Pour indiquer le moment o le
montant est calcul, on peut ajouter une relation dextension entre les cas Se servir et
Payer , avec un point dextension qui prcise le moment o le calcul du montant inter-
vient, comme le montre la figure 1.31. Le paiement peut aussi intervenir avant de se
servir. Dans ce cas, il est possible dajouter un deuxime point dextension.
Modlisation des concepts abstraits
Parfois, le langage UML peut paratre limit. Il faut alors trouver, parmi les lments du
langage, celui qui convient le mieux une situation donne.
Un dernier besoin nest pas dcrit par le diagramme de cas dutilisation : cest larchivage
en fin de journe des transactions. Faut-il prendre en compte ce cas et, si oui, quel acteur
lutilise ? Un cas dutilisation est dclench par un vnement. Les vnements peuvent
tre classs en trois catgories :
Les vnements externes. Ils sont dclenchs par des acteurs.
Les vnements temporels. Ils rsultent de latteinte dun moment dans le temps.
Les vnements dtats. Ils se produisent quand quelque chose dans le systme nces-
site un traitement.
Ici, il sagit dun vnement temporel. Il est difficile de dfinir un acteur qui dclenche-
rait cet vnement. Comment le temps peut-il interagir avec un systme ? Cela dit, lar-
chivage quotidien est une fonctionnalit essentielle. Il faut la faire figurer dans la
modlisation du systme. quelle tape de la modlisation doit-on prendre en compte
cette fonctionnalit ? Comme nous en sommes produire le premier modle du systme
et que cette fonctionnalit est importante, nous choisissons, pour ne pas loublier, den
faire un cas dutilisation. Pour dclencher ce cas, nous introduisons un acteur appel
Timer qui, une fois par jour, dclenche un vnement temporel. Timer est un acteur, il
est donc en dehors du systme. Cela signifie que lheure est donne par une horloge
externe notre systme informatique (par exemple, lhorloge du systme dexploitation
du systme informatique).
La prise en compte des vnements dtats est plus dlicate puisque, par dfinition, ils se
produisent lintrieur dun systme. Ils ne peuvent donc pas tre dclenchs par un 41
Livre.indb 41 11/05/10 11:21:37

acteur, qui est forcment en dehors du systme. Il est toutefois possible quun vnement
dtat active un cas dutilisation condition que ce cas soit interne au systme. Une
faon de reprsenter un cas de ce type consiste le relier dautres cas via des relations
dextension et faire figurer comme condition dextension lvnement dtat. Cest
cette solution qui a t adopte entre les cas Se servir et Payer , en considrant ce
dernier comme un cas interne vis--vis du cas Se servir .
Nom de lacteur Rle

Acteur principal du cas dutilisation Se servir . Reprsente le client qui
Client
se sert de lessence.
Acteur principal des cas Payer et Vrifier niveau cuve pour remplis-
Pompiste
sage . Acteur secondaire pour le cas Armer pompe .
Capteur niveau cuve
Acteur secondaire du cas Vrifier niveau cuve pour armement .
pour armement
Capteur niveau cuve
Acteur secondaire du cas Vrifier niveau cuve pour remplissage .
pour remplissage
Timer Acteur secondaire du cas Archiver les transactions .
Banque Acteur secondaire du cas Payer par carte bancaire .
42
Livre.indb 42 11/05/10 11:21:37

Figure 1.31
Diagramme de cas
dutilisation dune
station-service. Capteur niveau cuve Capteur niveau cuve
pour armement pour remplissage
Station-Service
Vrifier niveau cuve Vrifier niveau cuve
pour armement pour remplissage
inclut
inclut
Se servir Armer pompe
Points dextension :
Client paiement : { la fin du Pompiste
cas se servir }
Condition : {si le client
a pris de lessence avant tend
de raccrocher le pistolet}
Payer
Payer en espce
Payer par carte
bancaire
Archiver les
Banque transactions
Payer par chque
Tous les soirs minuit
Timer
43
Livre.indb 43 11/05/10 11:21:37

7466 Chap01 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

7466 Chap01 PDF

Transféré par

Droits d'auteur :

Formats disponibles

a pit re 1

Livre.indb 9 11/05/10 11:21:35

Livre.indb 10 11/05/10 11:21:35

Client Consulter comptes

Figure 1.2 et 1.3

Livre.indb 11 11/05/10 11:21:35

Figure 1.4 Rle de lacteur

Le rectangle de la figure 1.5 est appel classeur .

Livre.indb 12 11/05/10 11:21:35

Figure 1.7 Logiciel de tlchargement

2.3. Relations entre cas dutilisation

Livre.indb 13 11/05/10 11:21:35

Consulter sur Internet

Figure 1.9 Systme de vente par correspondance

Passer une commande

Livre.indb 14 11/05/10 11:21:35

2.4. Relations entre acteurs

Figure 1.10 Systme de vente par correspondance

Passer une commande

Suivre une commande Rechercher article

Livre.indb 15 11/05/10 11:21:35

2.5. Regroupement des cas dutilisation en paquetages

Livre.indb 16 11/05/10 11:21:35

3.2. Comment recenser les cas dutilisation ?

Livre.indb 17 11/05/10 11:21:35

3.3. Description des cas dutilisation

Figure 1.12 Gestion dune banque

Guichetier Consulter compte Systme

Livre.indb 18 11/05/10 11:21:35

Demande de validit du compte

Demande type dopration

Retrait despces de 200 euros

Demande de dbit du compte

Autorisation de dlivrer les 200 euros

Les diffrentes faons de dcrire les cas dutilisation

Livre.indb 19 11/05/10 11:21:36

Description textuelle des cas dutilisation

Livre.indb 20 11/05/10 11:21:36

Description dun retrait dargent

Livre.indb 21 11/05/10 11:21:36

Livre.indb 22 11/05/10 11:21:36

Exercice 1 : Identification des acteurs et recensement

Considrons le systme informatique qui gre une station-service de distribution

11. Pour le syst

Livre.indb 23 11/05/10 11:21:36

Entretenir des vhicules

Livre.indb 24 11/05/10 11:21:36

Quel est le dfaut du diagramme prsent la figure 1.17 ?

Exercice 3 : Relations entre cas dutilisation cas internes

Choisissez et dessinez les relations entre les cas suivants :

2. Certains clients demandent lagent de voyages dtablir une facture dtaille.

Livre.indb 25 11/05/10 11:21:36

2. Ltablissement dune facture dtaille se fait uniquement sur demande du client. Ce

inclut inclut inclut

tablir une facture dtaille

Livre.indb 26 11/05/10 11:21:36

inclut inclut inclut

Agent de Points dextension :

Condition : { la demande du client} Rserver un billet Rserver un billet

tablir une facture dtaille

Exercice 4 : Identification des acteurs, recensement

Modlisez avec un diagramme de cas dutilisation le fonctionnement dun distribu-

Livre.indb 27 11/05/10 11:21:36