Le langage UML : Les cas dutilisation

CasU1 CasU2 A2

Lydie du Bousquet
Lydie.du-bousquet@imag.fr

A1 CasU4 CasU3

CasU5 S A3

En collaboration avec J.-M. Favre, I. Parissis, Ph. Lalanda, Y. Ledru

Le diagramme des cas dutilisation

Diagramme UML Pour dfinir
le systme du point de vue de lutilisateur Les limites prcises du systme

Notation simple, comprhensible par tous Permet de structurer

Les besoins Le reste du dveloppement
CasU1 CasU2 A2 A1 CasU4 CasU3

CasU5 S A3

Exemple de cas dutilisation

CrerUnCompte

Client ConsulterUnCompte

Guichetier DeposerDeLArgent SurUnCompte

RetirerDeLArgentAu Distributeur

RetirerDeLArgent DUnCompte

GererLesPrets Directeur Systme bancaire

Exemple de cas dutilisation

RetirerDeLArgentAu Distributeur Banque centrale ConsulterSonCompte RetirerLes CartesAvales

Client

Transporteur DeBillets

Ajouter DesBillets

Assurer LaMaintenance

Technicien

DistributeurDeBillets

Diagramme et modle de cas dutilisation

Diagramme
Les acteurs Les cas dutilisation Le systme
A1 CasU4 CasU3 CasU1 CasU2 A2

CasU5 S A3

Modle de cas dutilisation

Plusieurs diagrammes de cas dutilisation Des descriptions textuelles Des diagrammes de squence Les fonctions essentielles du systme, Ses limites, lenvironnement

Modle pour communiquer

Modle informel centr utilisateur Avant tout sous forme textuelle

Diagramme utilis
pour pour pour pour les runions de "brainstorming" simplifier la communication structurer les documents structurer le dveloppement

Diagramme = plan du document

6

Langage peu formalis

Modle de cas d'utilisation peu standardis par UML Diffrents styles Diffrentes interprtations

Modle construit par raffinements successifs et consensus grandissant

Peu de formalisme, beaucoup de bon sens et de communication

lments de base

Acteurs

Cas d'utilisation

Systme

Cas dutilisation (CU)

CasDUtilisationX

Une manire dutiliser le systme Une suite dinteractions entre un acteur et le systme
Ex: le guichetier veut crer un nouveau compte Le client veut retirer de largent dans le distributeur

Correspond une fonction visible par lutilisateur Permet datteindre un but pour un utilisateur Doit tre utile en soi

Entrer

EnregistrerEntre

RetirerDeLArgentAu Distributeur

EntrerPendant LesHeuresDOuverture

TaperSonCode

Le systme
Modlis comme une bote noire Est un ensemble de cas dutilisation Contient
Les cas dutilisation Mais PAS les acteurs
DistributeurDeBillets

SystemeDeControleDAcces

Un modle de cas dutilisation permet de dfinir :

les fonctions essentielles du systme, les limites du systme, le systme par rapport son environnement, dlimiter le cadre du projet !
10

Les acteurs
lment qui interagit avec le systme Prend des dcisions, des initiatives =
il est actif

Client

Rle quun utilisateur joue par rapport au systme

Ex : client, guichetier

PorteurDeCarte

Gardien

Administrateur

Capteur

11

Acteurs vs Utilisateurs
Ne pas confondre les 2 notions
Un acteur dcrit un rle Un utilisateur = personne utilisant le systme

Client

Une mme personne peut avoir deux rles

Maurice, directeur de banque et guichetier

Plusieurs personnes peuvent avoir le mme rle

Pierre et Paul sont 2 clients

Un acteur nest pas forcment un tre humain

Un distributeur de billet peut-tre vu comme un acteur

12

Diffrents types dacteurs

Utilisateurs principaux
Ex: client, guichetier

Client

Utilisateurs secondaires
Ex : Contrleur, directeur, ingnieur systme

Priphriques externes
Ex : capteurs, horloge interne

Systmes externes
Ex : Systme interbancaire
13

Description des acteurs

Pour chaque acteur
Choisir un identificateur reprsentatif de son rle Donner une brve description textuelle

14

Description des acteurs : Diffrents notations possibles

Notations alternatives pour les acteurs
<<actor>> PorteurDeCarte PorteurDeCarte

PorteurDeCarte

Note de style : utiliser plutt le strotype <<actor>> pour les acteurs non humains
<<actor>> CapteurAIncendie PorteurDeCarte <<actor>> SystmeBancaire

