Modélisation avec UML : Diagramme des Cas

d’utilisations

David Célestin FAYE

UFR SAT/UGB
Le diagramme des cas d’utilisation (vue fonctionnelle)

Plan 2

1 Le diagramme des cas d’utilisation (vue fonctionnelle)

David Célestin FAYE Modélisation avec UML 2/67

Les Diagrammes d’UML 3
Diagramme

Diagramme Diagramme
De structure comportemental

Diagramme Diagramme Diagramme Diagramme Diagramme de

de classes de packages de d'objets d'activités Cas d'utilisation

Diagramme Diagramme Diagramme de Diagramme Diagramme de

de composants de déploiement Structure composite d'interaction Transition d'état

Diagramme Diagramme de
De séquence communication

Diagramme Diagramme
Vue d'ensemble De timing
Des interactions
Introduction 4

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

pas des informaticiens.
Z Il leur faut donc un moyen simple d’exprimer leurs besoins.
Z rôle des diagrammes de cas d’utilisation : permettent de
recueillir, d’analyser et d’organiser les besoins, et de recenser
les grandes fonctionnalités d’un syste ?me.
:
But de l’analyse
Etudier la demande du client et la convertir en éléments
exploitables pour la conception.

?
Cas d’utilisation 5
Modélisation des besoins
Avant de développer un système, il faut savoir précisément à QUOI
il devra servir, i.e à quels besoins il devra répondre.

Z Modéliser les besoins permet de :

Faire l’inventaire des fonctionnalités attendues ;
Organiser les besoins entre eux, de manière à faire apparaitre
des relations (réutilisations possibles, ...).
Z Avec UML, on modélise les besoins au moyen de diagrammes
de cas d’utilisation.

Objectif
Z Expression du comportement du système (actions et
réactions), selon le point de vue de l’utilisateur extérieur
Z Décrivent le système et ses relations avec l’environnement
Le système est considéré comme une boîte noire
Cas d’utilisation 6

Intérêts
Permettent de délimiter les frontières du système
Il définit un comportement du système sans révéler sa
structure interne
Utilisés par les utilisateurs finaux pour exprimer leurs attentes
et leurs besoins
Permettent d’impliquer les utilisateurs dès les premiers stades
du développement
Constituent une base pour les tests fonctionnels
Cas d’utilisation 7

Un cas d’utilisation
implique des séries d’actions plus élémentaires.
est une séquence de transactions entre un acteur et le système
n’est pas un module du système
est plutôt une fonctionnalité du système

cas d’utilisation
Un cas d’utilisation « raconte »comment on doit utiliser le
système pour atteindre un but particulier
Cas d’utilisation 8

Scénarios d’utilisation
Séquences d’étapes spécifiques
décrivant une interaction entre l’utilisateur et le système
permettant à l’utilisateur de réaliser un objectif

Z C’est une histoire spécifique de l’utilisation d’un système

Z Intérêt : Base de discussion avec le client pour l’ analyse des
besoins

Exemple
Scénario d’un achat réussi d’articles en liquide,
Scénario d’un échec d’achat d’articles à cause d’un refus de
paiement à crédit.
Cas d’utilisation 9

Exemple de Scénarios d’utilisation

Système : Site de vente en ligne

Scénario : Effectuer une commande
Le client s’authentifie dans le système puis choisit une adresse et un
mode de livraison. Le système indique le montant total de sa
commande au client. Le client donne ses informations de
paiement.La transaction n’est pas autorisée, le système invite le
client à changer de mode de paiement. Le client modifie ses
informations. La transaction est effectuée et le système en informe
le client par e-mail.
Cas d’utilisation 10
Cas d’utilisation
Ensemble de scénarios réalisant un objectif de l’utilisateur
représente un ensemble de séquences d’actions qui sont
réalisées par le système et qui produisent un résultat
observable intéressant pour un acteur particulier.
Il permet de décrire ce que le futur système devra faire, sans
spécifier comment il le fera.
scénario1 scénario2 scénario3
Cas d’utilisation 11

Cas d’utilisation
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 ».
Cas d’utilisation 12
Cas d’utilisation : abstraction de plusieurs chemins d’exécution.
Une instance de cas d’utilisation est appelée : « scénario ».
Chaque fois qu’une instance d’un acteur déclenche un UC, un
scénario est créé (le cas d’utilisation est instancié). Ce scénario
suivra un chemin particulier dans le cas d’utilisation
chaque scénario consiste à une utilisation particulière, par un
acteur donné dans des circonstances données

