Étude de cas : Diagramme de cas d’utilisation pour une plateforme de livraison de nourriture

Modélisation des exigences du monde réel avec UML – Un guide pratique

1. Introduction

Dans le développement logiciel moderne, les diagrammes de cas d’utilisationsont un outil fondamental pour capturer les exigences fonctionnelles du point de vue de l’utilisateur. Cette étude de cas présente une analyse détaillée d’un diagramme de cas d’utilisation réalistepour une plateforme de livraison de nourriture, en utilisant la syntaxe PlantUMLcomme langage de modélisation. L’objectif est de démontrer non seulement quelséléments sont utilisés dans le diagramme, mais aussi pourquoiils sont choisis — en mettant en évidence les décisions de modélisation pratiques, les conventions, et les pièges courants.

Cette étude de cas sert à la fois aux débutants apprenant UMLet aux praticiens affinant leurs pratiques de modélisation. Elle décompose chaque élément du diagramme, explique son objectif et discute des implications réelles.

2. Aperçu du système

La plateforme de livraison de nourriture est une place de marché numérique reliant :

• Clients (particuliers commandant de la nourriture),
• Restaurants (fournisseurs de repas),
• Livreur (personnel de livraison),
• Passerelles de paiement externes (systèmes tiers gérant les transactions).

La plateforme permet aux utilisateurs de parcourir les restaurants, de passer des commandes, de suivre les livraisons, de gérer les paiements et d’appliquer des promotions. Le système s’intègre à des services externes tels que les processeurs de paiement et ne gère pas la logique de paiement en interne.

Code PlantUML :

@startuml
skinparam monochrome true
skinparam shadowing false

left to right direction

' Tous les acteurs sont définis en dehors du rectangle
actor Client
actor "Client inscrit" as RegClient
actor "Personnel du restaurant" as Restaurant
actor Livreur
actor "Processeur de paiement" as PaymentGW

rectangle "Plateforme de livraison de repas" {

(Parcourir les restaurants)
(Passer une commande)
(Suivre une commande)
(Gérer le menu)
(Accepter / Préparer la commande)
(Livrer la commande)
(Traiter le paiement)
(Émettre un remboursement)
(Appliquer un code promo)
(Utiliser un portefeuille)
(Paiement par carte)
(Paiement par portefeuille numérique)

' Associations – les flèches traversent la frontière
Client --> (Parcourir les restaurants)
RegClient --> (Passer une commande)
RegClient --> (Suivre une commande)

Restaurant --> (Gérer le menu)
Restaurant --> (Accepter / Préparer la commande)

Livreur --> (Livrer la commande)

PaymentGW --> (Traiter le paiement)
PaymentGW --> (Émettre un remboursement)

' include
(Passer une commande) ..> (Traiter le paiement) : <<include>>

' extend
(Passer une commande) <.. (Appliquer un code promo) : <<extend>>
(Traiter le paiement) <.. (Utiliser un portefeuille) : <<extend>>

' généralisation
(Traiter le paiement) <|-- (Paiement par carte)
(Traiter le paiement) <|-- (Paiement par portefeuille numérique)
}

' Généralisation d'acteur (aussi en dehors)
Client <|-- RegClient

note right of PaymentGW
Passerelle de paiement externe
(Stripe, PayPal, Adyen, ...)
end note

note bottom of (Appliquer un code promo)
Optionnel – uniquement lorsqu'un code valide est saisi
end note

@enduml

✅ Point clé: Le diagramme se concentre sur les interactions externes — il montre ce que le système fait pour ses utilisateurs et ses systèmes, et non comment il est implémenté.

3. Éléments du diagramme : Analyse approfondie avec une signification pratique

Voici une analyse détaillée de chaque élément UML utilisé dans le diagramme, accompagnée d’une interprétation du monde réel et d’une justification de la modélisation.

4. Décisions clés de modélisation et justification

✅ Pourquoi les acteurs sont-ils en dehors de la frontière du système

• Meilleure pratique: Les acteurs représentent des rôles en dehors du système.
• Pourquoi cela compte: Évite la confusion entre les composants du système et les entités externes.
• Exemple: Pilote n’est pas un module de la plateforme — il s’agit d’un rôle tiers interagissant avec celle-ci.

📌 Astuce Pro: Si tous les acteurs étaient à l’intérieur de la frontière, cela impliquerait que le système les inclut — ce qui est trompeur.

✅ Pourquoi utiliser Client <|-- ClientInscrit au lieu de dupliquer les liens

• Sans généralisation, vous devriez dessiner :
  PlantUML
  
  
  Modifier PlantUML dans VPasCode
  

  PlantUML Edit PlantUML in VPasCode

  Client --> (Parcourir les restaurants)
  ClientInscrit --> (Parcourir les restaurants)
  ClientInscrit --> (Passer une commande)
  

  Edit PlantUML in VPasCode

  
  
  Modifier PlantUML dans VPasCode
  
• Avec la généralisation, vous n’avez besoin que de :
  PlantUML
  
  
  Modifier PlantUML dans VPasCode
  

  PlantUML Edit PlantUML in VPasCode

  Client <|-- ClientInscrit
  Client --> (Parcourir les restaurants)
  ClientInscrit --> (Passer une commande)
  

  Edit PlantUML in VPasCode

  
  
  Modifier PlantUML dans VPasCode
  
• Résultat: Diagramme plus clair et plus facile à maintenir.

📌 Meilleure pratique: Utilisez la généralisation des acteurs chaque fois qu’un acteur spécialisé hérite de tous les comportements d’un acteur plus général.

✅ Pourquoi <<inclure>> et <<étendre>> sont utilisés correctement

