TEK-UP Ecole Supérieure Privée Technologie

& Ingénierie

Modélisation
UML

A.U. 2019-2020
Plan du cours

I. Introduction

II. Modélisation des besoins (Use Case)

III. Analyse: Modèle structurel

IV. Conception: Modèle structurel

V. Analyse: Modèle dynamique

VI. Conception: Modèle dynamique

VII. Architecture Physique

2
Ch. II
Modélisation des
besoins

3
 Motivation
Pourquoi les cas d’utilisation :
• Un système est conçu pour les utilisateurs :
• ils savent ce que le système doit faire mais pas comment le
faire ;
• ils connaissent l’aspect fonctionnel du système.

Le système doit donc être bâti à partir des descriptions des

utilisateurs.

4
 Motivation

Vue logique Vue des composants

Besoins des utilisateur= vue des cas

d’utilisation

Vue des processus Vue de déploiement

5
 Diagramme des cas d’utilisation
Un diagramme de cas d’utilisation est modélisé par :
▪ des acteurs qui utilisent le système ;
▪ les ‘services’ offerts par le système.

• Intérêt des cas d’utilisation :

▪ les use cases permettent de délimiter le système (les acteurs sont à
l’extérieur du système) ;
▪ ils permettent de lever les ambiguïtés du cahier des charges à l’aide
d’un formalisme graphique ;
▪ les use cases peuvent servir à concevoir les tests puisqu’ils
représentent les utilisations nominales du système.
▪ Initie le travail d’équipe

6
 L’utilisateur et le système

Use Case 1

Use Case 2 Services

Utilisateur
Use Case 3

Système

7
 ➢ Diagramme de cas d’utilisation répond aux questions suivantes :
● Quelles sont les tâches principales réalisées par les acteurs
(entités matériels ou logiciels externe au logiciel qui entrent
en interaction) ?
● Les informations manipulées par les acteurs ?
● Les informations manipulées par le logiciel ?
● Le diagramme contient les acteurs, les cas d’utilisation
(services) et les applications.

8
 Diagramme de cas d’utilisation
● Un diagramme de cas d’utilisation :
● décrit
● le système
● les acteurs
● les cas d’utilisation
● contient
● des descriptions textuelles

9
 Principaux concepts des diagrammes de cas d’utilisation

● Acteurs

● Système

● Cas d’utilisation

● Relations (entre cas d’utilisation, entre acteurs, entre acteurs

et cas d’utilisation)

10
 Le système
● Le système est un ensemble de cas d’utilisation
● Le système ne comprend pas les acteurs.

Nom du système

Nom du
système

11
 Le système
● Le système est
● modélisé par un ensemble de cas d’utilisation
● vu comme une boîte noire
● Le système contient :
● les cas d’utilisation,
● mais pas les acteurs.
● Un modèle de cas d’utilisation permet de définir :
● les fonctions essentielles du système,
● les limites du système,
● le système par rapport à son environnement,
● délimiter le cadre du projet !

12
 Acteurs
● Un Acteur = élément externe qui interagit avec le système (prend des
décisions, des initiatives. Il est "actif".)
● rôle qu’un "utilisateur" joue par rapport au système
● Ex. : un client, un guichetier, un responsable maintenance, …

13
 Acteurs
● Un acteur est représenté par:
● un petit bonhomme (stick man) avec son nom dessous ou
● par un rectangle contenant le mot-clé << actor>> avec son nom dessous ou
● Par un mélange de ces 2 représentations

<<actor>>
Nom de l’acteur Nom de l’acteur
Nom
acteur

acteur humain acteur non humain

● Pour les identifier :
● Quelles sont les entités externes au système qui interagissent directement avec le
système ?

14
 Utilité des acteurs
● La définition d’acteurs permet
● d’identifier les cas d’utilisation
Ex. : que peut faire un guichetier ? un client ? le directeur ?
● de voir le système de différents points de vues
● de déterminer des droits d’accès par type d’acteur
● de fixer des ordres de priorité entre acteurs
● ...

