Diagrammes de cas d’utilisation : Un guide pratique

Un diagramme de cas d’utilisation est un diagramme comportemental UML qui montre comment les utilisateurs externes ou les systèmes interagissent avec un système. Il se concentre sur ce que fait le système du point de vue d’un acteur, et non sur les détails d’implémentation internes.

Les diagrammes de cas d’utilisation sont particulièrement utiles lors de l’analyse des exigences car ils offrent une vue de haut niveau de la fonctionnalité et de la portée du système.

1. Ce qu’un diagramme de cas d’utilisation montre

Un diagramme de cas d’utilisation contient généralement :

• Limite du système — définit ce qui se trouve à l’intérieur du système modélisé.

• Acteurs — utilisateurs externes, organisations, appareils ou systèmes qui interagissent avec lui.

• Cas d’utilisation — objectifs ou services que le système fournit.

• Associations — liens de communication entre les acteurs et les cas d’utilisation.

• Relations entre les cas d’utilisation — telles que <<inclure>> et <<étendre>>.

• Généralisation — héritage entre les acteurs ou les cas d’utilisation.

Un diagramme de cas d’utilisation ne montre généralement pas :

• Étapes de l’algorithme

• Tables de base de données

• Classes de programme

• Flux de travail internes

• Dispositions détaillées de l’interface utilisateur

• Séquences de messages dans le temps

Ces détails sont mieux représentés par des diagrammes d’activité, de classes, de séquence ou d’états.

2. Concepts clés

Limite du système

La limite du système est un rectangle entourant les cas d’utilisation qui appartiennent au système.

Par exemple, dans un système de commerce en ligne :

+--------------------------------------+
|        Système de commerce en ligne        |
|                                      |
|  (Parcourir les produits)                   |
|  (Passer une commande)                       |
|  (Effectuer un paiement)                      |
+--------------------------------------+

Les acteurs restent en dehors de la limite car ils sont externes au système.

La limite aide à clarifier le périmètre du système. Si une capacité se trouve en dehors de la limite, elle n’est pas implémentée par le système modélisé.

Acteurs

Un acteur est tout élément externe qui interagit avec le système pour atteindre un objectif.

Les acteurs peuvent inclure :

• Utilisateurs humains

• Applications externes

• Périphériques matériels

• Autres organisations

• Événements temporels ou planifiés, lorsqu’ils sont modélisés comme des déclencheurs externes

Exemples :

• Client

• Bibliothécaire

• Passerelle de paiement

• Administrateur

• Service d’envoi d’e-mails

Un acteur représente un rôle, pas nécessairement une personne spécifique. Par exemple, « Client » est généralement préférable à « Alex ».

Les acteurs peuvent être :

• Acteurs principaux— initient des interactions pour atteindre un objectif.

• Acteurs de soutien— fournissent des services au système.

Par exemple, un client peut initier « Passer une commande », tandis qu’une passerelle de paiement prend en charge « Traiter le paiement ».

Cas d’utilisation

Un cas d’utilisationreprésente un objectif significatif ou un service fourni par le système.

Les bons noms de cas d’utilisation suivent généralement cette forme :

Verbe + objet

Exemples :

• Enregistrer un compte

• Rechercher dans le catalogue

• Soumettre une demande

• Générer un rapport

• Annuler une réservation

• Traiter le paiement

Un cas d’utilisation doit décrire un résultat observable, plutôt qu’une étape d’implémentation interne.

Privilégier :

Passer une commande

plutôt que :

Valider l'objet commande

Le second décrit une opération interne plutôt qu’un objectif utilisateur.

Associations

Une association est un lien de communication entre un acteur et un cas d’utilisation.

Elle indique que l’acteur participe ou initie le cas d’utilisation.

Client ---- (Passer une commande)

Les associations n’indiquent généralement pas la séquence, le flux de contrôle ou la direction. Si l’ordre des interactions est important, utilisez un diagramme de séquence ou un diagramme d’activité.

3. Relations entre les cas d’utilisation

<<inclure>>

Utilisez <<inclure>> lorsqu’un cas d’utilisation utilise toujours un autre cas d’utilisation.

Par exemple, passer une commande peut toujours nécessiter une authentification :

(Passer une commande) ..> (Authentifier le client) : <<inclure>>

Le cas d’utilisation de base dépend du cas d’utilisation inclus.

Utilisez inclure lorsque :

• Le comportement est obligatoire.

• Le comportement est réutilisé par plusieurs cas d’utilisation.

• Extraire le comportement améliore la clarté.

Exemple :

