Vous êtes sur la page 1sur 34

Chapitre 2:

Vue fonctionnelle: diagramme des


cas d’utilisation
Objectif du cours: comprendre l’intérêt et les
concepts de base (notations) d’un diagramme de
cas d’utilisation, et comment le concevoir…

Dr. Ouarda ZEDADRA GL 1


Modèle et Modélisation

Dr. Ouarda ZEDADRA GL 2


UML Définition

• UML: Unified Modelling Language (pour ‘langage de


modélisation unifié’);
• C’est un langage de modélisation visuel qui permet de
modéliser des processus, des phénomènes ou des systèmes;
• UML est composé de notation et de diagrammes;
– Notation: éléments se trouvant dans les diagrammes, exemple: symboles,
connecteurs, notes, valeurs…
– Diagrammes: représentation graphique d’un système ou une partie de ce
dernier (s’intéresse à un aspect précis)

Dr. Ouarda ZEDADRA GL 3


Subdivision des diagrammes UML selon l’axe de
trois
Statique (structurel- pas de temps)
La structure du système en terme d’objets et les
interactions entre eux

Diagramme de Classes
Diagramme d’Objets
Diagramme de Composants
Diagramme de Déploiement

Fonctionnel Dynamique (temporel)


Que fait le système Décrivent le comportement du système, l’
exécution des activités
Diagramme de Use Case
Diagramme d'Etats-Transitions
Diagramme d'Activité
Diagramme de Séquence

Dr. Ouarda ZEDADRA GL 4


Introduction
• Capture les exigences fonctionnelles du système (ce que le système doit
faire);
• Chaque cas d’utilisation correspond à une fonction du système selon le
point de vue d’un de ses acteurs;
• Il scinde la fonctionnalité du système en unités cohérentes, les cas
d’utilisation, ayant un sens pour les acteurs;
• Décrit les interactions entre les différents acteurs (utilisateurs de cas) et le
système, selon le point de vue de l’utilisateur;
• Il ne faut pas négliger cette première étape pour produire un logiciel
conforme aux attentes des utilisateurs;
• Pour élaborer les cas d’utilisation, il faut des entretiens avec les
utilisateurs;
• La représentation d’un cas d’utilisation met en jeu trois concepts: acteur,
cas d’utilisation et interaction entre l’acteur et le cas d’utilisation.

Dr. Ouarda ZEDADRA GL 5


Acteur [définition]
o Un acteur à un rôle de l’utilisation du système (personne, système
ou organisation…).
o Le couple (utilisateur, role) constitue un acteur spécifique;
o Toute entité extérieure au système et interagissant avec celui-ci qui
à un objectif d’utiliser le système.
o Acteurs humains, acteurs « machine » (système extérieur
communiquant avec le système étudié).
o Il sera bénéfique de penser aux acteurs comme des rôles et non
pas des individus (une même personne physique peut se comporter
en autant d’acteurs différents que le nombre de rôles qu’elle joue vis a
vis du système).

Dr. Ouarda ZEDADRA GL 6


Acteur [Représentation graphique]

o Symboliquement, un acteur se représente par :


 un ‘bonhomme’ et être identifie par son nom.
 Une classe stéréotypée «Acteur »

Classeur
<<Acteur>> stéréotypé

Client

Nom de
l’acteur

Dr. Ouarda ZEDADRA GL 7


Acteur [Exemple]
o Question: Quels sont les acteurs d’un Distributeur Automatique d’Argent
(DAA).
o Clarifications:
1. Penser aux acteurs comme des rôles et non pas des personnes.
2. Un acteur peut être une personne physique, machine, système, organisation…
3. Ne jamais penser a un acteur comme l’utilisateur final du système seulement, mais
plutôt des entités qui peuvent êtres sollicitées pour fournir des informations au
système, ou compléter la réalisation d’une fonction…
4. Tracer les frontières du système, et se positionner en dehors du système et imaginer
toute les entités qui peuvent interagir avec le système .

DAA

client Ici les cas Responsable


d’utilisation Argent

c’est-à-dire les
fonctions du
Agent
maintenance système Banque
« système»

Dr. Ouarda ZEDADRA GL 8


Cas d’utilisation [définition]

o Modélise un service rendu par le système;