❗ Erreur courante: Inverser la direction de la flèche. N’oubliez jamais :

• inclure: Base ..> Inclus
• étendre: Extension <.. Base

✅ Pourquoi Traiter le paiement possède des généralisations

• Paiement par carte et Paiement par portefeuille numérique sont formes spécialisées de Traiter le paiement.
• Cela montre que la plateforme prend en charge plusieurs méthodes de paiement, mais elles suivent toutes le même flux de base.
• La généralisation permet un comportement partagé et une extensibilité future.

📌 Cas d’utilisation: Ajouter une nouvelle méthode de paiement (par exemple, Apple Pay) ne serait qu’une autre généralisation de Traiter le paiement.

5. Interprétations du monde réel et questions répondues

Ce diagramme n’est pas seulement une aide visuelle : il répond à des questions commerciales et techniques essentielles :

✅ Valeur commerciale: Le diagramme communique clairement ce que fait le système, qui l’utilise, et quels comportements sont obligatoires par rapport aux facultatifs.

6. Lignes directrices de modélisation courantes démontrées

Le diagramme illustre plusieurs bonnes pratiques dans la modélisation des cas d’utilisation UML :

📌 Avertissement: De nombreux diagrammes utilisent mal <<étendre>> pour signifier « facultatif » sans comprendre la nature conditionnelle des extensions. Ce diagramme évite cette erreur.

7. Améliorations potentielles et critique

Bien que le diagramme soit solide, voici suggestions constructives pour affinement :

🔧 1. Ajouter des stéréotypes pour plus de clarté

acteur "Traitement des paiements" comme PaymentGW <<système>>

• Pourquoi: Rend explicite qu’il s’agit d’un système externe, et non d’un rôle humain.
• Avantage: Réduit l’ambiguïté, en particulier dans les grands modèles.

🔧 2. Clarifier Appliquer le code promoCondition d’extension

Actuellement :

note en bas de (Appliquer le code promo)
  Optionnel – uniquement lorsqu'un code valide est saisi
fin note

• Mieux: Utiliser une notation de condition ou gardien dans le <<extend>> flèche :

(Passer une commande) <.. (Appliquer un code promo) : <<extend>> [code promo valide]

• Pourquoi: Plus précis qu’une note — lie directement l’extension à une condition.

🔧 3. Envisager d’ajouter un Voir l'historique des commandes Cas d’utilisation

• Actuellement manquant, mais probablement important pour les clients et les restaurants.
• Pourrait être ajouté en tant que Client enregistré cas d’utilisation.

🔧 4. Regrouper les cas d’utilisation liés (Optionnel)

Pour les diagrammes plus grands, regrouper les cas d’utilisation dans des paquets:

package "Gestion des commandes" {
    (Passer une commande)
    (Suivre une commande)
    (Appliquer un code promo)
}
package "Paiement" {
    (Traiter le paiement)
    (Utiliser un portefeuille)
    (Paiement par carte)
    (Paiement par portefeuille numérique)
}

• Avantage: Améliore l’évolutivité et la lisibilité.

8. Quelles sont les prochaines étapes ?

Cette étude de cas a montré comment un diagramme de cas d’utilisation bien structuré peut capturer clairement et de manière concise une logique métier complexe. Pour approfondir votre compréhension, voici les prochaines étapes suggérées:

🔄 Option 1 : Vue centrée sur le restaurant

Modéliser le même domaine à partir de la perspective du restaurant:

• Se concentrer sur Gérer le menu, Accepter / Préparer la commande, Voir les commandes, Mettre à jour le statut.
• Afficher Restaurant en tant qu’acteur principal.
• Inclure Client en tant qu’acteur secondaire (par exemple, Client envoie une commande → Restaurant la reçoit).

✅ Avantage: Révèle différents objectifs du système et rôles des acteurs.

🔄 Option 2 : Ajouter plus de points d’extension

Améliorer Passer une commande avec :

• Appliquer un coupon (si le code promo est invalide → <<extend>> avec un message d’erreur)
• Demander des instructions spéciales (facultatif)
• Planifier la commande (pour une livraison future)

🔄 Option 3 : Comparer inclure vs étendre avec des exemples

📌 Règle générale:

• Utiliser <<inclure>> lorsque le comportement doit se produire.
• Utiliser <<étendre>> lorsque le comportement pourrait se produire dans certaines conditions.

🔄 Option 4 : Convertir en diagrammes de séquence ou d’activité

Pour une analyse plus approfondie :

• Diagramme de séquence: Montrer le flux de Passer une commande → Traiter le paiement → Livrer la commande avec des messages entre les acteurs et le système.
• Diagramme d’activité: Modéliser les points de décision dansTraiter le paiement (par exemple, carte refusée → réessayer ou passer au portefeuille électronique).

9. Conclusion

Cette étude de cas démontre queun diagramme de cas d’utilisation bien conçu est bien plus qu’un croquis visuel — c’est unoutil de communication stratégique qui :

• Clarifie le périmètre du système,
• Capture les règles métier,
• Guide le développement,
• Prévient les malentendus.

LePlateforme de livraison de repas diagramme est unexcellent exemple de :

• Utilisation appropriée de la notation UML,
• Décisions de modélisation solides,
• Séparation claire des préoccupations,
• Utilisation efficace des notes et des généralisations.

En suivant les principes présentés ici —une dénomination orientée vers l’objectif, une utilisation correcte deinclure/étendre, généralisation d’acteur, et utilisation stratégique des notes — vous pouvez créer des diagrammes de cas d’utilisation qui sont à la fois précis et actionnable.

✅ Leçons finales