Diagramme de Cas d’utilisation

Motivation Pourquoi les cas d’utilisation :

•Un système est conçu pour les utilisateurs :

• ils savent ce que le système doit faire mais pas comment le faire ; • ils connaissent l’aspect fonctionnel du système.

Le système doit donc être bâti à partir des descriptions des utilisateurs.

Diagramme des cas d’utilisation

Un diagramme de cas d’utilisation est modélisé par :

 des acteurs qui utilisent le système ;  les ‘services’ offerts par le système.

• Intérêt des cas d’utilisation :

 les use cases permettent de délimiter le système (les acteurs sont à

l’extérieur du système) ;

 ils permettent de lever les ambiguïtés du cahier des charges à l’aide d’un

formalisme graphique ;

 les use cases peuvent servir à concevoir les tests puisqu’ils représentent

les utilisations nominales du système.

 Initie le travail d’équipe

L’utilisateur et le système

Use Case 1

Use Case 2

Services

Utilisateur

Use Case 3

Système

Diagramme de cas d’utilisation répond aux questions suivantes : ◦ Quelles sont les tâches principales réalisées par les acteurs (entités matériels ou

logiciels externe au logiciel qui entrent en interaction) ?

◦ Les informations manipulées par les acteurs ? ◦ Les informations manipulées par le logiciel ?

Le diagramme contient les acteurs, les cas d’utilisation (services) et les applications.

Diagramme de cas d’utilisation

Un diagramme de cas d’utilisation : ◦ décrit

◦ le système

◦ les acteurs

◦ les cas d’utilisation

◦ contient

◦ des descriptions textuelles

Principaux concepts des diagrammes de cas d’utilisation

Acteurs

Système

Cas d’utilisation

Relations (entre cas d’utilisation, entre acteurs, entre acteurs et cas d’utilisation)

Le système

Le système est un ensemble de cas d’utilisation

Le système ne comprend pas les acteurs.

Nom du système

Le système

Le système est ◦ modélisé par un ensemble de cas d’utilisation ◦ vu comme une boîte noire

Le système contient : ◦ les cas d’utilisation, ◦ mais pas les acteurs.

Un modèle de cas d’utilisation permet de définir : ◦ les fonctions essentielles du système, ◦ les limites du système, ◦ le système par rapport à son environnement, ◦ délimiter le cadre du projet !

Acteurs

Un Acteur = élément externe qui interagit avec le système (prend des décisions, des initiatives. Il est "actif".)

rôle qu’un "utilisateur" joue par rapport au système Ex. : un client, un guichetier, un responsable maintenance, …

◦

Acteurs

Un acteur est représenté par: ◦ un petit bonhomme (stick man) avec son nom dessous ou ◦ par un rectangle contenant le mot-clé << actor>> avec son nom dessous ou ◦ Par un mélange de ces 2 représentations

<<actor>> Nom de l’acteur

Nom de l’acteur

Nom acteur

acteur humain acteur non humain

Pour les identifier : ◦ Quelles sont les entités externes au système qui interagissent directement avec le système

Utilité des acteurs La définition d’acteurs permet ◦ d’identifier les cas d’utilisation

Ex. : que peut faire un guichetier ? un client ? le directeur ?

◦ de voir le système de différents points de vues ◦ de déterminer des droits d’accès par type d’acteur ◦ de fixer des ordres de priorité entre acteurs ◦ ...

Acteurs vs. utilisateurs Ne pas confondre la notion d'Acteur et de personne utilisant le système: ◦ Une même personne physique peut jouer le rôle de plusieurs acteurs Ex. : Maurice est un Chef d’agence et est aussi un client de la banque.

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

Ex. : Paul et Pierre sont deux clients

Un acteur n’est pas forcément un être humain ex: un distributeur de billet peut être vu comme un acteur

Le recensement des acteurs

Comment ?

 Par un dialogue avec le client et les utilisateurs ;  en repérant les frontières du système.

Qui sont-ils ?

 Des utilisateurs humains : utilisateurs du logiciel à travers son interface graphique,

par exemple;

 des périphériques manipulés par le système (imprimantes, capteurs, … ) ;  des logiciels déjà disponibles à intégrer dans le projet : disponibles qui