o Ensemble d’actions réalisées par le système en réponse a un
besoin d’un acteur;
o cas d’utilisation correspond donc à une fonction du système,
selon le point de vue d’un de ses acteurs ;
o Toute manière d’utiliser le système;
o Les cases d’utilisation capturent les différents buts que les
différents acteurs ont pour l’utilisation du système;
o Entre un utilisateur et le système, un cas d’utilisation décrit
les interactions liées à un objectif fonctionnel de l’utilisateur

Dr. Ouarda ZEDADRA GL 9


Cas d’utilisation [représentation
graphique]

o Symboliquement, un cas d’utilisation se représente par :


 un ‘ellipse’ et être identifie par son nom.
 Une classe stéréotypée «cas d’utilisation »

Cas
<<use case>>
d’utilisation
Nom du cas

Dr. Ouarda ZEDADRA GL 10


Cas d’utilisation [Exemple]
o Question: Quels sont les cas d’utilisation d’un Distributeur Automatique d’Argent
(DAA). Autrement dit, pour quoi un utilisateur se rapproche d’un DAA?
o Clarifications:
1. Tracer les frontières du système;
2. Se placer du point de vue de chaque acteur et déterminer comment et surtout pourquoi
il se sert (se rapprocher) du système.
3. Nommez les cas d’utilisation avec un verbe à l’infinitif suivi d’un complément en vous
plaçant du point de vue de l’acteur et non pas de celui du système

DAA
Retirer argent

client Consulter Banque


compte « système»

Remplir la
machine avec
l’argent
Maintenir la Responsable
Agent
Argent
maintenance machine

Dr. Ouarda ZEDADRA GL 11


Cas d’utilisation [Description]
• Chaque cas d’utilisation doit être décrit (sous forme textuelle ou sous
forme spécification précise comme un diagramme de séquence!!) afin de
bien identifier les traitements a réalisé par le système;
• À un cas d’utilisation correspond plusieurs scénarios;
• Comme une classe qui détient les aspects communs de ses instances, un
cas d’utilisation peut être considéré comme une abstraction de plusieurs
chemins d’ exécution (scénarios d’ exécution) d’une utilisation du
système;
• Un scénario est une instance de cas d’utilisation, un flot d'évènement.
– Un scenario suivra un chemin particulier dans la description d’un cas d’utilisation;
– Il est impossible de décrire un cas d’utilisation en écrivant tous les scenarios, l’
exhaustivité est difficile a atteindre, mais il faut répertorier les scenarios les plus
représentatifs afin de gérer les risques;

Le diagramme de cas d’utilisation UML sert comme une table visuelle


des contenus textuelles des cases d’utilisations!!!

Dr. Ouarda ZEDADRA GL 12


Cas d’utilisation [Description textuelle des cases
d’utilisation]
• Décrit les étapes de l’ interaction entre les acteurs et le
système, commençant par l’acteur principal (insertion de la
carte de crédit par le client par exemple);

• Scenarios nominaux (de success): C’est ce qui se produit


dans les conditions idéales. Se déroule sans incident et qui
aboutit au résultat souhaitée (retrait avec succès);
• Les scenarios alternatifs: les autres scenarios, secondaires ou
correspondant a la résolution d’anomalies:
– Exceptions: cas d’échec (demande plus d’agent que dans son compte!!)
– Extensions: options qui s’ inscrivent avec le scenario de succès
(impression de nouvelle avoir lors de retrait);

Dr. Ouarda ZEDADRA GL 13


Cas d’utilisation [Exemples scenarios]

a) Exemple : Cas d’utilisation Retirer de l’argent


• Le client de la banque s’identifie,
• Le système lui propose les différents comptes sur lesquels il peut effectuer un retrait,
• Le client choisit le compte à débiter et spécifie le montant du retrait,
• Le système vérifie si le retrait est autorisé, si oui il déduit le montant du compte et délivre
l’argent, sinon il renvoie un message de rejet de l’opération

b) Scénario du
c) scénario du cas
cas d’utilisation
d’utilisation :: Retirer
Retirer de
de l’argent
l’argent ;; retrait
retrait non
autorisé  Scenario
autorisé nominal
 Scenario