15
 Acteurs vs. utilisateurs
● Ne pas confondre la notion d'Acteur et de personne utilisant
le système:
● Une même personne physique peut jouer le rôle de plusieurs acteurs
Ex. : Maurice est un Chef d’agence et est aussi un client de la banque.
● Plusieurs personnes peuvent jouer un même rôle
Ex. : Paul et Pierre sont deux clients

● Un acteur n’est pas forcément un être humain ex: un

distributeur de billet peut être vu comme un acteur

16
 Le recensement des acteurs
❑ Comment ?
▪ Par un dialogue avec le client et les utilisateurs ;
▪ en repérant les frontières du système.

❑ Qui sont-ils ?
▪ Des utilisateurs humains : utilisateurs du logiciel à travers son interface
graphique, par exemple;
▪ des périphériques manipulés par le système (imprimantes, capteurs, … ) ;
▪ des logiciels déjà disponibles à intégrer dans le projet : disponibles qui
communiquent avec le système grâce à une interface logicielle (API, ODBC,
…);
▪ attention à ne pas oublier les acteurs qui administrent le système ;
▪ un même utilisateur peut avoir plusieurs rôles et être plusieurs acteurs :
17
 Acteurs

<<acteur>>
Secrétaire Site Web de l'établissement

Etudiant
Système de Gestion
Scolaire
<<acteur>>
Imprimante

18
 Différents types d’acteurs
●Utilisateurs principaux
ex: client, guichetier
● Utilisateurs secondaires
ex: contrôleur, directeur, ingénieur système, administrateur...
● Périphériques externes
ex: un capteur, une horloge externe, …
●Systèmes externes
ex: systèmes bancaires

19
 Exemple: une bibliothèque

Chercheur
Système
bibliothèque

Bibliotécaire

Département

20
 Exemple

Client

21
 Exemple

RetirerDeLArgentAu
Distributeur
Client Banque
Centrale

ConsulterSonCompte
RetirerLes
CartesAvalées

Ajouter Assurer
Transporteur Technicien
DeBillets DesBillets LaMaintenance

DistributeurDeBillet
22
 Acteurs
Mais du point de vue système on distingue deux types :
● Acteurs principaux
● Acteurs secondaires

23
 Acteurs principaux et secondaires
● Acteur principal d’un CU
● Celui pour qui le CU produit un résultat observable
● A gauche des CU
● Rôle indiqué éventuellement sur l’association côté acteur :
<<principal>>
(valeur par défaut)

● Acteur secondaire d’un CU

● Celui pour qui le CU ne produit pas un résultat observable par
l’utilisateur
● Souvent sollicités pour des informations complémentaires
● Peuvent uniquement consulter ou informer le système (pas d’objectif à
part entière de la part de l’acteur secondaire)
● A droite des CU
● Rôle indiqué éventuellement sur l’association côté acteur :
<<secondaire>>
23 ● Ex. : système d’authentification appelé par le distributeur de billets
 Cas d’utilisation (CU)
● Cas d’utilisation (CU)
● une manière d’utiliser le système
● une suite d’interactions entre un acteur et le système
● Correspond à une fonction du système visible par l’acteur
● Doit être utile en soi
● Permet à un acteur d’atteindre un but
● Regroupe un ensemble de scénarii correspondant à un
même but

25
 Cas d’utilisation: définition
▪ “Description d’un ensemble de séquences d’actions,
comportant éventuellement des variantes, que le système
exécute pour produire un résultat tangible et qui a de la
valeur pour l’utilisateur.”

Payercotisationmembre Consultercatalogue

Enregistrer nouvel utlisateur Emprunter unlivre

Réserver un livre

26
 Cas d'utilisation