communiquent avec le système grâce à une interface logicielle (API, ODBC, …);

 attention à ne pas oublier les acteurs qui administrent le système ;  un même utilisateur peut avoir plusieurs rôles et être plusieurs acteurs :

Acteurs

SecrétaireEtudiantSystème de Gestion Scolaire<<acteur>>Imprimante<<acteur>>Site Web de l'établissementDifférents types d’acteurs

Utilisateurs principaux

ex: client, guichetier

Utilisateurs secondaires

ex: contrôleur, directeur, ingénieur système, administrateur...

Périphériques externes

ex: un capteur, une horloge externe, …

Systèmes externes

ex: systèmes bancaires

Exemple: une bibliothèque

Système bibliothèque

Chercheur

Bibliotécaire

Département

Exemple

Client

Exemple

Client

RetirerDeLArgentAu Distributeur

Banque Centrale

ConsulterSonCompte

RetirerLes CartesAvalées

Transporteur DeBillets

Ajouter DesBillets

Assurer LaMaintenance

Technicien

DistributeurDeBillet

Acteurs

Mais du point de vue système on distingue deux types :

Acteurs principaux

Acteurs secondaires

Acteurs principaux et secondaires

Acteur principal d’un CU ◦ Celui pour qui le CU produit un résultat observable ◦ A gauche des CU ◦ Rôle indiqué éventuellement sur l’association côté acteur : <<principal>>

(valeur par défaut)

Acteur secondaire d’un CU ◦ Celui pour qui le CU ne produit pas un résultat observable par l’utilisateur ◦ Souvent sollicités pour des informations complémentaires ◦ Peuvent uniquement consulter ou informer le système (pas d’objectif à part

entière de la part de l’acteur secondaire)

◦ A droite des CU ◦ Rôle indiqué éventuellement sur l’association côté acteur : <<secondaire>> ◦ Ex. : système d’authentification appelé par le distributeur de billets

Cas d’utilisation (CU)

Cas d’utilisation (CU) ◦ une manière d’utiliser le système ◦ une suite d’interactions entre un acteur et le système

Correspond à une fonction du système visible par l’acteur

Doit être utile en soi

Permet à un acteur d’atteindre un but

Regroupe un ensemble de scénarii correspondant à un même but

Cas d’utilisation: définition

“Description d’un ensemble de séquences d’actions, comportant éventuellement des variantes, que le système exécute pour produire un résultat tangible et qui a de la valeur pour l’utilisateur.”

Payer cotisation membre

Consulter catalogue

Enregistrer nouvel utlisateur

Emprunter un livre

Réserver un livre

Cas d'utilisation

Les cas d’utilisations

Permettent de modéliser les attentes (besoins) des utilisateurs

Représentent les fonctionnalités du système

Suite d’événements, initiée par des acteurs, qui correspond à une utilisation particulière du système

L’image d’une fonctionnalité du système, déclenchée en réponse à la stimulation d’un acteur externe.

Cas d'utilisation

Un cas d'utilisation est représenté par une ellipse en trait plein, contenant son nom.

Nom Cas UtilisationRelations entre éléments de base

Relations acteurs <-> cas d'utilisation ?

Relations acteurs <-> acteurs ?

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

Relation acteur - cas d'utilisation Point de vue besoin: Représente la possibilité d'atteindre un but

Point de vue système: Représente un canal de communication

Échange de messages, potentiellement dans les deux sens

Protocole particulier concernant le cas d'utilisation considéré

Une relation de communication

Client

RetirerDeLArgent AuDistributeur

Association acteur/CU vu comme un canal de communication

Décrit le comportement du système vu de l'exterieur

Echange de messages

Client

RetirerDeLArgent AuDistributeur

Diagramme de cas d ’utilisation

Client

RetirerDeLArgentAu Distributeur

ConsulterSonCompte

RetirerLes CartesAvalées

Transporteur DeBillets

Ajouter DesBillets

Assurer LaMaintenance

Technicien

DistributeurDeBillets

Relation de communication acteur-acteur

• Communications externes

non modélisée

• UML se concentre sur la description du système et de ses interactions avec l'extérieur

Client

Guichetier

ConsulterSonCompte