d’exception
Acteur déclencheur : Mr. ZEDADRA
Acteur déclencheur
Ce scénario commence : Mr.
parZEDADRA
:
Ce
• scénario commence
Mr. ZEDADRA par :
s’identifie,
• Mr. ZEDADRA
Le système lui s’identifie,
propose les différents comptes sur lesquels il peut effectuer un retrait,
• LeMr.système
ZEDADRAlui choisit
propose lescompte
son différents comptes
chèque sur lesquels
et demande il peut effectuer un retrait,
80000DA,
• Mr./*Le système
ZEDADRA vérifie
choisit son que le retrait
compte chèqueest
et autorisé*/
demande 200000DA,
/*Le système
• Le système délivrevérifie que le retrait est autorisé*/
les billets.
La somme
• Mr. n’existe
ZEDADRA prendpas dans le compte, le système renvoie un message d’erreur.
l’argent.

Dr. Ouarda ZEDADRA GL 14


Exemple d’un diagramme de cas d’utilisation modélisant
l’accès à une banque

• Le diagramme des cas d’utilisation montre les cas d’utilisation représentés sous
la forme d’ellipses et les acteurs sous la forme de personnages. Il indique
également les relations de communication qui les relient.

Frontière du banque Nom du système


système
Retirer Cas d’utilisation
argent

Effectuer
Acteur
virement

Client
Consulter
comptes
Association

Dr. Ouarda ZEDADRA GL 15


Relations Acteur / cas d’utilisation
[définitions]
 L’interaction entre un acteur et un cas d’utilisation se représente comme une association.
Elle forme un chemin de communication entre acteur et cas d’utilisation;
 se représente par un trait continu;
 Cette relation supporte différents modèles de communication, par exemple:
 Les services que le système doit fournir à chacun des acteurs du cas d’utilisation;
 Les informations du système qu’un acteur peut introduire, consulter ou modifier;
 Les changements intervenant dans l’environnement dont un acteur informe le système;
 Les changements intervenant au sein du système dont ce dernier informe un acteur;
 Propriétés:
o Multiplicité: nombre d’interaction de l’acteur avec un cas
 plusieurs fois: *
 Exactement n fois
 Entre n et m fois: n…m
o Acteur principal & secondaire
o Cas d’utilisation interne: n’est pas directement lié avec un acteur;

Dr. Ouarda ZEDADRA GL 16


Relations Acteur /cas d’utilisation [Acteur
principal ou secondaire]
o Acteur principal & secondaire
 Acteur principal: le cas rends service à cet acteur. C’est cet acteur qui déclenche
le cas;
 Acteur secondaire: produit des services complémentaires aux cas d’utilisation;
 Il existe un ou plusieurs acteur principaux;
• Exemple: diagramme de cas d’utilisation représentant un système de partage de
fichier.

Dr. Ouarda ZEDADRA GL 17


Relations Acteur /cas d’utilisation [cas interne]

• Cas d’utilisation interne: n’est pas relié directement avec un


acteur;

Dr. Ouarda ZEDADRA GL 18


Relations entre cas d’utilisation
[définitions]

• Afin d’optimiser la formalisation des besoins en ayant recours


notamment a la réutilisation de cas d’utilisation, trois
relations peuvent êtres décrites entre cas d’utilisation:
1. Relation d’inclusion (include);
2. Relation d’extension (extend);
3. Relation de généralisation.

Dr. Ouarda ZEDADRA GL 19