Les cas d’utilisations
● Permettent de modéliser les attentes (besoins) des
utilisateurs
● Représentent les fonctionnalités du système
● Suite d’événements, initiée par des acteurs, qui
correspond à une utilisation particulière du système
● L’image d’une fonctionnalité du système, déclenchée
en réponse à la stimulation d’un acteur externe.

27
 Cas d'utilisation
Un cas d'utilisation est représenté par une ellipse en trait
plein, contenant son nom.

Nom Cas Utilisation

28
 Relations entre éléments de base

● Relations acteurs <-> cas d'utilisation ?

● Relations acteurs <-> acteurs ?

● Relations cas d'utilisation <-> cas d'utilisation ?

29
 Relation acteur - cas d'utilisation
● Point de vue besoin: Représente la possibilité d'atteindre
un but
● Point de vue système: Représente un canal de
communication
● Échange de messages, potentiellement dans les deux sens
● Protocole particulier concernant le cas d'utilisation
considéré

30
 Une relation de communication

RetirerDeLArgent
Client AuDistributeur

❑ Association acteur/CU vu comme un canal de communication

❑ Décrit le comportement du système vu de l'exterieur
❑ Echange de messages

RetirerDeLArgent
Client AuDistributeur

31
 Diagramme de cas d ’utilisation

RetirerDeLArgentAu
Distributeur
Client

ConsulterSonCompte
RetirerLes
CartesAvalées

Ajouter Assurer
Transporteur Technicien
DeBillets DesBillets LaMaintenance

DistributeurDeBillets
32
 Relation de communication acteur-acteur

• Communications externes
non modélisée
ConsulterSonCompte

Client
• UML seconcentre sur la
description du systèmeet RetirerDeLArgent
desesinteractions avec AuDistributeur

l'extérieur

RetirerDeLArgent
ParChèque

Guichetier
Système
Bancaire
33
 Relation acteur - acteur :
généralisation
Un acteur peut être une spécialisation
d'un autre acteur déjà défini.
Acteur général

Dans ce cas, on utilise la relation de

généralisation/spécialisation.

Acteur spécialisé

34
Relations cas d'utilisation - cas d'utilisation

UML définit trois types de relations standardisées entre

cas d'utilisation :
● Une relation d'inclusion, formalisée par la dépendance
«include»
● Une relation d'extension, formalisée par la dépendance
«extend»
● Une relation de généralisation/spécialisation

35
 Les relations entre cas d’utilisation
❑ Les trois types de relations sont :
❑ l’inclusion (<<include>>)quand le cas source comprend le cas
destination ;
❑ l’extension (<<extends>>) quand le cas source ajoute
optionnellement son comportement au cas destination.
❑ la généralisation quand le cas enfant est une spécialisation du cas
parent ;

36
 Exemple de relations entre cas d'utilisation :
inclusion, extension et spécialisation
« include »

« include » RetirerDeLArgent

S'Identifier

« include »

Transferer
DeLArgent

« extends »
« extends »

RetirerDeLArgent RetirerDeLArgent
AvecRecu

RetirerDeLArgent RetirerDeLArgent
AuDistributeur
37
 Relation d'inclusion
● A inclut B : le cas A inclut obligatoirement le
comportement définit par le cas B; permet de factoriser
des fonctionnalités partagées
● Le cas d'utilisation pointé par la flèche (dans notre cas
B) est une sous partie de l'autre cas d'utilisation (A,
dans notre exemple).

<<include>>

38
 Relation d'inclusion
Les cas d'utilisation "Déposer de
l'argent", "Retirer de l'argent", "Effectuer
Retirer de l'argent des virements" et "Consulter solde"
incorporent de façon explicite le cas
d'utilisation "S'authentifier", à un endroit
spécifié dans leurs enchaînements.
<<include>>
Déposer de l'argent

<<include>>

S'authentifier

<<include>>
Effectuer des virements

<<include>>

Consulter solde

39
 Relation d'inclusion
