Maîtriser l’approche pilotée par les cas d’utilisation : un guide complet des exigences et de la conception

Introduction

En génie logiciel, combler l’écart entre les besoins des parties prenantes et la mise en œuvre technique est souvent la phase la plus difficile du développement. L’approche pilotée par les cas d’utilisation offre une méthodologie structurée et itérative pour résoudre ce problème. En se concentrant surla manière dont les utilisateurs interagissent avec le systèmepour atteindre des objectifs spécifiques, cette approche garantit que les exigences sont claires, testables et directement traçables vers les artefacts de conception.

Ce guide propose un parcours complet de l’approche pilotée par les cas d’utilisation, en passant des exigences de haut niveau à la conception détaillée. Nous utiliserons un exemple unique et continu — unsystème de gestion des commandes en ligne—pour illustrer chaque étape, assurant ainsi la cohérence et la clarté tout au long du processus.

---

Aperçu de la méthodologie

L’approche pilotée par les cas d’utilisation suit une progression naturelle de haut en bas. Chaque étape affine la précédente, ajoutant de la précision et réduisant l’ambiguïté.

Pourquoi cet ordre est-il important ?

1. Diagramme de cas d’utilisation:Fournit un inventaire complet des capacités et du périmètre. Il est rapide à parcourir et idéal pour un accord des parties prenantes surceque fait le système.
2. Description du cas d’utilisation:Lève l’ambiguïté en fixant les préconditions, les postconditions, les acteurs et la priorité. Il « fige » le contrat de comportement.
3. Flux d’événements:Transforme le contrat en étapes concrètes et testables. Cela sert de matière première tant pour les cas de test que pour la conception technique.
4. Activité/Diagramme de séquence: Fait office de pont vers le code. Il identifie les objets participants, leurs responsabilités, les échanges de messages et les règles de branchement exactes.

---

Étape 1 : Diagramme des cas d’utilisation (exigences)

Le diagramme des cas d’utilisation capture qui interagit avec le système (acteurs) et ce qu’ils peuvent faire (cas d’utilisation), ainsi que les relations entre eux.

Concepts clés

• Acteur principal : Déclenche le cas d’utilisation (placé à gauche).
• Acteur secondaire : Soutient le système ou reçoit des notifications (placé à droite).
• Limite du système : Le rectangle définissant la portée du système.
• <<inclure>>: Représente un comportement partagé obligatoire. Si le cas d’utilisation A inclut le cas d’utilisation B, B doit se produire pour que A soit terminé.
• <<étendre>>: Représente un comportement optionnel. Le cas d’utilisation B étend le cas d’utilisation A uniquement dans des conditions spécifiques.

Exemple : Système de gestion des commandes en ligne

@startuml
skinparam linetype ortho
skinparam defaultFontSize 14
skinparam defaultFontColor #333333
skinparam vpDiagramType UseCaseDiagram
skinparam actor {
  BackgroundColor #E8F5E9
}
skinparam usecase {
  BackgroundColor #BBDEFB
  BorderColor #1976D2
  ArrowColor #1976D2
}

left to right direction
actor "Clientn(Principal)" as cust
actor "Entrepôtn(Secondaire)" as wh

rectangle "Système de gestion des commandes" {
  usecase "Passer une commande" as UC1
  usecase "Annuler une commande" as UC2
  usecase "Suivre une commande" as UC3
  usecase "Connexion" as UC4
  usecase "Imprimer la facture" as UC5
}