RetirerDeLArgent AuDistributeur

RetirerDeLArgent ParChèque

Système Bancaire

Relation acteur - acteur : généralisation

La seule relation entre acteurs est la relation de généralisation

CréerUnCompte

Guichetier

FermerUnCompte

RetirerDeLArgent DUnCompte

AnnulerUnCompte

Guichetier EnChef

CréerUnCompte

FermerUnCompte

RetirerDeLArgent DUnCompte

AnnulerUnCompte

Guichetier

Guichetier EnChef

Relation acteur - acteur : généralisation

Un acteur peut être une spécialisation d'un autre acteur déjà défini.

Dans ce cas, on utilise la relation de généralisation/spécialisation.

Acteur généralActeur spécialiséRelations cas d'utilisation - cas d'utilisation

UML définit trois types de relations standardisées entre cas d'utilisation :

Une relation d'inclusion, formalisée par la dépendance «include»

Une relation d'extension, formalisée par la dépendance «extend»

Une relation de généralisation/spécialisation

Les relations entre cas d’utilisation

Les trois types de relations sont :

l’inclusion (<<include>>)quand le cas source comprend le cas destination ; l’extension (<<extends>>) quand le cas source ajoute optionnellement son comportement

au cas destination.

la généralisation quand le cas enfant est une spécialisation du cas parent ;

Exemple de relations entre cas d'utilisation : inclusion, extension et spécialisation

« include »

RetirerDeLArgent

« extends »

S'Identifier

« include »

Transferer DeLArgent

« extends »

RetirerDeLArgent AvecDifféré

RetirerDeLArgent

RetirerDeLArgent AuDistributeur

Relation d'inclusion

A inclut B : le cas A inclut obligatoirement le comportement définit par le cas B; permet de factoriser des fonctionnalités partagées

Le cas d'utilisation pointé par la flèche (dans notre cas B) est une sous partie de l'autre cas d'utilisation (A, dans notre exemple).

<<include>>ABRelation d'inclusion

Les cas d'utilisation "Déposer de l'argent", "Retirer de l'argent", "Effectuer des virements" et "Consulter solde" incorporent de façon explicite le cas d'utilisation "S'authentifier", à un endroit spécifié dans leurs enchaînements.

<<include>><<include>><<include>><<include>>Retirer de l'argentDéposer de l'argentEffectuer des virementsConsulter soldeS'authentifierRelation d'inclusion

Remarques

La relation include n’a pour seul objectif que de factoriser une partie de la description d’un cas d’utilisation qui serait commune à d’autres cas d’utilisation.

Le cas d’utilisation inclus dans les autres cas d’utilisation n’est pas à proprement parlé un vrai cas d’utilisation car il n’a pas d’acteur déclencheur ou receveur d’évènement. Il est juste un artifice pour faire de la réutilisation d’une portion de texte.

Relation d'extension

Le CU source (B) ajoute, sous certaines conditions, son comportement au CU destination (A)

En d’autres termes, le CU B peut être appelé au cours de l’exécution du CU A

Le comportement ajouté s’insère au niveau d’un point d’extension définit dans le CU destination

<<extend>>BAPoint d'insertionRelation d'extension

Le cas d'utilisation de destination peut fonctionner tout seul, mais il peut également être complété par un autre cas d'utilisation, sous certaines conditions.

On utilise principalement cette relation pour séparer le comportement optionnel (les variantes) du comportement obligatoire.

Relation d'extension

Exemple :

Au moment de l'authentification, il se peut que le guichet retire la carte.

<<extend>>Retenir la carteS'authentifierRelations d’inclusion VS d'extension

La relation « extend" montre une possibilité d'exécution d'interactions qui augmenteront les fonctionnalités du cas étendu, mais de façon optionnelle, non obligatoire,

La relation "include" suppose une obligation d'exécution des interactions dans le cas de base.

Relation d'héritage

Il peut également exister une relation d'héritage entre cas d'utilisation.

Cette relation exprime une relation de spécialisation/généralisation au sens classique.

Relation d'héritage : Exemple Dans un système d'agence de voyage, un acteur "Touriste" peut participer à un cas d'utilisation de base qui est "Réserver voyage", qui suppose par exemple, des interactions basiques au comptoir de l'agence. Une réservation peut être réalisée par téléphone ou par Internet.