Remarques
● La relation include n’a pour seul objectif que de
factoriser une partie de la description d’un cas
d’utilisation qui serait commune à d’autres cas
d’utilisation.
● Le cas d’utilisation inclus dans les autres cas
d’utilisation n’est pas à proprement parlé un vrai cas
d’utilisation car il n’a pas d’acteur déclencheur ou
receveur d’évènement. Il est juste un artifice pour faire
de la réutilisation d’une portion de texte.

40
 Relation d'extension
● Le CU source (B) ajoute, sous certaines conditions,
son comportement au CU destination (A)
● En d’autres termes, le CU B peut être appelé au cours
de l’exécution du CU A
A
B Point d'insertion
<<extend>>

● Le comportement ajouté s’insère au niveau d’un point

d’extension définit dans le CU destination

41
 Relation d'extension
● Le cas d'utilisation de destination peut fonctionner tout
seul, mais il peut également être complété par un autre
cas d'utilisation, sous certaines conditions.
● On utilise principalement cette relation pour séparer le
comportement optionnel (les variantes) du
comportement obligatoire.

42
 Relation d'extension
Exemple :
Au moment de l'authentification, il se peut que le guichet
retient la carte.

S'authentifier
Retenir la carte
<<extend>>

43
 Relations d’inclusion VS d'extension
● La relation extend montre une possibilité
d'exécution d'interactions qui augmenteront les
fonctionnalités du cas étendu, mais de façon
optionnelle, non obligatoire,
● La relation "include" suppose une obligation
d'exécution des interactions dans le cas de base.

44
 Relation d'héritage
● Il peut également exister une relation d'héritage entre
cas d'utilisation.
● Cette relation exprime une relation de
spécialisation/généralisation au sens classique.

45
 Relation d'héritage : Exemple
Dans un système d'agence de voyage, un acteur
"Touriste" peut participer à un cas d'utilisation de
base qui est "Réserver voyage", qui suppose par
exemple, des interactions basiques au comptoir
de l'agence. Une réservation peut être réalisée par
téléphone ou par Internet.

46
 Relation d'héritage : Exemple
● On voit qu'il ne s'agit pas d'une relation "extend", car la
réservation par Internet n'étend pas les interactions ni les
fonctionnalités du cas d'utilisation "Réserver voyage".
● Les deux cas d'utilisation "Réservation voyage" et
"Réserver voyage par Internet" sont liés : la réservation
par Internet est un cas particulier de réservation.
● De façon générale en objet, une situation de cas
particulier se traduit par une relation de
généralisation/spécialisation.

47
 Relation d'héritage : Exemple

Reserver voyage

Réserver voyage par téléphone Réserver voyage par Internet

48
 Relations entre cas d’utilisation
Résumé
Les cas peuvent être structurées par des relations :
● A inclut B : le cas A inclut obligatoirement le
comportement définit par le cas B; permet de factoriser
des fonctionnalités partagées
● A étend B : le cas A est une extension optionnelle du
cas B à un certain point de son exécution.
● A généralise B : le cas B est un cas particulier du cas
A.

49
 Relations entre cas d’utilisation :
Exemple
Un client peut effectuer un retrait bancaire. Le retrait
peut être effectué sur place ou par Internet. Le client
doit être identifié (en fournissant son code d’accès)
pour effectuer un retrait, mais si le montant dépasse
500DT, la vérification du solde de son compte est
réalisée.

50
 Cas du publiphone
1. Le prix minimal d’une communication interurbaine est de0.1 Dt.
2. Après l’introduction dela monnaie, l’utilisateur a2 mn pour
composer son numéro(ce délai estdécomptépar le standard).
3. Laligne peut être libre ouoccupée.
4. Le correspondant peut raccrocher le premier.
5. Le publiphone consommedel’argent dèsquel’appelé décroche et à
chaque unité detemps (UT) généréepar le standard.
6. On peut ajouter despièces àtoutmoment.
7. Lors du raccrochage, le soldede monnaieest rendu.