15

Utilit des acteurs

La dfinition dacteurs permet surtout
De trouver les cas dutilisation que peut faire le guichetier, le directeur ?

Mais peut aussi tre utilis pour

Dfinir diffrents points de vues sur le systme Dterminer les droits daccs par type dacteurs Fixer les ordres de priorits entre acteurs

16

Mthodologie

17

Le processus unifi
(1) Dfinir le modle de cas dutilisation
(1) (2) (3) (4) (5)

Introduire le systme Trouver les acteurs Dcrire brivement chaque acteur Trouver les cas dutilisation, exprimer les relations Dcrire le modle comme un tout

(2) Dfinir les priorits entres CU (3) Dtailler chaque CU (en fonction des priorits)

18

Description prliminaire de chaque lment

Quelques lignes Eviter les incomprhensions Sance de "brainstorming"

Systme

Acteurs

Cas d'utilisation

19

Description prliminaire du systme

Choisir un identificateur
Baptiser le systme, le plus tt possible Risque d'tre rfrenc dans toute la vie future de l'entreprise

Brve description textuelle (quelques lignes max.)

CGDR24/7

Le systme logiciel CGDR24/7 ("Crdit Grenoblois Dans la Rue, 24h/24, 7j/7"), dploy sur un distributeur de billets de la gamme DB600, a pour but de contrler l'ensemble des fonctions associes au distributeur en incluant son fonctionnement normal, mais aussi sa scurit et sa maintenance. .

20

Description prliminaire des acteurs

Pour chaque acteur :

Client

choisir un identificateur reprsentatif de son rle donner une brve description textuelle
Un guichetier est un employ de la banque charg de faire linterface entre le systme informatique et les clients quil reoit au comptoir. Le guichetier peut raliser les oprations courantes : cration dun compte, dpt et retrait dargent, etc.
21

Guichetier

Description prliminaire des acteurs

identificateur reprsentatif : note de style :
choisir une forme nominale dcrivant un rle identification concise mais prcise terme provenant autant que possible du mtier utiliser par exemple le style MajMin

Client

importance :
essentiel pour discuter avec le client et prciser les besoins rfrenc tout au long des documents pourra apparatre dans les manuels utilisateurs, dans l'interface homme-systme, dans le code ...

22

Description des cas dutilisation

Pour chaque cas dutilisation

CasDUtilisationX

Choisir un identificateur reprsentatif Donner une description textuelle simple Prciser ce que fait le systme et lacteur Se concentrer sur le fonctionnement normal Fonction doit tre comprhensible Pas trop dtaille

Les cas dutilisation ne doivent pas se chevaucher

23

Description des cas dutilisation

CasDUtilisationX

identificateur reprsentatif : notes de style : choisir une forme verbale dcrivant une action l'acteur est gnralement le sujet identification concise mais prcise viter les connecteurs (et, ou, puis, ...) terme provenant autant que possible du mtier utiliser par exemple le style MajMin terme gnrique comme "Grer" en cas de besoin Grer = Crer, Supprimer, Ajouter, Modifier, ... Exemple: GrerLesDroits
24

Le processus unifi
(1) Dfinir le modle de cas dutilisation
(1) (2) (3) (4) (5)

Introduire le systme Trouver les acteurs Dcrire brivement chaque acteur Trouver les cas dutilisation, exprimer les relations Dcrire le modle comme un tout

(2) Dfinir les priorits entres CU (3) Dtailler chaque CU (en fonction des priorits)

25

Relations entre lments de base

? ? ?

Relations acteurs <-> cas d'utilisation ? Relations acteurs <-> acteurs ? Relations cas d'utilisation <-> cas d'utilisation ?
26

Relation acteur cas dutilisation Communication

Reprsente une communication (initie par lacteur)
possibilit d'atteindre un but canal de communication

change de messages potentiellement dans les 2 sens

Client

RetirerDeLArgent AuDistributeur

Sera raffin par la suite (spcifications externes)

Si lacteur est un humain : interface homme systme Si lacteur est un logiciel : interface logicielle
27

<?xml version="1.0"?> <?xml <xs:schema xmlns:xs="XMLSchema"> xmlns:xs="XMLSchema"> <xs:element name="note"> name="note"> <xs:complexType> xs:complexType> <xs:sequence> xs:sequence> <xs:element name="to" type="xs:string"/> name="to" type="xs:string"/> <xs:element name="from" type="xs:string"/> name="from" type="xs:string"/> <xs:element name="heading" type="xs:string"/> name="heading" type="xs:string"/> <xs:element name="body" type="xs:string"/> name="body" type="xs:string"/> </xs:sequence> </xs:sequence> </xs:complexType> </xs:complexType> </xs:element> </xs:element> </xs:schema> </xs:schema>