Relations entre cas d’utilisation [inclusion]
• Une relation d’inclusion d’un cas A par rapport a un cas d’utilisation B signifie qu’une instance
de A contient le comportement décrit par B;
• Cette relation sert à enrichir un cas d’utilisation par un autre cas d’utilisation. Cet
enrichissement est réalisé par une inclusion impérative;
• Lorsque une séquence d’ évènements dans la cas inclut représentent clairement une étape du
cas invoqué on doit utilisé une relation de type include;
• Le cas d’utilisation inclus existe uniquement dans ce but. En effet, il ne répond pas à un objectif
d’un acteur primaire. Un tel cas est une sous-fonction;
• L’inclusion sert à partager une fonctionnalité commune entre plusieurs cas d’utilisation. Elle
peut également être employée pour structurer un cas d’utilisation en décrivant ses sous-
fonctions;
• Elle est représentée par une flèche pointillée munie du stéréotype «include»
Retirer
Cas A Argent
<< include >>
<< include
Cas C
Cas B >>
<< include >>
S’authentifier
Les cas A et C ont recours au cas B
Dr. Ouarda ZEDADRA GL 20
Relations entre cas d’utilisation [Raffinement ou
extension]
o Une relation d’extension « extend » indique une relation optionnelle. Elle étend le
comportement du cas d’utilisation de base (A), en ajoutant une nouvelle séquence d’étapes
(ceux dans le cas B) aux étapes qui existent déjà dans la cas de base;
o L’extension se fait dans le cas d’utilisation de base, en des points précis et prévus lors de la
conception, appelés points d’extension;
o L’application de chaque extension est décidée lors du déroulement d’un scénario. Par
conséquent, le cas d’utilisation de base peut être employé sans être étendu;
o Elle permet aussi de structurer un cas d’utilisation ou à partager un cas d’utilisation de sous-
fonction;
o Représentée par une flèche pointillée munie du stéréotype «extend»
Retirer
Argent
Cas A
<< extend >>
<< extend >>
Cas B
Vérifier solde

Dr. Ouarda ZEDADRA GL 21


Relations entre cas d’utilisation [généralisation/
spécialisation]
o Il est possible de spécialiser un cas d’utilisation en un autre. On obtient ainsi un
sous-cas d’utilisation;
o Comme pour les classes, le sous-cas hérite du comportement du sur-cas
d’utilisation. Un sous-cas d’utilisation hérite également des relations de
communication, d’inclusion et d’extension du sur-cas;
o Souvent, le sur-cas d’utilisation est abstrait, c’est-à-dire qu’il correspond à un
comportement partiel complété dans les sous-cas d’utilisation;
o Représentée par un triangle comme celui de l’héritage;
Retirer
argent Consulter
compte

Retirer des Retirer Consulter


Consulter
des euros depuis
dinars depuis guichet
internet
de poste

Dr. Ouarda ZEDADRA GL 22


Relations entre acteurs [généralisation/
spécialisation]
 Acteur  Acteur =généralisation
 A peut être substitué par B;
 Tous les cas accessibles à A le sont aussi à B; mais pas le
contraire

Exemple:
Système de vente par correspondance
Passer
Préposé aux commandes commande

Suivre une
commande

Gérer le stock
Directeur de vente

Dr. Ouarda ZEDADRA GL 23


Comment identifier les acteurs ? [Astuces]

• Utilisateur ou acteur ;
• Les acteurs d’un système sont les entités externes à ce système qui
interagissent avec lui;
• Ces acteurs permettent de cerner l’interface que le système va devoir offrir
à son environnement;
• Utilisateur avec le sens de la personne physique qui va appuyer sur un
bouton) d’un système.
• Les acteurs inclus les utilisateurs humains mais aussi les autres systèmes
informatiques ou hardware qui vont communiquer avec le système.
• Un acteur englobe tout une classe d’utilisateur. Ainsi, plusieurs utilisateurs
peuvent avoir le même rôle, et donc correspondre à un même acteur, et une
même personne physique peut jouer des rôles différents vis-à-vis du
système, et donc correspondre à plusieurs acteurs ;

Dr. Ouarda ZEDADRA GL 24