51
 Le diagramme des use case

Publiphone

«actor»
téléphoner Standard

secondaire
Appelant

52
53
 Description des cas d’utilisation
● Le diagramme de cas d’utilisation décrit les grandes
fonctions d’un système du point de vue des acteurs.
● Mais il n’expose pas de façon détaillée le dialogue
entre les acteurs et les cas d’utilisation.
● nécessité de décrire ce dialogue

54
 Description de l'interaction

RetirerDeLArgent
Client AuDistributeur

Description du dialogue
• via une description textuelle
ou
• via des diagrammes de
séquences "systèmes"

55 Plus tard dans le cours

...
 L’élaboration des cas d’utilisation
❑ Les use cases peuvent être décrits sous la forme de
flots d’événements de différentes façons :

Le distributeur affiche un message d’accueil

demandant à un client d’introduire sa carte
bancaire ;
• le client introduit sa carte bancaire ;
•le distributeur demande le mot de passe de la
carte ;
• ...
56
 Scénario
● Pour décrire ou valider un CU
● Un scénario est un exemple :
● une manière particulière d’utiliser le système …
● … par un acteur particulier …
● … dans un contexte particulier.
● cas d’utilisation = ensemble de scénarios
● scénario = une exécution particulière d’un CU

57
 Exemples de scénarios
● Appel téléphonique
● Scénario : le numéro appelé est occupé
● L'appelant décroche le téléphone
● L'appelant commence à composer le numéro
● L'appelant termine de composer le numéro
● La tonalité "occupée" commence à sonner
● L'appelant raccroche le téléphone
● Scénario : le numéro appelé n'est pas occupé
● L'appelant décroche le téléphone
● L'appelant commence à taper le numéro
● L'appelant termine de taper le numéro
● Le téléphone commence à sonner
● L'appelé décroche
● La conversation se déroule
● L'appelé raccroche le téléphone

58
L’élaboration des cas d’utilisation
❑ Un cas d’utilisation est généralement décrit par plusieurs
scénario :
❑ Regroupe une famille de scénarios d’utilisation (cas nominal, alternatives, exceptions)
❑ Est une ab straction du dialogue s ystème/utilisat❑eQuursand un acteur interagit avec le
système:
❑Le cas d’utilisation instancie un
scénario

59
 Exemple de scénario
SCENARIO
• Paul insère sa carte dans le distributeur d103
• Le système accepte la carte et lit le numéro de compte
Retirer • Le système demande le code
DeLArgent • Paul tape ‘ 1234 ’
AuDistributeur • Le système indique que ce n ’est pas le bon code
• Le système affiche un message et propose de recommencer
• Paul tape ‘ 6222’
• Le système affiche que le code est correct
• Le système demande le montant du retrait
• Paul tape 5000 Euros
• Le système vérifie s ’il y a assez d ’argent sur le compte
•...

60
 Description Textuelle des cas
d’utilisation
❑ Il n’existe pas de norme (UML) établie pour la description
textuelle des cas d’utilisation.
❑ Généralement, on y trouve pour chaque cas d’utilisation :
• son nom,
• un bref résumé de son déroulement,
• le contexte dans lequel il s’applique,
• les acteurs qu’il met en jeu,
• une description détaillée :
• le déroulement nominal de toutes les interactions,
• les cas nécessitant des traitements d’exception,
• les effets du déroulement sur l’ensemble du système,
• des contraintes,
• etc.
61
 Description des cas d’utilisation
Sommaire d’identification
Titre : ……………….. Type : …………………
Résumé :………………………………………………………………………………
Acteurs :
Date de création : Date de mise à
jour :…………………………………
Version : Auteur(s) :

Description des Enchaînements :

Pré conditions :
Scénario nominal :
1.
2.
…
Enchaînements alternatifs / Exceptions:
A1…
A2…
Contraintes
62….
 Exemple de description détaillée
