Вы находитесь на странице: 1из 9

Theme : UML USE CASE DIAGRAMS

Introduction :
L Unified Modeling Langage (UML) ou le Langage Unifi pour la Modlisation permet de construire plusieurs modles dun system .Le diagramme de cas dutilisation ou le Use Case est lun des tout premier modle UML construire lors de la ralisation dun System car Il permet de recueillir, danalyser et dorganiser les besoins ; avec lui dbute l tape d analyse du system . Le Diagramme de cas dutilisation illustre les divers rles des utilisateurs d un system Informatique et comment ces rles se servent du system.

I les composantes du diagramme de cas dutilisation


GAB Retirer de l argent Cas dutilisation Nom du sujet

Effectuer un virement

<<Actor>> SI. Banque

ACTEUR

Contoure

A- ACTEUR Un acteur reprsente un rle jou par une entit externe (utilisateur humain, dispositif matriel ou autre systme) qui interagit directement avec le systme tudi. Un acteur peut consulter et/ou modifier directement ltat du systme, en mettant et/ou en recevant des messages susceptibles dtre porteurs de donnes. En somme un acteur reprsente le rle jou par un utilisateur vis--vis du system concevoir. Comment les identifier ? Les acteurs candidats sont systmatiquement :

les utilisateurs humains directs : faites donc en sorte didentifier tous les profils possibles, sans oublier ladministrateur, loprateur de maintenance, etc. ; les autres systmes connexes qui interagissent aussi directement avec le systme tudi, souvent par le biais de protocoles bidirectionnels. Comment les reprsenter ? La reprsentation graphique standard de lacteur en UML est licne appele << stick man >>, avec le nom de lacteur sous le dessin. On peut galement figurer un acteur sous la forme rectangulaire dune classe, avec le mot-cl << actor >>. Remarque : ACTEUR PRINCIPAL OU SECONDAIRE Contrairement ce que lon pourrait croire, tous les acteurs nutilisent pas forcment le systme! Nous appelons acteur principal celui pour qui le cas dutilisation produit un rsultat observable. Par opposition, nous qualifions dacteurs secondaires les autres participants du cas dutilisation. Les acteurs secondaires sont souvent sollicits pour des informations complmentaires ; ils peuvent uniquement consulter ou informer le systme lors de lexcution du cas dutilisation. B- CAS D UTILISATION Un cas dutilisation ( use case ) reprsente un ensemble de squences dactions qui sont ralises par le systme et qui produisent un rsultat observable intressant pour un acteur particulier .Cest dire qu il reprsente une communication typique entre un utilisateur et un systme informatique, Il permet de dcrire ce que le futur systme devra faire, sans spcifier comment il le fera. Comment les identifier ? Lobjectif est le suivant : lensemble des cas dutilisation doit dcrire exhaustivement les exigences fonctionnelles du systme. Chaque cas dutilisation correspond donc une fonction mtier du systme, selon le point de vue dun de ses acteurs. Pour chaque acteur, il convient de : rechercher les diffrentes intentions mtier avec lesquelles il utilise le systme, dterminer dans le cahier des charges les services fonctionnels attendus du systme. Nommez les cas dutilisation par un verbe linfinitif suivi dun complment, du point de vue de lacteur (et non pas du point de vue du systme). Comment les analyser ? Pour dtailler la dynamique du cas dutilisation, la procdure la plus vidente consiste recenser de faon textuelle toutes les interactions entre les acteurs et le systme. Le cas dutilisation doit avoir un dbut et une fin clairement identifis. Il faut galement prciser les variantes possibles, telles que le cas nominal, les diffrents cas alternatifs et derreur, tout en essayant dordonner squentiellement les descriptions, afin damliorer leur lisibilit. Comment les reprsenter ? Le diagramme de cas dutilisation est un schma qui montre les cas dutilisation (ovales) relis par des associations (lignes) leurs acteurs (icne du stick man , ou reprsentation

graphique quivalente). Chaque association signifie simplement participe . Un cas dutilisation doit tre reli au moins un acteur. Une fois les cas dutilisation identifis, il faut encore les dcrire ! C- SCNARIO Un scnario reprsente une succession particulire denchanements, sexcutant du dbut la fin du cas dutilisation, un enchanement tant lunit de description de squences dactions . Un cas dutilisation contient en gnral un scnario nominal et plusieurs scnarios alternatifs (qui se terminent de faon normale) ou derreur (qui se terminent en chec). On peut dailleurs proposer une dfinition diffrente pour un cas dutilisation : ensemble de scnarios dutilisation dun systme relis par un but commun du point de vue dun acteur .