Scénario principal
Il correspond à l’instance principal du cas d’utilisation. C’est
souvent le chemin « normal »d’exécution du cas d’utilisation qui
n’implique pas d’erreurs.

Scénario secondaire
Il peut être un cas alternatif , un cas exceptionnel ou une erreur.
Cas d’utilisation et scénarios 13
Diagramme des cas d’utilisation 14

Cas d’utilisation : Effectuer une commande

Scénario principal :
1 Le client s’authentifie dans le système
2 Le client choisit une adresse et un mode de livraison.
3 Le système indique le montant total de sa commande au client.
4 Le client donne ses informations de paiement.
5 La transaction est effectuée et le système en informe le client
par e-mail.
Cas particulier
5a La transaction n’est pas autorisée, le système invite le client à
changer de mode de paiement. Retour à l’étape 4.
Cas d’utilisation et scénario 15

Les cas d’utilisation se déterminent en observant et en

précisant, acteur par acteur, les séquences d’interaction -les
scénarios- du point de vue de l’utilisateur
Un cas d’utilisation regroupe une famille de scénarios
d’utilisation selon un critère fonctionnel.
Les cas d’utilisation sont des abstractions du dialogue entre les
acteurs et le système : ils décrivent des interactions
potentielles, sans entrer dans le détail de chaque scénario.
Un cas d’utilisation doit être vu comme une classe dont les
instances sont des scénarios.
Cas d’utilisation et scénario 16

En Résumé
Les scénarios qui définissent la suite logique des interactions
qui constituent ce cas.
Chaque fois qu’un acteur interagit avec le système, le cas
d’utilisation instancie un scénario ;
Ce scénario correspond au flot de messages échangés par les
objets durant l’interaction particulière qui correspond au
scénario
Les scénarios sont utiles pour :
analyser et concevoir le système
justifier les choix effectués (ils serviront à la documentation
des cas d’utilisation)
de spécifier les tests.
Description des cas d’utilisation 17

Comment décrire les cas d’utilisation ?

Diagramme de cas d’utilisations
Récapitulatif graphique des interactions entre acteurs et cas
Diagramme de séquence
Description de chaque scénario
Séquences d’interactions entre les acteurs et le système
Diagramme des cas d’utilisation 18

Dans la modélisation par les use cases 2 concepts

fondamentaux interviennent :
Les acteurs : utilisateurs du système.
Les uses cases : utilisation du système
Tout système peut être décrit par un certain nombre de cas
d’utilisation représentant les besoins exprimés par l’ensemble
des utilisateurs.
La représentation d’un cas d’utilisation met à jour trois
concepts.
L’acteur.
Le cas d’utilisation.
l’interaction entre l’acteur et le cas d’utilisation
Diagramme des cas d’utilisation 19

Comment découvrir les cas d’utilisation ?

Délimiter le périmètre du système
Identifier les acteurs interagissant avec le système :
Ceux qui utilisent le système
Ceux qui fournissent un service au système
Identifier les acteurs principaux
→ Ceux qui utilisent le système pour atteindre un but
Définir les cas d’utilisation correspondant à ces buts
→ Nom = Verbe à l’infinitif + Groupe nominal
Acteur 20

Acteur
Entité (Quelqu’un ou quelque chose) externe au système décrit
qui échange de l’information (entrée/sortie).
Rôle joué par des entités externes au système et qui ont des
interactions avec le système.
L’acteur au sens UML
peut être humain,
une entité informatique
ou une entité matérielle
Identifié par le nom du rôle
Exemple : utilisateur, autre système.
Acteur 21
Z L’acteur peut consulter ou modifier l’état du système.
Z En réponse à l’action d’un acteur, le système fournit un service
qui correspond à son besoin.
Z Les acteurs peuvent être classés (hiérarchisés) en faisant une
sorte d’héritage.
Z La représentation graphique standard de l’acteur en UML est
l’icône appelée stick man, avec le nom de l’acteur sous le
dessin
humain

ou

Entité matérielle ou informatique

Identification des acteurs 22

Z Les principaux acteurs sont les utilisateurs du système.

Un acteur correspond à un rôle, pas à une personne physique.
Une même personne physique peut être représentée par
plusieurs acteurs si elle a plusieurs rôles.
Si plusieurs personnes jouent le même rôle vis-à-vis du
système, elles seront représentées par un seul acteur.
Z Ne pas confondre les 2 notions
Un acteur décrit un rôle
Un utilisateur = personne utilisant le système
Z En plus des utilisateurs, les acteurs peuvent être :
Des périphériques manipulés par le système (imprimantes...) ;
Des logiciels déjà disponibles à intégrer dans le projet ;
Des systèmes informatiques externes au système mais qui
interagissent avec lui, etc.
Acteurs (bonnes pratiques) 23