Relation d'héritage : Exemple On voit qu'il ne s'agit pas d'une relation "extend", car la réservation par Internet n'étend pas les interactions ni les fonctionnalités du cas d'utilisation "Réserver voyage".

Les deux cas d'utilisation "Réservation voyage" et "Réserver voyage par Internet" sont liés : la réservation par Internet est un cas particulier de réservation.

De façon générale en objet, une situation de cas particulier se traduit par une relation de généralisation/spécialisation.

Relation d'héritage : Exemple

Reserver voyageRéserver voyage par téléphoneRéserver voyage par InternetRelations entre cas d’utilisation

Résumé

Les cas peuvent être structurées par des relations :

A inclut B : le cas A inclut obligatoirement le comportement définit par le cas B; permet de factoriser des fonctionnalités partagées

A étend B : le cas A est une extension optionnelle du cas B à un certain point de son exécution.

A généralise B : le cas B est un cas particulier du cas A.

Description de l'interaction

Client

RetirerDeLArgent AuDistributeur

Description du dialogue

•

via une description textuelle ou via des diagrammes de séquences "systèmes"

L’élaboration des cas d’utilisation

Les use cases peuvent être décrits sous la forme de flots d’événements de différentes façons :

Le distributeur affiche un message d’accueil demandant à un client d’introduire sa carte bancaire ; • le client introduit sa carte bancaire ; • le distributeur demande le mot de passe de la carte ; • ...

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

Exemples de scénarios

Appel téléphonique ◦ Scénario : le numéro appelé est occupé

◦ L'appelant décroche le téléphone ◦ L'appelant commence à composer le numéro ◦ L'appelant termine de composer le numéro ◦ La tonalité "occupée" commence à sonner ◦ L'appelant raccroche le téléphone

◦ Scénario : le numéro appelé n'est pas occupé

◦ L'appelant décroche le téléphone ◦ L'appelant commence à taper le numéro ◦ L'appelant termine de taper le numéro ◦ Le téléphone commence à sonner ◦ L'appelé décroche ◦ La conversation se déroule ◦ L'appelé raccroche le téléphone

L’élaboration des cas d’utilisation

Un cas d’utilisation est généralement décrit par plusieurs scénario :

Regroupe une famille de scénarios d’utilisation (cas nominal, alternatives, exceptions) Est une abstraction du dialogue système/utilisateurs Quand un acteur interagit avec le

système:

Le cas d’utilisation instancie un scénario

Retirer DeLArgent AuDistributeur

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

Description Textuelle des cas d’utilisation

Il n’existe pas de norme (UML) établie pour la description textuelle des cas d’utilisation.

Généralement, on y trouve pour chaque cas d’utilisation :

• son nom, • un bref résumé de son déroulement, • le contexte dans lequel il s’applique, • les acteurs qu’il met en jeu, • une description détaillée :

•

le déroulement nominal de toutes les interactions,

les cas nécessitant des traitements d’exception, les effets du déroulement sur l’ensemble du système,

• • • des contraintes, • etc.

Description des cas d’utilisation

Sommaire d’identification Titre : ……………….. Type : ………………… Résumé :……………………………………………………………………………… Acteurs : Date de création : Date de mise à jour :………………………………… Version : Auteur(s) :

Description des Enchaînements : Pré conditions : Scénario nominal : 1. 2. … Enchaînements alternatifs / Exceptions: A1… A2… Contraintes ….

Exemple de description détaillée d ’un CU

Précondition : Le distributeur contient des billets, il est en attente d ’une opération, il n’est ni en panne, ni en maintenance

Retirer DeLArgent AuDistributeur

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 description détaillée d ’un CU

Retirer DeLArgent AuDistributeur

Déroulement normal : (1) le client introduit sa carte bancaire (2) le système lit la carte et vérifie si la carte est valide (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 une 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, rejète la carte et le cas d ’utilisation se termine. (B) Code erroné : au cours de l ’étape (5) ...

Exemple de description détaillée d ’un CU

Retirer DeLArgent AuDistributeur

Contraintes non fonctionnelles :

(A) Performance : le système doit réagir dans un délai 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.