UML

Amina OUSSALEH TAOUFIK – Cours UML EHTP Mars 2024

Diagramme de cas d’utilisation
Diagramme de cas d’utilisation - Partie 1
Diagramme de cas d’utilisation - Partie 1
Objectif:
Comprendre les besoins du client pour rédiger le cahier des charges fonctionnel.

Trois questions :

1. Définir les utilisations principales du système: à quoi sert-il?

2. Définir l’environnement du système : qui va l’utiliser ou interagir avec lui?

3. Définir les limites du système: où s’arrête sa responsabilité?

Elements de description

1. Diagramme de cas d’utilisation.

2. Description textuelle des cas d’utilisation. Scénarios d’utilisation:

Séquences d’étapes décrivant une
3. Diagrammes de séquence des scénarios d’utilisation. interaction entre l’utilisateur et le système
et permettant à l’utilisateur de réaliser un
objectif.
Diagramme de cas d’utilisation - Partie 1
Exemple de sénarios d’utilisation : Sénario exceptionnel

Système : Site de vente en ligne Le client s’authentifie dans le système puis

choisit une adresse et un mode de livraison.
Sénario : Commander
Le système indique le montant total de sa
Sénario nominal
commande au client. Le client donne ses
Le client s’authentifie dans le système puis informations de paiement. La transaction
choisit une adresse et un mode de livraison. n’est pas autorisée, le système invite le client
Le système indique le montant total de sa
à changer de mode de paiement. Le client
commande au client. Le client donne ses
modifie ses informations. La transaction est
informations de paiement. La transaction est
effectuée et le système en informe le client
effectuée et le système en informe le client
par e-mail.
par e-mail.
Diagramme de cas d’utilisation - Partie 1
Diagramme de Cas d’utilisation:
1. Ensemble de scénarios réalisant un objectif de l’utilisateur.

2. Fonctionnalités principales du système du point de vue extérieur.

Acteur: Entité qui interagit avec le système

• Personne, logiciel, extérieur au système décrit.

• Représente un rôle (plusieurs rôles possibles pour une même entité).

• Identifié par le nom du rôle.

• 2 types d’acteurs: Principale et secondaire.

Cas d’utilisation: Fonctionnalité visible de l’extérieur.

• Action déclenchée par un acteur.

• Identifié par une action (verbe à l’infinitif ex: créer un compte, commander …) Vision du sytème centrée sur l’utilisateur
Association /Relation:
• Relation entre les acteurs et les cas d’utilisation.
• Représente la possibilité pour l’acteur de déclencher le cas.
Diagramme de cas d’utilisation - Partie 1
Diagramme de cas d’utilisation - Partie 1
Exemple:
Diagramme de cas d’utilisation - Partie 1
Relations entre acteurs
Il n’ya qu’un seul type de relation entre acteurs:
La relation de généralisation
Diagramme de cas d’utilisation - Partie 1
Exemple (Relations entre acteurs):
Diagramme de cas d’utilisation - Partie 1
Exemple (Relations entre acteurs):
Diagramme de cas d’utilisation - Partie 1
Exemple (Relations entre acteurs):
Diagramme de cas d’utilisation - Partie 1
Relations entre cas d’utilisation

1. Généralisation
• Un cas A est une
généralisation d’un cas B si B
est un cas particulier de A.
Diagramme de cas d’utilisation - Partie 1
Relations entre cas d’utilisation

2. Include
• Un cas A inclut un cas B si le comportement
décrit par le cas A inclut le comportement 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 »

Cas Cas
d’utilisation d’utilisation
A B
Diagramme de cas d’utilisation - Partie 1
Relations entre cas d’utilisation

3. Extends
• Un cas d’utilisation B étend un
cas d’utilisation A lorsque le cas d’utilisation B
peut être appelé au cours de l’exécution du
cas d’utilisation A.
• Exécuter A peut éventuellement entraîner
l’exécution de B
• Contrairement à l’inclusion, l’extension est
optionnelle.
• Cette dépendance est symbolisée par le
stéréotype « extends »
Diagramme de cas d’utilisation - Partie 1

VS

Notation ancienne

Généralisation

Analogie

Extends
Diagramme de cas d’utilisation - Partie 1
Exemple (différents types d’associations):
Diagramme de cas d’utilisation - Partie 1
Conseils:

