23
Chapitre 2 DIAGRAMME DE CAS d’UTILISATION 1

Chapitre 2 DIAGRAMME DE CAS

  • Upload
    others

  • View
    2

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Chapitre 2 DIAGRAMME DE CAS

Chapitre 2

DIAGRAMME DE CAS

d’UTILISATION1

Page 2: Chapitre 2 DIAGRAMME DE CAS

2

• diagramme de classes

•diagramme de déploiement

•…

Statique (ce que le système EST)

• diagramme de séquence

•…

Fonctionnel

(ce que le système FAIT)

Dynamique

(comment le système

EVOLUE)

• diagramme de cas d’utilisation

•…

Axes de modélisation d ’un système

Page 3: Chapitre 2 DIAGRAMME DE CAS

Bien recueillir les besoins

Bien souvent, la maîtrise d’ouvrage et les utilisateurs ne sont pas des

informaticiens.

Il leur faut donc un moyen simple d’exprimer leurs besoins. C’est précisémentle rôle des diagrammes de cas d’utilisation qui permettent de recueillir,

d’analyser et d’organiser les besoins, et de recenser les grandes

fonctionnalités d’un système.

Il s’agit donc de la première étape UML, d’analyse d’un système.

Un diagramme de cas d’utilisation capture le comportement d’un système,

d’un sous-système, d’une classe ou d’un composant tel qu’un utilisateur

extérieur le voit.

Il scinde la fonctionnalité du système en unités cohérentes,

Les cas d’utilisation, ayant un sens pour les acteurs.

Les cas d’utilisation permettent d’exprimer le besoin des utilisateurs d’un système,

ils sont donc une vision orientée utilisateur de ce besoin, au contraire d’une

vision informatique.

Compréhensibles par toutes les personnes, même par les non-informaticiens.

3

Page 4: Chapitre 2 DIAGRAMME DE CAS

Définition

Un cas d’utilisation « raconte » comment on doit utiliser le système

pour atteindre un but particulier

o Il correspond à une fonction du système

o Il décrit les interactions entre le système et les utilisateurs

o Il est exprimé en prose structurée

o Il détermine un contrat à remplir par le système

o Il induit des exigences fonctionnelles applicables au système

et il peut être utilisé pour organiser la spécification

4

Page 5: Chapitre 2 DIAGRAMME DE CAS

Diagramme de cas d’utilisation

Représente les fonctions du système de point de vue de l ’utilisateur.

Eléments du diagramme :

o acteur : un rôle joué par une personne, un service, etc. qui interagit avec le

système étudié

o cas d’utilisation : manière spécifique d ’utiliser un système. Image d’une

fonctionnalité attendue, déclenchée en réponse à la stimulation d’un acteur

o relations entre cas d’utilisations et acteurs

5

Cas d’utilisation

Acteur

relationCeci est un cas

d’utilisation

Ceci est

une relation

Ceci est

un acteur

Page 6: Chapitre 2 DIAGRAMME DE CAS

Acteurs : diagramme de cas d’utilisation

Un acteur représente un ensemble cohérent de rôles joués vis-à-vis d’un système

o Exemple : mettre « comptable » plutôt que « madame Mariem ».

Plusieurs personnes peuvent avoir le même rôle

o exemple : « client » pour une banque

Tout ce qui est à l’extérieur du système et qui interagit avec le système est

un acteur.

Acteur humain : il s’agit ici d’un rôle et non d’un acteur identifié.

Acteur non humain : exemple un logiciel de comptabilité ou d’ERP avec

lequel le système interagit

ou

6

Page 7: Chapitre 2 DIAGRAMME DE CAS

Acteurs : diagramme de cas d’utilisation

On distingue 4 catégories d ’acteurs:

o les acteurs principaux (ex: usager, client, etc.)

o les acteurs secondaires (ex: opérateur de maintenance, administrateur, etc.)

o le matériel externe (capteurs, imprimantes, périphériques divers, etc.)

o les autres systèmes (serveur central, service ou organisation, etc.)

7

Un Acteur peut hériter d’autres Acteurs.

Cycliste

Facteur

Circuler à

bicyclette

Distribuer le

courrier

Page 8: Chapitre 2 DIAGRAMME DE CAS

CAS D ’UTILISATION Identification (1)