Interface hommesystme
Client

Interface systmesystme
RetirerDeLArgentAu Distributeur <<actor>> SystmeBancaire ConsulterSonCompte

Technicien

RetirerLes CartesAvales

DistributeurDeBillets

Description (par la suite) dans les documents de spcification externes

28

Relation entre acteurs : Gnralisation

La seule relation entre acteur est la gnralisation
CrerUnCompte
CrerUnCompte

Guichetier FermerUnCompte

Guichetier

FermerUnCompte

RetirerDeLArgent DUnCompte

RetirerDeLArgent DUnCompte

AnnulerUnCompte Guichetier EnChef

AnnulerUnCompte Guichetier EnChef

29

Communications entre acteurs

Sont extrieures au systmes Ne sont pas modlises Car UML se concentre
sur la description du systme et linteraction systme extrieur
Guichetier Systme Bancaire ConsulterSonCompte Client RetirerDeLArgent AuDistributeur

RetirerDeLArgent ParChque

30

Communication entre CU
Pas de communication entre cas dutilisation
Client RetierDeLArgent

UML se concentre sur les interactions systme - extrieur

ConsulterLesSoldes

Directeur Systme Bancaire

31

Le processus unifi
(1) Dfinir le modle de cas dutilisation
(1) (2) (3) (4) (5)

Introduire le systme Trouver les acteurs Dcrire brivement chaque acteur Trouver les cas dutilisation, exprimer les relations Dcrire le modle comme un tout

(2) Dfinir les priorits entres CU (3) Dtailler chaque CU (en fonction des priorits)

32

Description du modle de cas dutilisation

Un modle de cas dutilisation peut contenir
Plusieurs diagrammes Plusieurs descriptions textuelles

Structuration en terme de paquetages Vision globale du systme Permet de dfinir des priorits entre CU Utile pour le client, pour la planification Trop gnrale pour les dveloppeurs
33

Exemple de diagramme de cas dutilisation dcor

{ 12/03/02 }

{ MUST }

CrerUnCompte

{ 25/12/02 }

{ SHOULD }
{ 10/10/02 } ConsulterUnCompte { 20/03/02 } Guichetier

Client

{ SHOULD } { MUST }
RetirerDeLArgentAu Distributeur

DeposerDeLArgent SurUnCompte { 10/12/02 } { 12/05/02 }

{ MAY } { MUST }
GererLesPrets

RetirerDeLArgent DUnCompte Systme bancaire

Directeur

34

Attention
them too complicated and get stuck. Usually, youll get less hurt by doing too little than by doing too much . [UML Distilled, Martin Fowler]
Congratulations: Use cases have been written, and are imperfect . [Applying UML and Patterns, Craig Larman] A big danger of use cases is that people make

35

Modle de cas d'utilisation: Description dtaille

Description dtaille des cas d'utilisation Prconditions, Dbuts, Postconditions, Fins Alternatives, Contraintes non fonctionnelles Relations entre cas d'utilisation: inclusion, extension, spcialisation Scnarii
36

Le processus unifi
(1) Dfinir le modle de cas dutilisation
(1) (2) (3) (4) (5)

Introduire le systme Trouver les acteurs Dcrire brivement chaque acteur Trouver les cas dutilisation, exprimer les relations Dcrire le modle comme un tout

(2) Dfinir les priorits entres CU (3) Dtailler chaque CU (en fonction des priorits)

37

Exemple de description dun cas dutilisation

Client RetirerDeLArgent AuDistributeur

Description via des diagrammes de squences ou textuelle

38

Exemple de description dun cas dutilisation

Lorsquun client a besoin de liquide il peut en utilisant un distributeur retirer de largent de son compte. Pour cela : - le client insre sa carte bancaire dans le distributeur - le systme demande le code pour l identifier - le client choisit le montant du retrait - le systme vrifie qu il y a suffisamment d argent - si cest le cas, le systme distribue les billets et dbite le compte du client - le client prend les billets et retire sa carte

Retirer DeLArgent AuDistributeur

39

Description dtaille de chaque cas dutilisation