cust -[#black]- UC1
cust -[#black]- UC2
cust -[#black]- UC3
UC1 -[#crimson]- wh
UC2 -[#crimson]- wh
UC1 ...> UC4 : <<inclure>>
UC2 ...> UC4 : <<inclure>>
UC3 ...> UC4 : <<inclure>>
UC1 <... UC5 : <<étendre>>
@enduml

Analyse du diagramme :

• Le Client initie la passation, l’annulation et le suivi des commandes.
• LeEntrepôt est impliqué dans la passation et l’annulation des commandes (probablement pour les mises à jour des stocks).
• Connexion est inclus dans Passer, Annuler et Suivre les commandes, ce qui signifie que l’authentification est obligatoire pour ces actions.
• Imprimer la facture étend Passer une commande, ce qui signifie qu’il s’agit d’une étape facultative qui peut survenir après qu’une commande a été passée.

---

Étape 2 : Description du cas d’utilisation (Spécification)

Un diagramme nomme les cas d’utilisation mais manque de détails. LeTableau de description des cas d’utilisatione spécifie le contrat précis pour chaque cas d’utilisation.

Exemple : UC-01 Passer une commande

Champ	Valeur
Identifiant du cas d’utilisation	UC-01
Nom	Passer une commande
Acteur principal	Client
Acteur secondaire	Entrepôt
Préconditions	Le client est connecté ; le panier contient au moins un article ; les articles sont en stock
Postconditions (Succès)	La commande est enregistrée avec le statutconfirmée; le paiement est encaissé ; un numéro de suivi est émis
Postconditions (Échec)	Aucune commande créée ; panier inchangé ; utilisateur informé de la raison
Flux principal	→ Voir Étape 3
Flux alternatifs / exceptions	Stock insuffisant ; paiement refusé
Priorité	Élevée

Objectif : Cette étape définit ce qui doit être vrai avant l’exécution du cas d’utilisation (préconditions) et ce qui doit être vrai après (postconditions), établissant des critères de succès/échec clairs.

---

Étape 3 : Flux d’événements (Scénarios)

C’est le cœur comportemental de l’approche. Le cas d’utilisation « Passer une commande » se développe en un script de scénario—une séquence d’étapes numérotées rédigée avant l’existence de tout diagramme de conception détaillé.

Scénario principal de succès (flux de base)

1. Le client se connecte.
2. Le client valide le panier avec les articles sélectionnés.
3. Le système valide le contenu du panier et la disponibilité du stock.
4. Le système prélève le montant total via la passerelle de paiement.
5. Le système enregistre la commande avec le statut confirmée.
6. Le système renvoie une confirmation de commande avec un numéro de commande.
7. Le système notifie l’entrepôt pour préparer, emballer et expédier.

Scénarios alternatifs

• 3a. Stock insuffisant : Le système signale les articles indisponibles et retourne au panier.
• 4a. Paiement refusé : Le système informe le client et ne crée pas la commande.

Convention clé : Chaque scénario correspond directement à une étape de la description. Ces flux servent de base aux diagrammes d’activité et de séquence de l’étape suivante.

---

Étape 4 : Conception détaillée (diagrammes de séquence et d’activité)

À cette étape, vous choisissez la notation en fonction de l’aspect du système que vous souhaitez mettre en évidence.

• Diagramme de séquence: Met en évidenceles lignes de vie, l’ordre des messages et les responsabilités entre les objets. Idéal pour découvrir les classes et les méthodes.
• Diagramme d’activité : Met en évidencele flux de contrôle et les décisions via les couloirs/parties. Idéal pour documenter les processus et les responsabilités des rôles.

4A. Diagramme de séquence (Perspective d’interaction)

@startuml
title Diagramme de séquence de passation de commande
skinparam linetype ortho
skinparam defaultFontSize 14
skinparam defaultFontColor #333333
skinparam sequenceParticipant underline
skinparam vpDiagramType InteractionDiagram
skinparam {
  FontSize 14
  ArrowColor #4A4A4A
  ArrowFontColor #4A4A4A
  BackgroundColor #FFFFFF
  BorderColor #DEDEDE
  FontColor #333333
  Participant {
    BorderColor #0077B6
    BackgroundColor #F0F8FF
    FontColor #005691
  }
  Actor {
    BorderColor #6A057F
    BackgroundColor #F5EEF8
    FontColor #510363
  }
  Sequence {
    ArrowThickness 2
    LifeLineBorderColor #444444
    LifeLineBackgroundColor #F7F7F7
    BoxBorderColor #AAAAAA
    BoxBackgroundColor #FFFFFF
    BoxFontColor #333333
  }
}

actor "Client" as USR
participant "Service de commande" as OS
participant "Passerelle de paiement" as PG
database "Base de données de commande" as DB

activate USR
USR -> OS : submitOrder(items)
activate OS
alt Validation & Paiement
  OS -> OS : validateCart(items)
  OS -> PG : charge(total)
  activate PG
  PG --> OS : paymentOk
  deactivate PG
  OS -> DB : saveOrder(status=confirmed)
  activate DB
  DB --> OS : orderId
  deactivate DB
  OS --> USR : orderConfirmation(orderId)
else Stock insuffisant
  OS -> DB : checkStock(items)
  activate DB
  DB --> OS : stockUnavailable
  deactivate DB
  OS --> USR : error("En rupture de stock")
else Échec du paiement
  PG --> OS : paymentFailed
  OS --> USR : error("Paiement refusé")
end
deactivate OS
@enduml

Concepts clés :

• Appels synchrones : Flèches pleines (->).
• Réponses : Flèches pointillées (-->).
• Barres d’activation : Affiche la durée de vie du traitement d’un objet.
• alt Fragment combiné : Regroupe les trois scénarios (Succès, Stock insuffisant, Échec du paiement), reflétant directement le flux d’événements de l’étape 3.

4B. Diagramme d’activité (Perspective processus)

@startuml
<style>
  element { MaximumWidth 150 }
  start   { Backgroundcolor #00695C }
  stop    { Backgroundcolor #C2185B }
  activity{ Backgroundcolor #81D4FA; MaximumWidth 150 }
  diamond { Backgroundcolor #FFB74D; MaximumWidth 80 }
  arrow   { LineColor #424242; Fontcolor #000000 }
  swimlane{ Fontcolor #000000; FontSize 14 }
</style>
title Diagramme d'activité de passation de commande

|#F0F8FF|Client|
start
:Connexion;
:Parcourir le catalogue;
:Ajouter des articles au panier;

if (Prêt à passer la commande ?) then (oui)
  :Passer à la caisse;
else (non)
  :Retour à la navigation;
  stop
endif

|#E8F5E9|Système|
:Valider le panier;
:Traiter le paiement;

if (Paiement approuvé ?) then (oui)
  :Créer la commande (status=confirmée);
else (non)
  :Notifier l'échec du paiement;
endif

|#F5EEF8|Entrepôt|
if (Paiement approuvé ?) then (oui)
  :Préparer et emballer les articles;
  :Expédier la commande;
  :Envoyer le numéro de suivi;
  stop
else (non)
  stop
endif
@enduml

Concepts clés :

• Couloirs: Attribuer chaque action à la partie responsable (Client, Système, Entrepôt).
• Nœuds de décision : if/then/else/endif les structures codent les scénarios de branchement.
• Marqueurs de début/fin : Délimitent le début et la fin du processus.

---

Points clés de PlantUML

Pour modéliser efficacement cette approche avec PlantUML, retenez les éléments essentiels de la syntaxe suivants :

1. Diagrammes de cas d’utilisation:
   • Utilisez usecase pour les fonctions.
   • Utilisez ...> pour <<include>> relations.
   • Utilisez <... pour <<extend>> relations.
   • Utilisez rectangle "Nom du système" {} pour définir la limite du système.
2. Diagrammes de séquence :
   • Définissez les participants en utilisant acteur, participant, ou base de données.
   • Utilisez -> pour les appels synchrones et --> pour les réponses.
   • Utilisez activer et désactiver pour afficher les durées de vie des objets.
   • Utilisez alt, sinon, et fin pour les fragments combinés représentant des flux alternatifs.
3. Diagrammes d’activité :
   • Utilisez |#color|NomDeCouloir| pour définir les couloirs.
   • Utilisez :action; pour les activités.
   • Utilisez if/else/endif pour les nœuds de décision.
   • Utilisez démarrage et arrêt pour marquer les limites du processus.

---

Conclusion

L’ Approche pilotée par les cas d’utilisation est plus qu’une simple technique de documentation ; c’est un cadre pour un raffinement progressif. En commençant par la vue d’ensemble (Diagramme de cas d’utilisation) et en approfondissant les comportements spécifiques (Flux d’événements) et les interactions techniques (Séquence/Diagrammes d’activité), les équipes peuvent s’assurer que chaque ligne de code remonte à un besoin utilisateur vérifié.

Cette méthode réduit le risque de malentendus entre les parties prenantes et les développeurs, facilite des tests plus simples grâce à des scénarios clairs, et aboutit à une conception de système robuste et centrée sur l’utilisateur. Que vous construisiez une plateforme de commerce électronique simple ou un système d’entreprise complexe, le respect de cette progression structurée conduira à des exigences plus claires et à un logiciel de meilleure qualité.