View
102
Download
2
Category
Preview:
Citation preview
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
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
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
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
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
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/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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
Recommended