Chaque cas d utilisation doit tre dcrit en dtail Commencer par les cas dutilisation prioritaires Description utile pour la suite du dveloppement Description dtaille plus o moins formelle
langue naturelle mais structure, vocabulaire prcis diagramme dtats ...

40

Informations dcrire
Quand le cas d'utilisation commence, pr-conditions Quand le cas d'utilisation se termine, post-conditions Le chemin correspondant au droulement normal = les interactions entre le systme et les acteurs Les variantes possibles et les cas derreurs Les ventuels besoins non fonctionnels

Maj YL 2007

41

Exemple de description dtaille dun cas d'utilisation

Prcondition : Le distributeur contient des billets, il est en attente dune opration, il nest ni en panne, ni en maintenance
Retirer DeLArgent AuDistributeur

Dbut : lorsquun client introduit sa carte bancaire dans le distributeur. Fin : lorsque la carte bancaire et les billets sont sortis. Postcondition : Si de largent a pu tre retir la somme dargent sur le compte est gale la somme dargent quil y avait avant, moins le montant du retrait. Sinon la somme d argent sur le compte est la mme quavant.
42

Exemple de description dtaille dun cas d'utilisation

Droulement normal : (1) le client introduit sa carte bancaire (2) le systme lit la carte et vrifie si la carte est valide (3) le systme demande au client de taper son code (4) le client tape son code confidentiel (5) le systme vrifie que le code correspond la carte (6) le client choisi une opration de retrait (7) le systme demande le montant retirer Variantes : (A) Carte invalide : au cours de ltape (2) si la carte est juge invalide, le systme affiche un message derreur, rejte la carte et le cas dutilisation se termine. (B) Code erron : au cours de l tape (5) ...
43

Retirer DeLArgent AuDistributeur

Exemple de description dtaille dun cas d'utilisation

Contraintes non fonctionnelles : (A) Performance : le systme doit ragir dans un dlai infrieur 4 secondes, quelque soit laction de lutilisateur. (B) Rsistance aux pannes : si une coupure de courant ou une autre dfaillance survient au cours du cas dutilisation, la transaction sera annule, largent ne sera pas distribu. Le systme doit pouvoir redmarrer automatiquement dans un tat cohrent et sans intervention humaine. (C) Rsistance la charge : le systme doit pouvoir grer plus de 1000 retraits dargent par jour ...
44

Retirer DeLArgent AuDistributeur

Format(s) "standardis(s)"
Pas de format standard propos en UML Diffrents formats proposs dans la littrature Choix du format en fonction des besoins

45

Relations entre cas d'utilisation : inclusion, extension et spcialisation

include RetirerDeLArgent S'Identifier include Transferer DeLArgent include

extends extends RetirerDeLArgent AvecDiffr RetirerDeLArgent

RetirerDeLArgent AuDistributeur

RetirerDeLArgent

46

Attention
"The UML includes other relationships between use cases beyond the simple includes, such as <<extends>>. I strongly suggest that you ignore them. I've seen too many situations in which teams can get terribly hung up on when to use different use case relationships, and such energy is wasted. Instead, concentrate on the textual description of a use case."
[UML Distilled, MartinFowler]

"A common sign of a novice (or academic) use case modeler is a preoccupation with use case diagrams and use case relationships, rather than writing text. ... Use case diagrams and use case relationships are secondary in use case work. Use cases are text documents. Doing use case work means to write text."
[Applying UML and Patterns, Craig Larman]
47

Scnario
Pour dcrire ou valider un cas d'utilisation Un scnario est un exemple :
une manire particulire dutiliser le systme par un acteur particulier dans un contexte particulier.

cas dutilisation = ensemble de scnarios scnario = une excution particulire dun cas d'utilisation
Maj YL 2007

48

Exemple de scnario
Retirer DeLArgent AuDistributeur

SCENARIO 4 Le client insre sa carte dans le distributeur d2103 Le systme accepte la carte et lit le numro de compte Le systme demande le code Le client tape 1234 Le systme indique que ce nest pas le bon code Le systme affiche un message et propose de recommencer Le client tape 6622 Le systme affiche que le code est correct Le systme demande le montant du retrait Le client tape 10000 Euros Le systme vrifie sil y a assez d argent sur le compte ...
49

Diagrammes de squences "systmes"

Pour dcrire un scnario : un diagramme de squences Diagramme de squences :
Lune des notations UML, une notation gnrale Peut tre utilise dans de nombreux contextes Permet de dcrire une squence des messages changs entre diffrents objets Diffrents niveaux de dtails

Pour dcrire un scnario simple, deux objets : lacteur et le systme

