Institut Supérieur des Etudes Technologiques

de Mahdia

Département: Technologies de l’informatique

Conception Orientée Objet

(UML)
Diagramme de cas d’utilisation

Chebbi Ikram Mail: Chebbi_ikram@yahoo.fr

MW5.1 AU: 2020-2021

 Introduction
La phase d’analyse des besoins nécessite :
de comprendre les besoins à couvrir par le système,
d’exprimer et de formaliser ces besoins.

il faut savoir précisément à QUOI devra servir le système

Moyens pour représenter les besoins en UML :

Diagramme de cas d’utilisation
+ d'autres diagrammes.

2
 Introduction

L’utilisateur exprime des besoins envers son système.

Le système offre des fonctionnalités à l’utilisateur.

Comportement = {Actions} + {Réactions}

3
 Introduction
• Un DCU sert de base à la traçabilité des exigences d'un système dans
un processus de développement intégrant UML.

• Un DCU se limite aux préoccupations "réelles" des utilisateurs :

– ne présente pas de solutions d'implémentation;
– ne forme pas un inventaire fonctionnel du système.

• Un besoin:
– définit le contour du système à modéliser: précise le but à atteindre;
– permet d'identifier les fonctionnalités principales (critiques) du système.

4
 Introduction
Un DCU:
Recentre l’expression des besoins sur les utilisateurs,

Facilite la structuration des besoins des utilisateurs,

Facilite l’expression des besoins des utilisateurs et leur communication

avec les experts et les informaticiens,

Ramène les informaticiens aux préoccupations premières des

utilisateurs,

Permet aux utilisateurs de structurer et d’articuler leurs désirs.

5
 Introduction
Commencer par établir le DCU permet de:
mener un développement orienté utilisateur;
de découper le système global en grandes tâches qui pourront être
réparties entre les équipes de développement.

Une fois obtenu, le diagramme des cas d’utilisation est un support

privilégié de communication entre les équipes, ainsi qu’avec les clients.

6
 Concepts: Acteur
Définition 1:

Représente un rôle joué par une entité externe (utilisateur humain,

dispositif matériel, ou autre système) qui interagit directement avec le
système étudié.

Définition 2:

Une entité externe agissant sur le système qui peut :

Échanger de l’information avec ce système;
Consulter ou modifier l'état du système.

7
 Concepts: Acteur
Les acteurs sont déterminés en examinant les :
Utilisateurs directs du système;
Responsables de l’exploitation et/ou de la maintenance;
Autres systèmes interagissant avec le système en question.

Représentés sous forme de petits personnages ou sous forme de rectangle avec

le stéréotype <<acteur>>.

8
 Concepts: Acteur
Un acteur peut être :
Principal:
Utilise les fonctions principales du système;
Secondaire:
Effectue des tâches administratives ou de maintenance;
Matériel externe:
Les dispositifs matériels :
Autres que les machines où s’exécute l’application;
Faisant partie du domaine de l’application;
Nécessaires au fonctionnement du système.
Les autres systèmes avec qui le système doit interagir.

9
 Concepts: Acteur
Un acteur peut être :
Principal:
Utilise les fonctions principales du système;
Secondaire:
Effectue des tâches administratives ou de maintenance;
Matériel externe:
Les dispositifs matériels :
Autres que les machines où s’exécute l’application;
Faisant partie du domaine de l’application;
Nécessaires au fonctionnement du système.
Les autres systèmes avec qui le système doit interagir.

1
0
 Concepts: Cas d’utilisation
Définition 1:

Un cas d’utilisation modélise une interaction entre le système

informatique à développer et un utilisateur ou acteur interagissant avec

le système.

Définition 2:

Un cas d’utilisation décrit un ensemble d’actions réalisées par le système

et produit un résultat observable pour un acteur.

Constations:

Modélise: pas de détails (pas d’algorithme des interactions);

Les actions représentées par les CU sont automatisées et non manuelles. 1
1
 Concepts: Cas d’utilisation

Un cas d’utilisation se représente par une ellipse contenant le nom du cas

(un verbe à l’infinitif), et optionnellement, au-dessus du nom, un stéréotype.

Exemple:

1
2
Relation entre acteur et cas d’utilisation:
relation d’association
Une relation d’association est:
un chemin de communication entre un acteur et un cas d’utilisation et est représenté
par un trait continu.
Un acteur déclenche un cas d’utilisation.
L’acteur peut envoyer et recevoir des messages.
L’association entre acteur cas d’utilisation peut être orientée ou non.
Un acteur peut utiliser plusieurs fois le même cas d'utilisation.

1
3
Relations entre cas d’utilisation:

Il existe principalement deux types de relations :

les dépendances stéréotypées, qui sont explicitées par un stéréotype (les plus
utilisés sont l’inclusion et l’extension),
et la généralisation/spécialisation.
Une dépendance se représente par une flèche avec un trait pointillé.