d ’un CU

Précondition :
Le distributeur contient des billets, il est en attente d ’une
opération, il n’est ni en panne, ni en maintenance
Retirer
DeLArgent Début : lorsqu ’un client introduit sa carte bancaire dans le
AuDistributeur distributeur.

Fin : lorsque la carte bancaire et les billets sont sortis.

Postcondition :
Si de l ’argent a pu être retiré la somme d’argent sur le
compte est égale à la somme d ’argent qu’il y avait avant,
moins le montant du retrait. Sinon la somme d ’argent sur le
compte est la même qu’avant.

63
 Exemple de description détaillée
d ’un CU
Déroulement normal :
(1) le client introduit sa carte bancaire
(2) le système lit la carte et vérifie si la carte est valide
(3) le système demande au client de taper son code
(4) le client tape son code confidentiel
Retirer
(5) le système vérifie que le code correspond à la carte
DeLArgent
AuDistributeur (6) le client choisi une opération de retrait
(7) le système demande le montant à retirer
…
Variantes :
(A)Carte invalide : au cours de l ’étape (2) si la carte est
jugée invalide, le système affiche un message d ’erreur,
rejète la carte et le cas d ’utilisation se termine.
(B) Code erroné : au cours de l ’étape (5) ...

64
 Exemple de description détaillée
d ’un CU
Contraintes non fonctionnelles :

(A) Performance : le système doit réagir dans un délai

inférieur à 4 secondes, quelque soit l’action de l ’utilisateur.
Retirer
DeLArgent
AuDistributeur (B) Résistance aux pannes : si une coupure de courant ou
une autre défaillance survient au cours du cas d ’utilisation,
la transaction sera annulée, l ’argent ne sera pas distribué.
Le système doit pouvoir redémarrer automatiquement dans
un état cohérent et sans intervention humaine.

(C) Résistance à la charge : le système doit pouvoir gérer

plus de 1000 retraits d ’argent simultanément
...

65
Exercice de Cas d’utilisation : Fonctionnement des
caisses enregistreuses d’un super marché
● Un système simplifié de caisse enregistreuse de supermarché :
● Un client arrive à la caisse avec des articles à payer
● Le caissier enregistre le numéro d’identification de chaque article, ainsi que la quantité si
elle est supérieure à un.
● La caisse affiche le prix de chaque article et son libellé.
● Lorsque tous les achats sont enregistrés, le caissier signale la fin de la vente.
● La caisse affiche le total des achats.
● Le client choisit son mode de paiement :
● Liquide : le caissier encaisse l’argent reçu, la caisse indique la monnaie à rendre au client.
● Chèque : le caissier vérifie la solvabilité du client en transmettant une requête à un centre
d’autorisation via la caisse.
● Carte de crédit : un terminal bancaire fait partie de la caisse. Il transmet une demande
d’autorisation en fonction du type de carte.
● La caisse enregistre la vente et imprime le ticket
● Le caissier donne le ticket de caisse au client.
● Après saisie article le client peut présenter des coupons de réduction.
● Lorsque le paiement est termine, la caisse transmet les informations sur le nombre
d’articles vendus au système de gestion des stocks.
● Tous les matins, le responsable du magasin initialise les caisses pour la journée.

66
 Diagramme de Cas d’utilisation de la
caisse
Responsable Initialier la caisse
Magasin
<<étend>>
Prendre en compte coupons

Traiter le passage en caisse

Caissier
<<Acteur>>
<<inclut>> Gestion des stocks

Client <<Acteur>>
Traiter le Paiement Centre autorisation
cartes

<<Acteur>>
Centre autorisation
Paiement Liquide Paiement Chèque Paiement Carte
chèques

67
 Description des Cas d’utilisation
