Cahier des charges : gestion de

bibliothèque
• Un gérant de bibliothèque désire automatiser
la gestion des prêts.

• Il commande un logiciel permettant aux

utilisateurs de connaître les livres présents,
d'en réserver jusqu'à 2. L'adhérent peut
connaître la liste des livres qu'il a empruntés
ou réservés.

• L'adhérent possède un mot de passe qui lui

est donné à son inscription.
• L'emprunt est toujours réalisé par les
employés qui travaillent à la bibliothèque.
Après avoir identifié l'emprunteur, ils savent
si le prêt est possible (nombre max de
prêts = 5), et s'il a la priorité (il est celui qui
a réservé le livre).

• Ce sont les employés qui mettent en

bibliothèque les livres rendus et les
nouveaux livres. Il leur est possible de
connaître l'ensemble des prêts réalisés
dans la bibliothèque.
2) Le diagramme des Use Cases
ou des cas d ’utilisation

Ce que doit faire le système

sans spécifier comment il le fait
 But des Use Cases
Les cas d'utilisation représentent les
fonctionnalités que le système doit savoir faire.

Chaque cas d'utilisation peut être complété par

un ensemble d'interactions successives d'une
entité en dehors du système (l’utilisateur) avec
le système lui même.

Système
 But des Use Cases
Les Uses Cases permettent :
– De connaître le comportement du système sans
spécifier comment ce comportement sera réalisé.
– De définir les limites précises du système
– Au développeur de bien comprendre l'attente des
utilisateurs et les experts du domaine.

De plus les Use Cases sont :

– Des instruments de validation et de test du
système en cours et en fin de construction.
 Modèle des cas d'utilisations
• Un diagramme de cas d’utilisation définit :
➢le système
➢les acteurs
➢les cas d'utilisations
➢les liens entre acteurs et cas d'utilisations

• Un modèle de cas d'utilisation se définit par :

➢des diagrammes de cas d’utilisation
➢une description textuelle des scénarios
d'utilisation
➢une description de ces scénarios par :
✓les diagrammes de séquences
✓les diagrammes de collaboration
 Les Acteurs
• Un acteur représente une personne ou un
périphérique qui joue un rôle (interagit) avec le
système.
• Relation entre acteurs : généralisation (héritage)

Héritage
relation entre acteurs
un bibliothécaire est un abonné

un administrateur est un bibliothécaire

abonné
un administrateur est un abonné
abonné bibliothécaire

Acteur bibliothécaire administrateur

Les cas d’utilisation (use-case)
• Un cas d’utilisation est un moyen de
représenter les différentes possibilités
d'utiliser un système.
• Il exprime toujours une suite d'interactions
entre un acteur et l'application.
• Il définit une fonctionnalité utilisable par un
acteur.
Emprunter
Regarder la liste
des livres
Réserver
Organisation des Use Cases :
include
• La relation "include" précise qu'un cas d’utilisation
contient le comportement défini dans un autre cas
d’utilisation.
• Cette relation permet de mettre en commun des
comportements communs à plusieurs cas
d'utilisation.

Emprunt <<include>>

Identification
abonné

Réservation <<include>>
Organisation des Use Cases :
extend
• La relation "extend" précise qu'un cas
d’utilisation peut dans certains cas
augmenter le comportement d'un autre cas
d'utilisation.
• Une condition devra valider cette
augmentation.
• Le point d'utilisation de cette augmentation
peut être défini dans un "point d'extension".
 Réservation
Regarder liste des
Extension points
<<extend>> livres
avant le choix du livre
avant le choix du livre

• Dans cet exemple, le cas d'utilisation

"Regarder la liste des livres » augmente le
cas d'utilisation d'une réservation, avant le
choix du livre, si l'utilisateur en fait la
demande.
 Organisation des Use Cases :
généralisation
• Cette relation "est un" introduit la notion
d’héritage.
• Les cas d'utilisation "Vérification par mot passe" et
"Vérification par carte" sont des spécialisations du
cas d'utilisation "Identification abonné".
• Autrement dit : si l'on dit que l'on fait une
"Identification abonné", ce peut être une
"Vérification par carte" ou une "Vérification par mot
passe".
Héritage Vérification par
mot passe
Identification
abonné Vérification par
carte
 Modélisation d’un système:
obtenir les cas d'utilisation
• Identifier les acteurs qui utilisent, qui gèrent, qui
exécutent des fonctions spécifiques.
• Organiser les acteurs par relation d’héritage.
• Pour chaque acteur, rechercher les cas d’utilisation
avec le système. En particulier, ceux qui modifient
l’état du système ou qui attendent une réponse du
système.
• Ne pas oublier les variantes d’interactions (cas
d’erreur, cas interdits).
• Organiser ces interactions par héritage, par
utilisation et par extension..
 Le système
• Le système définit l'application informatique, il ne
contient donc pas les acteurs, mais les cas d'utilisation
et leur associations
Gestion de bibliothèque

Réserver un livre

Connaître les livres empruntés

Connaître les livres présents

Ajouter de nouveaux livres

Remettre un livre

Réaliser un emprunt
 Les diagrammes de cas
d’utilisation
Bibliothèque

Réserver un livre

Client Cas d’utilisation

Connaître les livres empruntés

Acteurs Connaître les livres présents

Ajouter de nouveaux livres

Remettre un livre

Employé Réaliser un emprunt

 Les diagrammes de cas
d’utilisation
Bibliothèque

Connaître les livres empruntés

<< include >>
Réserver un livre << include >>

Extension point Identification

Client avant la réservation
<<extends>>
Identification
Connaître les livres présents par carte

