-DIAGRAMME DES CAS D’UTILISATION-

PRÉPARÉ PAR: AMINE SENNOUNIENCADRÉ PAR: PR.BOUBKER SBIHI

Modélisation des SI avec UML

2

Plan

Introduction: UMLDéfinitions Diagramme de casActeurCas d'utilisationAssociations et cas d'utilisationExercice d’applicationConclusion

3

Introduction: UML

UML permet de construire plusieurs modèles d’un système : certains montrent le système du point de vue des utilisateurs, d’autres montrent sa structure interne, d’autres encore en donnent une vision globale ou détaillée. Les modèles se complètent et peuvent être assemblés.

Ils sont élaborés tout au long du cycle de vie du développement d’un système (depuis le recueil des besoins jusqu’à la phase de conception). Dans cet exposé, nous allons étudier l’un des modèles , en l’occurrence le premier à construire : le diagramme de cas d’utilisation.

Il permet de recueillir, d’analyser et d’organiser les besoins. Avec lui débute l’étape d’analyse d’un système.

4

UML: Diagramme de cas

Les diagrammes de cas d'utilisation sont des diagrammes

UML utilisés pour donner une vision globale du comportement

fonctionnel d'un système Logiciel

Ils sont utiles pour des présentations auprès de la direction ou des acteurs d'un projet,

mais pour le développement, les cas d’utlisation sont plus

appropriés.

Un cas d'utilisation représente une unité discrète d'interaction entre un utilisateur

(humain ou machine) et un système.

5

Diagramme de cas

Vuelogique

Vuecomportement

Vuedéploiement

Vueimplémentation

diagrammes de classesdiagrammes d'objets

diagrammes d'étatsdiagrammes d'activitésdiagrammes de séquencediagrammes de collaboration

diagrammes de composantes

diagrammes de déploiement

Vue utilisateurdiagrammes de cas

6

Définition

Définition des cas d’utilisation («use cases»)Permettent d’impliquer les utilisateurs dès les premiers stades du

développement pour exprimer leurs besoins.Décrivent les fonctionnalités offertes par le système (le

« quoi? » avant le « comment? ») : délimitation du système par l’ensemble des fonctions qu’il

offre, relations avec son environnement (acteurs).

Modélisent à la fois les traitements (fonctionnalités) et les communications (interactions) ≠ acteurs/flux de Merise.

Utilisables pour tout projet indépendamment d’UML et de l’approche objet.

7

Définitions

Acteurs et casActeur : personne ou système qui interagit avec le système

étudié en échangeant de l’information.

Ex: utilisateurs directs du système (bénéficiaires des services), responsables de son fonctionnement (ex: administrateur), autres systèmes qui interagissent avec lui…

Un acteur représente un rôle. La même personne physique peut jouer le rôle de plusieurs acteurs et plusieurs personnes physiques peuvent jouer le même rôle et donc agir comme un même acteur.

Cas : interaction avec le système par un acteur dans une certaine intention; un service rendu par le système; une fonctionnalité.

8Diagrammes de cas d’utilisation

Décrivent les interactions entre les acteurs et le système représenté comme un ensemble de cas.

Les interactions sont orientées (avec une flèche) ou non.

Découvrons comment ?

9

Diagrammes de cas d’utilisation

acteur humain

acteur système

acteur

acteur

Le système

interactioncas

d’utilisation X

cas d’utilisation

Y

L’acteur est source et/ou destination d’une interaction

Frontière du

système

Groupement éventuel des cas enpaquetage(s)

<<actor>>« stick man »

ACTEURS

Diagramme de cas

11

Acteur

Un acteur est la description d'un ensemble cohérent de rôles qu'un utilisateur (personne ou système) joue lorsqu'il interagit avec le système.

Exemple :

Client

<<acteur>>Bibliothéquaire

12

Représentation graphique d'un acteur

Un acteur est une classe stéréotypée représentée par un rectangle avec le stéréotype «acteur» ou par une icône.

Client

<<acteur>>Bibliothéquaire

13

Nommer un acteur

