-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
Top Related