"Diagramme de squences systme"

50

Exemple de scnario
paul : Client
Insrer carte Demander code Entrer code 1234 Message derreur Demander code Appeler Sylvia Entrer code 6622 Vrifier code Vrifier carte

le systme

...

51

Cas d'utilisation vs. scnarii

Niveau modle

Niveau instances

52

Rsum
Diffrents concepts UML
Modle et diagramme des cas dutilisation Acteur, cas dutilisation Scnario

Processus Unifi : commencer par les acteurs Utiliser les diagrammes mais surtout la langue naturelle! Moyen de communication avec le client Modle prliminaire vs. Modle dtaill Processus itratif
53

Pour en savoir un plus...

Chapitre gratuit tlchargeable http://www.craiglarman.com/book_applying_2nd/Applying_2nd.htm

Pour un template "standard" de description de cas d'utilisation

http://alistair.cockburn.us/usecases/uctempla.htm
54

Pour en savoir encore plus ...

Des livres spcialiss

55

Pour en savoir encore plus ...

56

Pour en savoir encore plus ...

57

Diagrammes de cas dutilisation Problmes rcurrents

58

Problmes rcurrents
Les problmes soulevs dans cette partie correspondent des questions rcurrentes en pratique. Problmes ventuellement sans rponse dans la norme Interprtations et solutions parfois diffrentes dans les livres Problmes rcurrents souvent implicites
=> Chercher quelles conventions existent dans le contexte de travail ou se mettre d'accord sur des conventions lorsque le problme se pose

59

Cas d'utilisation "essentiels"

60

Problme des cas d'utilisation orients-solution

Dcrire les buts et les besoins des acteurs, les interactions mais pas l'interface (concrte) Le POURQUOI, POUR QUI, pas le COMMENT
RetirerDeLArgent

Client
ConsulterSonCompte

Se concentrer sur l'essentiel => cas d'utilisation "essentiels"

Technicien

RetirerLes CartesAvales

DistributeurDeBillets

61

Cas d'Utilisation "Essentiels"

"Essential uses cases" Ne pas dcrire l'interface concrte Dcrire
les objectifs et intentions de l'acteur Dcrire les responsabilits du systme Les "interactions abstraites"

62

Rcriture dans un style essentiel

Retirer DeLArgent AuDistributeur

- le client insre sa carte bancaire dans le distributeur - le systme demande le code pour l identifier - le client tape le montant du retrait sur le clavier - le systme vrifie quil y a suffisamment d argent - le systme affiche un message de confirmation ... Extraction de l'essentiel - le client s'identifie - le systme vrifie l'identification - le client dtermine le montant du retrait - le systme vrifie quil y a suffisamment d argent
63

Retirer DeLArgent AuDistributeur

Les intermdiaires

64

Problme des intermdiaires (1)

Reprsentation des intermdiaires entre le systme et l'intress ? Diffrents points de vue
On insiste sur le lien de communication, l'change de messages et l'interface

Client

Guichetier

RetirerDeLArgent AvecUnChque

Client

RetirerDeLArgent AvecUnChque

On insiste sur les objectifs et on masque compltement les aspects lis l'interface
65

Problme des intermdiaires (2)

<<actor>>

Portable DUnClient Client

Consulter SonCompte

ClientVia UnPortable

Consulter SonCompte

Projet: dvelopper le systme centralis accessible partir d'un portable

Projet: dvelopper le systme embarqu dans un portable pour accder au systme centralis

Client

Consulter SonCompte ViaUnPortable

Client

Consulter SonCompte

Projet: dvelopper le systme centralis accessible partir du systme embarqu CGPEW

Projet: dvelopper le systme global

66

Cas d'utilisation partags vs. Cas d'utilisation collaboratifs.

67

Une notation peu informative

Client Guichetier

ConsulterUnCompte

Systme Bancaire

L'association "communique" est peu informative : qui ralise le cas d'utilisation ? qui collabore son droulement ? quels acteurs peuvent participer un mme scnario simultanment ? Pas de notation standard pour exprimer les rponses

68

Une notation mais deux interprtations

Client Guichetier Client

ConsulterUnCompte

ConsulterUnCompte

Systme Bancaire

(1) CAS D'UTILISATION "PARTAGE" Deux acteurs peuvent raliser le cas d'utilisation mais pour rpondre des objectifs qui leur sont propres

(2) CAS D'UTILISATION "COLLABORATIF" Deux acteurs collaborent la ralisation d'un objectif. Le systme intragit avec les deux acteurs.
69