Chaque acteur doit avoir un nom qui le distingue des autres acteurs - Unicité du nom complet (noms des packages englobant + le nom de l'acteur).

En pratique les noms de acteurs sont des noms pris dans le vocabulaire du domaine.

Il est d'usage de capitaliser la première lettre de chaque mot.

<<acteur>>ClientBanque PréposéBanque

14

Types des acteurs

Utilisateurs principaux

(client)

Périphériques externes

( horloge interne)

Système externes

(système inter-bancaire)

Utilisateurs secondaires (directeur)

15

Généralisation entre acteurs

Les acteurs peuvent avoir des associations de généralisation

Exemple :

Client

Particulier Entreprise

16

Acteurs vs utilisateurs

Ne pas confondre les 2 notions Un acteur décrit un rôle Un utilisateur = personne utilisant le

système Une même personne peut avoir deux rôles Maurice, directeur de banque et guichetier Plusieurs personnes peuvent avoir le même

rôle Pierre et Paul sont 2 clients

CAS D'UTILISATION

Diagramme de cas

18

Cas d'utilisation

Un cas est est une classe qui représente un ensemble de fonctions ou de comportements fournis par un système à un ou des acteurs.(exigences fonctionnelles du système)

Exemple :

Signer Contrat Assurance

Acheter Automobile

19

Représentation graphique d'un cas

Un cas est représenté par une ellipseun ensemble de cas peut être placé dans un

rectangle qui symbolise le système

20

Nommer un cas

Chaque cas doit avoir un nom qui le distingue des autres cas - Unicité du nom complet (noms des packages englobant + le nom du cas).

En pratique les noms de cas sont des verbes pris dans le vocabulaire du domaine.

Emprunter Livre

Accorder Crédit

21

Organiser les cas

Service

Opération

Serviceniveau système

niveau sous-système

niveau classe

22

Cas d’utilisation

23

Description du cas d’utilisation

IdentificationNom du cas : « Rechercher une vidéo ».But : décrire les étapes permettant au client de rechercher une vidéo via le distributeur automatique.Acteur principal : XXXXActeur secondaire : XXXXDate de création : le jj/mm/aaaa.Responsable : M. XXXXVersion : 1.0.

24

La description du cas d’utilisation

Chaque cas d’utilisation doit être précisé par une description textuelle qui peut être structurée en plusieurs sections :

conditions au démarrage (pré-conditions),conditions à la terminaison (post-conditions),étapes du déroulement normal (« nominal »),variantes possibles et les cas d’erreurs,informations échangées entre acteur et système,contraintes non fonctionnelles (performance, sécurité,

disponibilité, confidentialité…).

Exemple : cas RetirerArgentDistributeur

25

Description du cas d’utilisation

précondition

•contient des billets ; en attente d’une opération : ni en panne, ni en maintenance.

postcondition

•si de l’argent a pu être retiré, la somme sur le compte est égale à la somme qu’il y avait avant moins le retrait. Sinon, la somme sur le compte est inchangée.

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 choisit une opération de retrait, (7) le système demande le montant à retirer, etc.

26

Description du cas d’utilisation

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, rejette la carte et le cas d’utilisation se termine.•(B) …

contraintes

•(A) Performance : le système doit réagir dans un délai inférieur à 4 secondes, quelque soit l’action de l’utilisateur.•(B)

Sécurité …

27

La description du cas d’utilisation

Les cas d’utilisations peuvent être vus comme des classes de scénarios. Chaque scénario correspond à une utilisation particulière ou une manière d’exécution du cas d’utilisation, par un acteur donné, dans des circonstances données.

28

Un exemple de scénario

• Le client insère sa carte dans le distributeur d2103Le système accepte la carte et lit le numéro de compteLe système demande le codeLe client tape ‘ 1234 ’Le système indique que ce n’est pas le bon codeLe système affiche un message et propose de recommencer

…

ASSOCIATIONS ET CAS D'UTILISATION

Diagramme de cas

30

Généralisation

L'association de généralisation entre cas d'utilisation a la même sémantique que pour les classes

Valider usager

Scannerrétine

Vérifiermot de passe

31

« communique »

La relation communique permet de modéliser les échanges de messages entre acteurs et cas d'utilisation

Cas

Acteur

<<communique>>

32

Relations entre cas

A <<include>> B : le cas A inclut obligatoirement le cas B (permet de décomposer et de factoriser).

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

33

Relations entre cas

<<xxx>> est un stéréotype UML c’est à dire un moyen de caractériser et classer des éléments des modèles UML; certains sont prédéfinis, mais les utilisateurs peuvent en définir d’autres.

Client Commander

Choisir articles Demander

catalogue

<<extend>><<include>>

Payer

<<include>>

attention ausens des flèches

34

« étend »

Permet d’étendre, de façon structurée, le comportement d’un cas d’utilisation de base en utilisant un autre cas d’utilisation à un point d’extension spécifique.

Traiter unecommande

urgente

Traiter unecommande

Points d'extensionétablir priorité

<<étend>>(établir priorité)

Points d'extension

35

« inclut »

La relation inclut permet de modéliser l'inclusion de cas d'utilisation pour éviter les répétitions

Factoriser des sous-fonctions qui sont communes à d’autres cas d’utilisation

Traiter unecommande

ValiderUtilisateur

<<inclut>>

36

Exercice d’application: Enoncé

Modélisez avec un diagramme de cas d’utilisation le fonctionnement d’une banque qui interagit avec ses clients. Les guichetiers créent les comptes, déposent l’argent des clients dans

les comptes, et peuvent aussi fermer le compte, le guichetier chef peut en plus de ceci annuler ce compte.

l’opération de dépôt d’argent peut se faire de deux manières différentes:

en numéraire ou par voie de chèques.

37

Corrigé

Guichetier

Guichetier Chef

Créer un compte

Fermer un compte

Déposer de l’argent sur un

compte

Annuler un

compte

Déposer

chèques

Déposer numérair

e

38

Explications relatives au corrigé

Un ‘Guichetier Chef’ est un ‘Guichetier’ spécialisé qui peut faire tout ce que peut faire un Guichetier et, en plus, il peut annuler un compte.

L’héritage simplifie le dessin (moins d’interactions à dessiner).

‘Déposer chèques’ et ‘Déposer numéraire’ sont 2 spécialisations de ‘Déposer de l’argent sur un compte’ (2 manières de faire).

39

Conclusion

L’objectif de cette phase de la modélisation est donc de clairement identifier les frontières du système et les interfaces qu’il doit offrir à l’utilisateur. Si cette étape commence avant la conception de l’architecture interne du système, il est en général utile, quand la réflexion est suffisamment poussée, de poser les bases de la structure interne du système, et donc d’alterner analyse des besoins et ébauche des solutions envisagées.

Le diagramme de cas d’utilisation est un premier modèle d’un système. Que savons- nous sur le système après avoir créé ce diagramme ? Sur le système lui-même, en interne, pas grand-chose à vrai dire. C’est encore une boîte noire à l’architecture et au mode de fonctionnement interne inconnus. Donc, a fortiori, à ce stade, nous ne savons toujours pas comment le réaliser. En revanche, son interface avec le monde qui l’entoure est partiellement connue : nous nous sommes placés du point de vue des acteurs pour définir les spécifications fonctionnelles.

40

Références

Ambler, S.W. (2003) The Elements of UML Style , Londres : Cambridge University Press.

Cockburn, A. (2001). Rédiger des cas d'utilisations efficaces , Paris : Eyrolles. (voir aussi http://alistair.cockburn.us/ ) -Consulté le 24/12/2012-

C. Larman, UML 2 et les Design Patterns, 2005, Campus Press. A. Cockburn, Rédiger des cas d’utilisation efficaces, 2002, Eyrolles. G. Overgaard, K. Palmkvist, Use Cases - Patterns and Blueprints,

2004, Addison Wesley E. Yourdon, Managing Software Reqs - A Use Case Approach, 2003,

Addison Wesley D. Kulak, Use Cases: Requirements in context, 2003, Addison-

Wesley K. Bittner, I. Spence, Use Case Modeling, 2003, Addison-Wesley