Le symbole utilisé pour la généralisation est une flèche avec un trait plein dont la
pointe est un triangle fermé désignant le cas le plus général.

1
4
Relations entre cas d’utilisation: inclusion

Un cas A inclut un cas B si le comportement décrit par le cas A inclut le

comportement du cas B: le cas A dépend de B.

Lorsque A est sollicité, B l’est obligatoirement, comme une partie de A.

Cette dépendance est symbolisée par le stéréotype «include».

1
5
Relations entre cas d’utilisation: inclusion

Les inclusions permettent essentiellement de factoriser une partie de la description

d’un cas d’utilisation, qui serait commun à d’autres cas d’utilisation.

Exemple: Les relations entre cas permettent la réutilisabilité du cas s'authentifier : il

sera inutile de développer plusieurs fois un module d'authentification.

1
6
Relations entre cas d’utilisation: inclusion

Les inclusions permettent également de décomposer un cas complexe en sous cas

plus simples.

Cependant, il ne faut surtout pas abuser de ce type de décomposition : il faut éviter

de réaliser du découpage fonctionnel d’un cas d’utilisation en plusieurs sous-cas
d’utilisation pour ne pas retomber dans le travers de la décomposition fonctionnelle.

Les CU ne s’enchaînent pas, car il n’y a aucune représentation temporelle dans un

DCU.

1
7
Relations entre cas d’utilisation: extension

Un cas A étend un cas B lorsque le cas A peut être appelé au cours de l’exécution du
cas B.

Exécuter B peut éventuellement entraîner l’exécution de A : contrairement à l’inclusion,

l’extension est optionnelle.

Cette dépendance est symbolisée par le stéréotype « Extend »

1
8
Relations entre cas d’utilisation: généralisation

Un cas A est une généralisation d’un cas B si B est un cas particulier de A.

Cette relation de généralisation/spécialisation se traduit par le concept d’héritage
dans les langages orientés objet.

Un virement est un cas particulier de paiement.

Un virement est une sorte de paiement.

1
9
Relations entre cas d’utilisation: exemple

2
0
Relations entre acteurs

Une seule relation possible : la généralisation

2
1
Identification des acteurs

Les principaux acteurs sont les utilisateurs du système.

Un acteur correspond à un rôle, pas à une personne physique.

Une même personne physique peut être représentée par plusieurs acteurs si elle a
plusieurs rôles.
Si plusieurs personnes jouent le même rôle vis-à-vis du système, elles seront
représentées par un seul acteur.

En plus des utilisateurs, les acteurs peuvent être :

Des 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 se fonde sur les frontières
du système

2
2
Acteurs principaux et secondaires

L'acteur est dit principal pour un cas d'utilisation lorsque l'acteur est à l'initiative
des échanges nécessaires pour réaliser le cas d'utilisation.
Les acteurs secondaires sont sollicités par le système alors que le plus souvent, les
acteurs principaux ont l'initiative des interactions.
Le plus souvent, les acteurs secondaires sont d'autres systèmes informatiques
avec lesquels le système développé est inter-connecté.

2
3
Recenser les cas d'utilisation

Il n'y a pas une manière mécanique et totalement objective de repérer les cas
d'utilisation.
Il faut se placer du point de vue de chaque acteur et déterminer comment il se sert du
système, dans quels cas il l'utilise, et à quelles fonctionnalités il doit avoir accès.
Il faut éviter les redondances et limiter le nombre de cas en se situant au bon niveau
d'abstraction (par exemple, ne pas réduire un cas à une seule action).
Il ne faut pas faire apparaître les détails des cas d'utilisation, mais il faut rester au
niveau des grandes fonctions du système.
Trouver le bon niveau de détail pour les cas d'utilisation est un problème
diffcile qui nécessite de l'expérience.

2
4
Description des cas d'utilisation

Le diagramme de cas d'utilisation décrit les grandes fonctions d'un système du point de
vue des acteurs, mais n'expose pas de façon détaillée le dialogue entre les acteurs et les
cas d'utilisation.
Un simple nom est tout à fait insuffisant pour décrire un cas d'utilisation.
Chaque cas d'utilisation doit être documenté pour qu'il n'y ait aucune ambiguïté
concernant son déroulement et ce qu'il recouvre précisément.

2
5
Cas d’utilisation et scénarios

La présentation graphique des CU:

Donne une vue d’ensemble (sans détails) sur les différentes fonctionnalités du
système.
Peut être affinée par les scénarios.

Un CU est une collection de scénarios de succès ou d’échec qui décrit la façon dont
un acteur particulier utilise un système pour atteindre un objectif..

Un scénario est une suite spécifique d’interactions entre les acteurs et le système.
C’est une instance du CU, un chemin particulier dans sa combinatoire.

