Cours2 uml usecase

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

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

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

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
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)

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

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
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...

7/10/13
7
13
Use Case : Gestion des missions
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

7/10/13
8
15
Héritage entre Acteurs
16
Relations « includes, extends »
Cas de base Cas de base
Cas inclus extension
<<include>> <<extend>>

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
18
Exemples
Quelles relations utiliser ?
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

7/10/13
10
19
Corrigés des exemples
Quelles relations utiliser ?
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

7/10/13
11
21
Use Case : Gestion comptabilité

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
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é

7/10/13
13
Relations entre packages
import
include
use
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

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

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
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
Abonné
S’abonner
extends

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
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…)

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.
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

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

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 !)
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.

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 »
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

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
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 »)

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)
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)

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)
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

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
Exemple de Cas d’Utilisation SIVEX
SIVEX: Planification des missions (fiche de
description)

7/10/13
25
49
Use Case : Gestion des missions
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.)

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)
52
  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

7/10/13
27
53
  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
54
  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

7/10/13
28
55
  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 :

Cours2 uml usecase

Contenu connexe

Tendances (20)

En vedette (20)

Similaire à Cours2 uml usecase (20)

Plus de vangogue (15)

Cours2 uml usecase