Ce que l’utilisateur attend du système
Pourquoi faire ?
Ce n’est pas du code !!
Être sûr que le système développé répond aux besoins
de l’utilisateur final :
- cartographie des fonctionnalités
Donne une vue globale du système
ce qui est externe au système (acteurs)
les fonctionnalités du système (use cases)
Point de vue de l’utilisateur externe
Syntaxe
Acteurs <<actor>> <<actor>>
Cas d’utilisation
« use cases » nom
Relations
acteur/cas
cas i / cas j
Le diagramme
Frontière du
système
Nom du système
<<actor>>
Acteur non humain
Cas 1
Cas d’utilisation 1
Acteur humain 1
Cas 2
Cas d’utilisation 2
association
Acteur humain 2
Exemple
Navigateur web
<<actor>>
ordinateur
Consulter
page web
Cas d’utilisation 1
utilisateur
Exercer contrôle
parental
Cas d’utilisation 2
administrateur
Acteur (Actor)
Quelqu’un ou quelque chose
EXTERNE au système
Qui interagit avec le système
<<actor>>
SI Banque
Client Stick-man
SI Banque
Relations entre acteurs
Généralisation/spécialisation
Acteur
générique
acteur1
Acteur
spécialisé
acteur2
Le Client
Exemple
Navigateur web
<<actor>>
ordinateur
Consulter
utilisateur page web
Cas d’utilisation 1
Exercer contrôle
parental
Cas d’utilisation 2
administrateur
Cas d’utilisation (Use case)
Fonctionnalité visible
C’est un objectif que l’on (le client) veut atteindre
grâce au système à développer
Séquence déclenchée par un acteur
PAS un module du système
Consulter compte
Client Le système permet à l’acteur Client
de consulter son compte
Acteur primaire/secondaire
<<actor>>
Secondaire Acteur non humain
Cas d’utilisation 1
Acteur humain 1
Cas d’utilisation 2
Acteur primaire : bénéficiaire de la
fonctionnalité Acteur humain 2
Acteur secondaire : participant à la
réalisation de la fonctionnalité
Description textuelle d’un cas
Sommaire d’identification Inclut titre, résumé, dates de création et de modification,
(obligatoire) version, responsible, acteurs…
Description des scénarios Décrit le scénario nominal, les scénarios (ou
(obligatoire) enchaînements) alternatifs, les scénarios (ou enchaînements)
d’erreur, mais aussi les préconditions et les postconditions.
Exigences non-fonctionnelles Ajoute, si c’est pertinent, les informations suivantes :
(optionnel) fréquence, volumétrie, disponibilité, fiabilité, intégrité,
confidentialité, performances, concurrence, etc. Précise
également les contraintes d’interface homme-machine
comme des règles d’ergonomie, charte graphique…
Scénario
Succession particulière d’enchaînements, s’exécutant
du début à la fin d’un cas d’utilisation
Un cas d’utilisation contient en général un scénario
nominal et plusieurs scénarios alternatifs ou d’erreur
début
Fin normale
erreur
En résumé
Liste de fonctionnalités
Liste des « acteurs » à qui elles sont dédiées
Utilisateurs « type »
Associe chaque utilisateur type aux fonctionnalités qui
lui sont dédiées
Mais qui fait ce genre de job ???
=> Analyste fonctionnel
TD
Guichet Automatique de
Banque (GAB)
0..1 0..1
0..1
0..1 0..1
0..1 0..1
0..1
0..1
Liste des cas d’utilisation
Porteur de carte
Retirer de l’argent
Client Banque
Retirer de l’argent
Consulter le solde de son compte courant
Déposer du numéraire
Déposer des chèques
Opérateur de maintenance
Recharger le distributeur
Récupérer les cartes avalés
Récupérer les chèques déposés
Description textuelle
Sommaire
Titre : Retirer de l’argent
Résumé : ce cas d’utilisation permet à un porteur de carte, qui n’est
pas client de la banque, de retirer de l’argent, si son crédit
hebdomadaire le permet.
Acteurs : porteur de carte non client (principal), Sys. Auto. (secondaire)
Date de création : 01/11/2005 Date de mise à jour : 30/11/2005
Version : 3.2 Responsable : FTB
Description des scénarios
Préconditions
La caisse du GAB est alimentée (au moins 1 billet)
Aucune carte ne se trouve déjà dans le lecteur
Scénario nominal
1. Le porteur de carte introduit sa carte dans le lecteur de cartes
2. Le GAB vérifie que la carte introduite est une carte bancaire
3. Le GAB demande au porteur de carte son code
4. Le porteur de carte saisit son code
5. Le GAB compare le code d’identification avec celui qui est codé sur
la carte
6. Le GAB demande une autorisation au système d’autorisation global
7. Le système d’auto. donne son accord et indique le solde hebdo
8. Le GAB demande au porteur de carte de saisir le montant désiré du
retrait
Scénario nominal (suite)
9. Le porteur de carte saisit le montant désiré du retrait
10. Le GAB contrôle le montant demandé par rapport au solde
hebdomadaire
11. Le GAB demande au porteur de carte s’il veut un ticket
12. Le porteur de carte demande un ticket
13. Le GAB rend sa carte au porteur de carte
14. Le porteur de carte reprend sa carte
15. Le GAB délivre les billets et un ticket
16. Le porteur de carte prend les billets et le ticket
Enchaînements alternatifs
A1 : code d’identification provisoirement erroné
démarre au point 5 du scénario nominal
6. Le GAB indique au porteur de carte que le code est erroné, pour
la première ou deuxième fois
7. Le GAB enregistre l’échec sur la carte
Le scénario nominal reprend au point 3
Enchaînements alternatifs (suite)
A2 : montant demandé supérieur au solde hebdomadaire
A3 : ticket refusé
Enchaînements d’erreurs
E1 : carte non valide
E2 : code d’identification définitivement erroné
E3 : retrait non autorisé
E4 : carte non reprise
E5 : billets non pris
E6 : annulation de la transaction
Postconditions
La caisse du GAB contient moins de billets qu’au début du cas
d’utilisation (le nombre de billets manquants est fonction du
montant exact du retrait)
Une transaction de retrait a été enregistrée par le GAB avec
toutes les informations pertinentes (montant, numéro de carte,
date, etc.)
Exigences non fonctionnelles
Temps de réponse < 2 s
Durée transaction nominale <2 minutes
Concurrence nulle (mono-utilisateur)
Disponibilité 7j/7 et 24h/24, l’absence de papier pour
imprimer les tickets ne doit pas empêcher les retraits
Intégrité : les interfaces du GAB doivent résister au
vandalisme
Confidentialité : la comparaison du code d’identification
saisi sur le clavier du GAB avec celui de la carte doit être
fiable à 10-6
Besoins d’IHM
Lecteur de carte bancaire
Clavier numérique (pour saisir son code) avec des touches
validation, correction et annulation
Ecran pour affichage des messages du GAB
Des touches autour de l’écran pour sélectionner le montant
du retrait parmi ceux proposés
Un distributeur de billet
Un distributeur de tickets
Exercice : modélisation d’un
magasin
n Le client entre dans le magasin, passe dans les rayons,
demande éventuellement des renseignements ou
procède à des essais, prend des articles (ou les réserve
si le stock est insuffisant), passe à la caisse ou il règle
ses achats. Il peut régler en liquide, par chèque (pour un
montant supérieur à 15 euros, ou par carte pour un
montant supérieur à 13 euros). Il peut éventuellement
présenter un (ou des) bon(s) de réduction
28
Factorisation des cas
Relation d’inclusion
Le cas A inclut le cas B :
Le comportement de A dépend de celui de B
Solliciter A nécessite de solliciter B
<<includes>> B
A
29
Factorisation des cas : exemple
<<includes>> Vérifier
téléphoner présence
réseau
Vérifier
<<includes>>
crédit
moi
30
Factorisation des cas : exemple
31
Extension entre cas
A étend B :
lors de l’utilisation de B, A peut être appelé
Point d’extension : à quel moment fait-on appel à A?
<<extend>> B
Point d’extension
A
32
Extension entre cas
Au moment de la vérification du montant, le scénario peut
être étendu à la consultation du solde.
Le point d’extension est déclaré dans la description
textuelle. 33
Généralisation entre cas
A est une généralisation de B :
B est un cas particulier de A
B
A
34
• Généralisation de cas (rappel exemple)
Généralisation de cas
Cas abstrait
Cas concret
36