2 UML Use Case

Diagramme des cas d’utilisation
(Use-Case Diagram)
Définitions
 Objectifs :
 Modélisation de la vue des utilisateurs
 Définition des fonctions du système et ses limites
 Structuration des besoins (cahier de charge)
 Notation très simple et compréhensible elle permet donc

la communication avec l’utilisateur
S. Mouline Licence SMI-FSR Mod. 31 UML - Use Case Diagram 2

Des vues et des diagrammes UML
Diagram
Structure Behaviour
Diagram Diagram
Class Component Object Activity Use case

Diagram Diagram Diagram Diagram Diagram
Profile Composite Deployment Package Interation State

Diagram Structure Diagram Diagram Diagram Machine
Diagram Diagram
Sequence Communication Interaction Timing

Diagram Diagram Overview Diagram
Diagram

Exemple classique
Client Banque
Centrale
Transporteur Technicien
DeBillets
DistributeurDeBillet

Diagramme de cas d’utilisation
Exemple 1
Distributeur de billets
Retirer de l'argent
du distributeur
Client
Consulter son compte

Retirer les
cartes avalées
Ajouter Assurer
des billets la maintenance
Transporteur Technicien
de billets

Diagramme de cas d’utilisation (DCU)
Exemple 2
Système bancaire
Créer un compte
Consulter un compte
Retirer de l'argent au Client

distributeur
Déposer de l'argent
Guichetier
sur un compte
Retirer de l'argent
d'un compte Gérer les prêts
Directeur

Les concepts de base
« use case »
 Cas d'utilisation «stereotype» Nom du cas
Nom du cas -nom_prop : Integer
+nom_opération();void
 Description de l’utilisation du système

 Ensemble d’interactions entre un acteur et le système

Correspond à une fonction du système visible par l’acteur
 Regroupe un ensemble de scénarii correspondant à un même but
Créer un Enregistrer Retirer de l'argent Créer un compte pendant Taper son

S'identifier
compte création au distributeur les heures d'ouverture code

 Système