Rester lisible:

• Pas plus de 6 à 8 cas dans un diagramme.

• Au besoin, faire plusieurs diagrammes (si cas disjoints entre acteurs, pour
détailler un cas…)

• Relations entre cas seulement si nécessaires et pas trop lourdes.

• Pour les details, privilégier la description textuelle.

Diagramme de cas d’utilisation - Partie 1
Exercice 1 : Etude de Cas Gestion d’un GAB
Enoncé :
On considère le système suivant de gestion d’un GAB (Guichet Automatique
Bancaire) :
- le distributeur délivre de l’argent à tout porteur de carte (carte Visa ou carte de la
banque)
- pour les clients de la banque, il permet :
1. la consultation du solde du compte
2. le dépôt d’argent (chèque ou numéraire)
- toute transaction est sécurisée et nécessite par conséquent une authentification.
-le client peut aussi imprimer un ticket après avoir effectué un retrait.
Travail à Faire :
Modéliser cette situation par un diagramme de cas d’utilisation
Diagramme de cas d’utilisation - Partie 1
Exercice 2 : Site de location et de vente de vélos
Enoncé :
Un site de location et de vente de vélos présente un catalogue consultable par
tous les internautes. Seuls les clients inscrits peuvent, après s’être connectés,
sélectionner des vélos en achat ou en location puis payer la commande. Au
moment du paiement, il est possible d’utiliser un code de réduction.
L’administrateur du site s’occupe de gérer le catalogue.
Travail à Faire :
Modéliser cette situation par un diagramme de cas d’utilisation
Diagramme de cas d’utilisation détaillé - Partie 2
Diagramme de cas d’utilisation détaillé - Partie 2
Description textuelle d’un cas d’utilisation:
• Nom du cas d’utilisation
• Brève description
• Acteurs
• 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
• Scénario alternatif ou variantes et Scénario
exceptionnels ou scénario d’erreur
Diagramme de cas d’utilisation détaillé - Partie 2
Diagramme de cas d’utilisation détaillé - Partie 2
Diagramme de cas d’utilisation détaillé - Partie 2
Diagramme de cas d’utilisation détaillé - Partie 2

Diagramme de séquence (analyse):

• Représentation graphique de la chronologie des échanges de messages entre les
acteurs et le système
• La chronologie est représentée verticalement
• Et les échanges de messages sont représentés horizontalement
Diagramme de cas d’utilisation détaillé - Partie 2

Type de message dans un diagramme de séquence (analyse):

Diagramme de cas d’utilisation détaillé - Partie 2

Exemple Scénario nominal du Cas d’utilisation : Consulter Solde GAB

Diagramme de cas d’utilisation détaillé - Partie 2
Exemple Scénarios alternatifs du Cas d’utilisation : Consulter Solde GAB

Alternative

Boucle
Diagramme de cas d’utilisation détaillé - Partie 2

Exemple: service de planification et de sondages en ligne

Organizer est un service en ligne de planification et de sondages. Il permet à tout internaute, sans inscription préalable, de créer un
sondage permettant d'établir un choix en accord avec les invités du sondage. Il peut s'agir d'une date de réunion ou de n'importe quel
autre type d'options. Pour créer un sondage, l'internaute renseigne son nom et son adresse e-mail, et donne un titre au sondage ainsi
qu'une description. S'il choisit la planification d'événements, il lui faut choisir des dates possibles pour l'événement, puis des horaires
pour chacune des dates. S'il choisit un autre type de sondage, il doit nommer les différentes options possibles. Enfin, quel que soit le
type de sondage choisi, il peut donner une liste de personnes invitées à répondre à ce sondage, en renseignant leurs adresses e-mail.
Lorsqu'il confirme la création de l'événement, un e-mail contenant l'URL vers le sondage est envoyé par Organizer à chaque personne
invitée. Un e-mail de confirmation de la création du sondage est également envoyé à l'organisateur, contenant l'URL du sondage muni
des fonctions d'administration. Seuls les invités d'un sondage et son organisateur peuvent consulter ce sondage et y répondre. Un
invité répond à un sondage en donnant son nom et en cochant les options qui lui conviennent, puis en validant sa participation au
sondage. Il peut également laisser un commentaire visible par tous les invités à propos de ce sondage. À chaque fois qu'un invité
répond au sondage ou publie un commentaire, l'organisateur de ce sondage en est informé par e-mail. Les réponses des invités et les
commentaires sont visibles par tous les invités au sondage. L'organisateur peut à tout moment supprimer le sondage qu'il a créé. Il
peut également en modifier le titre ou la description, il peut ajouter ou supprimer des options, ou inviter des personnes
supplémentaires au sondage. Lorsque tous les invités ont répondu au sondage, ou lorsque l'organisateur le souhaite, il peut déclarer
le sondage clos en fixant une option parmi celles possibles. Il coche pour cela l'option choisie et valide son choix. Un e-mail est alors
envoyé à tous les invités (ainsi qu'à l'organisateur) pour les informer de l'option retenue. Le sondage est désormais fermé (il n'accepte
plus de réponses) mais est toujours consultable jusqu'à ce que l'organisateur le supprime.
Diagramme de cas d’utilisation détaillé - Partie 2