Comment identifier les acteurs ? [Astuces]
• Chaque acteur doit être nommé. Ce nom doit refléter son rôle car un acteur
représente un ensemble cohérent de rôles joués vis-à-vis du système;
• Pour trouver les acteurs d’un système, il faut identifier quels sont les
différents rôles que vont devoir jouer ses utilisateurs (ex : responsable
clientèle, responsable d’agence, administrateur, …). Il faut également
s’intéresser aux autres systèmes avec lesquels le système va devoir
communiquer comme :
– Les périphériques manipulés par le système (imprimantes, …) ;
– Des logiciels déjà disponibles à intégrer dans le projet ;
– Des systèmes informatiques externes au système mais qui interagissent
avec lui, etc.
• Pour faciliter la recherche des acteurs, on peut imaginer les frontières du
système. Tout ce qui est à l’extérieur et qui interagit avec le système est un
acteur, tout ce qui est à l’intérieur est une fonctionnalité à réaliser.
• Vérifiez que les acteurs communiquent bien directement avec le système
par émission ou réception de messages.
Dr. Ouarda ZEDADRA GL 25
Comment recenser les cas d’utilisation ?
[Astuces]
• L’ensemble des cas d’utilisation doit décrire exhaustivement les exigences
fonctionnelles du système;
• Chaque cas d’utilisation correspond donc à une fonction du système, selon le point
de vue d’un de ses acteurs ;
• Aussi, pour identifier les cas d’utilisation, il faut se placer du point de vue de chaque
acteur et déterminer comment et surtout pourquoi il se sert du système ;
• Il faut éviter les redondances et limiter le nombre de cas en se situant à un bon
niveau d’abstraction. Trouver le bon niveau de détail pour les cas d’utilisation
est un problème difficile qui nécessite de l’expérience ;
• Nommez les cas d’utilisation avec un verbe à l’infinitif suivi d’un complément en
vous plaçant du point de vue de l’acteur et non pas de celui du système;
• Dans tous les cas, il faut bien garder à l’esprit qu’il n’y a pas de notion temporelle
dans un diagramme de cas d’utilisation;
• Les cas d’utilisation offrent une technique de représentation qui convient au
dialogue avec l’utilisateur car son formalisme reste proche du langage naturel.

Dr. Ouarda ZEDADRA GL 26


Conclusions/ Remarques
o Les cas ne modélisent pas non plus les séquences d’action. L’ordre n’est pas
représenté dans les diagrammes cas d’utilisation (mais il y aura d’autres
diagrammes complémentaires pour le faire).
o Les relations de type include ou extend expriment des inclusions et pas des
relations temporelles.
o Les diagrammes de séquence associés aux cas d’utilisation nous aide à découvrir
les objets du système;
o En outre, un diagramme de cas ne doit pas représenter la moindre des
actions.
o Mais chaque cas d’utilisation doit être décrit textuellement ou par
diagramme de séquence pour décrire ses actions;
o L’association du diagramme des cas avec les diagrammes de séquence peut
apporter une notion temporelle au diagramme de cas.

Dr. Ouarda ZEDADRA GL 27


Diagramme des cas d’utilisation [Agence de
voyage]

• Une agence de voyage organise des voyages. Le client doit


disposer d’un titre de transport (billet d’avion, train,…), d’une
chambre a son arrive a l’hôtel. Il doit se rendre à l’hôtel par un
taxi. Il peut demander une facture détaillée a tout moment.

Modéliser le fonctionnement de cette agence par un diagramme de


cas d’utilisation.

Dr. Ouarda ZEDADRA GL 28


Diagramme des cas d’utilisation [Agence de
voyage]

Dr. Ouarda ZEDADRA GL 29


Diagramme des cas d’utilisation [le club équestre]

Un club équestre offre les prestations d’hébergement des chevaux, de cours


d’équitation, de balades. Seuls les adhérents ont accès aux cours et aux
hébergements. Les autres clients ont la possibilité de faire des balades et
d’adhérer.
Quels sont les acteurs qui interagissent avec ces services?
Construire le diagramme des cas d’utilisation

Dr. Ouarda ZEDADRA GL 30


Diagramme des cas d’utilisation [le club équestre]
Quels sont les acteurs qui interagissent avec ces services?
Le moniteur, le palefrenier, l’animateur et le client. L’ adhèrent et le
client sont des acteurs primaires. Le moniteur, le palefrenier et l’animateur
sont des acteurs secondaires.

Dr. Ouarda ZEDADRA GL 31


Diagramme des cas d’utilisation [L’hippodrome]

Un hippodrome offre à ses clients la possibilité de suivre les


courses et de parier.
Quels sont les acteurs qui interagissent avec ces services?
Construire le diagramme des cas d’utilisation

Dr. Ouarda ZEDADRA GL 32


Diagramme des cas d’utilisation [L’hippodrome]

Quels sont les acteurs qui interagissent avec ces services?


Le spectateur, le parieur et le client qui est a la fois spectateur et
parieur.

Dr. Ouarda ZEDADRA GL 33


Merci !!

Commentaires et questions

Dr. Ouarda ZEDADRA GL 34