II Principes
RELATION ENTRE LES CAS D UTLISATION

Factorisation de comportements communs plusieurs cas dutilisation mais : intention diffrente, liaisons diffrentes avec les acteurs . U1 inclut U2 : U2 est un sous cas appel en plusieurs points. U2 tend U1 : le comportement de U2 contient celui de U1 : U2 ralise quelque chose de plus que U1. un acteur ralise le cas dutilisation de base et toutes les extensions qui se prsentent. U1 gnralise U2 : le comportement de U2 hrite celui de U1 (vrai aussi pour les acteurs). Etend : indique les variations dun comportement normal (les cas particuliers importants). Inclut ou Gnralise sutilisent pour viter les rptitions dans la description dtaille des UC.

POINT DEXTENSION

Retirer de largent
Point dextension : vrification solde {aprs avoir demand le montant}

tend
Si montant>100F Vrifier le solde

Une extension peut intervenir un point prcis du cas tendu. On lindique dans un compartiment du cas dutilisation, Avec une contrainte indiquant le moment o il intervient. On peut indiquer une condition dans une note.

III exercice pratique


TUDE DUN GUICHET AUTOMATIQUE DE BANQUE Cette tude de cas concerne un systme simplifi de Guichet Automatique de Banque (GAB). Le GAB offre les services suivants : Distribution dargent tout Porteur de carte de crdit, via un lecteur de carte et un distributeur de billets. Consultation de solde de compte, dpt en numraire et dpt de chques pour les Clients porteurs dune carte de crdit de la banque adosse au GAB. Noubliez pas non plus que : Toutes les transactions sont scurises. Il est parfois ncessaire de recharger le distributeur, etc. partir de ces quatre phrases, nous allons progressivement : identifier les acteurs ;

identifier les cas dutilisation ; construire un diagramme de cas dutilisation ; dcrire textuellement les cas dutilisation ; organiser et structurer les cas dutilisation. SOLUTION DU PROBLEME Identification des acteurs : La phrase 1 nous permet didentifier immdiatement un premier acteur vident : tout Porteur de carte. Il pourra uniquement utiliser le GAB pour retirer de largent avec sa carte. La phrase 2 identifie des services supplmentaires qui ne sont proposs quaux clients de la banque porteurs dune carte de crdit de cette dernire. Il sagit donc dun profil diffrent du prcdent, que nous matrialisons par un deuxime acteur, appel Client banque La phrase 3 nous incite prendre en compte le fait que toutes les transactions sont scurises. Mais scurises par qui ? Pas par le GAB. Il existe donc dautres entits externes qui jouent le rle de Systme dautorisation et avec lesquelles le GAB communique directement. Une interview de lexpert mtier est ncessaire, pour nous permettre didentifier deux acteurs diffrents : le Systme dautorisation global Carte Bancaire, pour les transactions de retrait ; le Systme dinformation de la banque, pour autoriser toutes les transactions effectues par un client avec sa carte de la banque, mais galement pour accder au solde des comptes. Enfin, la phrase 4 nous rappelle quun GAB ncessite galement des actions de maintenance, telles que le rechargement en billets du distributeur, la rcupration des cartes avales, etc. Ces actions de maintenance sont effectues par un nouvel acteur, que nous appellerons pour simplifier : Oprateur de maintenance Identification des cas dutilisation : Porteur de carte : Retirer de largent. Client banque : Retirer de largent ( ne pas oublier !). Consulter le solde de son compte courant. Dposer du numraire. Dposer de largent (du numraire ou des chques) Oprateur de maintenance : Recharger le distributeur. Maintenir ltat oprationnel (rcuprer les cartes avales, rcuprer les chques dposs, remplacer le ruban de papier, etc.). Systme dautorisation (Sys. Auto.) :