Exemple: service de planification et de sondages en ligne

Organizer est un service en ligne de planification et de sondages. Il permet à tout internaute, sans inscription préalable, de créer un
sondage permettant d'établir un choix en accord avec les invités du sondage. Il peut s'agir d'une date de réunion ou de n'importe quel
autre type d'options. Pour créer un sondage, l'internaute renseigne son nom et son adresse e-mail, et donne un titre au sondage ainsi
qu'une description. S'il choisit la planification d'événements, il lui faut choisir des dates possibles pour l'événement, puis des horaires
pour chacune des dates. S'il choisit un autre type de sondage, il doit nommer les différentes options possibles. Enfin, quel que soit le
type de sondage choisi, il peut donner une liste de personnes invitées à répondre à ce sondage, en renseignant leurs adresses e-mail.
Lorsqu'il confirme la création de l'événement, un e-mail contenant l'URL vers le sondage est envoyé par Organizer à chaque personne
invitée. Un e-mail de confirmation de la création du sondage est également envoyé à l'organisateur, contenant l'URL du sondage muni
des fonctions d'administration. Seuls les invités d'un sondage et son organisateur peuvent consulter ce sondage et y répondre. Un
invité répond à un sondage en donnant son nom et en cochant les options qui lui conviennent, puis en validant sa participation au
sondage. Il peut également laisser un commentaire visible par tous les invités à propos de ce sondage. À chaque fois qu'un invité
répond au sondage ou publie un commentaire, l'organisateur de ce sondage en est informé par e-mail. Les réponses des invités et les
commentaires sont visibles par tous les invités au sondage. L'organisateur peut à tout moment supprimer le sondage qu'il a créé. Il
peut également en modifier le titre ou la description, il peut ajouter ou supprimer des options, ou inviter des personnes
supplémentaires au sondage. Lorsque tous les invités ont répondu au sondage, ou lorsque l'organisateur le souhaite, il peut déclarer
le sondage clos en fixant une option parmi celles possibles. Il coche pour cela l'option choisie et valide son choix. Un e-mail est alors
envoyé à tous les invités (ainsi qu'à l'organisateur) pour les informer de l'option retenue. Le sondage est désormais fermé (il n'accepte
plus de réponses) mais est toujours consultable jusqu'à ce que l'organisateur le supprime.
Diagramme de cas d’utilisation détaillé - Partie 2

Exemple: service de planification et de sondages en ligne

Diagramme de cas d’utilisation détaillé - Partie 2

Exemple UML : Etude de Cas Gestion d’un GAB

Enoncé :
On considère le système suivant de gestion d’un GAB (Guichet Automatique Bancaire) :
- le distributeur délivre de l’argent à tout porteur de carte (carte Visa ou carte de la banque)
- pour les clients de la banque, il permet :
1. la consultation du solde du compte
2. le dépôt d’argent (chèque ou numéraire)
- toute transaction est sécurisée et nécessite par conséquent une authentification
- dans le cas où une carte est avalée par le distributeur, un opérateur de maintenance se charge de
la récupérer. C’est la même personne qui collecte également les dépôts d’argent et qui recharge le
distributeur.
Travail à Faire :
Modéliser cette situation par un diagramme de cas d’utilisation
 Langage UML: Diagrammes des cas d’utilisation
Exemple UML : Etude de Cas
Gestion d’un GAB