Date post: | 11-Dec-2015 |
Category: |
Documents |
Upload: | badr-aqraou |
View: | 45 times |
Download: | 2 times |
UMl (Unified Modeling language)
INTRODUCfION
Il LA MODELISATION des USE CASES
III LA MODELISATION des ClASSES
IV LA MODELISATION des INTERACfIONS
V LA MODELISATION des ACTIVITES
VI LA MODELISATION des Machines dEtat
VII La MODELISATION STATIQUE
(Compleacutement Package Objet Composant Deacuteploiement Structures Composites)
Bibliographie
Grady Booch James Rumbaugh et Ivar Jacobson
1) UML 20 le Guide de lUtilisateur
2 UML 20 le Manuel de Reacutefeacuterence
3) UML le Processus Unifieacute
MLAI UML La notation unifieacutee de modeacutelisation objet MASSON
P A MULLER Modeacutelisation Objet avec UML
EYROLLES
Urlographie wwwdeveloppezcom
Introduction
UML est un langage qui sappuie sur la technologie orienteacutee objet et sesconcepts
Meacutethodologie Meacutethode et Formalisme
bull Le terme laquo meacutethodologie raquodans son sens premier deacutesigne leacutetude
des meacutethodes scientifiques et techniques Il est employeacute pour deacutesigner lutilisation dune deacutemarche
rationnelle et structureacutee lors de leacutelaboration dun logiciel
bull Un formalisme est un ensemble de notations et de regravegles deacutecrivant des concepts permettant de
speacutecifier construire visualiser et documenter un systegraveme informatique
bull Une meacutethode informatique est une deacutemarche conceptuelle et
organisationnelle baseacutee sur un formalisme speacutecifique et permettant la mise en oeuvre dune solution
informatique
UML nest pas une meacutethode
UML est un langage objet graphique autrement dit un formalisme orienteacute objet ce nest pas une
meacutethode mais une synthegravese de tous les concepts et formalismes meacutethodologiques les plus utiliseacutes
dans la Technologie Objet
o UML est issu de la fusion du formalisme de trois meacutethodes orienteacutees objet qui eacutetaient les
plus utiliseacutees aux USA
o OMT (Object Modeling Technique)de James Rumbaugh
o BOOCH de Grady Booch
1
o OOSE (Object Oriented Sofware Engineering) de Ivar Jacobson qui fut inteacutegreacutee agrave UMl en
1997
o UMl sinspire eacutegalement de toutes les autres meacutethodes leaders du marcheacute
[J le formalisme UMl peut donc ecirctre utiliseacute dans diffeacuterents processus de deacuteveloppement et en
particulier dans celui proposeacute par les concepteurs du langage (RUP Rational Unified Process
ou le Processus Unifieacute) (UP l Unified Process) ( 2TUP Two Track Unified Process ) (XP
Extreme Programming )0
o la migration de MERISE 00 agrave UMl peut se faire assez aiseacutement
[J UML et la standardisation
o Initialement UMl a eacuteteacute soumise en janvier 1997 agrave lOMG (Object Management Group) dans
le cadre de la standardisation des meacutethodes danalyse et de conception orienteacutees objet la
version 10 dUML a tregraves vite obtenu le ralliement de nombreux acteurs du marcheacute
(Microsoft Oracle Hewlett-Packard )et de nombreux eacutediteurs dAGL (ateliers de geacutenie
logiciel) UML 20 est la derniegravere version voteacutee en 2003
o la technologie orienteacutee objet et le formalisme UMl en particulier veacutehiculent des concepts
tregraves geacuteneacuteraux dont lapplication nest pas limiteacutee au domaine informatique
UML et La Modeacutelisation
bull Un Systegraveme est un ensemble deacuteleacutements organiseacutes et de relations entre ces
eacuteleacutements en vue datteindre un objectif Il est deacutecrit par un ensemble de Modegraveles en
geacuteneacuteral sous diffeacuterents points de vues ou angles
bull Un Modegravele cest une abstraction dun Systegraveme complegravete et fermeacutee du point de
vue seacutemantique c ad repreacutesentant une simplification coheacuterente de la reacutealiteacute et
creacuteeacutee dans le but de faciliter la compreacutehension du systegraveme (UMl20 propose 13 en
tout)
bull Un Diagramme est une repreacutesentation graphique dun ensemble deacuteleacutements sous
forme dun graphe connecteacute de sommets (eacuteleacutements structurels) et darcs (relations)
bull Un diagramme nest pas un modegravele ce nest quune repreacutesentation de quelques
eacuteleacutements du modegravele
o Plusieurs diagrammes savegraverent souvent neacutecessaires pour illustrer un modegravele complet
o Pour la modeacutelisation UML distingue 2 cateacutegories de diagrammes
Les Diagrammes Structurels permettent de visualiser construire et documenter les aspects
statiques dun systegraveme
Dans cette cateacutegorie on trouve 6 diagrammes
- de Classes
- dObjets
- de Composants
- de Deacuteploiement
2
- de Structure Composite
- de Package
Les Diagrammes Comportementaux
permettent de visualiser construire et documenter
les aspects dynamiques dun systegraveme Dans cette
cateacutegorie on trouve 7 diagrammes
bull des USE CASES
bull des Interactions
C Seacutequence
C de Communication (av collaboration)
C vue densemble des Interactions
C deTiming
bull dlActiviteacutes
bull de Machine dEtats (av Etats-Transitions)
o En principe ni UML ni le Processus Unifieacute (la Meacutethode) nobligent agrave repreacutesenter les 13
diagrammes
Ils laissent agrave lanalyste et au concepteur la latitude deacutecisionnelle en fonction de leurs besoins
Cependant les 2 diagrammes qui savegraverent toujours neacutecessaires sont surtout
bull le diagramme des USE CASES et
bull le diagramme de Classes
Il) La Modeacutelisation des USE CASES
(CAS DUTILISATION ou CAS DUSAGE)
111) Que sont les USE CASES
Les USE CASES constituent le concept principal de la meacutethode OOSE dIvar Jacobson
Le concept des USE CASE a eacuteteacute repris dans le but deffectuer une bonne deacutelimitation du systegraveme mais
eacutegalement pour ameacuteliorer la compreacutehension de son fonctionnement et reacutealiser sa speacutecification
Les USE CASES repreacutesentent un meacutecanisme qui permet de deacutetecter didentifier de comprendre et
de consigner les besoins
Ils permettent dorienter tout le processus de deacuteveloppement car les activiteacutes dAnalyse de
Conception et de Test sont effectueacutees agrave partir des USE CASES
Les USE CASES repreacutesentent le premier modegravele du systegraveme agrave concevoir
Les USE CASES sont une repreacutesentation orienteacutee laquo fonctionnaliteacuteraquo du systegraveme qui permettent de
modeacuteliser les attentes des utilisateurs
3
Une bonne compreacutehension du systegraveme est primordiale avant dentreprendre lanalyse et la
conception
USE
CONCEPTION
Il2 Les concepts
Deux concepts fondamentaux pour repreacutesenter les USE CASES
- les acteurs qui utilisent le systegraveme
- les USE CASES qui repreacutesentent lutilisation
du systegraveme par les acteurs
A) Les acteurs (utilisateurs du systegraveme)
Pour permettre une bonne deacutelimitation du systegraveme il est bon de bien seacuteparer les eacuteleacutements
constitutifs du systegraveme logiciel des eacuteleacutements exteacuterieurs les acteurs repreacutesentent cette frontiegravere
Ce sont des eacuteleacutements exteacuterieur au systegraveme et qui interagissent avec lui
Il faut dabord Identifier les acteurs qui peuvent ecirctre des
Humains ce sont des utilisateurs du logiciel agrave
travers son interface graphique par exemple
Logiciels ce sont des logiciels deacutejagrave disponibles qui
communiquent avec le systegraveme gracircce agrave une
interface logicielle (une API par exemple)
Mateacuteriels robots et automates qui exploitent les
donneacutees du systegraveme ou qui sont piloteacutes par le
systegraveme (GAB)
Systegravemes exteacuterieurs (le Systegraveme de la banque de la
socieacuteteacute)
Al) Typologie des acteurs
Il existe trois types dacteurs
Les acteurs principaux ou primaires Ceux qui utilisent le systegraveme pour atteindre leurs buts (ils sont
la raison de lexistence du systegraveme)
Les acteurs secondaires Ceux qui administrent le systegraveme et assurent sa maintenance Ce sont eux
qui paramegravetrent le systegraveme et qui lui fournissent toutes les informations ou services neacutecessaires agrave son bon fonctionnement pour les acteurs principaux
Exla personne chargeacutee de la MAJ des cours des devises
Les acteurs externes Ceux qui ont un inteacuterecirct dans le comportement du cas dutilisation
Ex les services des impocircts du commerce
4
Remarquef
bull Un acteur correspond agrave un rocircle joueacute vis-agrave-vis du systegraveme (Un salarieacute dune banque correspond
souvent agrave un ou plusieurs rocircles directeur guichetier responsable devises ) et plusieurs individus
jouent souvent le mecircme rocircle (guichetier)
bull Une mecircme entiteacute peut repreacutesenter tour agrave tour deux types dacteurs
Exemple dans le caS de petites agences bancaires le directeur dagence peut ecirctre ameneacute agrave faire des opeacuterations de maintenance (alimenter le DAB en liquide)
A2) Pourquoi des acteurs
Identifier les acteurs dun systegraveme permet de
deacutelimiter le systegraveme Un acteur est un eacuteleacutement exteacuterieur au systegraveme qui interagit avec ce dernier
- avoir une vue orienteacutee utilisateur du systegraveme Avant de se lancer dans lanalyse et la conception
interne du systegraveme il est bon den avoir une vue externe qui correspond agrave toutes les fonctionnaliteacutes
attendues par les diffeacuterents acteurs
Remarque
UMl permet de steacutereacuteotyper les acteurs et dutiliser dautres icocircnes plus speacutecifiques (avec
utilisation des couleurs et images) en fonction des besoins pour offrir un meilleur repegravere visuel
Mais lutilisation de ces icocircnes doit ecirctre faite avec parcimonie
Ex
Un eacutetudiant Une eacutetudiante
A3) Les relations entre ACTEURS
Pour UMl la relation preacutevue entre acteurs est une relation de geacuteneacuteralisationSpeacutecialisation
B) Les USE CASES Eleacutements de linterface dutilisation
Bl) Deacutefinitions
Un USE CASE est une suite de seacutequences dactions y compris des variantes (souvent initieacutee par un
des acteurs) et qui correspond agrave une exeacutecution particuliegravere du systegraveme pour produire un reacutesultat ou
reacutepondre au(x) besoin(s) dun acteur
les USE CASES permettent de bien comprendre le systegraveme
Le but des USE CASES nest pas de faire une description exhaustive des fonctionnaliteacutes du systegraveme
logiciel en deacuteveloppement Ils permettent de deacutecrire ce que fait un systegraveme (un sous systegraveme une
classe ou une interface) mais ne preacutecisent pas comment il le fait
5
Ils permettent de repreacutesenter les besoins fonctionnels et non fonctionnels (seacutecuriteacute
performances ) que doit reacutealiser le systegraveme logiciel en deacuteveloppement
B) Les USE CASES Eleacutements de linterface dutilisation
Bi) Deacutefinitions
o Un USE CASE est une suite de seacutequences dactions y compris des variantes (souvent initieacutee
par un des acteurs) et qui correspond agrave une exeacutecution particuliegravere du systegraveme pour
produire un reacutesultat ou reacutepondre aulx) besoin(s) dun acteur
o Les USE CASES permettent de bien comprendre le systegraveme
Le but des USE CASES nest pas de faire une description exhaustive des fonctionnaliteacutes du
systegraveme logiciel en deacuteveloppement Ils permettent de deacutecrire ce que fait un systegraveme (un
sous systegraveme une classe ou une interface) mais ne preacutecisent pas comment il le fait
o Ils permettent de repreacutesenter les besoins fonctionnels et non fonctionnels (seacutecuriteacute
performances) que doit reacutealiser le systegraveme logiciel en deacuteveloppement
o Ils sont utiliseacutes aussi comme moyen de dialogue entre diffeacuterents travailleurs (Speacutecificateurs
Analystes Concepteurs Programmeurs ) et entre ces derniers et les acteurs (ou
utilisateurs)
Le symbole graphique dun Use Case se fait par
~om du Use Case
B 2) Description dun USE CASE
o La description des USE CASES doit ecirctre syntheacutetique compreacutehensible (comme tout modegravele) et
doit eacutegalement rendre compte aiseacutement du deacuteroulement dun cas dutilisation
o Un USE CASE peut ecirctre deacutecrit de diffeacuterentes faccedilons
bull de faccedilon informelle il sagit alors de texte libre comme peuvent lecirctre les speacutecifications
bull de faccedilon formelle il peut alors sagir dune langage structureacute de diagrammes ou dun
pseudo-code
bull Il est recommandeacute deffectuer au moins deux descriptions
bull + Une externe (au niveau Analyse) qui speacutecifie les besoins du point de vue de lacteur
uniquement
bull
bull + une interne (au niveau conception) qui prend en consideacuteration les concepts du
systegraveme (classes eacutecrans controcircles base de donneacutees )
bull Pour cette description interne on peut utiliser une maquette (une succession
deacutecrans) ougrave on indiquerait les options et les informations que doit renseigner un acteur pour
un Use Case donneacute
bull Ex Retrait dArgent dans une agence bancaire
6
Responsable argent
Exemple Un cas dutilisation peut ecirctre le retrait despegraveces demandeacute par un
client sur un compte preacutecis
Une description teKtuelle peut ecirctre
+ La responsable argent alimente chaque guichetier en argent chaque matin et en fonction des
besoins
+ Le guichetier saisit le numeacutero de compte du client
+ Lapplication valide le compte aupregraves du systegraveme central
+ Lapplication demande le type dopeacuteration au guichetier
+ Le guichetier choisit un retrait despegraveces du montant en Dirhams
+ Le systegraveme laquo guichetraquo interroge le systegraveme central pour sassurer que le compte est
suffisamment approvisionneacute
+ Le systegraveme central effectue le deacutebit du compte
+ Le systegraveme notifie au guichetier quil peut deacutelivrer le montant demandeacute
UML na pas speacutecifieacute un canevas de description pour les USE CASES mais le modegravele le plus reacutepandu
correspond au format ci dessus
o Acteur Principal celui qui fait appel au systegraveme
o Parties prenantes et inteacuterecircts deacutecrit et deacutelimite ce que le systegraveme fait
o Preacute conditions ce qui doit ecirctre vrai avant le deacutebut dun sceacutenario
o Post conditions (garanties de succegraves) ce qui doit ecirctre vrai agrave la fin dun sceacutenario
o Sceacutenario Principal chemin type le plus utiliseacute pour les parties impliqueacutees
o Extensions (ou Sceacutenarios alternatifs) branchements particuliegraveres ou dexception
o Speacutecifications Particuliegraveres besoins non fonctionnels dispositifs dES
o Liste de variantes et de donneacutees technologiques
ex lecteur de cartes pour diffeacuterents codes agrave barres
o Freacutequence doccurrences
o Questions ouvertes pour compleacuteter les speacutecifications dans les iteacuterations suivantes
Certains pratiquants ont apporteacute agrave ce modegravele quelques preacutecisions
(voir exemple 1 ci dessous)
7
Une autre description proposeacutee ressemble au diagramme de reacutepartition des tacircches Homme
Machine (du MOT de MERISE) et utilise deux colonnes une pour lacteur et autre pour le systegraveme
(voir exemple 1 ci-dessous)
83) les relations entre USE CASES au sein dun systegraveme
On distingue trois types de relations entre USE CASES
a) la relation de Geacuteneacuteralisation 1Speacutecialisation
Cest le principe dheacuteritage ex
b) la relation laquo Include raquo
o Permet la factorisation dun ensemble de tacircches
o Dans un systegraveme il existe des tacircches que doit faire reacuteguliegraverement un utilisateur
Par exemple le guichetier aura souvent besoin de valider le numeacutero du compte de lutilisateur On
peut preacuteciser comment se fait cette validation dans un Use Case et indiquer que cette fonctionnaliteacute
sera utiliseacutee dans diffeacuterents USE CASES
Cette relation permet donc de
+ factoriser des USE CASES correspondant agrave des fonctionnaliteacutes qui servent dans diffeacuterents USE
CASES
+ expliciter la constitution dun USE CASE complexe en le deacutecomposant en plusieurs USE CASES
relieacutes
Exemple Consideacuterons le USE CASE laquo Valider utilisateurraquo deacutecrit comme suit
+ le guichetier saisit le code de la banque du compte
+ il saisit te numeacutero du compte
+ il saisit la cleacute de compte
+ le systegraveme calcule la cleacute du compte et veacuterifie quelle est bonne
+ le systegraveme interroge le compte sur le systegraveme central
+ le systegraveme affiche le compte ainsi que son deacutetenteur
c) la relation laquo extend raquo
Cette relation qui peut exister entre USE CASES indique que le USE CASE qui est pointeacute par la flegraveche
est une sous-partie optionnelle de lautre USE CASE et quil peut aussi ecirctre utiliseacute tout seul
8
La relation laquo extend ) indique que tous les USE CASES fils heacuteritent de toutes les caracteacuteristiques du
USE CASE pegravere (USE CASE qui est pointeacute par la flegraveche) cest-agrave-dire quils ont les mecircmes liens avec les
acteurs et les autres USE CASES
Ce type dheacuteritage a aussi une valeur seacutemantique
Il indique que tous les USE CASES fils sont des cas particuliers du USE CASE pegravere
Exemple ( CommanderTeacuteleacutephone) est le USE CASE geacuteneacuterique et laquo Demander prix produitsraquo est
un cas particulier du premier
Remarque Il faut distinguer entre une relation laquo extend raquo
et une relation de Geacuteneacuteralisation ISpeacutecialisation
Il3) le Diagramme des USE CASES
Cette repreacutesentation graphique permet de voir de faccedilon simple
+ les diffeacuterents acteurs
+ comment est deacutelimiteacute le systegraveme
+ les fonctionnaliteacutes demandeacutees au systegraveme
+ les rocircles des diffeacuterents acteurs vis-agrave-vis du
systegraveme
Il faut donner un nom au diagramme
9
1
CAISSIER
Applkation BaliCaire
Responsable Devise
DIRECTEUR Acte-ur
Syst Ce-nb-aJ
Description du cas dutilisation laquo Retraits Dirhamsraquo Modegravele classique
Sommaire didentification (obligatoire)
Titre retrait dargent avec un chegraveque ou un chegraveque guichet
Reacutesumeacute ce cas permet agrave un client de la banque de retirer de
largent de son compte avec un chegraveque une carte ou un
chegraveque guichet si son solde ou son deacutecouvert le lui permet
Acteurs guichetier de la banque le systegraveme central
Date de creacuteation 110904 Date de MAJ 190904
Version 23
Responsable Kaddour ben Jilali
Description des enchaIcircnements (obligatoire)
o Preacute conditions Le systegraveme est lanceacute le guichetier est identifieacute le solde caisse est
suffisamment approvisionneacute
o Sceacutenario Principal
1) Le client preacutesente un chegraveque agrave lui pour retirer des dirhams
2) Le guichetier demande identification du client
10
3 Le systegraveme valide lidentification et affiche la signature
4 Le guichetier veacuterifie la signature apposeacutee sur le chegraveque
5) Le systegraveme veacuterifie le solde et le deacutecouvert du compte client
6) Le systegraveme donne son accord
7 Le guichetier deacutelivre le montant demandeacute
Le systegraveme met agrave jour le compte client et le solde caisse
bull Sceacutenarios alternatifs
SAl Le client na pas de chegraveque
Cet enchaicircnement deacutemarre au point 1)
la) Le guichetier remplit un chegraveque guichet avec le montant demandeacute
1) Le client signe le chegraveque
2) le guichetier le reprend
Ce sceacutenario continue au point 2 du sceacutenario principal
SA2 Le solde et le deacutecouvert ne permettent pas le retrait
Cet enchaicircnement deacutemarre en 6)
6a) le systegraveme ne donne pas laccord pour le retrait
1) le chegraveque est remis au client
2) lopeacuteration est termineacutee
bull Post conditions Le compte client est mis agrave jour ainsi que le solde de la caisse en
cas de succegraves du retrait autrement ils doivent rester inchangeacutes
bull Besoins dIHM lfocultatiO
+ un lecteur de chegraveques
+ Un terminal avec clavier (pour saisir le num chegraveque si le lecteur ny arrive pas) et afficher limage de
la signature du client
+ Un compteur de billets
o Contraintes non fonctionnels lfocultatiO
+ Temps de reacuteponse Une transaction nominale doit durer moins de 2 minutes
+ Concurrence Un chegraveque du client peut ecirctre retireacute en mecircme temps par une autre personne
aupregraves dun autre guichetier dans la mecircme agence
11
1 slj~ IbL~~ )~ l~ 3((1
+ Disponibiliteacute le systegraveme doit ecirctre lanceacute 15 mn avant les horaires du travail est arrecircteacute agrave la
demande du directeur de lagence
+ Confidentialiteacute leacutecran doit ecirctre positionneacute de telle sorte quil ne peut ecirctre lu par un client
quelque soit sa position
Description du cas dutilisation laquo Retraits Dirhamsraquo
Modegravele de 2 colonnes pour les sceacutenarios (ou enchaicircnements)
Description des enchaIcircnements obligatoire
D Sceacutenario Principal
Le guichetier 1Le systegraveme
1) prend le chegraveque client
et demande identification
2) lit le chegraveque et
veacuterifie identification et
affiche la signature
3) veacuterifie la signature
~~----------~---------------~ tXfflLe
~ r ~l)~J ~s (~i~ iv ow SeJv 10 ~ (~hgtQ t~ ~ bA JoJe-eJ lt
et ~ J~ kA slj~iJV ~l S(~
Le S crf)- _ JeA b 1~~ ))J
Loc s~eacuteJi
D cc(9v-~~~eacute Jt iJr-6
12
o OOSE (Object Oriented Sofware Engineering) de Ivar Jacobson qui fut inteacutegreacutee agrave UMl en
1997
o UMl sinspire eacutegalement de toutes les autres meacutethodes leaders du marcheacute
[J le formalisme UMl peut donc ecirctre utiliseacute dans diffeacuterents processus de deacuteveloppement et en
particulier dans celui proposeacute par les concepteurs du langage (RUP Rational Unified Process
ou le Processus Unifieacute) (UP l Unified Process) ( 2TUP Two Track Unified Process ) (XP
Extreme Programming )0
o la migration de MERISE 00 agrave UMl peut se faire assez aiseacutement
[J UML et la standardisation
o Initialement UMl a eacuteteacute soumise en janvier 1997 agrave lOMG (Object Management Group) dans
le cadre de la standardisation des meacutethodes danalyse et de conception orienteacutees objet la
version 10 dUML a tregraves vite obtenu le ralliement de nombreux acteurs du marcheacute
(Microsoft Oracle Hewlett-Packard )et de nombreux eacutediteurs dAGL (ateliers de geacutenie
logiciel) UML 20 est la derniegravere version voteacutee en 2003
o la technologie orienteacutee objet et le formalisme UMl en particulier veacutehiculent des concepts
tregraves geacuteneacuteraux dont lapplication nest pas limiteacutee au domaine informatique
UML et La Modeacutelisation
bull Un Systegraveme est un ensemble deacuteleacutements organiseacutes et de relations entre ces
eacuteleacutements en vue datteindre un objectif Il est deacutecrit par un ensemble de Modegraveles en
geacuteneacuteral sous diffeacuterents points de vues ou angles
bull Un Modegravele cest une abstraction dun Systegraveme complegravete et fermeacutee du point de
vue seacutemantique c ad repreacutesentant une simplification coheacuterente de la reacutealiteacute et
creacuteeacutee dans le but de faciliter la compreacutehension du systegraveme (UMl20 propose 13 en
tout)
bull Un Diagramme est une repreacutesentation graphique dun ensemble deacuteleacutements sous
forme dun graphe connecteacute de sommets (eacuteleacutements structurels) et darcs (relations)
bull Un diagramme nest pas un modegravele ce nest quune repreacutesentation de quelques
eacuteleacutements du modegravele
o Plusieurs diagrammes savegraverent souvent neacutecessaires pour illustrer un modegravele complet
o Pour la modeacutelisation UML distingue 2 cateacutegories de diagrammes
Les Diagrammes Structurels permettent de visualiser construire et documenter les aspects
statiques dun systegraveme
Dans cette cateacutegorie on trouve 6 diagrammes
- de Classes
- dObjets
- de Composants
- de Deacuteploiement
2
- de Structure Composite
- de Package
Les Diagrammes Comportementaux
permettent de visualiser construire et documenter
les aspects dynamiques dun systegraveme Dans cette
cateacutegorie on trouve 7 diagrammes
bull des USE CASES
bull des Interactions
C Seacutequence
C de Communication (av collaboration)
C vue densemble des Interactions
C deTiming
bull dlActiviteacutes
bull de Machine dEtats (av Etats-Transitions)
o En principe ni UML ni le Processus Unifieacute (la Meacutethode) nobligent agrave repreacutesenter les 13
diagrammes
Ils laissent agrave lanalyste et au concepteur la latitude deacutecisionnelle en fonction de leurs besoins
Cependant les 2 diagrammes qui savegraverent toujours neacutecessaires sont surtout
bull le diagramme des USE CASES et
bull le diagramme de Classes
Il) La Modeacutelisation des USE CASES
(CAS DUTILISATION ou CAS DUSAGE)
111) Que sont les USE CASES
Les USE CASES constituent le concept principal de la meacutethode OOSE dIvar Jacobson
Le concept des USE CASE a eacuteteacute repris dans le but deffectuer une bonne deacutelimitation du systegraveme mais
eacutegalement pour ameacuteliorer la compreacutehension de son fonctionnement et reacutealiser sa speacutecification
Les USE CASES repreacutesentent un meacutecanisme qui permet de deacutetecter didentifier de comprendre et
de consigner les besoins
Ils permettent dorienter tout le processus de deacuteveloppement car les activiteacutes dAnalyse de
Conception et de Test sont effectueacutees agrave partir des USE CASES
Les USE CASES repreacutesentent le premier modegravele du systegraveme agrave concevoir
Les USE CASES sont une repreacutesentation orienteacutee laquo fonctionnaliteacuteraquo du systegraveme qui permettent de
modeacuteliser les attentes des utilisateurs
3
Une bonne compreacutehension du systegraveme est primordiale avant dentreprendre lanalyse et la
conception
USE
CONCEPTION
Il2 Les concepts
Deux concepts fondamentaux pour repreacutesenter les USE CASES
- les acteurs qui utilisent le systegraveme
- les USE CASES qui repreacutesentent lutilisation
du systegraveme par les acteurs
A) Les acteurs (utilisateurs du systegraveme)
Pour permettre une bonne deacutelimitation du systegraveme il est bon de bien seacuteparer les eacuteleacutements
constitutifs du systegraveme logiciel des eacuteleacutements exteacuterieurs les acteurs repreacutesentent cette frontiegravere
Ce sont des eacuteleacutements exteacuterieur au systegraveme et qui interagissent avec lui
Il faut dabord Identifier les acteurs qui peuvent ecirctre des
Humains ce sont des utilisateurs du logiciel agrave
travers son interface graphique par exemple
Logiciels ce sont des logiciels deacutejagrave disponibles qui
communiquent avec le systegraveme gracircce agrave une
interface logicielle (une API par exemple)
Mateacuteriels robots et automates qui exploitent les
donneacutees du systegraveme ou qui sont piloteacutes par le
systegraveme (GAB)
Systegravemes exteacuterieurs (le Systegraveme de la banque de la
socieacuteteacute)
Al) Typologie des acteurs
Il existe trois types dacteurs
Les acteurs principaux ou primaires Ceux qui utilisent le systegraveme pour atteindre leurs buts (ils sont
la raison de lexistence du systegraveme)
Les acteurs secondaires Ceux qui administrent le systegraveme et assurent sa maintenance Ce sont eux
qui paramegravetrent le systegraveme et qui lui fournissent toutes les informations ou services neacutecessaires agrave son bon fonctionnement pour les acteurs principaux
Exla personne chargeacutee de la MAJ des cours des devises
Les acteurs externes Ceux qui ont un inteacuterecirct dans le comportement du cas dutilisation
Ex les services des impocircts du commerce
4
Remarquef
bull Un acteur correspond agrave un rocircle joueacute vis-agrave-vis du systegraveme (Un salarieacute dune banque correspond
souvent agrave un ou plusieurs rocircles directeur guichetier responsable devises ) et plusieurs individus
jouent souvent le mecircme rocircle (guichetier)
bull Une mecircme entiteacute peut repreacutesenter tour agrave tour deux types dacteurs
Exemple dans le caS de petites agences bancaires le directeur dagence peut ecirctre ameneacute agrave faire des opeacuterations de maintenance (alimenter le DAB en liquide)
A2) Pourquoi des acteurs
Identifier les acteurs dun systegraveme permet de
deacutelimiter le systegraveme Un acteur est un eacuteleacutement exteacuterieur au systegraveme qui interagit avec ce dernier
- avoir une vue orienteacutee utilisateur du systegraveme Avant de se lancer dans lanalyse et la conception
interne du systegraveme il est bon den avoir une vue externe qui correspond agrave toutes les fonctionnaliteacutes
attendues par les diffeacuterents acteurs
Remarque
UMl permet de steacutereacuteotyper les acteurs et dutiliser dautres icocircnes plus speacutecifiques (avec
utilisation des couleurs et images) en fonction des besoins pour offrir un meilleur repegravere visuel
Mais lutilisation de ces icocircnes doit ecirctre faite avec parcimonie
Ex
Un eacutetudiant Une eacutetudiante
A3) Les relations entre ACTEURS
Pour UMl la relation preacutevue entre acteurs est une relation de geacuteneacuteralisationSpeacutecialisation
B) Les USE CASES Eleacutements de linterface dutilisation
Bl) Deacutefinitions
Un USE CASE est une suite de seacutequences dactions y compris des variantes (souvent initieacutee par un
des acteurs) et qui correspond agrave une exeacutecution particuliegravere du systegraveme pour produire un reacutesultat ou
reacutepondre au(x) besoin(s) dun acteur
les USE CASES permettent de bien comprendre le systegraveme
Le but des USE CASES nest pas de faire une description exhaustive des fonctionnaliteacutes du systegraveme
logiciel en deacuteveloppement Ils permettent de deacutecrire ce que fait un systegraveme (un sous systegraveme une
classe ou une interface) mais ne preacutecisent pas comment il le fait
5
Ils permettent de repreacutesenter les besoins fonctionnels et non fonctionnels (seacutecuriteacute
performances ) que doit reacutealiser le systegraveme logiciel en deacuteveloppement
B) Les USE CASES Eleacutements de linterface dutilisation
Bi) Deacutefinitions
o Un USE CASE est une suite de seacutequences dactions y compris des variantes (souvent initieacutee
par un des acteurs) et qui correspond agrave une exeacutecution particuliegravere du systegraveme pour
produire un reacutesultat ou reacutepondre aulx) besoin(s) dun acteur
o Les USE CASES permettent de bien comprendre le systegraveme
Le but des USE CASES nest pas de faire une description exhaustive des fonctionnaliteacutes du
systegraveme logiciel en deacuteveloppement Ils permettent de deacutecrire ce que fait un systegraveme (un
sous systegraveme une classe ou une interface) mais ne preacutecisent pas comment il le fait
o Ils permettent de repreacutesenter les besoins fonctionnels et non fonctionnels (seacutecuriteacute
performances) que doit reacutealiser le systegraveme logiciel en deacuteveloppement
o Ils sont utiliseacutes aussi comme moyen de dialogue entre diffeacuterents travailleurs (Speacutecificateurs
Analystes Concepteurs Programmeurs ) et entre ces derniers et les acteurs (ou
utilisateurs)
Le symbole graphique dun Use Case se fait par
~om du Use Case
B 2) Description dun USE CASE
o La description des USE CASES doit ecirctre syntheacutetique compreacutehensible (comme tout modegravele) et
doit eacutegalement rendre compte aiseacutement du deacuteroulement dun cas dutilisation
o Un USE CASE peut ecirctre deacutecrit de diffeacuterentes faccedilons
bull de faccedilon informelle il sagit alors de texte libre comme peuvent lecirctre les speacutecifications
bull de faccedilon formelle il peut alors sagir dune langage structureacute de diagrammes ou dun
pseudo-code
bull Il est recommandeacute deffectuer au moins deux descriptions
bull + Une externe (au niveau Analyse) qui speacutecifie les besoins du point de vue de lacteur
uniquement
bull
bull + une interne (au niveau conception) qui prend en consideacuteration les concepts du
systegraveme (classes eacutecrans controcircles base de donneacutees )
bull Pour cette description interne on peut utiliser une maquette (une succession
deacutecrans) ougrave on indiquerait les options et les informations que doit renseigner un acteur pour
un Use Case donneacute
bull Ex Retrait dArgent dans une agence bancaire
6
Responsable argent
Exemple Un cas dutilisation peut ecirctre le retrait despegraveces demandeacute par un
client sur un compte preacutecis
Une description teKtuelle peut ecirctre
+ La responsable argent alimente chaque guichetier en argent chaque matin et en fonction des
besoins
+ Le guichetier saisit le numeacutero de compte du client
+ Lapplication valide le compte aupregraves du systegraveme central
+ Lapplication demande le type dopeacuteration au guichetier
+ Le guichetier choisit un retrait despegraveces du montant en Dirhams
+ Le systegraveme laquo guichetraquo interroge le systegraveme central pour sassurer que le compte est
suffisamment approvisionneacute
+ Le systegraveme central effectue le deacutebit du compte
+ Le systegraveme notifie au guichetier quil peut deacutelivrer le montant demandeacute
UML na pas speacutecifieacute un canevas de description pour les USE CASES mais le modegravele le plus reacutepandu
correspond au format ci dessus
o Acteur Principal celui qui fait appel au systegraveme
o Parties prenantes et inteacuterecircts deacutecrit et deacutelimite ce que le systegraveme fait
o Preacute conditions ce qui doit ecirctre vrai avant le deacutebut dun sceacutenario
o Post conditions (garanties de succegraves) ce qui doit ecirctre vrai agrave la fin dun sceacutenario
o Sceacutenario Principal chemin type le plus utiliseacute pour les parties impliqueacutees
o Extensions (ou Sceacutenarios alternatifs) branchements particuliegraveres ou dexception
o Speacutecifications Particuliegraveres besoins non fonctionnels dispositifs dES
o Liste de variantes et de donneacutees technologiques
ex lecteur de cartes pour diffeacuterents codes agrave barres
o Freacutequence doccurrences
o Questions ouvertes pour compleacuteter les speacutecifications dans les iteacuterations suivantes
Certains pratiquants ont apporteacute agrave ce modegravele quelques preacutecisions
(voir exemple 1 ci dessous)
7
Une autre description proposeacutee ressemble au diagramme de reacutepartition des tacircches Homme
Machine (du MOT de MERISE) et utilise deux colonnes une pour lacteur et autre pour le systegraveme
(voir exemple 1 ci-dessous)
83) les relations entre USE CASES au sein dun systegraveme
On distingue trois types de relations entre USE CASES
a) la relation de Geacuteneacuteralisation 1Speacutecialisation
Cest le principe dheacuteritage ex
b) la relation laquo Include raquo
o Permet la factorisation dun ensemble de tacircches
o Dans un systegraveme il existe des tacircches que doit faire reacuteguliegraverement un utilisateur
Par exemple le guichetier aura souvent besoin de valider le numeacutero du compte de lutilisateur On
peut preacuteciser comment se fait cette validation dans un Use Case et indiquer que cette fonctionnaliteacute
sera utiliseacutee dans diffeacuterents USE CASES
Cette relation permet donc de
+ factoriser des USE CASES correspondant agrave des fonctionnaliteacutes qui servent dans diffeacuterents USE
CASES
+ expliciter la constitution dun USE CASE complexe en le deacutecomposant en plusieurs USE CASES
relieacutes
Exemple Consideacuterons le USE CASE laquo Valider utilisateurraquo deacutecrit comme suit
+ le guichetier saisit le code de la banque du compte
+ il saisit te numeacutero du compte
+ il saisit la cleacute de compte
+ le systegraveme calcule la cleacute du compte et veacuterifie quelle est bonne
+ le systegraveme interroge le compte sur le systegraveme central
+ le systegraveme affiche le compte ainsi que son deacutetenteur
c) la relation laquo extend raquo
Cette relation qui peut exister entre USE CASES indique que le USE CASE qui est pointeacute par la flegraveche
est une sous-partie optionnelle de lautre USE CASE et quil peut aussi ecirctre utiliseacute tout seul
8
La relation laquo extend ) indique que tous les USE CASES fils heacuteritent de toutes les caracteacuteristiques du
USE CASE pegravere (USE CASE qui est pointeacute par la flegraveche) cest-agrave-dire quils ont les mecircmes liens avec les
acteurs et les autres USE CASES
Ce type dheacuteritage a aussi une valeur seacutemantique
Il indique que tous les USE CASES fils sont des cas particuliers du USE CASE pegravere
Exemple ( CommanderTeacuteleacutephone) est le USE CASE geacuteneacuterique et laquo Demander prix produitsraquo est
un cas particulier du premier
Remarque Il faut distinguer entre une relation laquo extend raquo
et une relation de Geacuteneacuteralisation ISpeacutecialisation
Il3) le Diagramme des USE CASES
Cette repreacutesentation graphique permet de voir de faccedilon simple
+ les diffeacuterents acteurs
+ comment est deacutelimiteacute le systegraveme
+ les fonctionnaliteacutes demandeacutees au systegraveme
+ les rocircles des diffeacuterents acteurs vis-agrave-vis du
systegraveme
Il faut donner un nom au diagramme
9
1
CAISSIER
Applkation BaliCaire
Responsable Devise
DIRECTEUR Acte-ur
Syst Ce-nb-aJ
Description du cas dutilisation laquo Retraits Dirhamsraquo Modegravele classique
Sommaire didentification (obligatoire)
Titre retrait dargent avec un chegraveque ou un chegraveque guichet
Reacutesumeacute ce cas permet agrave un client de la banque de retirer de
largent de son compte avec un chegraveque une carte ou un
chegraveque guichet si son solde ou son deacutecouvert le lui permet
Acteurs guichetier de la banque le systegraveme central
Date de creacuteation 110904 Date de MAJ 190904
Version 23
Responsable Kaddour ben Jilali
Description des enchaIcircnements (obligatoire)
o Preacute conditions Le systegraveme est lanceacute le guichetier est identifieacute le solde caisse est
suffisamment approvisionneacute
o Sceacutenario Principal
1) Le client preacutesente un chegraveque agrave lui pour retirer des dirhams
2) Le guichetier demande identification du client
10
3 Le systegraveme valide lidentification et affiche la signature
4 Le guichetier veacuterifie la signature apposeacutee sur le chegraveque
5) Le systegraveme veacuterifie le solde et le deacutecouvert du compte client
6) Le systegraveme donne son accord
7 Le guichetier deacutelivre le montant demandeacute
Le systegraveme met agrave jour le compte client et le solde caisse
bull Sceacutenarios alternatifs
SAl Le client na pas de chegraveque
Cet enchaicircnement deacutemarre au point 1)
la) Le guichetier remplit un chegraveque guichet avec le montant demandeacute
1) Le client signe le chegraveque
2) le guichetier le reprend
Ce sceacutenario continue au point 2 du sceacutenario principal
SA2 Le solde et le deacutecouvert ne permettent pas le retrait
Cet enchaicircnement deacutemarre en 6)
6a) le systegraveme ne donne pas laccord pour le retrait
1) le chegraveque est remis au client
2) lopeacuteration est termineacutee
bull Post conditions Le compte client est mis agrave jour ainsi que le solde de la caisse en
cas de succegraves du retrait autrement ils doivent rester inchangeacutes
bull Besoins dIHM lfocultatiO
+ un lecteur de chegraveques
+ Un terminal avec clavier (pour saisir le num chegraveque si le lecteur ny arrive pas) et afficher limage de
la signature du client
+ Un compteur de billets
o Contraintes non fonctionnels lfocultatiO
+ Temps de reacuteponse Une transaction nominale doit durer moins de 2 minutes
+ Concurrence Un chegraveque du client peut ecirctre retireacute en mecircme temps par une autre personne
aupregraves dun autre guichetier dans la mecircme agence
11
1 slj~ IbL~~ )~ l~ 3((1
+ Disponibiliteacute le systegraveme doit ecirctre lanceacute 15 mn avant les horaires du travail est arrecircteacute agrave la
demande du directeur de lagence
+ Confidentialiteacute leacutecran doit ecirctre positionneacute de telle sorte quil ne peut ecirctre lu par un client
quelque soit sa position
Description du cas dutilisation laquo Retraits Dirhamsraquo
Modegravele de 2 colonnes pour les sceacutenarios (ou enchaicircnements)
Description des enchaIcircnements obligatoire
D Sceacutenario Principal
Le guichetier 1Le systegraveme
1) prend le chegraveque client
et demande identification
2) lit le chegraveque et
veacuterifie identification et
affiche la signature
3) veacuterifie la signature
~~----------~---------------~ tXfflLe
~ r ~l)~J ~s (~i~ iv ow SeJv 10 ~ (~hgtQ t~ ~ bA JoJe-eJ lt
et ~ J~ kA slj~iJV ~l S(~
Le S crf)- _ JeA b 1~~ ))J
Loc s~eacuteJi
D cc(9v-~~~eacute Jt iJr-6
12
- de Structure Composite
- de Package
Les Diagrammes Comportementaux
permettent de visualiser construire et documenter
les aspects dynamiques dun systegraveme Dans cette
cateacutegorie on trouve 7 diagrammes
bull des USE CASES
bull des Interactions
C Seacutequence
C de Communication (av collaboration)
C vue densemble des Interactions
C deTiming
bull dlActiviteacutes
bull de Machine dEtats (av Etats-Transitions)
o En principe ni UML ni le Processus Unifieacute (la Meacutethode) nobligent agrave repreacutesenter les 13
diagrammes
Ils laissent agrave lanalyste et au concepteur la latitude deacutecisionnelle en fonction de leurs besoins
Cependant les 2 diagrammes qui savegraverent toujours neacutecessaires sont surtout
bull le diagramme des USE CASES et
bull le diagramme de Classes
Il) La Modeacutelisation des USE CASES
(CAS DUTILISATION ou CAS DUSAGE)
111) Que sont les USE CASES
Les USE CASES constituent le concept principal de la meacutethode OOSE dIvar Jacobson
Le concept des USE CASE a eacuteteacute repris dans le but deffectuer une bonne deacutelimitation du systegraveme mais
eacutegalement pour ameacuteliorer la compreacutehension de son fonctionnement et reacutealiser sa speacutecification
Les USE CASES repreacutesentent un meacutecanisme qui permet de deacutetecter didentifier de comprendre et
de consigner les besoins
Ils permettent dorienter tout le processus de deacuteveloppement car les activiteacutes dAnalyse de
Conception et de Test sont effectueacutees agrave partir des USE CASES
Les USE CASES repreacutesentent le premier modegravele du systegraveme agrave concevoir
Les USE CASES sont une repreacutesentation orienteacutee laquo fonctionnaliteacuteraquo du systegraveme qui permettent de
modeacuteliser les attentes des utilisateurs
3
Une bonne compreacutehension du systegraveme est primordiale avant dentreprendre lanalyse et la
conception
USE
CONCEPTION
Il2 Les concepts
Deux concepts fondamentaux pour repreacutesenter les USE CASES
- les acteurs qui utilisent le systegraveme
- les USE CASES qui repreacutesentent lutilisation
du systegraveme par les acteurs
A) Les acteurs (utilisateurs du systegraveme)
Pour permettre une bonne deacutelimitation du systegraveme il est bon de bien seacuteparer les eacuteleacutements
constitutifs du systegraveme logiciel des eacuteleacutements exteacuterieurs les acteurs repreacutesentent cette frontiegravere
Ce sont des eacuteleacutements exteacuterieur au systegraveme et qui interagissent avec lui
Il faut dabord Identifier les acteurs qui peuvent ecirctre des
Humains ce sont des utilisateurs du logiciel agrave
travers son interface graphique par exemple
Logiciels ce sont des logiciels deacutejagrave disponibles qui
communiquent avec le systegraveme gracircce agrave une
interface logicielle (une API par exemple)
Mateacuteriels robots et automates qui exploitent les
donneacutees du systegraveme ou qui sont piloteacutes par le
systegraveme (GAB)
Systegravemes exteacuterieurs (le Systegraveme de la banque de la
socieacuteteacute)
Al) Typologie des acteurs
Il existe trois types dacteurs
Les acteurs principaux ou primaires Ceux qui utilisent le systegraveme pour atteindre leurs buts (ils sont
la raison de lexistence du systegraveme)
Les acteurs secondaires Ceux qui administrent le systegraveme et assurent sa maintenance Ce sont eux
qui paramegravetrent le systegraveme et qui lui fournissent toutes les informations ou services neacutecessaires agrave son bon fonctionnement pour les acteurs principaux
Exla personne chargeacutee de la MAJ des cours des devises
Les acteurs externes Ceux qui ont un inteacuterecirct dans le comportement du cas dutilisation
Ex les services des impocircts du commerce
4
Remarquef
bull Un acteur correspond agrave un rocircle joueacute vis-agrave-vis du systegraveme (Un salarieacute dune banque correspond
souvent agrave un ou plusieurs rocircles directeur guichetier responsable devises ) et plusieurs individus
jouent souvent le mecircme rocircle (guichetier)
bull Une mecircme entiteacute peut repreacutesenter tour agrave tour deux types dacteurs
Exemple dans le caS de petites agences bancaires le directeur dagence peut ecirctre ameneacute agrave faire des opeacuterations de maintenance (alimenter le DAB en liquide)
A2) Pourquoi des acteurs
Identifier les acteurs dun systegraveme permet de
deacutelimiter le systegraveme Un acteur est un eacuteleacutement exteacuterieur au systegraveme qui interagit avec ce dernier
- avoir une vue orienteacutee utilisateur du systegraveme Avant de se lancer dans lanalyse et la conception
interne du systegraveme il est bon den avoir une vue externe qui correspond agrave toutes les fonctionnaliteacutes
attendues par les diffeacuterents acteurs
Remarque
UMl permet de steacutereacuteotyper les acteurs et dutiliser dautres icocircnes plus speacutecifiques (avec
utilisation des couleurs et images) en fonction des besoins pour offrir un meilleur repegravere visuel
Mais lutilisation de ces icocircnes doit ecirctre faite avec parcimonie
Ex
Un eacutetudiant Une eacutetudiante
A3) Les relations entre ACTEURS
Pour UMl la relation preacutevue entre acteurs est une relation de geacuteneacuteralisationSpeacutecialisation
B) Les USE CASES Eleacutements de linterface dutilisation
Bl) Deacutefinitions
Un USE CASE est une suite de seacutequences dactions y compris des variantes (souvent initieacutee par un
des acteurs) et qui correspond agrave une exeacutecution particuliegravere du systegraveme pour produire un reacutesultat ou
reacutepondre au(x) besoin(s) dun acteur
les USE CASES permettent de bien comprendre le systegraveme
Le but des USE CASES nest pas de faire une description exhaustive des fonctionnaliteacutes du systegraveme
logiciel en deacuteveloppement Ils permettent de deacutecrire ce que fait un systegraveme (un sous systegraveme une
classe ou une interface) mais ne preacutecisent pas comment il le fait
5
Ils permettent de repreacutesenter les besoins fonctionnels et non fonctionnels (seacutecuriteacute
performances ) que doit reacutealiser le systegraveme logiciel en deacuteveloppement
B) Les USE CASES Eleacutements de linterface dutilisation
Bi) Deacutefinitions
o Un USE CASE est une suite de seacutequences dactions y compris des variantes (souvent initieacutee
par un des acteurs) et qui correspond agrave une exeacutecution particuliegravere du systegraveme pour
produire un reacutesultat ou reacutepondre aulx) besoin(s) dun acteur
o Les USE CASES permettent de bien comprendre le systegraveme
Le but des USE CASES nest pas de faire une description exhaustive des fonctionnaliteacutes du
systegraveme logiciel en deacuteveloppement Ils permettent de deacutecrire ce que fait un systegraveme (un
sous systegraveme une classe ou une interface) mais ne preacutecisent pas comment il le fait
o Ils permettent de repreacutesenter les besoins fonctionnels et non fonctionnels (seacutecuriteacute
performances) que doit reacutealiser le systegraveme logiciel en deacuteveloppement
o Ils sont utiliseacutes aussi comme moyen de dialogue entre diffeacuterents travailleurs (Speacutecificateurs
Analystes Concepteurs Programmeurs ) et entre ces derniers et les acteurs (ou
utilisateurs)
Le symbole graphique dun Use Case se fait par
~om du Use Case
B 2) Description dun USE CASE
o La description des USE CASES doit ecirctre syntheacutetique compreacutehensible (comme tout modegravele) et
doit eacutegalement rendre compte aiseacutement du deacuteroulement dun cas dutilisation
o Un USE CASE peut ecirctre deacutecrit de diffeacuterentes faccedilons
bull de faccedilon informelle il sagit alors de texte libre comme peuvent lecirctre les speacutecifications
bull de faccedilon formelle il peut alors sagir dune langage structureacute de diagrammes ou dun
pseudo-code
bull Il est recommandeacute deffectuer au moins deux descriptions
bull + Une externe (au niveau Analyse) qui speacutecifie les besoins du point de vue de lacteur
uniquement
bull
bull + une interne (au niveau conception) qui prend en consideacuteration les concepts du
systegraveme (classes eacutecrans controcircles base de donneacutees )
bull Pour cette description interne on peut utiliser une maquette (une succession
deacutecrans) ougrave on indiquerait les options et les informations que doit renseigner un acteur pour
un Use Case donneacute
bull Ex Retrait dArgent dans une agence bancaire
6
Responsable argent
Exemple Un cas dutilisation peut ecirctre le retrait despegraveces demandeacute par un
client sur un compte preacutecis
Une description teKtuelle peut ecirctre
+ La responsable argent alimente chaque guichetier en argent chaque matin et en fonction des
besoins
+ Le guichetier saisit le numeacutero de compte du client
+ Lapplication valide le compte aupregraves du systegraveme central
+ Lapplication demande le type dopeacuteration au guichetier
+ Le guichetier choisit un retrait despegraveces du montant en Dirhams
+ Le systegraveme laquo guichetraquo interroge le systegraveme central pour sassurer que le compte est
suffisamment approvisionneacute
+ Le systegraveme central effectue le deacutebit du compte
+ Le systegraveme notifie au guichetier quil peut deacutelivrer le montant demandeacute
UML na pas speacutecifieacute un canevas de description pour les USE CASES mais le modegravele le plus reacutepandu
correspond au format ci dessus
o Acteur Principal celui qui fait appel au systegraveme
o Parties prenantes et inteacuterecircts deacutecrit et deacutelimite ce que le systegraveme fait
o Preacute conditions ce qui doit ecirctre vrai avant le deacutebut dun sceacutenario
o Post conditions (garanties de succegraves) ce qui doit ecirctre vrai agrave la fin dun sceacutenario
o Sceacutenario Principal chemin type le plus utiliseacute pour les parties impliqueacutees
o Extensions (ou Sceacutenarios alternatifs) branchements particuliegraveres ou dexception
o Speacutecifications Particuliegraveres besoins non fonctionnels dispositifs dES
o Liste de variantes et de donneacutees technologiques
ex lecteur de cartes pour diffeacuterents codes agrave barres
o Freacutequence doccurrences
o Questions ouvertes pour compleacuteter les speacutecifications dans les iteacuterations suivantes
Certains pratiquants ont apporteacute agrave ce modegravele quelques preacutecisions
(voir exemple 1 ci dessous)
7
Une autre description proposeacutee ressemble au diagramme de reacutepartition des tacircches Homme
Machine (du MOT de MERISE) et utilise deux colonnes une pour lacteur et autre pour le systegraveme
(voir exemple 1 ci-dessous)
83) les relations entre USE CASES au sein dun systegraveme
On distingue trois types de relations entre USE CASES
a) la relation de Geacuteneacuteralisation 1Speacutecialisation
Cest le principe dheacuteritage ex
b) la relation laquo Include raquo
o Permet la factorisation dun ensemble de tacircches
o Dans un systegraveme il existe des tacircches que doit faire reacuteguliegraverement un utilisateur
Par exemple le guichetier aura souvent besoin de valider le numeacutero du compte de lutilisateur On
peut preacuteciser comment se fait cette validation dans un Use Case et indiquer que cette fonctionnaliteacute
sera utiliseacutee dans diffeacuterents USE CASES
Cette relation permet donc de
+ factoriser des USE CASES correspondant agrave des fonctionnaliteacutes qui servent dans diffeacuterents USE
CASES
+ expliciter la constitution dun USE CASE complexe en le deacutecomposant en plusieurs USE CASES
relieacutes
Exemple Consideacuterons le USE CASE laquo Valider utilisateurraquo deacutecrit comme suit
+ le guichetier saisit le code de la banque du compte
+ il saisit te numeacutero du compte
+ il saisit la cleacute de compte
+ le systegraveme calcule la cleacute du compte et veacuterifie quelle est bonne
+ le systegraveme interroge le compte sur le systegraveme central
+ le systegraveme affiche le compte ainsi que son deacutetenteur
c) la relation laquo extend raquo
Cette relation qui peut exister entre USE CASES indique que le USE CASE qui est pointeacute par la flegraveche
est une sous-partie optionnelle de lautre USE CASE et quil peut aussi ecirctre utiliseacute tout seul
8
La relation laquo extend ) indique que tous les USE CASES fils heacuteritent de toutes les caracteacuteristiques du
USE CASE pegravere (USE CASE qui est pointeacute par la flegraveche) cest-agrave-dire quils ont les mecircmes liens avec les
acteurs et les autres USE CASES
Ce type dheacuteritage a aussi une valeur seacutemantique
Il indique que tous les USE CASES fils sont des cas particuliers du USE CASE pegravere
Exemple ( CommanderTeacuteleacutephone) est le USE CASE geacuteneacuterique et laquo Demander prix produitsraquo est
un cas particulier du premier
Remarque Il faut distinguer entre une relation laquo extend raquo
et une relation de Geacuteneacuteralisation ISpeacutecialisation
Il3) le Diagramme des USE CASES
Cette repreacutesentation graphique permet de voir de faccedilon simple
+ les diffeacuterents acteurs
+ comment est deacutelimiteacute le systegraveme
+ les fonctionnaliteacutes demandeacutees au systegraveme
+ les rocircles des diffeacuterents acteurs vis-agrave-vis du
systegraveme
Il faut donner un nom au diagramme
9
1
CAISSIER
Applkation BaliCaire
Responsable Devise
DIRECTEUR Acte-ur
Syst Ce-nb-aJ
Description du cas dutilisation laquo Retraits Dirhamsraquo Modegravele classique
Sommaire didentification (obligatoire)
Titre retrait dargent avec un chegraveque ou un chegraveque guichet
Reacutesumeacute ce cas permet agrave un client de la banque de retirer de
largent de son compte avec un chegraveque une carte ou un
chegraveque guichet si son solde ou son deacutecouvert le lui permet
Acteurs guichetier de la banque le systegraveme central
Date de creacuteation 110904 Date de MAJ 190904
Version 23
Responsable Kaddour ben Jilali
Description des enchaIcircnements (obligatoire)
o Preacute conditions Le systegraveme est lanceacute le guichetier est identifieacute le solde caisse est
suffisamment approvisionneacute
o Sceacutenario Principal
1) Le client preacutesente un chegraveque agrave lui pour retirer des dirhams
2) Le guichetier demande identification du client
10
3 Le systegraveme valide lidentification et affiche la signature
4 Le guichetier veacuterifie la signature apposeacutee sur le chegraveque
5) Le systegraveme veacuterifie le solde et le deacutecouvert du compte client
6) Le systegraveme donne son accord
7 Le guichetier deacutelivre le montant demandeacute
Le systegraveme met agrave jour le compte client et le solde caisse
bull Sceacutenarios alternatifs
SAl Le client na pas de chegraveque
Cet enchaicircnement deacutemarre au point 1)
la) Le guichetier remplit un chegraveque guichet avec le montant demandeacute
1) Le client signe le chegraveque
2) le guichetier le reprend
Ce sceacutenario continue au point 2 du sceacutenario principal
SA2 Le solde et le deacutecouvert ne permettent pas le retrait
Cet enchaicircnement deacutemarre en 6)
6a) le systegraveme ne donne pas laccord pour le retrait
1) le chegraveque est remis au client
2) lopeacuteration est termineacutee
bull Post conditions Le compte client est mis agrave jour ainsi que le solde de la caisse en
cas de succegraves du retrait autrement ils doivent rester inchangeacutes
bull Besoins dIHM lfocultatiO
+ un lecteur de chegraveques
+ Un terminal avec clavier (pour saisir le num chegraveque si le lecteur ny arrive pas) et afficher limage de
la signature du client
+ Un compteur de billets
o Contraintes non fonctionnels lfocultatiO
+ Temps de reacuteponse Une transaction nominale doit durer moins de 2 minutes
+ Concurrence Un chegraveque du client peut ecirctre retireacute en mecircme temps par une autre personne
aupregraves dun autre guichetier dans la mecircme agence
11
1 slj~ IbL~~ )~ l~ 3((1
+ Disponibiliteacute le systegraveme doit ecirctre lanceacute 15 mn avant les horaires du travail est arrecircteacute agrave la
demande du directeur de lagence
+ Confidentialiteacute leacutecran doit ecirctre positionneacute de telle sorte quil ne peut ecirctre lu par un client
quelque soit sa position
Description du cas dutilisation laquo Retraits Dirhamsraquo
Modegravele de 2 colonnes pour les sceacutenarios (ou enchaicircnements)
Description des enchaIcircnements obligatoire
D Sceacutenario Principal
Le guichetier 1Le systegraveme
1) prend le chegraveque client
et demande identification
2) lit le chegraveque et
veacuterifie identification et
affiche la signature
3) veacuterifie la signature
~~----------~---------------~ tXfflLe
~ r ~l)~J ~s (~i~ iv ow SeJv 10 ~ (~hgtQ t~ ~ bA JoJe-eJ lt
et ~ J~ kA slj~iJV ~l S(~
Le S crf)- _ JeA b 1~~ ))J
Loc s~eacuteJi
D cc(9v-~~~eacute Jt iJr-6
12
Une bonne compreacutehension du systegraveme est primordiale avant dentreprendre lanalyse et la
conception
USE
CONCEPTION
Il2 Les concepts
Deux concepts fondamentaux pour repreacutesenter les USE CASES
- les acteurs qui utilisent le systegraveme
- les USE CASES qui repreacutesentent lutilisation
du systegraveme par les acteurs
A) Les acteurs (utilisateurs du systegraveme)
Pour permettre une bonne deacutelimitation du systegraveme il est bon de bien seacuteparer les eacuteleacutements
constitutifs du systegraveme logiciel des eacuteleacutements exteacuterieurs les acteurs repreacutesentent cette frontiegravere
Ce sont des eacuteleacutements exteacuterieur au systegraveme et qui interagissent avec lui
Il faut dabord Identifier les acteurs qui peuvent ecirctre des
Humains ce sont des utilisateurs du logiciel agrave
travers son interface graphique par exemple
Logiciels ce sont des logiciels deacutejagrave disponibles qui
communiquent avec le systegraveme gracircce agrave une
interface logicielle (une API par exemple)
Mateacuteriels robots et automates qui exploitent les
donneacutees du systegraveme ou qui sont piloteacutes par le
systegraveme (GAB)
Systegravemes exteacuterieurs (le Systegraveme de la banque de la
socieacuteteacute)
Al) Typologie des acteurs
Il existe trois types dacteurs
Les acteurs principaux ou primaires Ceux qui utilisent le systegraveme pour atteindre leurs buts (ils sont
la raison de lexistence du systegraveme)
Les acteurs secondaires Ceux qui administrent le systegraveme et assurent sa maintenance Ce sont eux
qui paramegravetrent le systegraveme et qui lui fournissent toutes les informations ou services neacutecessaires agrave son bon fonctionnement pour les acteurs principaux
Exla personne chargeacutee de la MAJ des cours des devises
Les acteurs externes Ceux qui ont un inteacuterecirct dans le comportement du cas dutilisation
Ex les services des impocircts du commerce
4
Remarquef
bull Un acteur correspond agrave un rocircle joueacute vis-agrave-vis du systegraveme (Un salarieacute dune banque correspond
souvent agrave un ou plusieurs rocircles directeur guichetier responsable devises ) et plusieurs individus
jouent souvent le mecircme rocircle (guichetier)
bull Une mecircme entiteacute peut repreacutesenter tour agrave tour deux types dacteurs
Exemple dans le caS de petites agences bancaires le directeur dagence peut ecirctre ameneacute agrave faire des opeacuterations de maintenance (alimenter le DAB en liquide)
A2) Pourquoi des acteurs
Identifier les acteurs dun systegraveme permet de
deacutelimiter le systegraveme Un acteur est un eacuteleacutement exteacuterieur au systegraveme qui interagit avec ce dernier
- avoir une vue orienteacutee utilisateur du systegraveme Avant de se lancer dans lanalyse et la conception
interne du systegraveme il est bon den avoir une vue externe qui correspond agrave toutes les fonctionnaliteacutes
attendues par les diffeacuterents acteurs
Remarque
UMl permet de steacutereacuteotyper les acteurs et dutiliser dautres icocircnes plus speacutecifiques (avec
utilisation des couleurs et images) en fonction des besoins pour offrir un meilleur repegravere visuel
Mais lutilisation de ces icocircnes doit ecirctre faite avec parcimonie
Ex
Un eacutetudiant Une eacutetudiante
A3) Les relations entre ACTEURS
Pour UMl la relation preacutevue entre acteurs est une relation de geacuteneacuteralisationSpeacutecialisation
B) Les USE CASES Eleacutements de linterface dutilisation
Bl) Deacutefinitions
Un USE CASE est une suite de seacutequences dactions y compris des variantes (souvent initieacutee par un
des acteurs) et qui correspond agrave une exeacutecution particuliegravere du systegraveme pour produire un reacutesultat ou
reacutepondre au(x) besoin(s) dun acteur
les USE CASES permettent de bien comprendre le systegraveme
Le but des USE CASES nest pas de faire une description exhaustive des fonctionnaliteacutes du systegraveme
logiciel en deacuteveloppement Ils permettent de deacutecrire ce que fait un systegraveme (un sous systegraveme une
classe ou une interface) mais ne preacutecisent pas comment il le fait
5
Ils permettent de repreacutesenter les besoins fonctionnels et non fonctionnels (seacutecuriteacute
performances ) que doit reacutealiser le systegraveme logiciel en deacuteveloppement
B) Les USE CASES Eleacutements de linterface dutilisation
Bi) Deacutefinitions
o Un USE CASE est une suite de seacutequences dactions y compris des variantes (souvent initieacutee
par un des acteurs) et qui correspond agrave une exeacutecution particuliegravere du systegraveme pour
produire un reacutesultat ou reacutepondre aulx) besoin(s) dun acteur
o Les USE CASES permettent de bien comprendre le systegraveme
Le but des USE CASES nest pas de faire une description exhaustive des fonctionnaliteacutes du
systegraveme logiciel en deacuteveloppement Ils permettent de deacutecrire ce que fait un systegraveme (un
sous systegraveme une classe ou une interface) mais ne preacutecisent pas comment il le fait
o Ils permettent de repreacutesenter les besoins fonctionnels et non fonctionnels (seacutecuriteacute
performances) que doit reacutealiser le systegraveme logiciel en deacuteveloppement
o Ils sont utiliseacutes aussi comme moyen de dialogue entre diffeacuterents travailleurs (Speacutecificateurs
Analystes Concepteurs Programmeurs ) et entre ces derniers et les acteurs (ou
utilisateurs)
Le symbole graphique dun Use Case se fait par
~om du Use Case
B 2) Description dun USE CASE
o La description des USE CASES doit ecirctre syntheacutetique compreacutehensible (comme tout modegravele) et
doit eacutegalement rendre compte aiseacutement du deacuteroulement dun cas dutilisation
o Un USE CASE peut ecirctre deacutecrit de diffeacuterentes faccedilons
bull de faccedilon informelle il sagit alors de texte libre comme peuvent lecirctre les speacutecifications
bull de faccedilon formelle il peut alors sagir dune langage structureacute de diagrammes ou dun
pseudo-code
bull Il est recommandeacute deffectuer au moins deux descriptions
bull + Une externe (au niveau Analyse) qui speacutecifie les besoins du point de vue de lacteur
uniquement
bull
bull + une interne (au niveau conception) qui prend en consideacuteration les concepts du
systegraveme (classes eacutecrans controcircles base de donneacutees )
bull Pour cette description interne on peut utiliser une maquette (une succession
deacutecrans) ougrave on indiquerait les options et les informations que doit renseigner un acteur pour
un Use Case donneacute
bull Ex Retrait dArgent dans une agence bancaire
6
Responsable argent
Exemple Un cas dutilisation peut ecirctre le retrait despegraveces demandeacute par un
client sur un compte preacutecis
Une description teKtuelle peut ecirctre
+ La responsable argent alimente chaque guichetier en argent chaque matin et en fonction des
besoins
+ Le guichetier saisit le numeacutero de compte du client
+ Lapplication valide le compte aupregraves du systegraveme central
+ Lapplication demande le type dopeacuteration au guichetier
+ Le guichetier choisit un retrait despegraveces du montant en Dirhams
+ Le systegraveme laquo guichetraquo interroge le systegraveme central pour sassurer que le compte est
suffisamment approvisionneacute
+ Le systegraveme central effectue le deacutebit du compte
+ Le systegraveme notifie au guichetier quil peut deacutelivrer le montant demandeacute
UML na pas speacutecifieacute un canevas de description pour les USE CASES mais le modegravele le plus reacutepandu
correspond au format ci dessus
o Acteur Principal celui qui fait appel au systegraveme
o Parties prenantes et inteacuterecircts deacutecrit et deacutelimite ce que le systegraveme fait
o Preacute conditions ce qui doit ecirctre vrai avant le deacutebut dun sceacutenario
o Post conditions (garanties de succegraves) ce qui doit ecirctre vrai agrave la fin dun sceacutenario
o Sceacutenario Principal chemin type le plus utiliseacute pour les parties impliqueacutees
o Extensions (ou Sceacutenarios alternatifs) branchements particuliegraveres ou dexception
o Speacutecifications Particuliegraveres besoins non fonctionnels dispositifs dES
o Liste de variantes et de donneacutees technologiques
ex lecteur de cartes pour diffeacuterents codes agrave barres
o Freacutequence doccurrences
o Questions ouvertes pour compleacuteter les speacutecifications dans les iteacuterations suivantes
Certains pratiquants ont apporteacute agrave ce modegravele quelques preacutecisions
(voir exemple 1 ci dessous)
7
Une autre description proposeacutee ressemble au diagramme de reacutepartition des tacircches Homme
Machine (du MOT de MERISE) et utilise deux colonnes une pour lacteur et autre pour le systegraveme
(voir exemple 1 ci-dessous)
83) les relations entre USE CASES au sein dun systegraveme
On distingue trois types de relations entre USE CASES
a) la relation de Geacuteneacuteralisation 1Speacutecialisation
Cest le principe dheacuteritage ex
b) la relation laquo Include raquo
o Permet la factorisation dun ensemble de tacircches
o Dans un systegraveme il existe des tacircches que doit faire reacuteguliegraverement un utilisateur
Par exemple le guichetier aura souvent besoin de valider le numeacutero du compte de lutilisateur On
peut preacuteciser comment se fait cette validation dans un Use Case et indiquer que cette fonctionnaliteacute
sera utiliseacutee dans diffeacuterents USE CASES
Cette relation permet donc de
+ factoriser des USE CASES correspondant agrave des fonctionnaliteacutes qui servent dans diffeacuterents USE
CASES
+ expliciter la constitution dun USE CASE complexe en le deacutecomposant en plusieurs USE CASES
relieacutes
Exemple Consideacuterons le USE CASE laquo Valider utilisateurraquo deacutecrit comme suit
+ le guichetier saisit le code de la banque du compte
+ il saisit te numeacutero du compte
+ il saisit la cleacute de compte
+ le systegraveme calcule la cleacute du compte et veacuterifie quelle est bonne
+ le systegraveme interroge le compte sur le systegraveme central
+ le systegraveme affiche le compte ainsi que son deacutetenteur
c) la relation laquo extend raquo
Cette relation qui peut exister entre USE CASES indique que le USE CASE qui est pointeacute par la flegraveche
est une sous-partie optionnelle de lautre USE CASE et quil peut aussi ecirctre utiliseacute tout seul
8
La relation laquo extend ) indique que tous les USE CASES fils heacuteritent de toutes les caracteacuteristiques du
USE CASE pegravere (USE CASE qui est pointeacute par la flegraveche) cest-agrave-dire quils ont les mecircmes liens avec les
acteurs et les autres USE CASES
Ce type dheacuteritage a aussi une valeur seacutemantique
Il indique que tous les USE CASES fils sont des cas particuliers du USE CASE pegravere
Exemple ( CommanderTeacuteleacutephone) est le USE CASE geacuteneacuterique et laquo Demander prix produitsraquo est
un cas particulier du premier
Remarque Il faut distinguer entre une relation laquo extend raquo
et une relation de Geacuteneacuteralisation ISpeacutecialisation
Il3) le Diagramme des USE CASES
Cette repreacutesentation graphique permet de voir de faccedilon simple
+ les diffeacuterents acteurs
+ comment est deacutelimiteacute le systegraveme
+ les fonctionnaliteacutes demandeacutees au systegraveme
+ les rocircles des diffeacuterents acteurs vis-agrave-vis du
systegraveme
Il faut donner un nom au diagramme
9
1
CAISSIER
Applkation BaliCaire
Responsable Devise
DIRECTEUR Acte-ur
Syst Ce-nb-aJ
Description du cas dutilisation laquo Retraits Dirhamsraquo Modegravele classique
Sommaire didentification (obligatoire)
Titre retrait dargent avec un chegraveque ou un chegraveque guichet
Reacutesumeacute ce cas permet agrave un client de la banque de retirer de
largent de son compte avec un chegraveque une carte ou un
chegraveque guichet si son solde ou son deacutecouvert le lui permet
Acteurs guichetier de la banque le systegraveme central
Date de creacuteation 110904 Date de MAJ 190904
Version 23
Responsable Kaddour ben Jilali
Description des enchaIcircnements (obligatoire)
o Preacute conditions Le systegraveme est lanceacute le guichetier est identifieacute le solde caisse est
suffisamment approvisionneacute
o Sceacutenario Principal
1) Le client preacutesente un chegraveque agrave lui pour retirer des dirhams
2) Le guichetier demande identification du client
10
3 Le systegraveme valide lidentification et affiche la signature
4 Le guichetier veacuterifie la signature apposeacutee sur le chegraveque
5) Le systegraveme veacuterifie le solde et le deacutecouvert du compte client
6) Le systegraveme donne son accord
7 Le guichetier deacutelivre le montant demandeacute
Le systegraveme met agrave jour le compte client et le solde caisse
bull Sceacutenarios alternatifs
SAl Le client na pas de chegraveque
Cet enchaicircnement deacutemarre au point 1)
la) Le guichetier remplit un chegraveque guichet avec le montant demandeacute
1) Le client signe le chegraveque
2) le guichetier le reprend
Ce sceacutenario continue au point 2 du sceacutenario principal
SA2 Le solde et le deacutecouvert ne permettent pas le retrait
Cet enchaicircnement deacutemarre en 6)
6a) le systegraveme ne donne pas laccord pour le retrait
1) le chegraveque est remis au client
2) lopeacuteration est termineacutee
bull Post conditions Le compte client est mis agrave jour ainsi que le solde de la caisse en
cas de succegraves du retrait autrement ils doivent rester inchangeacutes
bull Besoins dIHM lfocultatiO
+ un lecteur de chegraveques
+ Un terminal avec clavier (pour saisir le num chegraveque si le lecteur ny arrive pas) et afficher limage de
la signature du client
+ Un compteur de billets
o Contraintes non fonctionnels lfocultatiO
+ Temps de reacuteponse Une transaction nominale doit durer moins de 2 minutes
+ Concurrence Un chegraveque du client peut ecirctre retireacute en mecircme temps par une autre personne
aupregraves dun autre guichetier dans la mecircme agence
11
1 slj~ IbL~~ )~ l~ 3((1
+ Disponibiliteacute le systegraveme doit ecirctre lanceacute 15 mn avant les horaires du travail est arrecircteacute agrave la
demande du directeur de lagence
+ Confidentialiteacute leacutecran doit ecirctre positionneacute de telle sorte quil ne peut ecirctre lu par un client
quelque soit sa position
Description du cas dutilisation laquo Retraits Dirhamsraquo
Modegravele de 2 colonnes pour les sceacutenarios (ou enchaicircnements)
Description des enchaIcircnements obligatoire
D Sceacutenario Principal
Le guichetier 1Le systegraveme
1) prend le chegraveque client
et demande identification
2) lit le chegraveque et
veacuterifie identification et
affiche la signature
3) veacuterifie la signature
~~----------~---------------~ tXfflLe
~ r ~l)~J ~s (~i~ iv ow SeJv 10 ~ (~hgtQ t~ ~ bA JoJe-eJ lt
et ~ J~ kA slj~iJV ~l S(~
Le S crf)- _ JeA b 1~~ ))J
Loc s~eacuteJi
D cc(9v-~~~eacute Jt iJr-6
12
Remarquef
bull Un acteur correspond agrave un rocircle joueacute vis-agrave-vis du systegraveme (Un salarieacute dune banque correspond
souvent agrave un ou plusieurs rocircles directeur guichetier responsable devises ) et plusieurs individus
jouent souvent le mecircme rocircle (guichetier)
bull Une mecircme entiteacute peut repreacutesenter tour agrave tour deux types dacteurs
Exemple dans le caS de petites agences bancaires le directeur dagence peut ecirctre ameneacute agrave faire des opeacuterations de maintenance (alimenter le DAB en liquide)
A2) Pourquoi des acteurs
Identifier les acteurs dun systegraveme permet de
deacutelimiter le systegraveme Un acteur est un eacuteleacutement exteacuterieur au systegraveme qui interagit avec ce dernier
- avoir une vue orienteacutee utilisateur du systegraveme Avant de se lancer dans lanalyse et la conception
interne du systegraveme il est bon den avoir une vue externe qui correspond agrave toutes les fonctionnaliteacutes
attendues par les diffeacuterents acteurs
Remarque
UMl permet de steacutereacuteotyper les acteurs et dutiliser dautres icocircnes plus speacutecifiques (avec
utilisation des couleurs et images) en fonction des besoins pour offrir un meilleur repegravere visuel
Mais lutilisation de ces icocircnes doit ecirctre faite avec parcimonie
Ex
Un eacutetudiant Une eacutetudiante
A3) Les relations entre ACTEURS
Pour UMl la relation preacutevue entre acteurs est une relation de geacuteneacuteralisationSpeacutecialisation
B) Les USE CASES Eleacutements de linterface dutilisation
Bl) Deacutefinitions
Un USE CASE est une suite de seacutequences dactions y compris des variantes (souvent initieacutee par un
des acteurs) et qui correspond agrave une exeacutecution particuliegravere du systegraveme pour produire un reacutesultat ou
reacutepondre au(x) besoin(s) dun acteur
les USE CASES permettent de bien comprendre le systegraveme
Le but des USE CASES nest pas de faire une description exhaustive des fonctionnaliteacutes du systegraveme
logiciel en deacuteveloppement Ils permettent de deacutecrire ce que fait un systegraveme (un sous systegraveme une
classe ou une interface) mais ne preacutecisent pas comment il le fait
5
Ils permettent de repreacutesenter les besoins fonctionnels et non fonctionnels (seacutecuriteacute
performances ) que doit reacutealiser le systegraveme logiciel en deacuteveloppement
B) Les USE CASES Eleacutements de linterface dutilisation
Bi) Deacutefinitions
o Un USE CASE est une suite de seacutequences dactions y compris des variantes (souvent initieacutee
par un des acteurs) et qui correspond agrave une exeacutecution particuliegravere du systegraveme pour
produire un reacutesultat ou reacutepondre aulx) besoin(s) dun acteur
o Les USE CASES permettent de bien comprendre le systegraveme
Le but des USE CASES nest pas de faire une description exhaustive des fonctionnaliteacutes du
systegraveme logiciel en deacuteveloppement Ils permettent de deacutecrire ce que fait un systegraveme (un
sous systegraveme une classe ou une interface) mais ne preacutecisent pas comment il le fait
o Ils permettent de repreacutesenter les besoins fonctionnels et non fonctionnels (seacutecuriteacute
performances) que doit reacutealiser le systegraveme logiciel en deacuteveloppement
o Ils sont utiliseacutes aussi comme moyen de dialogue entre diffeacuterents travailleurs (Speacutecificateurs
Analystes Concepteurs Programmeurs ) et entre ces derniers et les acteurs (ou
utilisateurs)
Le symbole graphique dun Use Case se fait par
~om du Use Case
B 2) Description dun USE CASE
o La description des USE CASES doit ecirctre syntheacutetique compreacutehensible (comme tout modegravele) et
doit eacutegalement rendre compte aiseacutement du deacuteroulement dun cas dutilisation
o Un USE CASE peut ecirctre deacutecrit de diffeacuterentes faccedilons
bull de faccedilon informelle il sagit alors de texte libre comme peuvent lecirctre les speacutecifications
bull de faccedilon formelle il peut alors sagir dune langage structureacute de diagrammes ou dun
pseudo-code
bull Il est recommandeacute deffectuer au moins deux descriptions
bull + Une externe (au niveau Analyse) qui speacutecifie les besoins du point de vue de lacteur
uniquement
bull
bull + une interne (au niveau conception) qui prend en consideacuteration les concepts du
systegraveme (classes eacutecrans controcircles base de donneacutees )
bull Pour cette description interne on peut utiliser une maquette (une succession
deacutecrans) ougrave on indiquerait les options et les informations que doit renseigner un acteur pour
un Use Case donneacute
bull Ex Retrait dArgent dans une agence bancaire
6
Responsable argent
Exemple Un cas dutilisation peut ecirctre le retrait despegraveces demandeacute par un
client sur un compte preacutecis
Une description teKtuelle peut ecirctre
+ La responsable argent alimente chaque guichetier en argent chaque matin et en fonction des
besoins
+ Le guichetier saisit le numeacutero de compte du client
+ Lapplication valide le compte aupregraves du systegraveme central
+ Lapplication demande le type dopeacuteration au guichetier
+ Le guichetier choisit un retrait despegraveces du montant en Dirhams
+ Le systegraveme laquo guichetraquo interroge le systegraveme central pour sassurer que le compte est
suffisamment approvisionneacute
+ Le systegraveme central effectue le deacutebit du compte
+ Le systegraveme notifie au guichetier quil peut deacutelivrer le montant demandeacute
UML na pas speacutecifieacute un canevas de description pour les USE CASES mais le modegravele le plus reacutepandu
correspond au format ci dessus
o Acteur Principal celui qui fait appel au systegraveme
o Parties prenantes et inteacuterecircts deacutecrit et deacutelimite ce que le systegraveme fait
o Preacute conditions ce qui doit ecirctre vrai avant le deacutebut dun sceacutenario
o Post conditions (garanties de succegraves) ce qui doit ecirctre vrai agrave la fin dun sceacutenario
o Sceacutenario Principal chemin type le plus utiliseacute pour les parties impliqueacutees
o Extensions (ou Sceacutenarios alternatifs) branchements particuliegraveres ou dexception
o Speacutecifications Particuliegraveres besoins non fonctionnels dispositifs dES
o Liste de variantes et de donneacutees technologiques
ex lecteur de cartes pour diffeacuterents codes agrave barres
o Freacutequence doccurrences
o Questions ouvertes pour compleacuteter les speacutecifications dans les iteacuterations suivantes
Certains pratiquants ont apporteacute agrave ce modegravele quelques preacutecisions
(voir exemple 1 ci dessous)
7
Une autre description proposeacutee ressemble au diagramme de reacutepartition des tacircches Homme
Machine (du MOT de MERISE) et utilise deux colonnes une pour lacteur et autre pour le systegraveme
(voir exemple 1 ci-dessous)
83) les relations entre USE CASES au sein dun systegraveme
On distingue trois types de relations entre USE CASES
a) la relation de Geacuteneacuteralisation 1Speacutecialisation
Cest le principe dheacuteritage ex
b) la relation laquo Include raquo
o Permet la factorisation dun ensemble de tacircches
o Dans un systegraveme il existe des tacircches que doit faire reacuteguliegraverement un utilisateur
Par exemple le guichetier aura souvent besoin de valider le numeacutero du compte de lutilisateur On
peut preacuteciser comment se fait cette validation dans un Use Case et indiquer que cette fonctionnaliteacute
sera utiliseacutee dans diffeacuterents USE CASES
Cette relation permet donc de
+ factoriser des USE CASES correspondant agrave des fonctionnaliteacutes qui servent dans diffeacuterents USE
CASES
+ expliciter la constitution dun USE CASE complexe en le deacutecomposant en plusieurs USE CASES
relieacutes
Exemple Consideacuterons le USE CASE laquo Valider utilisateurraquo deacutecrit comme suit
+ le guichetier saisit le code de la banque du compte
+ il saisit te numeacutero du compte
+ il saisit la cleacute de compte
+ le systegraveme calcule la cleacute du compte et veacuterifie quelle est bonne
+ le systegraveme interroge le compte sur le systegraveme central
+ le systegraveme affiche le compte ainsi que son deacutetenteur
c) la relation laquo extend raquo
Cette relation qui peut exister entre USE CASES indique que le USE CASE qui est pointeacute par la flegraveche
est une sous-partie optionnelle de lautre USE CASE et quil peut aussi ecirctre utiliseacute tout seul
8
La relation laquo extend ) indique que tous les USE CASES fils heacuteritent de toutes les caracteacuteristiques du
USE CASE pegravere (USE CASE qui est pointeacute par la flegraveche) cest-agrave-dire quils ont les mecircmes liens avec les
acteurs et les autres USE CASES
Ce type dheacuteritage a aussi une valeur seacutemantique
Il indique que tous les USE CASES fils sont des cas particuliers du USE CASE pegravere
Exemple ( CommanderTeacuteleacutephone) est le USE CASE geacuteneacuterique et laquo Demander prix produitsraquo est
un cas particulier du premier
Remarque Il faut distinguer entre une relation laquo extend raquo
et une relation de Geacuteneacuteralisation ISpeacutecialisation
Il3) le Diagramme des USE CASES
Cette repreacutesentation graphique permet de voir de faccedilon simple
+ les diffeacuterents acteurs
+ comment est deacutelimiteacute le systegraveme
+ les fonctionnaliteacutes demandeacutees au systegraveme
+ les rocircles des diffeacuterents acteurs vis-agrave-vis du
systegraveme
Il faut donner un nom au diagramme
9
1
CAISSIER
Applkation BaliCaire
Responsable Devise
DIRECTEUR Acte-ur
Syst Ce-nb-aJ
Description du cas dutilisation laquo Retraits Dirhamsraquo Modegravele classique
Sommaire didentification (obligatoire)
Titre retrait dargent avec un chegraveque ou un chegraveque guichet
Reacutesumeacute ce cas permet agrave un client de la banque de retirer de
largent de son compte avec un chegraveque une carte ou un
chegraveque guichet si son solde ou son deacutecouvert le lui permet
Acteurs guichetier de la banque le systegraveme central
Date de creacuteation 110904 Date de MAJ 190904
Version 23
Responsable Kaddour ben Jilali
Description des enchaIcircnements (obligatoire)
o Preacute conditions Le systegraveme est lanceacute le guichetier est identifieacute le solde caisse est
suffisamment approvisionneacute
o Sceacutenario Principal
1) Le client preacutesente un chegraveque agrave lui pour retirer des dirhams
2) Le guichetier demande identification du client
10
3 Le systegraveme valide lidentification et affiche la signature
4 Le guichetier veacuterifie la signature apposeacutee sur le chegraveque
5) Le systegraveme veacuterifie le solde et le deacutecouvert du compte client
6) Le systegraveme donne son accord
7 Le guichetier deacutelivre le montant demandeacute
Le systegraveme met agrave jour le compte client et le solde caisse
bull Sceacutenarios alternatifs
SAl Le client na pas de chegraveque
Cet enchaicircnement deacutemarre au point 1)
la) Le guichetier remplit un chegraveque guichet avec le montant demandeacute
1) Le client signe le chegraveque
2) le guichetier le reprend
Ce sceacutenario continue au point 2 du sceacutenario principal
SA2 Le solde et le deacutecouvert ne permettent pas le retrait
Cet enchaicircnement deacutemarre en 6)
6a) le systegraveme ne donne pas laccord pour le retrait
1) le chegraveque est remis au client
2) lopeacuteration est termineacutee
bull Post conditions Le compte client est mis agrave jour ainsi que le solde de la caisse en
cas de succegraves du retrait autrement ils doivent rester inchangeacutes
bull Besoins dIHM lfocultatiO
+ un lecteur de chegraveques
+ Un terminal avec clavier (pour saisir le num chegraveque si le lecteur ny arrive pas) et afficher limage de
la signature du client
+ Un compteur de billets
o Contraintes non fonctionnels lfocultatiO
+ Temps de reacuteponse Une transaction nominale doit durer moins de 2 minutes
+ Concurrence Un chegraveque du client peut ecirctre retireacute en mecircme temps par une autre personne
aupregraves dun autre guichetier dans la mecircme agence
11
1 slj~ IbL~~ )~ l~ 3((1
+ Disponibiliteacute le systegraveme doit ecirctre lanceacute 15 mn avant les horaires du travail est arrecircteacute agrave la
demande du directeur de lagence
+ Confidentialiteacute leacutecran doit ecirctre positionneacute de telle sorte quil ne peut ecirctre lu par un client
quelque soit sa position
Description du cas dutilisation laquo Retraits Dirhamsraquo
Modegravele de 2 colonnes pour les sceacutenarios (ou enchaicircnements)
Description des enchaIcircnements obligatoire
D Sceacutenario Principal
Le guichetier 1Le systegraveme
1) prend le chegraveque client
et demande identification
2) lit le chegraveque et
veacuterifie identification et
affiche la signature
3) veacuterifie la signature
~~----------~---------------~ tXfflLe
~ r ~l)~J ~s (~i~ iv ow SeJv 10 ~ (~hgtQ t~ ~ bA JoJe-eJ lt
et ~ J~ kA slj~iJV ~l S(~
Le S crf)- _ JeA b 1~~ ))J
Loc s~eacuteJi
D cc(9v-~~~eacute Jt iJr-6
12
Ils permettent de repreacutesenter les besoins fonctionnels et non fonctionnels (seacutecuriteacute
performances ) que doit reacutealiser le systegraveme logiciel en deacuteveloppement
B) Les USE CASES Eleacutements de linterface dutilisation
Bi) Deacutefinitions
o Un USE CASE est une suite de seacutequences dactions y compris des variantes (souvent initieacutee
par un des acteurs) et qui correspond agrave une exeacutecution particuliegravere du systegraveme pour
produire un reacutesultat ou reacutepondre aulx) besoin(s) dun acteur
o Les USE CASES permettent de bien comprendre le systegraveme
Le but des USE CASES nest pas de faire une description exhaustive des fonctionnaliteacutes du
systegraveme logiciel en deacuteveloppement Ils permettent de deacutecrire ce que fait un systegraveme (un
sous systegraveme une classe ou une interface) mais ne preacutecisent pas comment il le fait
o Ils permettent de repreacutesenter les besoins fonctionnels et non fonctionnels (seacutecuriteacute
performances) que doit reacutealiser le systegraveme logiciel en deacuteveloppement
o Ils sont utiliseacutes aussi comme moyen de dialogue entre diffeacuterents travailleurs (Speacutecificateurs
Analystes Concepteurs Programmeurs ) et entre ces derniers et les acteurs (ou
utilisateurs)
Le symbole graphique dun Use Case se fait par
~om du Use Case
B 2) Description dun USE CASE
o La description des USE CASES doit ecirctre syntheacutetique compreacutehensible (comme tout modegravele) et
doit eacutegalement rendre compte aiseacutement du deacuteroulement dun cas dutilisation
o Un USE CASE peut ecirctre deacutecrit de diffeacuterentes faccedilons
bull de faccedilon informelle il sagit alors de texte libre comme peuvent lecirctre les speacutecifications
bull de faccedilon formelle il peut alors sagir dune langage structureacute de diagrammes ou dun
pseudo-code
bull Il est recommandeacute deffectuer au moins deux descriptions
bull + Une externe (au niveau Analyse) qui speacutecifie les besoins du point de vue de lacteur
uniquement
bull
bull + une interne (au niveau conception) qui prend en consideacuteration les concepts du
systegraveme (classes eacutecrans controcircles base de donneacutees )
bull Pour cette description interne on peut utiliser une maquette (une succession
deacutecrans) ougrave on indiquerait les options et les informations que doit renseigner un acteur pour
un Use Case donneacute
bull Ex Retrait dArgent dans une agence bancaire
6
Responsable argent
Exemple Un cas dutilisation peut ecirctre le retrait despegraveces demandeacute par un
client sur un compte preacutecis
Une description teKtuelle peut ecirctre
+ La responsable argent alimente chaque guichetier en argent chaque matin et en fonction des
besoins
+ Le guichetier saisit le numeacutero de compte du client
+ Lapplication valide le compte aupregraves du systegraveme central
+ Lapplication demande le type dopeacuteration au guichetier
+ Le guichetier choisit un retrait despegraveces du montant en Dirhams
+ Le systegraveme laquo guichetraquo interroge le systegraveme central pour sassurer que le compte est
suffisamment approvisionneacute
+ Le systegraveme central effectue le deacutebit du compte
+ Le systegraveme notifie au guichetier quil peut deacutelivrer le montant demandeacute
UML na pas speacutecifieacute un canevas de description pour les USE CASES mais le modegravele le plus reacutepandu
correspond au format ci dessus
o Acteur Principal celui qui fait appel au systegraveme
o Parties prenantes et inteacuterecircts deacutecrit et deacutelimite ce que le systegraveme fait
o Preacute conditions ce qui doit ecirctre vrai avant le deacutebut dun sceacutenario
o Post conditions (garanties de succegraves) ce qui doit ecirctre vrai agrave la fin dun sceacutenario
o Sceacutenario Principal chemin type le plus utiliseacute pour les parties impliqueacutees
o Extensions (ou Sceacutenarios alternatifs) branchements particuliegraveres ou dexception
o Speacutecifications Particuliegraveres besoins non fonctionnels dispositifs dES
o Liste de variantes et de donneacutees technologiques
ex lecteur de cartes pour diffeacuterents codes agrave barres
o Freacutequence doccurrences
o Questions ouvertes pour compleacuteter les speacutecifications dans les iteacuterations suivantes
Certains pratiquants ont apporteacute agrave ce modegravele quelques preacutecisions
(voir exemple 1 ci dessous)
7
Une autre description proposeacutee ressemble au diagramme de reacutepartition des tacircches Homme
Machine (du MOT de MERISE) et utilise deux colonnes une pour lacteur et autre pour le systegraveme
(voir exemple 1 ci-dessous)
83) les relations entre USE CASES au sein dun systegraveme
On distingue trois types de relations entre USE CASES
a) la relation de Geacuteneacuteralisation 1Speacutecialisation
Cest le principe dheacuteritage ex
b) la relation laquo Include raquo
o Permet la factorisation dun ensemble de tacircches
o Dans un systegraveme il existe des tacircches que doit faire reacuteguliegraverement un utilisateur
Par exemple le guichetier aura souvent besoin de valider le numeacutero du compte de lutilisateur On
peut preacuteciser comment se fait cette validation dans un Use Case et indiquer que cette fonctionnaliteacute
sera utiliseacutee dans diffeacuterents USE CASES
Cette relation permet donc de
+ factoriser des USE CASES correspondant agrave des fonctionnaliteacutes qui servent dans diffeacuterents USE
CASES
+ expliciter la constitution dun USE CASE complexe en le deacutecomposant en plusieurs USE CASES
relieacutes
Exemple Consideacuterons le USE CASE laquo Valider utilisateurraquo deacutecrit comme suit
+ le guichetier saisit le code de la banque du compte
+ il saisit te numeacutero du compte
+ il saisit la cleacute de compte
+ le systegraveme calcule la cleacute du compte et veacuterifie quelle est bonne
+ le systegraveme interroge le compte sur le systegraveme central
+ le systegraveme affiche le compte ainsi que son deacutetenteur
c) la relation laquo extend raquo
Cette relation qui peut exister entre USE CASES indique que le USE CASE qui est pointeacute par la flegraveche
est une sous-partie optionnelle de lautre USE CASE et quil peut aussi ecirctre utiliseacute tout seul
8
La relation laquo extend ) indique que tous les USE CASES fils heacuteritent de toutes les caracteacuteristiques du
USE CASE pegravere (USE CASE qui est pointeacute par la flegraveche) cest-agrave-dire quils ont les mecircmes liens avec les
acteurs et les autres USE CASES
Ce type dheacuteritage a aussi une valeur seacutemantique
Il indique que tous les USE CASES fils sont des cas particuliers du USE CASE pegravere
Exemple ( CommanderTeacuteleacutephone) est le USE CASE geacuteneacuterique et laquo Demander prix produitsraquo est
un cas particulier du premier
Remarque Il faut distinguer entre une relation laquo extend raquo
et une relation de Geacuteneacuteralisation ISpeacutecialisation
Il3) le Diagramme des USE CASES
Cette repreacutesentation graphique permet de voir de faccedilon simple
+ les diffeacuterents acteurs
+ comment est deacutelimiteacute le systegraveme
+ les fonctionnaliteacutes demandeacutees au systegraveme
+ les rocircles des diffeacuterents acteurs vis-agrave-vis du
systegraveme
Il faut donner un nom au diagramme
9
1
CAISSIER
Applkation BaliCaire
Responsable Devise
DIRECTEUR Acte-ur
Syst Ce-nb-aJ
Description du cas dutilisation laquo Retraits Dirhamsraquo Modegravele classique
Sommaire didentification (obligatoire)
Titre retrait dargent avec un chegraveque ou un chegraveque guichet
Reacutesumeacute ce cas permet agrave un client de la banque de retirer de
largent de son compte avec un chegraveque une carte ou un
chegraveque guichet si son solde ou son deacutecouvert le lui permet
Acteurs guichetier de la banque le systegraveme central
Date de creacuteation 110904 Date de MAJ 190904
Version 23
Responsable Kaddour ben Jilali
Description des enchaIcircnements (obligatoire)
o Preacute conditions Le systegraveme est lanceacute le guichetier est identifieacute le solde caisse est
suffisamment approvisionneacute
o Sceacutenario Principal
1) Le client preacutesente un chegraveque agrave lui pour retirer des dirhams
2) Le guichetier demande identification du client
10
3 Le systegraveme valide lidentification et affiche la signature
4 Le guichetier veacuterifie la signature apposeacutee sur le chegraveque
5) Le systegraveme veacuterifie le solde et le deacutecouvert du compte client
6) Le systegraveme donne son accord
7 Le guichetier deacutelivre le montant demandeacute
Le systegraveme met agrave jour le compte client et le solde caisse
bull Sceacutenarios alternatifs
SAl Le client na pas de chegraveque
Cet enchaicircnement deacutemarre au point 1)
la) Le guichetier remplit un chegraveque guichet avec le montant demandeacute
1) Le client signe le chegraveque
2) le guichetier le reprend
Ce sceacutenario continue au point 2 du sceacutenario principal
SA2 Le solde et le deacutecouvert ne permettent pas le retrait
Cet enchaicircnement deacutemarre en 6)
6a) le systegraveme ne donne pas laccord pour le retrait
1) le chegraveque est remis au client
2) lopeacuteration est termineacutee
bull Post conditions Le compte client est mis agrave jour ainsi que le solde de la caisse en
cas de succegraves du retrait autrement ils doivent rester inchangeacutes
bull Besoins dIHM lfocultatiO
+ un lecteur de chegraveques
+ Un terminal avec clavier (pour saisir le num chegraveque si le lecteur ny arrive pas) et afficher limage de
la signature du client
+ Un compteur de billets
o Contraintes non fonctionnels lfocultatiO
+ Temps de reacuteponse Une transaction nominale doit durer moins de 2 minutes
+ Concurrence Un chegraveque du client peut ecirctre retireacute en mecircme temps par une autre personne
aupregraves dun autre guichetier dans la mecircme agence
11
1 slj~ IbL~~ )~ l~ 3((1
+ Disponibiliteacute le systegraveme doit ecirctre lanceacute 15 mn avant les horaires du travail est arrecircteacute agrave la
demande du directeur de lagence
+ Confidentialiteacute leacutecran doit ecirctre positionneacute de telle sorte quil ne peut ecirctre lu par un client
quelque soit sa position
Description du cas dutilisation laquo Retraits Dirhamsraquo
Modegravele de 2 colonnes pour les sceacutenarios (ou enchaicircnements)
Description des enchaIcircnements obligatoire
D Sceacutenario Principal
Le guichetier 1Le systegraveme
1) prend le chegraveque client
et demande identification
2) lit le chegraveque et
veacuterifie identification et
affiche la signature
3) veacuterifie la signature
~~----------~---------------~ tXfflLe
~ r ~l)~J ~s (~i~ iv ow SeJv 10 ~ (~hgtQ t~ ~ bA JoJe-eJ lt
et ~ J~ kA slj~iJV ~l S(~
Le S crf)- _ JeA b 1~~ ))J
Loc s~eacuteJi
D cc(9v-~~~eacute Jt iJr-6
12
Responsable argent
Exemple Un cas dutilisation peut ecirctre le retrait despegraveces demandeacute par un
client sur un compte preacutecis
Une description teKtuelle peut ecirctre
+ La responsable argent alimente chaque guichetier en argent chaque matin et en fonction des
besoins
+ Le guichetier saisit le numeacutero de compte du client
+ Lapplication valide le compte aupregraves du systegraveme central
+ Lapplication demande le type dopeacuteration au guichetier
+ Le guichetier choisit un retrait despegraveces du montant en Dirhams
+ Le systegraveme laquo guichetraquo interroge le systegraveme central pour sassurer que le compte est
suffisamment approvisionneacute
+ Le systegraveme central effectue le deacutebit du compte
+ Le systegraveme notifie au guichetier quil peut deacutelivrer le montant demandeacute
UML na pas speacutecifieacute un canevas de description pour les USE CASES mais le modegravele le plus reacutepandu
correspond au format ci dessus
o Acteur Principal celui qui fait appel au systegraveme
o Parties prenantes et inteacuterecircts deacutecrit et deacutelimite ce que le systegraveme fait
o Preacute conditions ce qui doit ecirctre vrai avant le deacutebut dun sceacutenario
o Post conditions (garanties de succegraves) ce qui doit ecirctre vrai agrave la fin dun sceacutenario
o Sceacutenario Principal chemin type le plus utiliseacute pour les parties impliqueacutees
o Extensions (ou Sceacutenarios alternatifs) branchements particuliegraveres ou dexception
o Speacutecifications Particuliegraveres besoins non fonctionnels dispositifs dES
o Liste de variantes et de donneacutees technologiques
ex lecteur de cartes pour diffeacuterents codes agrave barres
o Freacutequence doccurrences
o Questions ouvertes pour compleacuteter les speacutecifications dans les iteacuterations suivantes
Certains pratiquants ont apporteacute agrave ce modegravele quelques preacutecisions
(voir exemple 1 ci dessous)
7
Une autre description proposeacutee ressemble au diagramme de reacutepartition des tacircches Homme
Machine (du MOT de MERISE) et utilise deux colonnes une pour lacteur et autre pour le systegraveme
(voir exemple 1 ci-dessous)
83) les relations entre USE CASES au sein dun systegraveme
On distingue trois types de relations entre USE CASES
a) la relation de Geacuteneacuteralisation 1Speacutecialisation
Cest le principe dheacuteritage ex
b) la relation laquo Include raquo
o Permet la factorisation dun ensemble de tacircches
o Dans un systegraveme il existe des tacircches que doit faire reacuteguliegraverement un utilisateur
Par exemple le guichetier aura souvent besoin de valider le numeacutero du compte de lutilisateur On
peut preacuteciser comment se fait cette validation dans un Use Case et indiquer que cette fonctionnaliteacute
sera utiliseacutee dans diffeacuterents USE CASES
Cette relation permet donc de
+ factoriser des USE CASES correspondant agrave des fonctionnaliteacutes qui servent dans diffeacuterents USE
CASES
+ expliciter la constitution dun USE CASE complexe en le deacutecomposant en plusieurs USE CASES
relieacutes
Exemple Consideacuterons le USE CASE laquo Valider utilisateurraquo deacutecrit comme suit
+ le guichetier saisit le code de la banque du compte
+ il saisit te numeacutero du compte
+ il saisit la cleacute de compte
+ le systegraveme calcule la cleacute du compte et veacuterifie quelle est bonne
+ le systegraveme interroge le compte sur le systegraveme central
+ le systegraveme affiche le compte ainsi que son deacutetenteur
c) la relation laquo extend raquo
Cette relation qui peut exister entre USE CASES indique que le USE CASE qui est pointeacute par la flegraveche
est une sous-partie optionnelle de lautre USE CASE et quil peut aussi ecirctre utiliseacute tout seul
8
La relation laquo extend ) indique que tous les USE CASES fils heacuteritent de toutes les caracteacuteristiques du
USE CASE pegravere (USE CASE qui est pointeacute par la flegraveche) cest-agrave-dire quils ont les mecircmes liens avec les
acteurs et les autres USE CASES
Ce type dheacuteritage a aussi une valeur seacutemantique
Il indique que tous les USE CASES fils sont des cas particuliers du USE CASE pegravere
Exemple ( CommanderTeacuteleacutephone) est le USE CASE geacuteneacuterique et laquo Demander prix produitsraquo est
un cas particulier du premier
Remarque Il faut distinguer entre une relation laquo extend raquo
et une relation de Geacuteneacuteralisation ISpeacutecialisation
Il3) le Diagramme des USE CASES
Cette repreacutesentation graphique permet de voir de faccedilon simple
+ les diffeacuterents acteurs
+ comment est deacutelimiteacute le systegraveme
+ les fonctionnaliteacutes demandeacutees au systegraveme
+ les rocircles des diffeacuterents acteurs vis-agrave-vis du
systegraveme
Il faut donner un nom au diagramme
9
1
CAISSIER
Applkation BaliCaire
Responsable Devise
DIRECTEUR Acte-ur
Syst Ce-nb-aJ
Description du cas dutilisation laquo Retraits Dirhamsraquo Modegravele classique
Sommaire didentification (obligatoire)
Titre retrait dargent avec un chegraveque ou un chegraveque guichet
Reacutesumeacute ce cas permet agrave un client de la banque de retirer de
largent de son compte avec un chegraveque une carte ou un
chegraveque guichet si son solde ou son deacutecouvert le lui permet
Acteurs guichetier de la banque le systegraveme central
Date de creacuteation 110904 Date de MAJ 190904
Version 23
Responsable Kaddour ben Jilali
Description des enchaIcircnements (obligatoire)
o Preacute conditions Le systegraveme est lanceacute le guichetier est identifieacute le solde caisse est
suffisamment approvisionneacute
o Sceacutenario Principal
1) Le client preacutesente un chegraveque agrave lui pour retirer des dirhams
2) Le guichetier demande identification du client
10
3 Le systegraveme valide lidentification et affiche la signature
4 Le guichetier veacuterifie la signature apposeacutee sur le chegraveque
5) Le systegraveme veacuterifie le solde et le deacutecouvert du compte client
6) Le systegraveme donne son accord
7 Le guichetier deacutelivre le montant demandeacute
Le systegraveme met agrave jour le compte client et le solde caisse
bull Sceacutenarios alternatifs
SAl Le client na pas de chegraveque
Cet enchaicircnement deacutemarre au point 1)
la) Le guichetier remplit un chegraveque guichet avec le montant demandeacute
1) Le client signe le chegraveque
2) le guichetier le reprend
Ce sceacutenario continue au point 2 du sceacutenario principal
SA2 Le solde et le deacutecouvert ne permettent pas le retrait
Cet enchaicircnement deacutemarre en 6)
6a) le systegraveme ne donne pas laccord pour le retrait
1) le chegraveque est remis au client
2) lopeacuteration est termineacutee
bull Post conditions Le compte client est mis agrave jour ainsi que le solde de la caisse en
cas de succegraves du retrait autrement ils doivent rester inchangeacutes
bull Besoins dIHM lfocultatiO
+ un lecteur de chegraveques
+ Un terminal avec clavier (pour saisir le num chegraveque si le lecteur ny arrive pas) et afficher limage de
la signature du client
+ Un compteur de billets
o Contraintes non fonctionnels lfocultatiO
+ Temps de reacuteponse Une transaction nominale doit durer moins de 2 minutes
+ Concurrence Un chegraveque du client peut ecirctre retireacute en mecircme temps par une autre personne
aupregraves dun autre guichetier dans la mecircme agence
11
1 slj~ IbL~~ )~ l~ 3((1
+ Disponibiliteacute le systegraveme doit ecirctre lanceacute 15 mn avant les horaires du travail est arrecircteacute agrave la
demande du directeur de lagence
+ Confidentialiteacute leacutecran doit ecirctre positionneacute de telle sorte quil ne peut ecirctre lu par un client
quelque soit sa position
Description du cas dutilisation laquo Retraits Dirhamsraquo
Modegravele de 2 colonnes pour les sceacutenarios (ou enchaicircnements)
Description des enchaIcircnements obligatoire
D Sceacutenario Principal
Le guichetier 1Le systegraveme
1) prend le chegraveque client
et demande identification
2) lit le chegraveque et
veacuterifie identification et
affiche la signature
3) veacuterifie la signature
~~----------~---------------~ tXfflLe
~ r ~l)~J ~s (~i~ iv ow SeJv 10 ~ (~hgtQ t~ ~ bA JoJe-eJ lt
et ~ J~ kA slj~iJV ~l S(~
Le S crf)- _ JeA b 1~~ ))J
Loc s~eacuteJi
D cc(9v-~~~eacute Jt iJr-6
12
Une autre description proposeacutee ressemble au diagramme de reacutepartition des tacircches Homme
Machine (du MOT de MERISE) et utilise deux colonnes une pour lacteur et autre pour le systegraveme
(voir exemple 1 ci-dessous)
83) les relations entre USE CASES au sein dun systegraveme
On distingue trois types de relations entre USE CASES
a) la relation de Geacuteneacuteralisation 1Speacutecialisation
Cest le principe dheacuteritage ex
b) la relation laquo Include raquo
o Permet la factorisation dun ensemble de tacircches
o Dans un systegraveme il existe des tacircches que doit faire reacuteguliegraverement un utilisateur
Par exemple le guichetier aura souvent besoin de valider le numeacutero du compte de lutilisateur On
peut preacuteciser comment se fait cette validation dans un Use Case et indiquer que cette fonctionnaliteacute
sera utiliseacutee dans diffeacuterents USE CASES
Cette relation permet donc de
+ factoriser des USE CASES correspondant agrave des fonctionnaliteacutes qui servent dans diffeacuterents USE
CASES
+ expliciter la constitution dun USE CASE complexe en le deacutecomposant en plusieurs USE CASES
relieacutes
Exemple Consideacuterons le USE CASE laquo Valider utilisateurraquo deacutecrit comme suit
+ le guichetier saisit le code de la banque du compte
+ il saisit te numeacutero du compte
+ il saisit la cleacute de compte
+ le systegraveme calcule la cleacute du compte et veacuterifie quelle est bonne
+ le systegraveme interroge le compte sur le systegraveme central
+ le systegraveme affiche le compte ainsi que son deacutetenteur
c) la relation laquo extend raquo
Cette relation qui peut exister entre USE CASES indique que le USE CASE qui est pointeacute par la flegraveche
est une sous-partie optionnelle de lautre USE CASE et quil peut aussi ecirctre utiliseacute tout seul
8
La relation laquo extend ) indique que tous les USE CASES fils heacuteritent de toutes les caracteacuteristiques du
USE CASE pegravere (USE CASE qui est pointeacute par la flegraveche) cest-agrave-dire quils ont les mecircmes liens avec les
acteurs et les autres USE CASES
Ce type dheacuteritage a aussi une valeur seacutemantique
Il indique que tous les USE CASES fils sont des cas particuliers du USE CASE pegravere
Exemple ( CommanderTeacuteleacutephone) est le USE CASE geacuteneacuterique et laquo Demander prix produitsraquo est
un cas particulier du premier
Remarque Il faut distinguer entre une relation laquo extend raquo
et une relation de Geacuteneacuteralisation ISpeacutecialisation
Il3) le Diagramme des USE CASES
Cette repreacutesentation graphique permet de voir de faccedilon simple
+ les diffeacuterents acteurs
+ comment est deacutelimiteacute le systegraveme
+ les fonctionnaliteacutes demandeacutees au systegraveme
+ les rocircles des diffeacuterents acteurs vis-agrave-vis du
systegraveme
Il faut donner un nom au diagramme
9
1
CAISSIER
Applkation BaliCaire
Responsable Devise
DIRECTEUR Acte-ur
Syst Ce-nb-aJ
Description du cas dutilisation laquo Retraits Dirhamsraquo Modegravele classique
Sommaire didentification (obligatoire)
Titre retrait dargent avec un chegraveque ou un chegraveque guichet
Reacutesumeacute ce cas permet agrave un client de la banque de retirer de
largent de son compte avec un chegraveque une carte ou un
chegraveque guichet si son solde ou son deacutecouvert le lui permet
Acteurs guichetier de la banque le systegraveme central
Date de creacuteation 110904 Date de MAJ 190904
Version 23
Responsable Kaddour ben Jilali
Description des enchaIcircnements (obligatoire)
o Preacute conditions Le systegraveme est lanceacute le guichetier est identifieacute le solde caisse est
suffisamment approvisionneacute
o Sceacutenario Principal
1) Le client preacutesente un chegraveque agrave lui pour retirer des dirhams
2) Le guichetier demande identification du client
10
3 Le systegraveme valide lidentification et affiche la signature
4 Le guichetier veacuterifie la signature apposeacutee sur le chegraveque
5) Le systegraveme veacuterifie le solde et le deacutecouvert du compte client
6) Le systegraveme donne son accord
7 Le guichetier deacutelivre le montant demandeacute
Le systegraveme met agrave jour le compte client et le solde caisse
bull Sceacutenarios alternatifs
SAl Le client na pas de chegraveque
Cet enchaicircnement deacutemarre au point 1)
la) Le guichetier remplit un chegraveque guichet avec le montant demandeacute
1) Le client signe le chegraveque
2) le guichetier le reprend
Ce sceacutenario continue au point 2 du sceacutenario principal
SA2 Le solde et le deacutecouvert ne permettent pas le retrait
Cet enchaicircnement deacutemarre en 6)
6a) le systegraveme ne donne pas laccord pour le retrait
1) le chegraveque est remis au client
2) lopeacuteration est termineacutee
bull Post conditions Le compte client est mis agrave jour ainsi que le solde de la caisse en
cas de succegraves du retrait autrement ils doivent rester inchangeacutes
bull Besoins dIHM lfocultatiO
+ un lecteur de chegraveques
+ Un terminal avec clavier (pour saisir le num chegraveque si le lecteur ny arrive pas) et afficher limage de
la signature du client
+ Un compteur de billets
o Contraintes non fonctionnels lfocultatiO
+ Temps de reacuteponse Une transaction nominale doit durer moins de 2 minutes
+ Concurrence Un chegraveque du client peut ecirctre retireacute en mecircme temps par une autre personne
aupregraves dun autre guichetier dans la mecircme agence
11
1 slj~ IbL~~ )~ l~ 3((1
+ Disponibiliteacute le systegraveme doit ecirctre lanceacute 15 mn avant les horaires du travail est arrecircteacute agrave la
demande du directeur de lagence
+ Confidentialiteacute leacutecran doit ecirctre positionneacute de telle sorte quil ne peut ecirctre lu par un client
quelque soit sa position
Description du cas dutilisation laquo Retraits Dirhamsraquo
Modegravele de 2 colonnes pour les sceacutenarios (ou enchaicircnements)
Description des enchaIcircnements obligatoire
D Sceacutenario Principal
Le guichetier 1Le systegraveme
1) prend le chegraveque client
et demande identification
2) lit le chegraveque et
veacuterifie identification et
affiche la signature
3) veacuterifie la signature
~~----------~---------------~ tXfflLe
~ r ~l)~J ~s (~i~ iv ow SeJv 10 ~ (~hgtQ t~ ~ bA JoJe-eJ lt
et ~ J~ kA slj~iJV ~l S(~
Le S crf)- _ JeA b 1~~ ))J
Loc s~eacuteJi
D cc(9v-~~~eacute Jt iJr-6
12
La relation laquo extend ) indique que tous les USE CASES fils heacuteritent de toutes les caracteacuteristiques du
USE CASE pegravere (USE CASE qui est pointeacute par la flegraveche) cest-agrave-dire quils ont les mecircmes liens avec les
acteurs et les autres USE CASES
Ce type dheacuteritage a aussi une valeur seacutemantique
Il indique que tous les USE CASES fils sont des cas particuliers du USE CASE pegravere
Exemple ( CommanderTeacuteleacutephone) est le USE CASE geacuteneacuterique et laquo Demander prix produitsraquo est
un cas particulier du premier
Remarque Il faut distinguer entre une relation laquo extend raquo
et une relation de Geacuteneacuteralisation ISpeacutecialisation
Il3) le Diagramme des USE CASES
Cette repreacutesentation graphique permet de voir de faccedilon simple
+ les diffeacuterents acteurs
+ comment est deacutelimiteacute le systegraveme
+ les fonctionnaliteacutes demandeacutees au systegraveme
+ les rocircles des diffeacuterents acteurs vis-agrave-vis du
systegraveme
Il faut donner un nom au diagramme
9
1
CAISSIER
Applkation BaliCaire
Responsable Devise
DIRECTEUR Acte-ur
Syst Ce-nb-aJ
Description du cas dutilisation laquo Retraits Dirhamsraquo Modegravele classique
Sommaire didentification (obligatoire)
Titre retrait dargent avec un chegraveque ou un chegraveque guichet
Reacutesumeacute ce cas permet agrave un client de la banque de retirer de
largent de son compte avec un chegraveque une carte ou un
chegraveque guichet si son solde ou son deacutecouvert le lui permet
Acteurs guichetier de la banque le systegraveme central
Date de creacuteation 110904 Date de MAJ 190904
Version 23
Responsable Kaddour ben Jilali
Description des enchaIcircnements (obligatoire)
o Preacute conditions Le systegraveme est lanceacute le guichetier est identifieacute le solde caisse est
suffisamment approvisionneacute
o Sceacutenario Principal
1) Le client preacutesente un chegraveque agrave lui pour retirer des dirhams
2) Le guichetier demande identification du client
10
3 Le systegraveme valide lidentification et affiche la signature
4 Le guichetier veacuterifie la signature apposeacutee sur le chegraveque
5) Le systegraveme veacuterifie le solde et le deacutecouvert du compte client
6) Le systegraveme donne son accord
7 Le guichetier deacutelivre le montant demandeacute
Le systegraveme met agrave jour le compte client et le solde caisse
bull Sceacutenarios alternatifs
SAl Le client na pas de chegraveque
Cet enchaicircnement deacutemarre au point 1)
la) Le guichetier remplit un chegraveque guichet avec le montant demandeacute
1) Le client signe le chegraveque
2) le guichetier le reprend
Ce sceacutenario continue au point 2 du sceacutenario principal
SA2 Le solde et le deacutecouvert ne permettent pas le retrait
Cet enchaicircnement deacutemarre en 6)
6a) le systegraveme ne donne pas laccord pour le retrait
1) le chegraveque est remis au client
2) lopeacuteration est termineacutee
bull Post conditions Le compte client est mis agrave jour ainsi que le solde de la caisse en
cas de succegraves du retrait autrement ils doivent rester inchangeacutes
bull Besoins dIHM lfocultatiO
+ un lecteur de chegraveques
+ Un terminal avec clavier (pour saisir le num chegraveque si le lecteur ny arrive pas) et afficher limage de
la signature du client
+ Un compteur de billets
o Contraintes non fonctionnels lfocultatiO
+ Temps de reacuteponse Une transaction nominale doit durer moins de 2 minutes
+ Concurrence Un chegraveque du client peut ecirctre retireacute en mecircme temps par une autre personne
aupregraves dun autre guichetier dans la mecircme agence
11
1 slj~ IbL~~ )~ l~ 3((1
+ Disponibiliteacute le systegraveme doit ecirctre lanceacute 15 mn avant les horaires du travail est arrecircteacute agrave la
demande du directeur de lagence
+ Confidentialiteacute leacutecran doit ecirctre positionneacute de telle sorte quil ne peut ecirctre lu par un client
quelque soit sa position
Description du cas dutilisation laquo Retraits Dirhamsraquo
Modegravele de 2 colonnes pour les sceacutenarios (ou enchaicircnements)
Description des enchaIcircnements obligatoire
D Sceacutenario Principal
Le guichetier 1Le systegraveme
1) prend le chegraveque client
et demande identification
2) lit le chegraveque et
veacuterifie identification et
affiche la signature
3) veacuterifie la signature
~~----------~---------------~ tXfflLe
~ r ~l)~J ~s (~i~ iv ow SeJv 10 ~ (~hgtQ t~ ~ bA JoJe-eJ lt
et ~ J~ kA slj~iJV ~l S(~
Le S crf)- _ JeA b 1~~ ))J
Loc s~eacuteJi
D cc(9v-~~~eacute Jt iJr-6
12
1
CAISSIER
Applkation BaliCaire
Responsable Devise
DIRECTEUR Acte-ur
Syst Ce-nb-aJ
Description du cas dutilisation laquo Retraits Dirhamsraquo Modegravele classique
Sommaire didentification (obligatoire)
Titre retrait dargent avec un chegraveque ou un chegraveque guichet
Reacutesumeacute ce cas permet agrave un client de la banque de retirer de
largent de son compte avec un chegraveque une carte ou un
chegraveque guichet si son solde ou son deacutecouvert le lui permet
Acteurs guichetier de la banque le systegraveme central
Date de creacuteation 110904 Date de MAJ 190904
Version 23
Responsable Kaddour ben Jilali
Description des enchaIcircnements (obligatoire)
o Preacute conditions Le systegraveme est lanceacute le guichetier est identifieacute le solde caisse est
suffisamment approvisionneacute
o Sceacutenario Principal
1) Le client preacutesente un chegraveque agrave lui pour retirer des dirhams
2) Le guichetier demande identification du client
10
3 Le systegraveme valide lidentification et affiche la signature
4 Le guichetier veacuterifie la signature apposeacutee sur le chegraveque
5) Le systegraveme veacuterifie le solde et le deacutecouvert du compte client
6) Le systegraveme donne son accord
7 Le guichetier deacutelivre le montant demandeacute
Le systegraveme met agrave jour le compte client et le solde caisse
bull Sceacutenarios alternatifs
SAl Le client na pas de chegraveque
Cet enchaicircnement deacutemarre au point 1)
la) Le guichetier remplit un chegraveque guichet avec le montant demandeacute
1) Le client signe le chegraveque
2) le guichetier le reprend
Ce sceacutenario continue au point 2 du sceacutenario principal
SA2 Le solde et le deacutecouvert ne permettent pas le retrait
Cet enchaicircnement deacutemarre en 6)
6a) le systegraveme ne donne pas laccord pour le retrait
1) le chegraveque est remis au client
2) lopeacuteration est termineacutee
bull Post conditions Le compte client est mis agrave jour ainsi que le solde de la caisse en
cas de succegraves du retrait autrement ils doivent rester inchangeacutes
bull Besoins dIHM lfocultatiO
+ un lecteur de chegraveques
+ Un terminal avec clavier (pour saisir le num chegraveque si le lecteur ny arrive pas) et afficher limage de
la signature du client
+ Un compteur de billets
o Contraintes non fonctionnels lfocultatiO
+ Temps de reacuteponse Une transaction nominale doit durer moins de 2 minutes
+ Concurrence Un chegraveque du client peut ecirctre retireacute en mecircme temps par une autre personne
aupregraves dun autre guichetier dans la mecircme agence
11
1 slj~ IbL~~ )~ l~ 3((1
+ Disponibiliteacute le systegraveme doit ecirctre lanceacute 15 mn avant les horaires du travail est arrecircteacute agrave la
demande du directeur de lagence
+ Confidentialiteacute leacutecran doit ecirctre positionneacute de telle sorte quil ne peut ecirctre lu par un client
quelque soit sa position
Description du cas dutilisation laquo Retraits Dirhamsraquo
Modegravele de 2 colonnes pour les sceacutenarios (ou enchaicircnements)
Description des enchaIcircnements obligatoire
D Sceacutenario Principal
Le guichetier 1Le systegraveme
1) prend le chegraveque client
et demande identification
2) lit le chegraveque et
veacuterifie identification et
affiche la signature
3) veacuterifie la signature
~~----------~---------------~ tXfflLe
~ r ~l)~J ~s (~i~ iv ow SeJv 10 ~ (~hgtQ t~ ~ bA JoJe-eJ lt
et ~ J~ kA slj~iJV ~l S(~
Le S crf)- _ JeA b 1~~ ))J
Loc s~eacuteJi
D cc(9v-~~~eacute Jt iJr-6
12
3 Le systegraveme valide lidentification et affiche la signature
4 Le guichetier veacuterifie la signature apposeacutee sur le chegraveque
5) Le systegraveme veacuterifie le solde et le deacutecouvert du compte client
6) Le systegraveme donne son accord
7 Le guichetier deacutelivre le montant demandeacute
Le systegraveme met agrave jour le compte client et le solde caisse
bull Sceacutenarios alternatifs
SAl Le client na pas de chegraveque
Cet enchaicircnement deacutemarre au point 1)
la) Le guichetier remplit un chegraveque guichet avec le montant demandeacute
1) Le client signe le chegraveque
2) le guichetier le reprend
Ce sceacutenario continue au point 2 du sceacutenario principal
SA2 Le solde et le deacutecouvert ne permettent pas le retrait
Cet enchaicircnement deacutemarre en 6)
6a) le systegraveme ne donne pas laccord pour le retrait
1) le chegraveque est remis au client
2) lopeacuteration est termineacutee
bull Post conditions Le compte client est mis agrave jour ainsi que le solde de la caisse en
cas de succegraves du retrait autrement ils doivent rester inchangeacutes
bull Besoins dIHM lfocultatiO
+ un lecteur de chegraveques
+ Un terminal avec clavier (pour saisir le num chegraveque si le lecteur ny arrive pas) et afficher limage de
la signature du client
+ Un compteur de billets
o Contraintes non fonctionnels lfocultatiO
+ Temps de reacuteponse Une transaction nominale doit durer moins de 2 minutes
+ Concurrence Un chegraveque du client peut ecirctre retireacute en mecircme temps par une autre personne
aupregraves dun autre guichetier dans la mecircme agence
11
1 slj~ IbL~~ )~ l~ 3((1
+ Disponibiliteacute le systegraveme doit ecirctre lanceacute 15 mn avant les horaires du travail est arrecircteacute agrave la
demande du directeur de lagence
+ Confidentialiteacute leacutecran doit ecirctre positionneacute de telle sorte quil ne peut ecirctre lu par un client
quelque soit sa position
Description du cas dutilisation laquo Retraits Dirhamsraquo
Modegravele de 2 colonnes pour les sceacutenarios (ou enchaicircnements)
Description des enchaIcircnements obligatoire
D Sceacutenario Principal
Le guichetier 1Le systegraveme
1) prend le chegraveque client
et demande identification
2) lit le chegraveque et
veacuterifie identification et
affiche la signature
3) veacuterifie la signature
~~----------~---------------~ tXfflLe
~ r ~l)~J ~s (~i~ iv ow SeJv 10 ~ (~hgtQ t~ ~ bA JoJe-eJ lt
et ~ J~ kA slj~iJV ~l S(~
Le S crf)- _ JeA b 1~~ ))J
Loc s~eacuteJi
D cc(9v-~~~eacute Jt iJr-6
12
1 slj~ IbL~~ )~ l~ 3((1
+ Disponibiliteacute le systegraveme doit ecirctre lanceacute 15 mn avant les horaires du travail est arrecircteacute agrave la
demande du directeur de lagence
+ Confidentialiteacute leacutecran doit ecirctre positionneacute de telle sorte quil ne peut ecirctre lu par un client
quelque soit sa position
Description du cas dutilisation laquo Retraits Dirhamsraquo
Modegravele de 2 colonnes pour les sceacutenarios (ou enchaicircnements)
Description des enchaIcircnements obligatoire
D Sceacutenario Principal
Le guichetier 1Le systegraveme
1) prend le chegraveque client
et demande identification
2) lit le chegraveque et
veacuterifie identification et
affiche la signature
3) veacuterifie la signature
~~----------~---------------~ tXfflLe
~ r ~l)~J ~s (~i~ iv ow SeJv 10 ~ (~hgtQ t~ ~ bA JoJe-eJ lt
et ~ J~ kA slj~iJV ~l S(~
Le S crf)- _ JeA b 1~~ ))J
Loc s~eacuteJi
D cc(9v-~~~eacute Jt iJr-6
12