Vous êtes sur la page 1sur 35

MTHODOLOGIES DE CONCEPTION

Chapitre2: Diagramme de cas dutilisation

PLAN
Diagramme de Cas dutilisation(Dfinition) lments des diagrammes de cas dutilisation

Acteur Cas dutilisation Reprsentation dun diagramme de cas dutilisation

Relations dans les diagrammes de cas dutilisation


Relations entre acteurs et cas dutilisation Relations entre cas dutilisation Relations entre acteurs

Modlisation des besoins avec UML


Comment identier les acteurs ? Comment recenser les cas dutilisation ? Description textuelle des cas dutilisation

Diagramme de Cas dutilisation(Dfinition)

DIAGRAMME DE CAS DUTILISATION(SUITE)


Le

diagramme de cas dutilisation permet de formaliser les besoins, cest--dire les reprsenter sous une forme graphique suffisamment simple pour tre comprhensible par toutes les personnes impliques dans le projet. Dcrivent sous la forme daction et de raction, le systme point de vue utilisateur, dfinissant ainsi les limites du systme et ses relations avec son environnement.

DIAGRAMME DE CAS DUTILISATION

Permet de recueillir, analyser et organiser les besoins : Technique permettant didentifier et de noter les fonctionnalits du systme qui sont significatives pour ses utilisateurs (humains, matriels, logiciels, etc.) recenser les fonctionnalits dun systme ce quil devra faire (et pas comment ) description du comportement sous forme dactions/ractions vision plutt oriente utilisateur

lments des diagrammes de cas dutilisation

ACTEURS

Ils sont des entits externes qui interagissent avec le systme, comme une personne humaine, un robot, un logiciel, automate Une mme personne (ou robot, ...) peut tre plusieurs acteurs pour un systme, c'est pourquoi les acteurs doivent surtout tre dcrits par leur rle, ce rle dcrit les besoins et les capacits de l'acteur L'activit du systme a pour objectif de satisfaire les besoins de l'acteur On distingue 2 catgories d'acteurs les acteurs principales : ceux sont les utilisateurs du systme (ex : usager, client, etc) les acteurs secondaires : ceux qui administrent le systme (ex : oprateur de maintenance, administrateur, etc) 7

REPRSENTATION DUN ACTEUR

Il se reprsente par un petit bonhomme avec son nom (i.e. son rle)

Il est galement possible de reprsenter un acteur sous la forme dun classeur avec le strotype << actor >>
8

CAS DUTILISATION

Un cas d'utilisation reprsente une fonctionnalit du systme visible par lextrieur Tout systme peut tre dcrit par un certain nombre de cas dutilisation correspondant aux besoins exprims par lensemble des utilisateurs. chaque utilisateur, vu comme acteur, correspondra un certain nombre de cas dutilisation du systme

REPRSENTATION DUN CAS DUTILISATION


Le cas d'utilisation se reprsente par une ellipse contenant un nom dcrivant la fonctionnalit et ventuellement un strotype Remarque : Le nom du cas dutilisation doit se composer d'un verbe l'infinitif qui dcrit une action. Pour que l'ensemble du modle soit cohrent il faut choisir tous les verbes soit du point de vue du systme soit du point de vue de l'utilisateur (ce qui est gnralement prfrable)

10

REPRSENTATION DUN DIAGRAMME DE CAS DUTILISATION

La frontire du systme est reprsente par un cadre. Le nom du systme gure lintrieur du cadre, en haut. Les acteurs sont lextrieur et les cas dutilisation lintrieur

11

EXEMPLE SIMPLIFI DE DIAGRAMME DE CAS


DUTILISATION Frontire de systme MODLISANT UN SYSTME DE MESSAGERIE Nom de systme
Systme de messagerie Cas dutilisation Connecter

Lire boite Internaute

Acteur

envoyer

Association

Changer droit

Administrateur

12

Relations dans les diagrammes de cas dutilisation

13

RELATIONS ENTRE ACTEURS ET CAS DUTILISATION


Une relation dassociation est une interaction permet de dcrire les changes entre un acteur et un cas dutilisation Elle est reprsent par un trait continu

Association

Nom du cas dutilisation

Nom du lacteur

14

RELATIONS ENTRE CAS DUTILISATION


Afin doptimiser la formalisation des besoins en ayant recours notamment la rutilisation de cas dutilisation, trois relations peuvent tre dcrit entre cas dutilisation:
Une

relation dinclusion : la ralisation dun CU ncessite la ralisation dun autre CU relation dextension: le comportement dun CU peut tre complte par un autre CU (avec condition ventuelle) relation de gnralisation/spcialisation: principe dhritage entre CU

Une

Une

15

RELATION DINCLUSION
Dans ce type de relation le premier cas englobe l'autre et son issue dpend souvent de la rsolution du second Permet de dcomposer un cas dutilisation complexe en cas dutilisation plus simples. Permet de factoriser des comportements utiles plusieurs cas dutilisation.

16

RELATION DINCLUSION (FORMALISME)


Cas A Cas B

Cas C

Les cas A et C ont recours au cas B

Linclusion se reprsente par une che avec un trait pointill et le terme include. Si le cas A inclut ou tend le cas B, la che est dirige de A vers B.

17

RELATION DINCLUSION (EXEMPLE1 )


Accder au compte bancaire

sauthentifier

Utilisateur

Laccs aux informations dun compte bancaire inclut ncessairement une phase dauthentication avec un identiant et un mot de passe