Z Utiliser le symbole non stéréotypé pour les acteurs humains et

le symbole stéréotypé pour les acteurs non-humains
Z Ne pas confondre avec les utilisateurs : les acteurs englobent
tout utilisateur, mais aussi les autres systèmes informatiques et
matériels qui dialoguent avec le système
Z Pour trouver les acteurs :
quels sont les rôles que jouent les utilisateurs (ex : responsable
clientèle, administrateur, approbateur, etc.) ?
quels sont les systèmes avec lesquels le système communique
(périphériques, logiciels, systèmes informatiques, etc.) ?
quels sont les rôles des systèmes contributeurs ?
ne répertorier que ceux qui interagissent directement avec le
système
Cas d’utilisation 24

Cas d’utilisation
Z Expression d’un service réalisé de bout en bout, avec un
déclenchement, un déroulement et une fin, pour l’acteur qui
l’initie.
Z Fonctionnalité visible de l’extérieur
Z Action déclenchée par un acteur
Z Identifié par une action (verbe à l’infinitif)

Z Les uses cases peuvent être structurés.

Z Les uses cases peuvent être organisés en (packages).
Z L’ensemble des use cases décrit les objectifs du système.
Cas
Cas d'utilisation
d'utilisation
Spécification des cas d’utilisation 25

Diagramme des cas d'utilisation + Description textuelle

Cas
Cas11
Système Acteur
Acteur: :Acteur
ActeurAA
Contexte
Contexte: :
Cas 1 « extend» Entrées
Entrées: :
Sorties
Sorties: :
Cas 2 Scénario
Scénarioprincipal
principal: :
Acteur A 1.1.
« include » 2.2.
3.3.
Variantes
Variantes: :
Cas 3 1a.
1a.
1b.
1b.
3a.
3a.

Acteur B Cas 4 Cas 5

Diagramme des cas d’utilisation 26

nom du système

Site de vente en ligne

Commander

Client
association
acteur

Suivre commande

cas d'utilisation

limites du système
Relation entre Acteur et cas d’utilisation 27
Relations entre cas d’utilisation et acteurs
Les acteurs impliqués dans un cas d’utilisation lui sont liés par
une association.
Un acteur peut utiliser plusieurs fois le même cas d’utilisation.
Objectif : Représente la possibilité pour l’acteur de déclencher
le cas
Site de vente en ligne

Commander

Client association
acteur
cas d'utilisation

Suivre commande
Relation entre Acteur et cas d’utilisation : Multiplicité 28
Lorsqu’un acteur peut interagir plusieurs fois avec un cas
d’utilisation, il est possible d’ajouter une multiplicité sur
l’association du côté du cas d’utilisation.
* signifie plusieurs((pas représenté en général)).
n signifie exactement n.
n..m signifie entre n et m.

Site de téléchargement

Télécharger un fichier
0..5
Internaute
multiplicité

*
S'inscrire
Relations entre acteurs 29
La seule relation possible entre deux acteurs est la
généralisation
L’acteur A est une généralisation de l’acteur B si A peut être
remplacé par B.
Tous les cas d’utilisation accessible par A sont accessibles par
B. L’inverse n’est pas vrai.
Système de ventes

passer commande

Commercial
annuler commande

suivre commande

Directeur des ventes gérer stock

Acteurs principaux et secondaires 30
Acteur principal, acteur qui est à l’initiative des échanges
nécessaires pour réaliser le cas d’utilisation
Acteur principal, acteur à qui un cas d’utilisation rend
service.
Les autres acteurs sont appelés acteurs secondaires et sont
sollicités pour des informations supplémentaires(e.g, d’autres
systèmes informatiques avec lesquels le système est
inter-connecté.)
Un seul acteur principal par cas d’utilisation.

Site de téléchargement
«secondary »
télécharger un fichier

Internaute Serveur
Relations entre acteurs 31

NB : Un seul acteur principal par cas d’utilisation.

Système de ventes

passer commande

Commercial

gérer stock

Directeur des ventes

L’héritage entre Commercial et Directeur des ventes permettait à

ce dernier de pouvoir utiliser le cas d’utilisation passer commande
Relations entre cas d’utilisations 32