(Retirer de l'argent) ..> (Authentifier la carte) : <<inclure>>
(Vérifier le solde) ..> (Authentifier la carte) : <<inclure>>

Les deux cas d’utilisation nécessitent toujours l’authentification de la carte.

<<étendre>>

Utilisez <<étendre>> lorsqu’un comportement supplémentaire est optionnel ou inséré de manière conditionnelle dans un cas d’utilisation de base.

(Appliquer une réduction) ..> (Passer une commande) : <<étendre>>

Le comportement de réduction ne se produit que lorsque les conditions d’éligibilité sont remplies.

Utilisez étendre lorsque :

• Le comportement est optionnel.

• Cela ne se produit que sous une condition.

• Le cas d’utilisation de base est complet sans cela.

Exemples :

• « Ajouter un emballage cadeau » étend « Passer une commande ».

• « Demander un remboursement » étend « Annuler l’abonnement ».

• « Envoyer un e-mail promotionnel » étend « Terminer l’inscription ».

La flèche pointe du cas d’utilisation étendant vers le cas d’utilisation de base.

Généralisation

La généralisation représente une relation « est-un » entre des acteurs ou des cas d’utilisation.

Par exemple :

Client Premium --|> Client

Un client premium est une sorte de client et hérite des interactions du client.

La généralisation d’acteurs peut être utile lorsque plusieurs acteurs partagent un comportement commun :

Administrateur --|> Employé
Bibliothécaire --|> Employé

Utilisez la généralisation avec parcimonie. Si la relation est simplement « utilise » ou « participe à », une association est généralement plus appropriée.

4. Acteurs principaux et acteurs de soutien

Considérez un scénario de paiement en ligne :

• Le Client est l’acteur principal car il initie l’achat.

• Le Passerelle de paiement est un acteur de soutien car il traite le paiement à la demande du système.

Un modèle simple pourrait ressembler à ceci :

Client ---- (Passer une commande)
(Passer une commande) ---- Passerelle de paiement

Cette distinction est utile car elle clarifie qui bénéficie du cas d’utilisation et quels systèmes externes sont impliqués.

5. Comment identifier les cas d’utilisation

Une méthode pratique pour découvrir les cas d’utilisation est de se demander :

1. Qui utilise le système ?

2. Quel objectif chaque acteur souhaite-t-il atteindre ?

3. Quels services le système fournit-il ?

4. Quels événements déclenchent le comportement du système ?

5. Avec quels systèmes externes le système doit-il interagir ?

6. Quel comportement est toujours requis ?

7. Quel comportement est facultatif ou conditionnel ?

Pour chaque acteur, listez leurs objectifs :

L’objectif doit être significatif pour l’acteur. Évitez de transformer chaque petite opération du système en un cas d’utilisation.

6. Directives de dénomination

Utilisez des noms clairs et orientés vers l’objectif.

Exemples pertinents :

• Créer un compte

• Mettre à jour le profil

• Soumettre une réclamation

• Suivre l’expédition

• Approuver la demande

• Générer une facture

Évitez les noms vagues :

• Traitement du système

• Gérer les données

• Fonction utilisateur

• Exécuter une opération

Évitez les détails techniques excessifs :

• Exécuter une requête SQL

• Appeler un point de terminaison REST

• Instancier PaymentService

Ces étapes peuvent être valides pour l’implémentation, mais elles ne sont généralement pas utiles en tant que cas d’utilisation de haut niveau.

7. Exemple : Système de gestion de bibliothèque

Supposons qu’un système de bibliothèque prenne en charge :

• Les membres recherchant des livres

• Les membres empruntant des livres

• Les membres rendant des livres

• Les bibliothécaires gérant le catalogue

• Notifications de retard

• Traitement des paiements pour les amendes

Acteurs possibles :

• Membre

• Bibliothécaire

• Service de notification

• Service de paiement

Cas d’utilisation possibles :

• Rechercher dans le catalogue

• Emprunter un livre

• Rendre le livre

• Calculer l’amende

• Payer l’amende

• Gérer le catalogue

• Envoyer une notification de retard

Relations :

• Emprunter un livre inclut Vérifier l’adhésion.

• Emprunter un livre inclut Vérifier la disponibilité du livre.

• Rendre un livre inclut Calculer l’amende.

• Payer l’amende interagit avec le Service de Paiement.

• Envoyer une notification de retard interagit avec le Service de Notification.

8. Exemple PlantUML

Le code PlantUML suivant crée un diagramme de cas d’utilisation pour le système de bibliothèque :

@startuml
left to right direction

title Système de gestion de bibliothèque - Diagramme de cas d'utilisation

actor Membre
actor Bibliothécaire
actor "Service de notification" as Notification
actor "Service de paiement" as Payment

rectangle "Système de gestion de bibliothèque" {

  usecase "Rechercher dans le catalogue" as UC_Recherche
  usecase "Emprunter un livre" as UC_Emprunt
  usecase "Rendre un livre" as UC_Rendu
  usecase "Vérifier l'adhésion" as UC_VerifAdhesion
  usecase "Vérifier la disponibilité du livre" as UC_VerifDisponibilite
  usecase "Calculer l'amende" as UC_CalculAmende
  usecase "Payer l'amende" as UC_PayerAmende
  usecase "Gérer le catalogue" as UC_GererCatalogue
  usecase "Envoyer une notification de retard" as UC_Notifier
}

Membre --> UC_Recherche
Membre --> UC_Emprunt
Membre --> UC_Rendu
Membre --> UC_PayerAmende

Bibliothécaire --> UC_GererCatalogue
Bibliothécaire --> UC_Emprunt
Bibliothécaire --> UC_Rendu

Payment --> UC_PayerAmende
Notification --> UC_Notifier

UC_Emprunt ..> UC_VerifAdhesion : <<include>>
UC_Emprunt ..> UC_VerifDisponibilite : <<include>>
UC_Rendu ..> UC_CalculAmende : <<include>>

UC_Notifier ..> UC_Rendu : <<extend>>

@enduml

9. Explication de l’exemple

Acteurs

actor Membre
actor Bibliothécaire
actor "Service de notification" as Notification
actor "Service de paiement" as Payment

Le diagramme modélise deux acteurs humains et deux services externes.

Les alias tels que as Notification rendent les noms longs plus faciles à référencer par la suite.

Limite du système

rectangle "Système de gestion de bibliothèque" {
    ...
}

Le rectangle définit la portée du système. Les cas d’utilisation à l’intérieur du rectangle sont fournis par le système de bibliothèque.

Associations des acteurs

Membre --> UC_Recherche
Membre --> UC_Emprunter

Ces associations montrent qu’un membre peut rechercher dans le catalogue et emprunter des livres.

La direction de la flèche n’est généralement pas sémantiquement importante dans un diagramme de cas d’utilisation de base. Elle est principalement utilisée pour rendre le diagramme lisible.

Relations d’inclusion

UC_Emprunter ..> UC_VérifierMembre : <<include>>
UC_Emprunter ..> UC_VérifierDisponibilité : <<include>>

L’emprunt d’un livre nécessite toujours des vérifications d’adhésion et de disponibilité, c’est pourquoi ces éléments sont modélisés comme des cas d’utilisation inclus.

Relation d’extension

UC_Aviser ..> UC_Retour : <<extend>>

Cela indique que le comportement d’envoi d’un avis de retard est un comportement supplémentaire associé au retour d’un livre.

Cependant, dans un modèle de besoins réel, une conception plus naturelle pourrait consister à associer « Envoyer un avis de retard » à un processus planifié ou à un acteur tel que « Planificateur de la bibliothèque ». La meilleure relation dépend des règles métier réelles.

10. Spécification plus détaillée d’un cas d’utilisation

Un diagramme donne une vue d’ensemble, mais chaque cas d’utilisation important devrait généralement avoir une spécification textuelle.

Cas d’utilisation : Emprunter un livre

Un diagramme de cas d’utilisation ne devrait pas tenter de contenir tous ces détails. Le diagramme fournit la carte ; la spécification fournit le comportement.

11. Référence de syntaxe PlantUML

Déclaration des acteurs

actor Client
actor "Passerelle de paiement" as Gateway

Déclaration des cas d’utilisation

usecase "Passer une commande" as PlaceOrder
usecase "Traiter le paiement" as ProcessPayment

Création d’une limite de système

rectangle "Boutique en ligne" {
    usecase "Parcourir les produits" as Browse
    usecase "Passer une commande" as Order
}

Connexion des acteurs et des cas d’utilisation

Client --> Browse
Client --> Order

Inclure

Commande ..> ProcesserLePaiement : <<include>>

Étendre

AppliquerUnCoupon ..> Commande : <<extend>>

Généralisation des acteurs

ClientPremium --|> Client

Regroupement par paquets

Les paquets peuvent regrouper visuellement des cas d’utilisation liés :

rectangle "Système Bancaire" {
  package "Gestion des Comptes" {
    usecase "Ouvrir un Compte" as OpenAccount
    usecase "Fermer un Compte" as CloseAccount
  }

  package "Paiements" {
    usecase "Virement de Fonds" as TransferFunds
    usecase "Payer une Facture" as PayBill
  }
}

Notes

note right of PlaceOrder
  Le client doit être authentifié
  avant de passer une commande.
end note

12. Amélioration de la mise en page des diagrammes

PlantUML met automatiquement en page les diagrammes, mais plusieurs techniques améliorent la lisibilité.

Contrôler la direction

direction de gauche à droite

Cela est souvent utile lorsque les acteurs doivent apparaître sur les côtés et les cas d’utilisation au centre.

D’autres directions courantes incluent :

direction de haut en bas

Utiliser des alias

Au lieu de répéter de longs noms :

usecase "Vérifier l'identité du client" as VerifyIdentity

Ensuite, référencez :

RegisterAccount ..> VerifyIdentity : <<include>>

Regrouper les cas d’utilisation liés

Utilisez des paquets ou des rectangles imbriqués pour séparer les zones fonctionnelles :

package "Gestion des commandes" {
    usecase "Créer une commande" as CreateOrder
    usecase "Annuler une commande" as CancelOrder
}

Évitez les croisements excessifs

Un diagramme devient difficile à lire lorsque trop de lignes se croisent. Vous pouvez l’améliorer en :

• Placer les acteurs pertinents à proximité de leurs cas d’utilisation

• Regrouper les cas d’utilisation dans des paquets

• Diviser un grand diagramme en plusieurs diagrammes plus petits

• Utiliser des alias pour des références claires

• Éviter les relations inutiles

13. Erreurs courantes

Modéliser les fonctions internes comme des cas d’utilisation

Cela est généralement trop technique :

Valider la connexion à la base de données
Sérialiser la requête
Appeler l'API de paiement

Privilégiez des objectifs ayant un sens externe :

Effectuer un paiement
Soumettre une demande
Générer un rapport

Considérer chaque acteur comme une personne

Les systèmes et périphériques externes peuvent également être des acteurs :

• Passerelle de paiement

• Fournisseur d’identité

• Système d’entrepôt

• Lecteur de code-barres

• Service de notification

Utiliser inclure pour un comportement optionnel

Si le comportement est optionnel, utilisez étendre plutôt que inclure.

Incorrect :

Passer la commande ..> Appliquer le coupon : <<inclure>>

Si l’application d’un coupon est facultative, utilisez :

Appliquer le coupon ..> Passer la commande : <<étendre>>

Utiliser étendre pour un comportement obligatoire

Si un comportement se produit toujours, il devrait généralement être modélisé avec inclure.

Passer la commande ..> Authentifier le client : <<inclure>>

Connecter les cas d’utilisation directement sans signification

Une ligne entre deux cas d’utilisation doit représenter une relation UML valide. Évitez les connexions arbitraires qui impliquent simplement que les cas d’utilisation sont d’une manière ou d’une autre liés.

Créer un seul diagramme géant

Un diagramme de cas d’utilisation doit communiquer clairement à un niveau élevé. S’il contient des dizaines d’acteurs et de cas d’utilisation, créez plusieurs diagrammes organisés par sous-système ou domaine métier.

Montrer la séquence

Un diagramme de cas d’utilisation ne montre pas qu’un cas d’utilisation se produit avant un autre. Pour la séquence, utilisez un diagramme de séquence ou un diagramme d’activité.

14. Quand utiliser d’autres diagrammes UML

Les diagrammes de cas d’utilisation sont les meilleurs pour la portée du système et les objectifs de l’utilisateur. Combinez-les avec d’autres diagrammes lorsque plus de détails sont nécessaires :

15. Processus de modélisation recommandé

1. Définir la limite du système.

2. Identifier tous les acteurs externes.

3. Identifier les objectifs de chaque acteur.

4. Convertir ces objectifs en cas d’utilisation.

5. Relier les acteurs aux cas d’utilisation auxquels ils participent.

6. Identifier les comportements réutilisables obligatoires et les modéliser avec <<inclure>>.

7. Identifier les comportements optionnels ou conditionnels et les modéliser avec <<étendre>>.

8. Ajouter une généralisation uniquement là où il existe une véritable relation « est-un ».

9. Examiner le diagramme avec les parties prenantes.

10. Ajouter des spécifications textuelles pour les cas d’utilisation importants.

11. Diviser le diagramme s’il devient encombré.

16. Modèle PlantUML compact

Vous pouvez utiliser ceci comme point de départ :

@startuml
left to right direction

title Diagramme de cas d'utilisation du système

actor Utilisateur
actor "Système externe" as SystemeExterne

rectangle "Nom du système" {
  usecase "Objectif principal de l'utilisateur" as ObjectifPrincipal
  usecase "Comportement partagé requis" as ComportementRequis
  usecase "Comportement optionnel" as ComportementOptionnel
}

Utilisateur --> ObjectifPrincipal
SystemeExterne --> ObjectifPrincipal

ObjectifPrincipal ..> ComportementRequis : <<inclure>>
ComportementOptionnel ..> ObjectifPrincipal : <<étendre>>

@enduml

Le principe central consiste à modéliser les objectifs visibles de l’extérieur, et non les détails d’implémentation internes. Un diagramme de cas d’utilisation robuste rend immédiatement compréhensibles la limite du système, les acteurs, les capacités et les dépendances importantes.

Référence

Cette publication est également disponible en Deutsch, English, Español : liste des langues séparées par une virgule, فارسی : dernière langue.