18

RELATION DINCLUSION (EXEMPLE2 )

19

RELATION DEXTENSION
On dit quun cas dutilisation A tend un cas dutilisation B lorsque le cas dutilisation A peut tre appel au cours de lexcution du cas dutilisation B. La relation dextension permet denrichir un cas dutilisation de base en utilisant un autre cas dutilisation un point dextension spcifique. Permet de sparer un comportement optionnel ou rare du comportement obligatoire Indique quun cas dutilisation utilise facultativement ou sous certaines conditions une squence dactivits dcrite dans un autre cas dutilisation. Contrairement linclusion, lextension est optionnelle.

20

RELATION DINCLUSION (FORMALISME)

Cas A Point dextension :X

extend
Cas B

Le cas A tent B

La relation dextension est reprsente par une flche avec le terme Extend. Si le cas A extend ou tend le cas B, la che est dirige de B vers A. La condition est exprime sous la forme dune note

21

RELATION DINCLUSION (EXEMPLE)

Servir boisson chaude Point dextension :X

Condition:{ si plus de sucre} Point dextension :X

Client

Servir supplment sucre

22

RELATION DE
GNRALISATION/SPCIALISATION

Un cas A est une gnralisation/spcialisation dun cas B si B est un cas particulier de A


Cette relation de gnralisation/spcialisation est prsente dans la plupart des diagrammes UML et se traduit par le concept dhritage dans les langages orients objet.

23

RELATION DE
GNRALISATION/SPCIALISATION(FORMALISME)

Ces relations sont reprsentes par des traits pleins termin par une flche en triangle.
24

RELATION DE
GNRALISATION/SPCIALISATION(EXEMPLE)

retirer des euros cest un cas particulier de retirer de largent Retirer de largent

Client Retirer des euros Retirer des dollars


25

RELATIONS ENTRE ACTEURS


La seule relation possible entre deux acteurs est la gnralisation : un acteur A est une gnralisation dun acteur B si lacteur A peut tre substitu par lacteur B. Dans ce cas, tous les cas dutilisation accessibles A le sont aussi B, mais linverse nest pas vrai

Le symbole utilis pour la gnralisation entre acteurs est une che avec un trait plein dont la pointe est un triangle ferm dsignant lacteur le plus gnral (comme nous lavons dj vu pour la relation de gnralisation entre cas dutilisation).
26

Ce figure montre que le directeur des ventes est un prpos aux commandes avec un pouvoir supplmentaire : en plus de pouvoir passer et suivre une commande, il peut grer le stock. Par contre, le prpos aux commandes ne peut pas grer le stock
27

EXEMPLE GNRALE

28

MODLISATION DES BESOINS AVEC UML

29

COMMENT IDENTIFIER LES ACTEURS ?


UML nemploie pas le terme dutilisateur mais dacteur. Les acteurs dun systme sont les entits externes ce systme qui interagissent (saisie de donnes, rception dinformation, . . .)avec lui. Oublier des acteurs ou en identier de faux conduit donc ncessairement se tromper sur la dnition du systme produire.

30

COMMENT IDENTIFIER LES ACTEURS ?(SUITE)


Il faut faire attention ne pas confondre acteurs et utilisateurs (utilisateur avec le sens de la personne physique qui va appuyer sur un bouton) dun systme: Dune part parce que les acteurs inclus les utilisateurs humains mais aussi les autres systmes informatiques ou hardware qui vont communiquer avec le systme. Dautre part parce que plusieurs utilisateurs peuvent avoir le mme rle, et donc correspondre un mme acteur, et une mme personne physique peut jouer des rles diffrents vis--vis du systme, et donc correspondre plusieurs acteurs.
31

COMMENT IDENTIFIER LES CAS DUTILISATION ?


Lensemble des cas dutilisation doit dcrire les exigences fonctionnelles du systme. Chaque cas dutilisation correspond une fonction mtier du systme, selon le point de vue dun de ses acteurs. Pour identier les cas dutilisation, il faut se placer du point de vue de chaque acteur et dterminer comment et surtout pourquoi il se sert du systme.

Il faut viter les redondances et limiter le nombre de cas en se situant un bon niveau dabstraction.

32

DESCRIPTION TEXTUELLE DES CAS DUTILISATION chaque cas dutilisation doit tre associe une description textuelle des interactions entre lacteur et le systme et les actions que le systme doit raliser La description textuelle dun cas dutilisation est articule en six points :

Objectif: Une description rsume permettant de comprendre lintention principale du cas dutilisation Acteurs concerns: le ou les acteurs concerns par le cas doivent tre identifis en prcisant globalement leur rle Pr conditions: si certaines conditions particulires sont requises avant lexcution du cas, elles sont exprime ce niveau
33

DESCRIPTION TEXTUELLE DES CAS DUTILISATION (SUITE)

Post condition: par symtrie, si certaines conditions particulires doivent tre runies aprs lexcution du cas, elle sont exprimer ce niveau Scnario nominal: il sagit l du scnario principal qui doit se drouler sans incident et qui permet daboutir au rsultat souhait Scnarios alternatifs: les autres scnarios, secondaires ou correspondant la rsolution danomalies, sont dcrire ce niveau .Le lien avec le scnario principale se fait laide dune numrotation hirarchise(1.1a, 1.1b.) rappelant le numro de laction concerne
34

MTHODOLOGIES DE CONCEPTION
35

Fin de chapitre2: Diagramme De Cas dutilisation