Ajouter de nouveaux livres Identification

par mot de passe
Remettre un livre
Employé
Réaliser un emprunt
Scénarios d'un cas d'utilisation
• La description d’un cas d’utilisation se fait par des
scénarios qui définissent la suite logique des
interactions qui constituent ce cas.
• On peut définir des scénarios simples ou des
scénarios plus détaillés faisant intervenir les
variantes, les cas d'erreurs,etc.
• Cette description se fait de manière simple, par un
texte compréhensible par les personnes du
domaine de l'application.
• Elle précise ce que fait l'acteur et ce que fait le
système
• La description détaillée pourra préciser les
contraintes de l'acteur et celles du système.
 Scénarios d'un cas d'utilisation
Réservation d'un livre
description simplifiée

Le client se présente devant un terminal:

• (1) Le système affiche un message d ’accueil.
• (2) Le client choisit l’opération réservation parmi les différentes
opérations proposées.
• (3) Le système lui demande de s'authentifier.
• (4) Le client donne son identification (nom, mot de passe).
• (5) Le système lui demande de choisir un livre.
• (6) Le client précise le livre qu'il désire.
• (7) Le système lui précise si un exemplaire du livre lui est
réservé.
Scénarios d'un cas d'utilisation
Réservation d'un livre
description détaillée

• Pré-conditions: Le client doit être inscrit à la bibliothèque

Le client ne doit pas avoir atteint le
nombre maximum de réservation
Un exemplaire du livre doit être enregistré

• Post-conditions: (Si l'opération s'est bien déroulée)

Le client a une réservation supplémentaire
Le nombre d'exemplaires disponibles du
livre est décrémenté de 1
Scénarios d'un cas d'utilisation
Réservation d'un livre

Cas normal description détaillée

1. (1) Le système affiche un message d ’accueil sur le

terminal avec un choix d'opérations
2. (2) Le client choisit l’opération réservation parmi les
différentes opérations proposées.
3. (3) Le système lui demande de s'authentifier.
4. (4) Le client donne son identification (nom, mot de passe).
5. (5) Le système demande le titre du livre en donnant la
possibilité de choisir dans une liste.
6. (6) Le client précise le livre qu'il désire.
7. (7) Le système lui précise que un exemplaire du livre lui est
réservé.
Scénarios d'un cas d'utilisation
variante 1 en (6) le client demande à connaître les
livres présents

variante 2 en (4) le client n'est pas reconnu, dans ce

cas, tant qu'il n'est pas reconnu, on lui redemande
de s'authentifier

variante 3 en (4) le client est reconnu, mais le mot de passe

est incorrect,
il peut avoir 5 essais, par la suite le client sera
interdit pendant 1 heure.

variante 4 en (4) le client n'a plus le droit de réserver

variante 5 en (7) le livre n'est pas libre

 Scénario par diagramme de
séquences
▪ Suite aux descriptions textuelles, le
scénario peut être représenté en utilisant un
diagramme de séquences.
Le diagramme de séquences permet :
- de visualiser l’aspect temporel des
interactions
- de connaître le sens des interactions
(acteur vers système ou contraire)
 Scénario par diagramme de
séquences

Client Système de prêts

Afficher message d ’accueil

Choix de l ’opération réservation temps

Demande d ’identification du client

Réserver un livre
Identification du client

Demande identification du livre

Identification du livre

Message « le livre est réservé »

 Variation du scénario

Client Système de prêts

Afficher message d ’accueil

Choix de l ’opération réservation

Demande d ’identification du client

Réserver un livre
Identification du client

Refus trop de livres réservés

 Cas d ’utilisation:
Distributeur de billets
Distributeur de billets
Cas
d’utilisation
Effectuer un virement
Client Retirer l ’argent

Acteur Consulter un compte

client Banque

Gérer le distributeur Acteurs

gestionnaires

Effectuer la Maintenance

Employé
 Diagramme de séquences Use
Case Retirer de l'argent
Afficher message d ’accueil
Insère la carte Distributeur de
Demande de mot de passe billets
Client Entre mot de passe
Demande type opération
Entre demande retrait
Demande somme
Entre somme
Distribue l'argent
Retirer l’argent Demande prendre les billets
Prendre les billets
Imprimer le reçu
Éjecter la carte
Demande de prendre la carte
Prendre la carte
Afficher message d ’accueil
Exemple2 :
Système

Créer compte Déposer argent

Client

Guichetier
Consulter compte

Retirer de l'argent du
distributeur
Retirer de l'argent
Banque centrale

Gérer les comptes

Use case : “ Retrait en espèce ” :

1. Le guichetier saisit le n° de compte du client.

2. L’application valide le compte auprès du système
central.
3. L’application demande le type d’opération au
guichetier.
4. Le guichetier sélectionne un retrait d’espèces de
2000 DH.
5. Le système “ guichetier ” interroge le système
central pour s’assurer que le compte est
suffisamment approvisionné.
6. Le système central effectue le débit du compte.
7. Le système notifie au guichetier qu’il peut délivrer
le montant demandé.
 Descriptions à l’aide de
diagrammes de séquences

Saisie
compte Validation compte
Demande type d’opération

Retrait liquide (2000DH)

Vérification solde compte

Autorisation délivrance Débit compte

t Guichetier Système guichet Système central

29
 Descriptions à l’aide de
diagrammes de collaborations
(6) Débit compte

(4) Retrait espèces (2000DH)

Système Central
Guichetier

(5) vérification solde compte

(7) Autorisation
(3) Demande type délivrance
d’opération

(2) Validation compte

(1) Saisie compte
Système guichetier

30