Un cas d’utilisation représente un processus de « haut niveau » se déroulant de

bout en bout et incluant plusieurs étapes successives.

Ce n’est pas une opération élémentaire ou une transaction.

Un cas d’utilisation peut être vu comme une collection de scénarios décrivant

différentes façons d’utiliser le système pour atteindre un même but (avec ou

sans succès).

Un cas d’utilisation ne se décompose pas en « sous-cas d’utilisation ».

8

Page 9: Chapitre 2 DIAGRAMME DE CAS

CAS D ’UTILISATION Identification (2)

Les cas d ’utilisation correspondent

o aux principales tâches de chaque acteur

o à une valeur ajoutée pour l ’utilisateur

o à des fonctionnalités ou à des services attendus

o à des opérations sur les données du système

o à des anomalies ou des cas particuliers.

Un cas d ’utilisation doit être simple (description de 1 ou 2 pages maximum).

Le nombre d ’acteurs en relation avec un cas d ’utilisation ne doit pas être trop important.

2 activités qui s ’enchaînent toujours font généralement partie du même cas

d’utilisation.

La difficulté majeure est de trouver le bon niveau d’abstraction.

9

Page 10: Chapitre 2 DIAGRAMME DE CAS

CAS D ’UTILISATION Description caractéristique

La description d’un cas d’utilisation

o débute par une phrase du type

« Ce cas d’utilisation est déclenché quand

<un acteur> <adresse un stimulus au système> …»

o privilégie les interactions entre les acteurs et le système

o s’attache prioritairement à la séquence des événements qui conditionnent

les interactions (flux nominal)

o se termine lorsque le but est atteint ou dans une situation d'exception.

Si cette description est impossible, c’est probablement parce que l’objet

considéré n’est pas vraiment un cas d’utilisation …

10

Page 11: Chapitre 2 DIAGRAMME DE CAS

CAS D ’UTILISATION Construction

1) Identifier les acteurs (Qui utilise le système )

2) Identifier grossièrement les cas d ’utilisation essentiels.

3) Identifier les cas d ’utilisation exceptionnels.

4) Décrire chaque cas d ’utilisation en quelques phrases.

5) Elaborer un diagramme.

6) Vérifier que tous les besoins identifiés ont été alloués à un cas d ’utilisation.

7) Recenser les principaux scénarios pour chaque cas d ’utilisation.

11

Page 12: Chapitre 2 DIAGRAMME DE CAS

CAS D ’UTILISATION: Niveaux de description12

•Détaillé

Description précise et

structurée

Description des

alternatives

•Général

Brève description

3-5 phrases

Calculer un itinéraire

Titre: Calculer un itinéraire

Acteur: Usager

Description: Ce cas d’utilisation commence lorsque

l’usager se connecte au système pour obtenir un

itinéraire à suivre. Il précise son lieu de départ et

son lieu d’arrivée ainsi que les paramètres de

calcul. Le système lui fournit une chronologie des

étapes à suivre pour atteindre la destination dans

les conditions souhaitées.

Page 13: Chapitre 2 DIAGRAMME DE CAS

Relations entre cas d’utilisation13

Communication – exprime le fait que l ’acteur participe à la

réalisation d ’un cas d ’utilisation . C ’est la seule relation qui

peut exister entre un acteur et un cas d ’utilisation. ConsommateurPayer

Régler par chèque

Payer

Régler par CB

Généralisation - un cas d ’utilisation « enfant » hérite du

comportement et de la sémantique du cas d ’utilisation parent

Régler par CB Composer Code

<<include>>

Relation « Include » – Une relation « include » du cas

d ’utilisation A vers le cas d ’utilisation B signifie que le flot

d ’événements de A contient une séquence d ’événements

qui correspond à B.

Remplir ordre et montant

automatiquement

Régler par chèque

<<extend>>

Relation « Extend » – Une relation « extend » du cas

d ’utilisation A vers le cas d ’utilisation B signifie que le flot

d ’événements de A peut intervenir, de façon facultative,

pendant le déroulement de B. B spécifie un comportement

facultatif

Page 14: Chapitre 2 DIAGRAMME DE CAS

Relation d’inclusion

Un cas A inclut un cas B si le comportement décrit par le cas A inclut lecomportement du cas B : le cas A dépend de B.