Il existe 3 types de relations entre cas d’utilisation :

la relation de généralisation
la relation d’extension
la relation d’inclusion
Dans la suite « « XX » »est un stéréotype UML, c’est-à-dire un
moyen de caractériser et classer les éléments des modèles UML ;
certains sont prédéfinis, mais les utilisateurs peuvent en définir
d’autres
Relations entre cas d’utilisations : inclusion 33

Le cas A inclut le cas B (B est une partie obligatoire de A).

Le cas d’utilisation contient un autre cas d’utilisation

A B
<<include>>

Le cas qui incorpore l’autre ne peut pas être utilisé seul.

Si A inclut B, lorsque A est sollicité, B l’est obligatoirement.
A « include »B ⇔ A implique B
B est nécessaire pour A
Relations entre cas d’utilisations : inclusion 34

Cette relation permet de :

définir des comportements partageables entre plusieurs cas.
factoriser une partie de la description d’un cas d’utilisation
décomposer un cas complexe en sous-cas plus simples

Bonnes pratiques
Éviter d’utiliser avec abondance cette relation pour ne pas retomber
dans le travers de la décomposition fonctionnelle
Relations entre cas d’utilisations : inclusion 35

Attention, les cas d’utilisation ne s’enchaînent pas. Il n’y a pas

de représentation temporelle.
Un tel use case ne peut être lié qu’à un use case, pas à un
acteur.

Distributeur de billets

Retirer de l'argent

Client
« include »

Cas d'utilisation
S'authentifier
nécessaire

Retirer de l’argent inclut s’authentifier

Relations entre cas d’utilisations : extension 36

Le cas B étend le cas A (B est une partie optionnelle de A).

Le cas d’utilisation étend (précise) les objectifs (le
comportement) d’un autre cas d’utilisation Cette relation
permet de définir des variantes de comportement.

A B
<<extend>>

B étend A, lorsque B peut être appelé au cours de A.

Attention ce n’est pas obligatoire.
B « extend »A ⇔ B peut être provoqué par A
B est optionnel pour A
Relations entre cas d’utilisations : extension 37

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

point s’appelle le point d’extension.
L’extension peut être soumise à condition.

Guichetier

Effectuer un virement

Client
« extend»

Cas d'utilisation
Vérifier solde
optionnel

Vérifier solde étend effectuer virement On vérifie le solde, lorsque la

somme dépasse un seuil donné
Relations entre cas d’utilisations : généralisation 38

Motivations
Transmettre les propriétés et le comportement d’un cas
d’utilisation à un autre
Éviter la duplication
Encourager la réutilisation
Relations entre cas d’utilisations : généralisation 39
Le cas A est une généralisation du cas B (B est une sorte de A).

A B

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

A.
Système bancaire

Consulter compte

Client

Cas d'utilisation
particuliers
Consulter Consulter
au GAB par internet
Relations entre cas d’utilisations 40
Dépendances d’inclusion et d’extension 41

Z Les inclusions et les extensions sont représentées par des

dépendances.
Lorsqu’un cas B inclut un cas A, B dépend de A.
Lorsqu’un cas B étend un cas A, B dépend aussi de A.
On note toujours la dépendance par une flèche pointillée
B − − > A qui se lit « B dépend de A »
Z Lorsqu’un élément A dépend d’un élément B, toute
modification de B sera susceptible d’avoir un impact sur A.
Z Le sens des flèches indique la dépendance, pas le sens de la
relation d’inclusion.
Réutilisabilité avec les inclusions et les extensions 42

Z Les relations entre cas permettent la réutilisabilité des cas.

Z Dans l’exemple ci-dessous il sera inutile de développer plusieurs
fois un module d’authentification.

Passer une commande

<<include>>

S'authentifier

Suivre une commande <<include>>

Décomposition grâce aux inclusions et aux extensions 43

Z Quand un cas est trop complexe (faisant intervenir un trop

grand nombre d’actions), on peut procéder à sa décomposition
en cas plus simples.
Valider panier
<<include>>

<<include>>
Passer une commande S'authentifier

<<include>>

payer

Bonnes pratiques
Éviter d’utiliser avec abondance cette relation pour ne pas retomber
dans le travers de la décomposition fonctionnelle
Généralisation 44

Cette relation de généralisation/spécialisation correspond au

concept d’héritage dans les langages orientés objet. La flèche pointe
vers l’élément général.
Payement CB

payer

virement

Un virement est est un cas particulier de paiement.