2
6
Cas d’utilisation et scénarios

Chaque scénario est composé d’étapes qui peuvent être de trois sortes:
Un message d’un acteur au système;
Une validation ou un changement de l’état de système;
Un message du système vers un acteur.

Dans la description détaillée d’un CU, on trouve:

Un scénario nominal: celui qui permet de satisfaire les objectifs des acteurs par le
chemin le plus directe de succès.
Des extensions qui regroupent tous les autres scénarios: de succès(fin normale)
ou d’échec (exception)

Pour détailler un CU, on recense de façon textuelle toutes les interactions entre les
acteurs et le système.

Il n’existe pas de norme pour la description textuelle des cas d’utilisation.

2
7
Cas d’utilisation et scénarios

Format proposé dans la littérature:

Nom du cas d’utilisation:

Acteurs principaux:
Acteurs secondaires:
Objectifs:
Préconditions:
Postconditions:
Scénario nominal:
Extensions:
Exigences supplémentaires:

2
8
Cas d’utilisation et scénarios

Préconditions: définissent les conditions qui doivent être satisfaites pour que le CU
puisse démarrer.

Postconditions: définissent ce qui doit être vrai lorsque le CU se termine avec succès,
qu’il s’agisse d’un scénario nominal ou d’un scénario alternatif.

Contraintes ou exigences supplémentaires: définissent les exigences non

fonctionnelles et les contraintes de conception telles que la performance, sécurité,
ergonomie,…

2
9
Exemple de cas d’utilisation

Nom CU: Effectuer une commande

Acteur principal: Internaute

Objectifs: A tout moment l’internaute doit pouvoir accéder au formulaire du bon de

commande, dans lequel il peut saisir ses coordonnées et les informations nécessaires
au payement des livraisons.

Préconditions: le panier de l’internaute n’est pas vide et il a pu accéder au formulaire de

commande.

Postconditions: une commande a été enregistrée et transmise au service Commandes.

3
0
Exemple de cas d’utilisation

Scénario nominal:
1. L’internaute saisit l’ensemble des informations nécessaires au paiement et la
livraison, à savoir:
Son @ e-mail avec un mot de passe pour pouvoir suivre la commande;
Les coordonnées de l’@ de facturation (nom, prénom, @ postale complète,
tel);
Les coordonnées de l’@ de livraison si elle est différente de celle de
facturation (nom, prénom, @ postale complète, tel);
Un numéro de carte de crédit avec son type et sa date de validité.
2. Le système affiche un récapitulatif de la commande;
3. L’internaute valide sa commande;
4. Le système envoie la commande validée au service Commande;
5. Le système confirme la prise de la commande à l’internaute.

3
1
Exemple de cas d’utilisation

Extensions:
1a: l’internaute est déjà un client:
1. L’internaute s’identifie avec son e-mail et son mot de passe;
2. Le système affiche les données sauvegardées concernant l’@ de facturation
et le CU continue à l’étape 2 du scénario nominal;

2a: le système ne connait pas le client: le système avertit l’internaute que

son e-mail et son mot de passe ne correspondent pas à ceux d’un client
connu. Il lui propose de s’identifier de nouveau ( retour à 1.a.1).

3a: L’internaute annule sa commande: le système revient sur l’affichage du panier et

le CU est terminé.

Exigences supplémentaires:
Pour garantir la sécurité et la confidentialité des échanges, il est impératif que
l’envoi de données se fasse de manière cryptée.
Les cartes bancaires acceptées sont les Visa, American Express.
3
2
Conclusion

Les cas d’utilisation :

Sont de bons moyens pour modéliser les besoins des utilisateurs par les utilisateurs.
Les avantages :
Un formalisme simple :
Les concepts proposés sont faciles à comprendre et à utiliser.
Les modélisations résultats (UC):
Faciles à comprendre, à lire et à interpréter.
Un bon moyen de communication : client/concepteur et concepteur/concepteur
Les limitations :
Subjectifs, dépendant de l’utilisateur :
Peuvent être peu précis, ne reflétant pas les besoins majeurs de l’utilisateur ou
interprétés différemment.
Pas formels : pas de vérification automatique possible ni de génération des
autres diagrammes, …

3
3
Et maintenant: A vous de jouer

Organisation d’une conférence internationale

Considérons les Règles de gestion suivantes :

Le comité d’organisation adresse un appel à communication aux auteurs intéressés
par les thèmes de la conférence.

Un auteur soumet un papier décrivant ses travaux dans l’un des thèmes de la
conférence.

Un comité de programme est responsable de l’affectation des papiers reçus à des

lecteurs spécialisés pour évaluation.

Chaque lecteur évalue les papiers attribués par le comité de programme.

3
4
A retenir

35