1. 7/10/13
1
IUT de LYON
Module Analyse et Conception avec
UML (Unified Modelling Language)
Les Cas
d’Utilisation
(Use Case)
2
Cas d’utilisation : présentation
les « use case » d’Ivar JACOBSON
Décrire une utilisation du système (ensemble
de séquences d’actions) par un acteur
particulier
Acteurs externes à l’application
Un acteur = un rôle
Modélise l’un des aspects (comportement /
service) du système par rapport à cet acteur
doit renseigner sur le rôle particulier de l’acteur
(VA)
UML V. Deslandres – IUT de LYON
2. 7/10/13
2
3
Cas d’utilisation : présentation
Diagramme de description du QUOI FAIRE
Quelles sont les fonctionnalités : on décrit les cas précis
d'utilisation de l'application
Ex.: Utilisations d'un téléviseur
Pour regarder les chaînes publiques
Pour regarder le câble
Pour programmer/enregistrer avec son magnéto-cassette
Pour visionner avec son caméscope
Pour faire de l'internet
Comme miroir ou porte aquarium !
Mais pas du COMMENT
ni manipulation d’IHM, ni gestion des erreurs
matérielles
UML V. Deslandres – IUT de LYON
4
Cas d’utilisation (2)
L’ensemble des cas d’utilisation doit décrire
exhaustivement les exigences attendues du
système
Expression des besoins fonctionnels
Chaque « cas » = une fonction Métier du
système selon le point de vue d’un des acteurs
C’est un ensemble d’échanges entre l’acteur et le
système : un acteur demande des traitements, le
système fournit des services
Représentation : acteurs et patates !
Chaque « patate » est un « cas d’utilisation » du
système
UML V. Deslandres – IUT de LYON
3. 7/10/13
3
5
Exemple : diagnostic médical
médecin
patient
secrétaire
Règlement / facturation
Élaboration d’un diagnostic
Proposition du traitement
Analyse des symptômes
Gestion des RDV
<< include >>
<< include >>
UML V. Deslandres – IUT de LYON
6
Exemple : agence de banque
guichetier
client
responsable
clientèle
Effectuer opérations sur
Les comptes
Gérer les clients
Planifier des rendez-vous
Gestion de commande
Ouvrir un compte
Prospecter
UML V. Deslandres – IUT de LYON
4. 7/10/13
4
7
Cas d’utilisation : construction
On part des acteurs identifiés dans l’étude
préliminaire
chercher les intentions (métier) avec lesquelles il
utilise le système
déterminer dans le CdesCh les services fonctionnels
attendus
UML V. Deslandres – IUT de LYON
8
Construction des cas
On utilise les échanges de messages identifiés
dans le contexte dynamique
Distinguer l’acteur principal des acteurs
secondaires
Acteur principal: pour lequel le Cas produit la plus-
value métier (souvent : le déclencheur)
L'acteur secondaire ne fait que recevoir le résultat
obtenu à l'issue de la réalisation de l'utilisation
envisagée (en général placé à droite)
UML V. Deslandres – IUT de LYON
5. 7/10/13
5
9
Validation
Pour chaque cas d’utilisation candidat :
vérifier qu’il fournit une VA notable à l’acteur
contrôler qu’un événement externe en déclenche l’exécution
Ne pas descendre trop bas : un UC n’est ni une
transaction, ni une fonction du système !
Ex.: saisie des commandes, elles peuvent l’être via le web, via les
feuilles issues du service commercial, ou manuellement après
contacts téléphoniques.
Ca conduit donc à 3 séquences d’actions différentes mais pour un
seul cas d’utilisation : la saisie des commandes.
REGLE : un cas d’utilisation doit regrouper au moins 2
séquences (sans compter les exceptions)
Séquence principale + alternative
UML V. Deslandres – IUT de LYON
UML V. Deslandres – IUT de LYON
10
Etude de cas SIVEX
On part du diagramme de contexte dynamique
Chercher l’« intention fonctionnelle » de
chaque acteur dans son intéraction avec le
système
Quelle fonctionnalité le concerne dans
l'application ?
S’inspirer des messages
Regrouper les intentions en unités cohérentes
6. 7/10/13
6
11
Ex. Planification missions
Acteur principal = répartiteur
Intentions
planifier les missions d’une agence, permettant la
réalisation des commandes en cours
Actions :
créer une nouvelle mission :
regrouper des commandes, affecter des ressources
disponibles, établir un parcours, évaluer les durées, le
volume nécessaire pour la camionette, etc…
modifier ou annuler une mission existante
UML V. Deslandres – IUT de LYON
12
Acteur principal =
Ex. Suivi de mission
chauffeur
• Intentions
• Actions
Informer en temps réel de l’état d’avancement de la
mission en cours
- Transmettre chaque arrêt et départ d’étape
- Signaler les événements de mission
acquittement client, panne, retard, absence client...
UML V. Deslandres – IUT de LYON
7. 7/10/13
7
13
Use Case : Gestion des missions
UML V. Deslandres – IUT de LYON
14
Formalisme des cas d’utilisation
Différents types de relations
Relation entre un acteur et un cas :
- trait simple : l'acteur déclenche le cas
- flèche vers acteur :
l'acteur reçoit le résultat du cas (acteur secondaire)
Relation d’héritage entre cas : un cas d'utilisation (une
fonctionnalité) dérive d'une fonctionnalité plus générale
ex.: « Sélection d'une location de vacances » et
« Sélection d'une péniche pour un séjour »
Relation d’héritage entre cas
UML V. Deslandres – IUT de LYON
8. 7/10/13
8
15
Héritage entre Acteurs
UML V. Deslandres – IUT de LYON
16
Relations « includes, extends »
Cas de base Cas de base
Cas inclus extension
<<include>> <<extend>>
UML V. Deslandres – IUT de LYON
9. 7/10/13
9
17
Autres relations entre cas
Relation d’inclusion « include » :
La réalisation d’un cas de base passe
obligatoirement par celle d’un cas spécifique inclus
(objectif : factorisation)
Ex. : procédure d’authentification
Relation d’extension « extend » :
Cas de base incorpore une extension, à un point
d’extension prévu
(obj.: représenter un comportement optionnel)
Ex. : la prise de commande peut conduire à la création
d’un nouveau client
UML V. Deslandres – IUT de LYON
18
Exemples
Quelles relations utiliser ?
UML V. Deslandres – IUT de LYON
Modification
document
Vérification
droit d’accès
?
Saisie
commande
Vérification
stock
?
Développement
pages d’un site
web
Définition
charte
graphique
?
Modification
document
Vérification
droit d’accès
include
Développement
pages d’un site
web
Définition
charte
graphique
extends
Saisie
commande
Vérification
stock
include
10. 7/10/13
10
19
Corrigés des exemples
Quelles relations utiliser ?
UML V. Deslandres – IUT de LYON
Modification
document
Vérification
droit d’accès
include
Développement
pages d’un site
web
Définition
charte
graphique
extends
Saisie
commande
Vérification
stock
include
20
Use Case SIVEX : Gestion des Commandes
Consultation
d'en-cours
Client
Réceptionniste
Gestion de
Commande secondaire
Gestion
des
Clients
(nouveau client)
<<extend>> Point d'extension :
nouveau client
UML V. Deslandres – IUT de LYON
12. 7/10/13
12
23
Package en UML = concept commun de regroupement :
Structuration des cas d’utilisation
Structuration par package
d’éléments d’un modèle
de diagrammes de ces éléments
d’autres packages
Contraintes :
tout élément n’appartient qu’à un seul paquetage
Ensemble cohérent au niveau sémantique
(expertise métier)
Représentation : icône de dossier
UML V. Deslandres – IUT de LYON
24
Techniques de regroupement
Par domaine d’expertise métier
regroupement le plus intuitif et efficace
permet de faciliter la spécilisation des analystes
organiser facilement la répartition des experts
Par acteur
facile si chaque cas est relié à UN seul acteur
Par lot de livraison client
dans le cas d’un développement incrémental, c ’est
parfois un critère utilisé
UML V. Deslandres – IUT de LYON
13. 7/10/13
13
Relations entre packages
import
include
use
UML V. Deslandres – IUT de LYON
26
Regroupement en packages : SIVEX
- Par domaine d’expertise
métier
- Ensembles d’acteurs
fortement liés
Définition du plan
de transport, et des
ressources
Acteurs: resp.
logistique
Définition des profils utilisateur
Acteur: administrateur
Gestion clients, gestion des
commandes, consultation des
en-cours
Acteurs : réceptionniste, client
UML V. Deslandres – IUT de LYON
14. 7/10/13
14
1. Contexte d'apprentissage d'UML
2. Développement logiciel
3. Application de téléchargement de Cours
28
Exemple 1 : cas d’utilisation décrivant un
fonctionnement
Cas d'utilisation décrivant le contexte dans lequel vous
allez apprendre à concevoir avec UML à l'IUT…
Impétrant
assister
aux cours
lire
ouvrages
rechercher
informations
Présenter le
formalisme
UML
Proposer des
exercices
Evaluer
impétrants
Enseignant
UML V. Deslandres – IUT de LYON
15. 7/10/13
15
29
Exemple 2 : cas d’utilisation de
fonctionnement
Cas d'utilisation de développement de logiciel
Chef de projet
(maîtrise d'œuvre)
Maître
d'ouvrage
Architecte
logiciel
Architecte
technique
Utilisateur
Développeur
Piloter le processus
développement
Objet
Concevoir une
architecture
technique
Organiser le
développement
logiciel et les tests
Définir les
besoins
Tester
UML V. Deslandres – IUT de LYON
30
Exemple 3 : cas d’utilisation d’une
application informatique
Décrivant le téléchargement d’un Cours
Internaute
BD Users /
droits
Chercher un
cours
Sélectionner un
ou plusieurs
cours
Télécharger un
cours
Ouvrir
l’application
Authentification
Serveur
de Cours
Connexion
include
extends
UML V. Deslandres – IUT de LYON
Abonné
S’abonner
extends
16. 7/10/13
16
Questions sur l’ex. 3
• Pourquoi ne voit-on pas le cas « Visualiser un
cours » (description, pré requis, etc.) ?
▫ Pourquoi voit-on le cas « Rechercher un Cours » ?
• Que représentent les cas inclus pour l’application ?
Pourquoi les isole-t-on ?
• Quel est le choix de conception du Client pour ce
site ? (qui pourrait être différent)
• Les cas sont incomplets : lesquels ajouter ?
- Contrôler le nb de cours téléchargés
- Déposer un commentaire
UML V. Deslandres – IUT de LYON
32
Description des Cas d’utilisation
On décrit les cas d’utilisation avec des
diagrammes d’abord, et éventuellement sous
forme textuelle.
Structure de description des cas d’utilisation
qui permet de mieux les exploiter par la suite :
sommaire d’identification (titre, but, résumé, acteurs,
dates, version, responsable)
description des enchaînements (nominaux,
exceptionnels, pré-post conditions)
éventt : besoins d’IHM
éventt : contraintes non-fonctionnelles (fréquence,
volumétrie, disponibilité, confidencialité, performances…)
UML V. Deslandres – IUT de LYON
17. 7/10/13
17
33
Quel format de description ?
Il existe différents modèles de cas d’utilisation détaillé
Le plus répandu est celui de www.usecases.org
(cf SIVEX, et ex. ici)
Description :
Titre, acteur principal, parties prenantes et intérêts, pré et
post conditions, scénario principal (happy path, succès) sans
condition ni branchement, extensions (scénarios
d’exception);
Spécifications particulières (hors contraintes fonctionnelles :
interface, langue, temps de réponse);
Technologies envisagées ou évolutions à MT (ex.
actuellement chèque accepté, en Juin 2003, plus de
chèque), questions à se poser.
UML V. Deslandres – IUT de LYON
34
Exercice : quelle validité des UC
Soit un système de vente en ligne
Lesquels de ces cas d’utilisation seraient
valides ?
Supprimer un article
Négocier un contrat avec un fournisseur
Traiter les retours
Se connecter
Imprimer un document
UML V. Deslandres – IUT de LYON
18. 7/10/13
18
35
Use Cases : réponse
Les 3 cas du milieu sont utiles à différents niveaux
d’abstraction, en fonction des acteurs et des objectifs.
La question plutôt à se poser est :
À quel niveau faut-il exprimer un cas d’utilisation de
façon à se qu’il soit utile pour l’analyse des besoins ?
Il faut pour cela identifier les Processus métier
élémentaires
UML V. Deslandres – IUT de LYON
36
Quels cas d’utilisation créer
Identifier les Processus Métier pour lesquels il
y a valeur ajoutée observable et mesurable
Qui laissent le système dans un état stable et
cohérent
Définir les acteurs externes et internes et se
concentrer sur leurs intentions
Notamment ne pas raisonner en interface
utilisateur
UML V. Deslandres – IUT de LYON
19. 7/10/13
19
37
Exemple sur l’exercice
« Se connecter » : processus Métier ? plus value ?
Non, but secondaire
« se connecter pour commander » : OK ( traiter vente)
« se connecter pour enregistrer les ventes du mois » : OK
( enrichir statistiques)
« se connecter pour mettre à jour le catalogue » : OK
( gérer articles)
« Supprimer un article » : secondaire aussi !
Gestion Article plus appropriée
« Imprimer un document » : inutile ici
activité technique, pas un besoin Métier
(L’étape d’authentification n’est jamais un processus métier,
sauf pour une modélisation purement informatique !)
UML V. Deslandres – IUT de LYON
38
Risques associés aux Cas
Ne pas réinventer la décomposition
fonctionnelle !
On fait de l’analyse ORIENTEE OBJET !!
Ne pas aller trop loin dans le détail, on en est
à la capture des besoins fonctionnels.
Limiter à 10 le nombre de (« grands ») CU, rester
synthétique
Les Cas d’utilisation ne sont pas une fin en
soi, leur objectif est de :
dialoguer avec le client, le rassurer sur ce qu’on a compris
analyser les besoins métier,
démarrer l’analyse en identifiant les classes candidates.
UML V. Deslandres – IUT de LYON
20. 7/10/13
20
39
Autres risques
Ne pas mélanger l’IHM et le fonctionnel
on décrit le métier des acteurs, indépendamment
des choix d’interface qui pourront évoluer…
– ex.: préférer « lors d’une 1ère commande, le
réceptionniste enregistre les caractéristiques du nouveau
client dans le système » à :
– « le réceptionniste saisit le nom du client en 8 car.
max, en majuscules, appuie sur ENTER, puis saisit le
prénom en minuscules » ou à
– « le réceptionniste enregistre par un syst. de
reconnaissance vocale les nom, prénom, adresse et
code postal du client »
UML V. Deslandres – IUT de LYON
DEMARCHE UML
• On part d’une étude de contexte
▫ Diagramme de contexte statique
▫ Diagramme de contexte dynamique
• On construit les diagrammes de Cas d’utilisation
• On les regroupe en packages si besoin
• On en déduit les classes, on fait de premiers
diagrammes de classes
▫ partiels ou global
UML V. Deslandres – IUT de LYON
21. 7/10/13
21
41
Démarche détaillée
Cas d’Utilisation / Diagramme de Classes
(1) Présentation du contexte et du sujet
(2) Identifier les acteurs externes du système à
l’aide d’un diagramme de contexte statique
Acteurs = rôles joués par des personnes ou
systèmes externes
Les acteurs internes (ex.: comptables, serveur
de BD… ) apparaîtront plus tard dans la
modélisation
Penser à l’environnement humain et informatique
Nommer ces acteurs
UML V. Deslandres – IUT de LYON
42
Démarche Cas d’utilisation (2)
(3) Ajouter les échanges d'informations acteurs / système
les nommer, éventuellement les définir par une phrase
créer ainsi le diagramme de contexte dynamique
(4) Construire le diagramme des cas d'utilisation :
identifier les services rendus aux acteurs par le
système (tâches)
étude plus fine des interactions acteurs / système, en
dissociant les grandes fonctions
nommer les services rendus, les définir par une phrase
Règle : avoir plusieurs séquences d’actions par CU
(« enregistrer un client » = si c’est juste une saisie, ça n’est
pas un CU; préférer « Gestion Client »)
UML V. Deslandres – IUT de LYON
22. 7/10/13
22
43
(5) Pour chaque cas d'utilisation :
Détailler son fonctionnement par un diagramme d’activités
Chaque activité peut être élémentaire
On peut montrer les séquences et les alternatives
(6) Associés aux activités, définir les objets partagés
entre acteurs et système :
Objets traités, mémorisés, produits, transformés
objets du monde modélisé
objets importants pour les acteurs
objets persistants ou pas
Cela va aider à identifier les classes candidates
Démarche Cas d’utilisation / diag Classes (3)
UML V. Deslandres – IUT de LYON
44
Lister et nommer les objets (avec le
vocabulaire des acteurs), les définir par une
phrase
Identifier ensuite les classes candidates et
construire un diagramme de classes
par package
Relier les objets, nommer les liens, les définir
par une phrase
Pour chaque cas d’utilisation (suite)
UML V. Deslandres – IUT de LYON
23. 7/10/13
23
45
6. Si nécessaire, réunir les objets des
différents cas dans un unique
diagramme de classes
(bien entendu un même objet peut intervenir
dans les différents cas d’utilisation envisagés :
Ex. dans une application de type « Editeur logiciel », un
document sera déposé, validé, fusionné, chaque action
correspond à un CU)
Démarche Cas d’utilisation / Diag Classes (4)
UML V. Deslandres – IUT de LYON
46
Exercice : site vente en ligne
Client : consulte, achète des produits, demande un
renseignement, souhaite obtenir un RV
personnalisé, etc.
Administrateur : ouvre comptes, etc.
Responsable Produits : MàJ le catalogue, veille
Technicien : répond aux questions techniques sur
les produits
UML V. Deslandres – IUT de LYON
24. 7/10/13
24
47
Site vente en ligne
Client
Maintenance site
Gestion des
Clients
Consultation
Catalogue
Gestion des
Commandes
MàJ
Catalogue
extends
extends
Veille technologique
Renseignements
techniques
Authentification
includes
Administrateur
Resp. Produits
Technicien
UML V. Deslandres – IUT de LYON
Exemple de Cas d’Utilisation SIVEX
SIVEX: Planification des missions (fiche de
description)
25. 7/10/13
25
49
Use Case : Gestion des missions
UML V. Deslandres – IUT de LYON
50
Ex SIVEX Description du Cas
« Planification des missions » (1/5)
BUT : planification des missions d’enlèvement, de
transport ou de livraison, d’une agence à partir du plan
de transport, des commandes à assurer
quotidiennement et des ressources disponibles
• RESUME : création d’une nouvelle mission à partir des cdes
confirmées, modification et annulation d’une mission existante.
• ACTEURS :
• PRE-CONDITIONS :
- le répartiteur est authentifié
- les commandes à planifer sont confirmées
répartiteur (ppal), chauffeur (sec.)
UML V. Deslandres – IUT de LYON
26. 7/10/13
26
51
DEF Enchaînements
Enchaînement nominal = fonctionnement normal
ex.: dans le processus d’appel téléphonique, fonctionnement
nominal =
Enchaînement exceptionnel = fonctionnement
anormal, traitement des événements exceptionnels
ex.: dans le processus d’appel téléphonique,
fonctionnement exceptionnel =
Décrocher combiné, entendre sonnerie attente, composer numéro,
attendre sonnerie appel, communiquer, raccrocher
Décrocher combiné, pas de sonnerie d’attente, vérifier
branchement ligne, (suite)
UML V. Deslandres – IUT de LYON
52
« Planification des missions » (2/5)
Enchaînements identifiés :
– créer une mission en attente
– affecter des commandes à une mission
– affecter les ressources
– modifier une mission en attente (désaffecter une commande,
modification des chauffeurs ou véhicule, modification des étapes…)
– valider une mission en attente
– modifier une mission validée
– annuler une mission (en attente ou validée)
– éditer les bordereaux de mission
UML V. Deslandres – IUT de LYON
27. 7/10/13
27
53
« Planification des missions » (3/5)
Exceptions identifiées :
– Pour une mission donnée, dépassement de tonnage véhicule
– Chauffeur sélectionné non qualifié pour conduire le véhi-cule choisi
pour la mission
– Tonnage de réserve entammé (chaque agence doit se réser-ver un
certain tonnage pour pouvoir répondre à des comman-des prioritaires ou
de dépannage)
– Estimation de temps incomplète pour une étape donnée donc pour la
mission comportant cette étape
UML V. Deslandres – IUT de LYON
54
« Planification des missions » (4/5)
Post-conditions
– Tout ce qui est connu à l’issue du cas
– Pour lister les commandes de l’agence, le répartiteur doit
pouvoir répertorier les commandes de l’agence par type,
poids, site desservi, affectée/non affectée, tarification urgent/
non urgent
– Les commandes non affectées doivent être de couleur
différente
Besoins d’IHM
UML V. Deslandres – IUT de LYON
28. 7/10/13
28
55
« Planification des missions » (5/5)
Contraintes non fonctionnelles : temps de
réponse
– Interface répartiteur : moins de 2 secondes
– Concurrence : les validations de mission doivent être
notifiées aux lecteurs potentiels par un message
d’avertissement en TR
– Disponibilité : le système doit être accessible au répartiteurs
6 jours sur 7, aux heures d’ouverture des agences
Autres contraintes :
UML V. Deslandres – IUT de LYON