Un virement est une sorte de paiement.
Généralisation 45

UML permet de regrouper des cas d’utilisation dans une entité

appelée « paquetage ».
Le regroupement peut se faire par acteur ou par domaine
fonctionnel.
Un diagramme de cas d’utilisation peut contenir plusieurs
paquetages et des paquetages peuvent être inclus dans
d’autres paquetages.

¨Paquetage
Un paquetage permet d’organiser des éléments de modélisation en
groupe. Un paquetage peut contenir des classes, des cas
d’utilisations, des interfaces, etc.
Recenser et décrire les cas d’utilisation 46

Z Pour bien recenser les cas d’utilisation :

se placer du point de vue de chaque acteur et déterminer
comment il se sert du système, dans quels cas il l’utilise, et à
quelles fonctionnalités il doit avoir accès.
éviter les redondances et limiter le nombre de cas en se situant
au bon niveau d’abstraction (par exemple, ne pas réduire un
cas à une seule action).
ne pas faire apparaître les détails des cas d’utilisation, mais il
faut rester au niveau des grandes fonctions du système.
Z Chaque cas d’utilisation doit être documenté pour qu’il n’y ait
aucune ambiguïté concernant son déroulement et ce qu’il
recouvre précisément.
Description des cas d’utilisation 47

La description des cas d’utilisation comprend :

Le début du cas d’utilisation.
La fin du cas d’utilisation.
L’interaction entre le cas d’utilisation et les acteurs.
Les échanges d’informations (paramètres des interactions).
La chronologie et l’origine des informations.
Les répétitions de comportement.
Les situations optionnelles.
Description des cas d’utilisation 48

Il y a en UML 3 représentations possibles pour un scénario :

description textuelle en langage naturel
diagramme de séquence
diagramme de collaboration
Description des cas d’utilisation 49

La description d’un cas d’utilisation

débute par une phrase du type
« Ce cas d’utilisation est déclenché quand <un acteur>
<adresse un stimulus au système> »
privilégie les interactions entre les acteurs et le système
s’attache prioritairement à la séquence des événements qui
conditionnent les interactions (flux nominal)
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
Description textuelle des cas d’utilisation 50

La fiche de description textuelle d’un cas d’utilisation n’est pas

normalisée par UML.
Toutefois on peut adopter la structuration suivante :

Sommaire d’identification (obligatoire)

titre, résumé, dates de création et de modification, version,
responsable, acteurs...

Description des scénarios (obligatoire)

Décrit le scénario nominal, les scénarios (ou enchaînements)
alternatifs, les scénarios (ou enchaînements) d’erreur, mais aussi les
préconditions et les postconditions.
Description textuelle des cas d’utilisation 51

Nom du cas d’utilisation

But
Brève description
Acteurs
Contexte
Données en entrée et pré-conditions
Données en sortie et post-conditions
Scénario principal pour ce cas d’utilisation
Étapes à suivre pour réaliser ce cas
Variantes, cas d’erreur
Déviations des étapes du scénario principal, scénarios
alternatifs, scénarios d’erreur
Exemple de cas d’utilisation 52
Exemple de cas d’utilisation 53
Exemple de Description textuelle des cas d’utilisation 54

Identification
Nom du cas : Payer CB
Objectif : Détailler les étapes permettant à client de payer par
carte bancaire
Acteurs : Client, Banque (secondaire)
Date : 10/09
Exemple de Description textuelle des cas d’utilisation 55

Séquencements : :
début : un client demande le paiement par carte bancaire
Pré-conditions
Le client a validé sa commande
Enchaînement nominal
1 Le client saisit les informations de sa carte bancaire
2 Le système vérifie que le numéro de CB est correct
3 Le système vérifie la carte auprès du système bancaire
4 Le système demande au système bancaire de débiter le client
5 Le système notifie le client du bon déroulement de la
transaction
Exemple de Description textuelle des cas d’utilisation 56

Enchaînements alternatifs
1 En (2) : si le numéro est incorrect, le client est averti de
l’erreur, et invité à recommencer
2 En (3) : si les informations sont erronées, elles sont
re-demandées au client
Post-conditions
La commande est validée
Le compte de l’entreprise est crédité
Cas d’utilisation (bonnes pratiques) 57

Z Se placer du point de vue de chacun des acteurs :

