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


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


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

?



include


web

Définition charte

graphique

extends

Saisie commande

Vérification stock

include

7/10/13

10

19

Corrigés des exemples

Quelles relations utiliser ?




include


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

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


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

« 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


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


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


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 :


Cours2 uml usecase

Documents

Transcript of Cours2 uml usecase