Problme des cas d'utilisation collaboratifs

Acteur "primaire" utilise le systme comme outil pour raliser son but initie gnralement la communication Acteur(s) "auxiliaire(s)" interviennent suite l'intervention de l'acteur primaire offrent gnralement leurs services au systme
Acteur primaire

Guichetier
ConsulterUnCompte

Systme Bancaire Acteur auxiliaire

70

Diffrents styles dans la pratique

STYLE "primaire": Ne reprsenter que les acteurs primaires dans les diagrammes STYLE "dcor": Utiliser une dcoration particulire (e.g. auxiliaire ou initiator) STYLE "gauche/droite": Positionner les acteurs primaires gauche, secondaires droite STYLE "flech": Utiliser une flche pour indiquer l'acteur primaire ( viter)
71

Style "primaire"
Ne reprsenter que l'acteur primaire

Client

ConsulterUnCompte

Vendeur

VendreAuxEnchres

72

Style "dcoration"
Utiliser une dcoration particulire (e.g. auxiliaire ou initiator)
Vendeur Client auxiliary auxiliary
<<actor>> SystmeBancaire ConsulterUnCompte

Acheteur
VendreAuxEnchres

auxiliary

Controleur 73

Style "droite/gauche"
primaire gauche, secondaire droite
<<actor>> SystmeBancaire

Client

ConsulterUnCompte

Acheteur Vendeur
VendreAuxEnchres

convention "invisible" sans indication

Controleur

74

Eviter les flches !

Vendeur
VendreAuxEnchres

Eviter la flche en UML (sauf si vous savez ce que vous faites)

Interprtation diverses et varies :

"l'acteur est initiateur" "la communication se fait que dans un seul sens" "je savais pas comment enlever la flche avec cet outil UML..." 75

Problmes des cas d'utilisation partags

A
ConsulterLesLivres

B
ConsulterLesLivres

Internaute
Acheter

Client Client

Acheter

C
ConsulterLesLivres

D
ConsulterLesLivres

Internaute

Internaute

Acheter

Acheter

Client

Client

76

Problmes des cas d'utilisation partags

A A
ConsulterLesLivres ConsulterLesLivres Acheter Acheter

B
ConsulterLesLivres

Internaute

Client Client

Acheter

Client

SYSTEME DE VENTE EN LIGNE

C
Internaute

Un client peut consulter la liste des livres et il peut en acheter

ConsulterLesLivres

ConsulterLesLivres

Internaute

Acheter

Acheter

Client

Client

77

Problmes des cas d'utilisation partags

A
ConsulterLesLivres

B B
Internaute Internaute
Acheter ConsulterLesLivres ConsulterLesLivres

On insiste sur le fait que l'une des fonctions Client importante est d'accueillir des internautes quelconques et de leur permettre de consulter la liste des livres sans que leur objectif soit d'acheter La diffrence est faite entre un internaute et ConsulterLesLivres un client (potentiellement habitu) Internaute Une personne peut changer de rle dynamiquement en jouant le rle internaute puis de client. Ce changement de rle est une caractristique Acheter exterieure au systme

Client Client

Acheter Acheter

ConsulterLesLivres

Internaute

Acheter

Client

Client

78

Problmes des cas d'utilisation partags

A
ConsulterLesLivres

B
ConsulterLesLivres

Internaute
Acheter

Client Client

Acheter

ConsulterLesLivres

D
Internaute

Acheter

Il est considr comme important de sparer les clients des internautesConsulterLesLivres Internaute ConsulterLesLivres est un cas d'utilisation normal pour un client Acheter aussi
Acheter

Client

Client

79

Problmes des cas d'utilisation partags

A
ConsulterLesLivres

B
Un client peut tout faire ce que peut faire un Internaute internaute (hritage des cas d'utilisation) Un client est un cas particulier d'internaute (spcialisation) Acheter La dernire rgle doit tre respecte Client
ConsulterLesLivres

Acheter

Client

C
ConsulterLesLivres

D
ConsulterLesLivres

Internaute

Internaute

Acheter

Acheter

Client

Client

80

Conclusion

81

Modle prliminaire des cas d utilisation

Equivalent dfinir une table des matires et des rsums pour chaque chapitre Pas de rgles strictes Effectuer les meilleurs regroupement possibles Rester simple ! Structuration possible en termes de paquetages Culture d'entreprise Stabilisation du modle par consensus

grandissant
82