Le langage UML : Les cas dutilisation
CasU1 CasU2 A2
Lydie du Bousquet
[Link]-bousquet@[Link]
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 [Link]
Pour un template "standard" de description de cas d'utilisation
[Link]
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