que fait-il avec le système ?
qu’attend-il du système ?
Z Un cas d’utilisation n’est déclenché que par un seul acteur
Z Limiter le nombre de cas en se plaçant au bon niveau
d’abstraction (« la mer »)
Z Décomposer les cas d’utilisation du type « Gérer »en :
« Créer... », « Modifier... », « Annuler... », « Lister... »,
« Éditer... », « Consulter... », « Rechercher... »,
« Archiver... », « Désarchiver... »
Les différents niveaux de cas d’utilisation 58

Un cas d’utilisation, comme tout diagramme UML, permet de

décrire une réalité selon différents niveaux de raffinement :
Niveau fonctionnalité(Objectifs utilisateur )
C’est l’objectif directement suivi par un acteur en interaction
avec le système.
Sa durée, de 2 à 20 minutes, peut être réduite si le
déclencheur est un système.
Exemples : S’inscrire à un module, Consulter un examen blanc
- Calculer la note finale
Les différents niveaux de cas d’utilisation 59

Niveau fonctionnalité(Objectifs utilisateur )cf. [Alistair Cockburn]

niveau de la mer
L’utilisateur est-il satisfait après avoir terminé le cas
d’utilisation ?, par exemple (réservation en ligne) :
cas d’utilisation de niveau utilisateur (client)
« réserver un hôtel », « réserver un vol »
cas d’utilisation trop bas :
« chercher un vol », « choisir une place », « chercher un
hôtel », « choisir une chambre »
cas d’utilisation trop hauts :
« réserver un voyage »
composé de sous-objectifs sous le niveau de la mer
compose des objectifs au dessus du niveau de la mer
Les différents niveaux de cas d’utilisation 60

Niveau stratégique :
Présente le contexte général, les grandes fonctions du système
(approche métier), ses objectifs.
Un cas d’utilisation de niveau stratégique implique plusieurs
objectifs utilisateur et s’étale généralement sur plusieurs jours,
semaines, mois ou années.
Exemples : L’étudiant s’inscrit à une formation - L’étudiant
s’inscrit à des modules - L’étudiant passe ses examens -
L’étudiant obtient son diplôme
Les différents niveaux de cas d’utilisation 61

Niveau stratégique(Objectifs stratégiques) cf. [Alistair Cockburn]

au dessus du niveau de la mer
impliquent plusieurs objectifs utilisateurs
servent à :
montrer le contexte de l’utilisateur
montrer le séquencement des objectifs liés
fournir une table des matières
Les différents niveaux de cas d’utilisation 62

Niveau sous-fonctionnalité
Ce sont des cas d’utilisation qui participent au bon
déroulement ou complètent des cas d’utilisation de niveau
fonctionnalité(niveau utilisateur).
Exemples : S’identifier - Éditer un examen blanc

Niveau sous-fonctionnalité (cf. [Alistair Cockburn])

sous le niveau de la mer
impliquent plusieurs objectifs utilisateurs
servent à :
identifier les cas simples
fractionner une partie de cas d’utilisation

Difficulté majeure : de trouver le bon niveau d’abstraction.

Les différents niveaux
Réserver un
de cas d’utilisation NIVEAU
63
voyage STRATÉGIQUE

Réserver un
voyage
NIVEAU
Réserver un
hôtel UTILISATEUR

Réserver un
vol

Chercher un
« include »
Réserver un hôtel
voyage Réserver un
hôtel
« include »
Chercher une
« include »
chambre
Réserver un
vol Chercher un
vol NIVEAU
SOUS-FONCTION
« include »

Choisir une
place
La transition vers les objets 64
 Démarche de construction du modèle des cas d’utilisation
65
Cas d’utilisation 66

En conclusion
Z Le diagramme d’utilisation permet :
d’exprimer simplement les besoins des utilisateurs
d’analyser les besoins des utilisateurs de déterminer les
interfaces du système
Z Le diagramme d’utilisation n’est pas un modèle
Z Il est inutile d’avoir une description exhaustive des relations
Ne pas confondre utilisateur et acteur
Cas d’utilisation 67
En conclusion
Z Le diagramme de cas d’utilisation est plus riche que le
diagramme acteur/flux de merise
Z En plus des acteurs et des communications, il y a les
différentes fonctionnalités attendues
Z permet de les organiser grâce aux relations d’héritages,
d’inclusion, d’extension
Z Les descriptions textuelles et les scénario d’utilisation
permettent à l’analyste d’exprimer de manière semi-formelle les
besoins fonctionnels et non fonctionnels du système étudié(son
cahier de charges)
Autres diagrammes possibles pour compléter la description d’un cas
d’utilisation :
Diagramme d’activités
Diagramme de séquence(vision boîte noire)