• Modélisé par un ensemble de cas d’utilisation (boîte
( noire)
• Le système contient des cas d ’utilisation (pas d’acteurs).
<<actor>>
 Acteur PorteurDeCarte
Plutôt pour des acteurs non humains
PorteurDeCarte
• Elément externe actif qui interagit avec le système
• rôle qu’un utilisateur joue par rapport au système

 Acteur (suite)
• Acteur ≠ Personne utilisant le système
• Un acteur n’est pas forcément un être humain
• Représente le rôle par rapport au système plutôt qu’une

position dans l'organisation
Une même personne peut jouer plusieurs rôles

Plusieurs personnes peuvent jouer un même rôle

Description Préliminaire des éléments du
DCU
 Exemple pour le système

Le système logiciel NomSyst ("Crédit Rabat Dans la Rue, 24h/24,
7j/7"), déployé sur un distributeur de billets de la gamme DB600, a
pour but de contrôler l'ensemble des fonctions associées au
distributeur en incluant son fonctionnement normal, mais aussi sa
sécurité et sa maintenance.
 Exemple pour l’acteur

Un guichetier est un employé de la banque chargé de faire
l’interface entre le système informatique et les clients qu’il reçoit
au comptoir. Le guichetier peut réaliser les opérations
courantes : création d ’un compte, dépôt et retrait d ’argent, etc.

Description Préliminaire des éléments du
DCU
Retirer
 Exemple pour le Use Case : de l'argent
au distributeur
Lorsqu’un client a besoin de liquide il peut en utilisant un distributeur

retirer de l’argent de son compte. Pour cela :
- le client insère sa carte bancaire dans le distributeur
- le système demande le code pour l ’identifier
- le client choisit le montant du retrait
- le système vérifie qu ’il y a suffisamment d ’argent
- si c ’est le cas, le système distribue les billets et débite le compte du
client
- le client prend les billets et retire sa carte

Relations entre les éléments d’un DCU
 Relations acteurs <-> cas d'utilisation
 Point de vue besoin: Représente la possibilité d'atteindre
un but
 Point de vue système: Représente un échange de messages
(communication)
 Multiplicité
 Nombre de fois qu’un acteur peut interagir avec un cas
d’utilisation, il est possible d’ajouter une multiplicité sur
l’association du côté du cas d’utilisation :
*  plusieurs ; n  exactement n ; n..m  entre n et m, etc.
 une multiplicité n’implique pas nécessairement que les cas

sont utilisés en même temps.

 Relations cas d'utilisation <-> cas d'utilisation

 Communications internes non modélisées
 Autres relations : inclusion, extension et
Spécialisation/Généralisation

 Relations cas d'utilisation <-> cas d'utilisation

Autres relations : Inclusion, Extension et
Spécialisation/Généralisation
{si date différée} Extension point : Date débit
Retirer De l'argent
Retirer De points
l'argent « include »
Différer le débit Extension
« extends » Date débit
S'identifier
Transferer « include »
Retirer de l'argent d'argent
au distributeur

 Relations acteurs <-> acteurs

 Communications externes non modélisées
 Une seule relation la généralisation
Créer un compte
Créer un compte
Guichetier Fermer un compte Guichetier

Fermer un compte
Retirer de l'argent
Retirer de l'argent d'un compte
d'un compte
Annuler un compte
Annuler un compte Guichetier
EnChef
Guichetier
en chef

La démarche : Processus Unifié
• Définir le modèle de cas d’utilisation

– Trouver les acteurs
– Décrire brièvement chaque acteur
– Trouver les cas d ’utilisation
– Décrire brièvement chaque cas d’utilisation
– Décrire le modèle comme un tout
• Définir des priorités et les risques entre CU
• Détailler chaque CU (en tenant compte des priorités

et des risques)

Description détaillée des cas d’utilisation
 Tout cas d ’utilisation doit être décrit en détail en

commençant par les CU prioritaires
 Description utile pour la suite du développement
 Description détaillée plus où moins formelle
 langue naturelle mais structurée, vocabulaire précis
 diagramme d’états
 ...

Informations à décrire
 Les pré-conditions
 Les post-conditions
 Le déroulement normal
 Les variantes possibles et les cas d’erreurs
 Les interactions entre le système et les acteurs
 Les informations échangées
 Les éventuels besoins non fonctionnels

Exemple de
description détaillée d ’un CU
Précondition :
Retirer Le distributeur contient des billets, il est en attente d’une
de l'argent
du distributeur opération, il n’est ni en panne, ni en maintenance
Début : lorsqu’un client introduit sa carte bancaire dans le

distributeur.
Fin : lorsque la carte bancaire et les billets sont sortis.
Postcondition :
Si de l ’argent a pu être retiré, la somme d’argent sur le
compte est égale à la somme d’argent qu’il y avait avant,
moins le montant du retrait. Sinon la somme d’argent sur le
compte est la même qu’avant.

Exemple de
Déroulement normal :
(1) le client introduit sa carte bancaire
Retirer (2) le système lit la carte et vérifie si la carte est valide
de l'argent
du distributeur (3) le système demande au client de taper son code
(4) le client tape son code confidentiel
(5) le système vérifie que le code correspond à la carte
(6) le client choisi l'opération de retrait
(7) le système demande le montant à retirer
…
Variantes :
(A) Carte invalide : au cours de l ’étape (2) si la carte est
jugée invalide, le système affiche un message d’erreur,
garde la carte et le CU se termine.
(B) Code erroné : au cours de l ’étape (5) ...

Exemple de
Contraintes non fonctionnelles :

Retirer
de l'argent (A) Performance : le système doit réagir dans un délai
du distributeur
inférieur à 4 secondes, quelque soit l’action de l ’utilisateur.
(B) Résistance aux pannes : si une coupure de courant ou

une autre défaillance survient au cours du cas d’utilisation,
la transaction sera annulée, l’argent ne sera pas distribué.
Le système doit pouvoir redémarrer automatiquement
dans un état cohérent et sans intervention humaine.
(C) Résistance à la charge : le système doit pouvoir gérer

plus de 1000 retraits d ’argent simultanément
...

Notion de scénario
 Pour décrire ou valider un CU
 Un scénario est un exemple :

 une manière particulière d’utiliser le système …
 … par un acteur particulier …
 … dans un contexte particulier.
 cas d’utilisation = ensemble de scénarios
 scénario = une exécution particulière d’un CU

Exemple de scénario
SCENARIO 4
Retirer • Omar insère sa carte dans le distributeur d2103
de l'argent
du distributeur
• Le système accepte la carte et lit le numéro de compte
• Le système demande le code
• Omar tape ‘ 1234 ’
• Le système indique que ce n ’est pas le bon code
• Le système affiche un message et propose de recommencer
• Omar tape ‘ 6622’
• Le système affiche que le code est correct
• Le système demande le montant du retrait
• Omar tape 500 dh
• Le système vérifie s ’il y a assez d ’argent sur le compte
...

Diagrammes de séquences systèmes
 Pour décrire un scénario : un diagramme de séquences
 Diagramme de séquences :
 L’une des notations UML, une notation générale
 Peut être utilisée dans de nombreux contextes
 Permet de décrire une séquence des messages
échangés entre différents objets
 Différents niveaux de détails
 Pour décrire un scénario simple,
deux objets : l’acteur et le système
=> "Diagramme de séquences système"

Exemple de scénario
Omar : Client le système
Insérer carte
Vérifier carte
Demander code
Entrer code ‘1234 ’
Vérifier code
Message d ’erreur
Demander code
Pense à un
autre code
Entrer code ‘6622 ’
...
Les problèmes récurrents
 Les problèmes soulevés dans cette partie correspondent à
des questions récurrentes en pratique.
 Problèmes éventuellement sans réponse dans la norme
 Interprétations et solutions parfois différentes dans les livres
 Problèmes récurrents souvent implicites
⇓
Chercher quelles conventions existent dans le contexte de travail
ou
se mettre d'accord sur des conventions lorsque le problème se pose

 Problème des cas d'utilisation orientés-solution

concrète
 Problème but vs. communication et problème des
intermédiaires
 Problème des cas d'utilisation partagés
 Problème des cas d'utilisation collaboratifs
 Problème de la granularité

 Problème des cas d'utilisation orientés-solution

concrète
 Problème but vs. communication et problème des
intermédiaires
 Problème des cas d'utilisation partagés
 Problème des cas d'utilisation collaboratifs
 Problème de la granularité

Problème des cas d'utilisation
orientés-solution
 Décrire les buts et les besoins des acteurs, les
interactions
mais pas l'interface (concrète)
 Le POURQUOI, POUR QUI, pas le COMMENT


Retirer de l'argent
Client
Se concentrer
Consulter son
compte
sur l'essentiel
Retirer les
Technicien Cartes avalées => cas d'utilisation "essentiels "
Distributeur de
billets
Cas d'Utilisation "Essentiels"
 "Essential uses cases"
 Ne pas décrire l'interface concrète
 Décrire
 les objectifs et intentions de l'acteur
 les responsabilités du système
 les "interactions abstraites"

Retirer
de l'argent
du distributeur - le client tape le montant du retrait sur le clavier
- le système affiche un message de confirmation

Réécriture dans un style essentiel
Retirer - le client tape le montant du retrait sur le clavier
de l'argent
du distributeur - le système vérifie qu’il y a suffisamment d ’argent
- le système affiche un message de confirmation
...
Extraction de l'essentiel
Retirer
de l'argent - le client s'identifie
du distributeur - le système vérifie l'identification
- le client détermine le montant du retrait

Se concentrer sur l'essentiel
 Eviter les décisions trop rapides
 Séparation des métiers

 analyse des besoins  modèle de cas d'utilisation
(UML)
 conception des  modèle de tâches ou autre
interfaces personne- (pas dans UML)
système

CU "but" vs. CU "interaction"
 Représentation des intermédiaires entre le système et
l'intéressé ?
 Différents points de vue
Retirer
de l'argent On insiste sur le lien de
avec un chéquier communication,
Client Guichetier l'échange de messages et
l'interface
Retirer
de l'argent On insiste sur les objectifs
avec un chéquier
et on masque
Client complètement les aspects
liés à l'interface

CU "but" vs. CU "interaction"
<<actor>>
Portable
DUnClient
Client Consulter Consulter
SonCompte ClientVia SonCompte
UnPortable
Consulter
Client SonCompte Consulter
Client
ViaUnPortable SonCompte

CU partagés vs. CU collaboratifs
Guichetier
Client
ConsulterUnCompte
Système
Bancaire
L'association "communique" est peu informative :
qui réalise le cas d'utilisation ? qui collabore à son
déroulement ?
quels acteurs peuvent participer à un même scénario
simultanément ?
Pas de notation standard pour exprimer les réponses

Une notation mais deux
interprétations
Guicheti
Client er Client
ConsulterUnCom ConsulterUnCom
pte Système pte
Bancaire
(1) CAS D'UTILISATION (2) CAS D'UTILISATION "COLLABORATIF"

"PARTAGE"
Deux acteurs collaborent à la réalisation
Deux acteurs peuvent réaliser le d'un objectif. Le système interagit avec
cas d'utilisation mais pour les deux acteurs.
répondre à des objectifs qui leur
son propre

Problème des cas d'utilisation
collaboratifs
Acteur "primaire"
• utilise le système comme Acteur primaire
outil pour réaliser son but
• initie généralement la
communication
Guichetie
r
ConsulterUnCom
Acteur(s) "auxiliaire(s)" pte
• interviennent suite à
l'intervention de l'acteur
primaire Système
Bancaire
• offrent généralement leurs Acteur auxiliaire
services au système

Différents styles dans la pratique
 STYLE "primaire":
Ne représenter que les acteurs primaires dans les
diagrammes
 STYLE "décoré":
Utiliser une décoration particulière (e.g. auxiliaire ou initiator)
 STYLE "gauche/droite":
Positionner les acteurs primaires à gauche, secondaires à
droite
 STYLE "fleché":
Utiliser une flêche pour indiquer l'acteur primaire (a éviter)

Style "primaire"
 Ne représenter que l'acteur primaire
ConsulterUnCompte
Client VendreAuxEnchères
Vendeur
 A le mérite d'être simple et d'obtenir des diagrammes lisibles

 Sans doute la meilleure solution lors des premières itérations

Style "décoration"
 Utiliser une décoration particulière (e.g. auxiliaire ou initiator)
Vendeur
Client
auxiliary
auxiliary
Acheteur
<<actor>>
SystèmeBancaire VendreAuxEnchères
ConsulterUnCompte
auxiliary
Controleur

Style "droite/gauche"
 primaire à gauche, secondaire à droite

<<actor>>
SystèmeBancaire
Client ConsulterUnCompte
Acheteur
Vendeur VendreAux
Enchères
Controleur
 convention "invisible" sans indication

Eviter les flêches !
Vendeur VendreAux
Enchères
 Interprétation diverses et variées :

 "l'acteur est initiateur"
 "la communication se fait que dans un seul sens"
 "je savais pas comment enlever la flêche avec cet outil UML..."
 Eviter la flêche en UML (sauf si vous savez ce que vous faites)

Problèmes des cas d'utilisation partagés
A B
ConsulterLesLivres ConsulterLesLivres
Internaute
Acheter
Acheter
Client
Client
C D
Internaute Internaute
Acheter
Acheter
Client Client
AA B
ConsulterLesLivres
Internaute
Acheter
Acheter Acheter
Client
Client Client
SYSTEME DE VENTE EN LIGNE
Un client peut consulter
C D
la liste des livres et
il peut en acheter
Acheter
Acheter
Client Client
A BB
Internaute ConsulterLesLivres
Internaute
Acheter
• OnClient
insiste sur le fait que l'une des fonctions Acheter
Acheter
importante est d'accueillir des internautes Client
Client
quelconques et de leur permettre de consulter
la liste des livres sans que leur objectif soit
C d'acheter D
• La différence est faite entre un internaute et
un client (potentiellement habitué)
• Une personne peut changer de rôle
dynamiquement en jouant le rôle internaute
puis de client.
• Ce changement de rôle est une caractéristique
Acheter
exterieure au système Acheter
Client Client
A B
Internaute
Acheter
Acheter
Client
Client
C D
• Il est considéré comme important de séparer
ConsulterLesLivres les clients des internautesConsulterLesLivres
Internaute • ConsulterLesLivres
Internauteest un cas d'utilisation
normal pour un client
• Acheter aussi
Acheter
Acheter
Client Client
A B
• Un client peut tout faire ce que peut faire un
Internaute
internaute (héritage des cas d'utilisation)
• Un client est un cas particulier d'internaute
Acheter
(spécialisation) Acheter
Client
• La dernière règle
Client doit être respectée
C D
Acheter
Acheter
Client Client
Problèmes de la granularité
 A quel niveau décrire les cas d'utilisation ?

 Bonne question ... mais pas de réponse
 Trop haut
 trop loin du système
 trop abstrait et "flou"
 trop complexe à décrire
 Trop bas
 trop de cas d'utilisation
 trop près de l'interface
 trop loin des besoins métiers
 Conclusion: choisir le "bon" niveau ...

2 UML Use Case

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

2 UML Use Case

Загружено:

Авторское право:

Доступные форматы

Diagramme des cas d’utilisation

 Notation très simple et compréhensible elle permet donc

S. Mouline Licence SMI-FSR Mod. 31 UML - Use Case Diagram 2

Class Component Object Activity Use case

Profile Composite Deployment Package Interation State

Sequence Communication Interaction Timing

S. Mouline Licence SMI-FSR Mod. 31 UML - Use Case Diagram 3

S. Mouline Licence SMI-FSR Mod. 31 UML - Use Case Diagram 4

Consulter son compte

S. Mouline Licence SMI-FSR Mod. 31 UML - Use Case Diagram 5

Retirer de l'argent au Client

S. Mouline Licence SMI-FSR Mod. 31 UML - Use Case Diagram 6

 Description de l’utilisation du système

Créer un Enregistrer Retirer de l'argent Créer un compte pendant Taper son

S. Mouline Licence SMI-FSR Mod. 31 UML - Use Case Diagram 7

• Le système contient des cas d ’utilisation (pas d’acteurs).

• Elément externe actif qui interagit avec le système

• rôle qu’un utilisateur joue par rapport au système

S. Mouline Licence SMI-FSR Mod. 31 UML - Use Case Diagram 8

• Un acteur n’est pas forcément un être humain

• Représente le rôle par rapport au système plutôt qu’une

Une même personne peut jouer plusieurs rôles

S. Mouline Licence SMI-FSR Mod. 31 UML - Use Case Diagram 9

 Exemple pour le système

 Exemple pour l’acteur

S. Mouline Licence SMI-FSR Mod. 31 UML - Use Case Diagram 10

Lorsqu’un client a besoin de liquide il peut en utilisant un distributeur

S. Mouline Licence SMI-FSR Mod. 31 UML - Use Case Diagram 11

*  plusieurs ; n  exactement n ; n..m  entre n et m, etc.

 une multiplicité n’implique pas nécessairement que les cas

S. Mouline Licence SMI-FSR Mod. 31 UML - Use Case Diagram 12

 Relations cas d'utilisation <-> cas d'utilisation

S. Mouline Licence SMI-FSR Mod. 31 UML - Use Case Diagram 13

 Relations cas d'utilisation <-> cas d'utilisation

S. Mouline Licence SMI-FSR Mod. 31 UML - Use Case Diagram 14

 Relations acteurs <-> acteurs

Guichetier Fermer un compte Guichetier

S. Mouline Licence SMI-FSR Mod. 31 UML - Use Case Diagram 15

• Définir le modèle de cas d’utilisation

• Définir des priorités et les risques entre CU

• Détailler chaque CU (en tenant compte des priorités

S. Mouline Licence SMI-FSR Mod. 31 UML - Use Case Diagram 16

 Tout cas d ’utilisation doit être décrit en détail en

S. Mouline Licence SMI-FSR Mod. 31 UML - Use Case Diagram 17

S. Mouline Licence SMI-FSR Mod. 31 UML - Use Case Diagram 18

Début : lorsqu’un client introduit sa carte bancaire dans le

Fin : lorsque la carte bancaire et les billets sont sortis.

S. Mouline Licence SMI-FSR Mod. 31 UML - Use Case Diagram 19

S. Mouline Licence SMI-FSR Mod. 31 UML - Use Case Diagram 20

Contraintes non fonctionnelles :

(B) Résistance aux pannes : si une coupure de courant ou

(C) Résistance à la charge : le système doit pouvoir gérer

S. Mouline Licence SMI-FSR Mod. 31 UML - Use Case Diagram 21

 Un scénario est un exemple :

 cas d’utilisation = ensemble de scénarios

 scénario = une exécution particulière d’un CU

S. Mouline Licence SMI-FSR Mod. 31 UML - Use Case Diagram 22

S. Mouline Licence SMI-FSR Mod. 31 UML - Use Case Diagram 23

=> "Diagramme de séquences système"

S. Mouline Licence SMI-FSR Mod. 31 UML - Use Case Diagram 24

Omar : Client le système

Entrer code ‘1234 ’

S. Mouline Licence SMI-FSR Mod. 31 UML - Use Case Diagram 26