‘caisse’
Sommaire d’identification
Titre : Traiter le passage en caisse
Résumé : un client arrive à une caisse avec des articles à acheter. Le caissier
enregistre les achats et récupère le paiement. A la fin de l’opération, le client part
avec les articles.
Acteurs : Caissier (P), Client (S), Gestion des stock (S)
Date de création : Date de mise à jour :…………………………………
Version : 1 Auteur(s) : Mr Foulen
Description des Enchaînements :
Pré conditions : La caisse est en service : un caissier y est connecté
Scénario nominal :
Représente le déroulement normal d’un cas d’utilisation : les différentes
interactions utilisateur / système permettant l’exécution réussie du traitement

(voir suite)

68
Description (suite)
1.Ce CU commence quand un client arrive
à la caisse avec des articles qu’il veut
acheter.
2.Le caissier enregistre chaque article. S’il y 3. La caisse détermine le prix de l’article et
a plus d’un exemplaire par article, le caissier ajoute des informations sur l’article à la vente
indique également la quantité. en cours.
4. Après avoir enregistré tous les articles, La caisse affiche la description et le prix de
le caissier indique que la vente est l’article en question.
terminée. 5. La caisse calcule et affiche le montant total
6.Le caissier annonce le montant total au de la vente.
client.
7. Le client choisit le type de paiement :
a. En cas de paiement …
b. En cas de …
c. En cas …

8. La caisse enregistre la vente et imprime

…
9. Le caissier donne le ticket de caisse
au client.
69
 Description (suite)
❑ Enchaînement alternatif :
❑ Quand l’enchaînement précisé par le scénario nominal ne peut pas se
dérouler comme prévu :
❑ Le cas d’utilisation converge tout de même.

❑ Exemple:
❑ Numéro d’identification d’un article est inconnu
❑ l’enchaînement démarre au point 2 du scénario nominal.
❑ 3. La caisse indique que le numéro d’identification de l’article est
inconnu. L’article ne peut alors pas être pris en compte dans la vente
encours.
❑ Le scénario reprend au point 2.

70
 Description (suite)
❑ Enchaînement d’erreur :
❑ Quand l’enchaînement précisé par le scénario nominal ne peut pas se dérouler
:
❑ Le cas d’utilisation se termine par un échec.

❑ Exemple:
❑ Client ne pouvant payer (ou le centre d’autorisation refuse le payement)
❑ l’enchaînement démarre au point 6 du scénario nominal.
❑ 7. Le client ne peut pas payer le total avec aucun des moyens autorisés.
❑ 8. Le caissier annule l’ensemble de la vente et le cas d’utilisation se termine en
échec :
❑ € la vente ne peut pas avoir lieu

71
 Conclusion
❑ Lescas d’utilisation est une forme possible de
documentation des besoins d’un système :
❑ une description textuelle peut suffire ;
❑ un maquettage simple représentant l’interface graphique d’un
système est très utile ;

❑ Lescas d’utilisation décrivent le « quoi » d’un système

mais pas le « comment » ;

❑ Ily a en général peu de cas d’utilisation mais beaucoup

de scénarios.

72
 Conclusion (…)
❑ Les avantages :
❑ Un formalisme simple :
❑ Les concepts proposés sont faciles à comprendre et à utiliser.
❑ Les modélisations résultats (UC):
❑ Faciles à comprendre, à lire et à interpréter.
❑ Un bon moyen de communication : client/concepteur et
concepteur/concepteur

❑ Les limitations :
❑ Subjectifs, dépendant de l’utilisateur :
❑ Peuvent être peu précis, ne reflétant pas les besoins majeurs de l’utilisateur ou
interprétés différemment.
❑ Pas formels : pas de vérification automatique possible ni de génération des
autres diagrammes, …
73
 Pour en savoir un plus...

Chapitre gratuit téléchargeable à

http://www.craiglarman.com/book_applying_2nd/Applying_2nd

Pour un template "standard" de description de cas d'utilisation

http://alistair.cockburn.us/usecases/uctempla.htm

74