Nant. Systme dinformation (SI) banque : Nant. Description textuelle des cas dutilisation Sommaire d identification Titre : Retirer de largent Rsum : ce cas dutilisation permet un Porteur de carte, qui nest pas client de la banque, de retirer de largent, si son crdit hebdomadaire le permet. Acteurs : Porteur de carte (principal), Systme dautorisation (secondaire). Date de cration : 02/03/02 Version : 5.0 Description des scnarios Prconditions La caisse du GAB est alimente (il reste au moins un billet !). Aucune carte ne se trouve dj coince dans le lecteur. La connexion avec le Systme dautorisation est oprationnelle. Scnario nominal 1. Le Porteur de carte introduit sa carte dans le lecteur de cartes du GAB. 2. Le GAB vrifie que la carte introduite est bien une carte bancaire. 3. Le GAB demande au Porteur de carte de saisir son code didentification. 4. Le Porteur de carte saisit son code didentification. 5. Le GAB compare le code didentification avec celui qui est cod sur la puce de la carte. 6. Le GAB demande une autorisation au Systme dautorisation. 7. Le Systme dautorisation donne son accord et indique le solde hebdomadaire. 8. Le GAB demande au Porteur de carte de saisir le montant dsir du retrait. 9. Le Porteur de carte saisit le montant dsir du retrait. 10. Le GAB contrle le montant demand par rapport au solde hebdomadaire. 11. Le GAB demande au Porteur de carte sil veut un ticket. 12. Le Porteur de carte demande un ticket. Date de mise jour : 05/05/06 Responsable : Pascal Roques

13. Le GAB rend sa carte au Porteur de carte. 14. Le Porteur de carte reprend sa carte. 15. Le GAB dlivre les billets et un ticket. 16. Le Porteur de carte prend les billets et le ticket. Enchanements alternatifs A1 : code didentification provisoirement erron Lenchanement A1 dmarre au point 5 du scnario nominal. 6. Le GAB indique au Porteur de carte que le code est erron, pour la premire ou deuxime fois. 7. Le GAB enregistre lchec sur la carte. Le scnario nominal reprend au point 3. A2 : montant demand suprieur au solde hebdomadaire Lenchanement A2 dmarre au point 10 du scnario nominal. 11. Le GAB indique au Porteur de carte que le montant demand est suprieur au solde hebdomadaire. Le scnario nominal reprend au point 8. A3 : ticket refus Lenchanement A3 dmarre au point 11 du scnario nominal. 12. Le Porteur de carte refuse le ticket. 13. Le GAB rend sa carte au Porteur de carte. 14. Le Porteur de carte reprend sa carte. 15. Le GAB dlivre les billets. 16. Le Porteur de carte prend les billets. Enchanements derreur E1 : carte non-valide Lenchanement E1 dmarre au point 2 du scnario nominal. 3. Le GAB indique au Porteur que la carte nest pas valide (illisible, prime, etc.), la confisque ; le cas dutilisation se termine en chec. E2 : code didentification dfinitivement erron

Lenchanement E2 dmarre au point 5 du scnario nominal. 6. Le GAB indique au Porteur de carte que le code est erron, pour la troisime fois. 7. Le GAB confisque la carte. 8. Le Systme dautorisation est inform ; le cas dutilisation se termine en chec. E3 : retrait non autoris Lenchanement E3 dmarre au point 6 du scnario nominal. 7. Le Systme dautorisation interdit tout retrait. 8. Le GAB jecte la carte ; le cas dutilisation se termine en chec. E4 : carte non reprise Lenchanement E4 dmarre au point 13 du scnario nominal. 14. Au bout de 10 secondes, le GAB confisque la carte. 15. Le Systme dautorisation est inform ; le cas dutilisation se termine en chec. E5 : billets non pris Lenchanement E5 dmarre au point 15 du scnario nominal. 16. Au bout de 10 secondes, le GAB reprend les billets. 17. Le cas dutilisation se termine en chec. E6 : annulation de la transaction Lenchanement E6 peut dmarrer entre les points 4 et 12 du scnario nominal. 4 12. Le Porteur de carte demande lannulation de la transaction en cours. Le GAB jecte la carte ; le cas dutilisation se termine en chec. Post conditions La caisse du GAB contient moins de billets quau dbut du cas dutilisation (le nombre de billets manquants est fonction du montant du retrait). Une transaction de retrait a t enregistre par le GAB avec toutes les informations pertinentes (montant, numro de carte, date, etc.). Les dtails de la transaction doivent tre enregistrs aussi bien en cas de succs que dchec.

Оценить