Lorsque A est sollicité, B l’est obligatoirement, comme une partie de A. Cette

dépendance est symbolisée par le stéréotype << include >>

Les inclusions permettent essentiellement de factoriser une partie de la

description d’un cas d’utilisation qui serait commune à d’autres cas

d’utilisation.

Les inclusions permettent également de décomposer un cas complexe ensous-cas plus simples.

14

Page 15: Chapitre 2 DIAGRAMME DE CAS

Relation d’extension

Un cas d’utilisation A étend un cas d’utilisation B lorsque le cas d’utilisation A peut être appelé au cours de l’exécution du cas d’utilisation B.

Exécuter B peut éventuellement entraîner l’exécution de A : contrairement à

l’inclusion, l’extension est optionnelle. Cette dépendance est symbolisée par le stéréotype << extend >> .

L’extension peut intervenir à un point précis du cas étendu. Ce point s’appelle

le point d’extension.

15

Remplacer

Rechercher<<extend>>demande de remplacement

de chaque occurrence trouvéeExtension points

• définition du remplaçant: avant début

de recherche

• substitution: à chaque occurrence

trouvée

mot clef (stéréotype)

Condition d’extension

Points d’extension

Page 16: Chapitre 2 DIAGRAMME DE CAS

Relation de généralisation

Un cas A est une généralisation d’un cas B, si B est un cas particulier de A.

Cette relation de généralisation/spécialisation est présente dans la

plupart des diagrammes UML et se traduit par le concept d’héritage

dans les langages orientés objet

16

Page 17: Chapitre 2 DIAGRAMME DE CAS

Relations entre acteurs

La seule relation possible entre deux acteurs est la généralisation : un acteur A est

une généralisation d’un acteur B si l’acteur A peut être substitué par l’acteur B.

Dans ce cas, tous les cas d’utilisation accessibles à A le sont aussi à B, mais

l’inverse n’est pas vrai.

17

Page 18: Chapitre 2 DIAGRAMME DE CAS

Comment recenser les cas d’utilisation

L’ensemble des cas d’utilisation décrit exhaustivement les exigences fonctionnelles

du système.

Chaque cas d’utilisation correspond à une fonction métier du système, selon le

point de vue d’un de ses acteurs

(exemple du distributeur de billet : Retirer de l’argent ou Distribuer de l’argent ).

Aussi, pour identifier les cas d’utilisation, il faut se placer du point de vue de

chaque acteur et déterminer comment et surtout pourquoi il se sert du système.

Il faut éviter les redondances et limiter le nombre de cas en se situant à un bon

niveau d’abstraction.

Nommez les cas d’utilisation avec un verbe à l’infinitif suivi d’un complément en

vous plaçant du point de vue de l’acteur, et non pas de celui du système.

Dans tous les cas, il faut bien garder à l’esprit qu’il n’y a pas de notion temporelle

dans un diagramme de cas d’utilisation.

18

Page 19: Chapitre 2 DIAGRAMME DE CAS

Exemple 119

Page 20: Chapitre 2 DIAGRAMME DE CAS

Exemple 2

Une agence de voyages organise des voyages où l’hébergement se fait en hôtel. Le client doit disposer d’un taxi quand il arrive à la gare pour se rendre à

l’hôtel

Certains clients demandent à l’agent de voyages d’établir une facture

détaillée. Cela donne lieu à un nouveau cas d’utilisation appelé « Etablir une facture détaillée». Comment mettre ce cas en relation avec les cas existants

Le voyage se fait soit par avion, soit par train. Comment modéliser cela

20

Réserver une

chambre d’hotel

Réserver

un taxi

Réserver un

billet de train

Organiser un

voyage

Agent de

voyage

Page 21: Chapitre 2 DIAGRAMME DE CAS

Exemple 2 (Correction)21

Page 22: Chapitre 2 DIAGRAMME DE CAS

Exemple 3

Distributeur de billets

Déterminer les cas d'utilisation d'un distributeur de billets. On

considère les scénarios où un client désire retirer de l'argent en

euros ou en dollars. Il faut traiter la situation où le stock de billets est

insuffisant. On s'intéresse également à la procédure d'identification

(de la carte et du client).

22

Page 23: Chapitre 2 DIAGRAMME DE CAS

Exemple 3 (Correction)23