É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’utilisation sont 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éaliste pour une plateforme de livraison de nourriture, en utilisant la syntaxe PlantUML comme langage de modélisation. L’objectif est de montrer non seulement ce qui éléments sont utilisés dans le diagramme, mais aussi pourquoi ils sont choisis — mettant en évidence les décisions de modélisation pratiques, les conventions, et les pièges courants.

Cette étude de cas s’adresse à la fois à les débutants apprenant UML et à les praticiens perfectionnant leurs pratiques de modélisation. Elle analyse chaque élément du diagramme, explique son objectif et discute des implications dans le monde réel.

---

2. Aperçu du système

Le plateforme de livraison de nourriture est une place de marché numérique qui connecte :

• Clients (individus qui commandent des aliments),

• Restaurants (fournisseurs de repas),

• Livreurs (personnel de livraison),

• Passerelles de paiement externes (systèmes tiers gérant les transactions).

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

Code PlantUML :

@startuml
skinparam monochrome true
skinparam shadowing false

direction de gauche à droite

‘ Tous les acteurs sont définis en dehors du rectangle
acteur Client
acteur « Client enregistré » comme RegCustomer
acteur « Personnel du restaurant » comme Restaurant
acteur Livreur
acteur « Processeur de paiement » comme PaymentGW

rectangle « Plateforme de livraison de nourriture » {

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

‘ Associations – les flèches traversent la frontière
Client –> (Parcourir les restaurants)
Client enregistré –> (Passer une commande)
Client enregistré –> (Suivre la commande)

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

Livreur –> (Livrer la commande)

Passerelle de paiement –> (Traiter le paiement)
Passerelle de paiement –> (Émettre un remboursement)

‘ inclure
(Passer une commande) ..> (Traiter le paiement) : <<inclure>>

‘ étendre
(Passer une commande) <.. (Application du code promo) : <<étendre>>
(Traiter le paiement) <.. (Utilisation du portefeuille) : <<étendre>>

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

‘ Généralisation d’acteur (également en dehors)
Client <|– Client enregistré

note à droite de Passerelle de paiement
Passerelle de paiement externe
(Stripe, PayPal, Adyen, …)
fin de la note

note en bas de (Application du code promo)
Facultatif – uniquement lorsque un code valide est saisi
fin note

@enduml

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

---

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

Ci-dessous se trouve une analyse complète de chaque élément UML utilisé dans le diagramme, accompagnée d’une interprétation concrète et d’une justification de modélisation.

#	Élément	Notation	Signification et objectif	Décision de modélisation / Commentaire
1	Frontière du système	rectangle "Plateforme de livraison de nourriture"	Définit le périmètre du système modélisé. Tous les cas d’utilisation à l’intérieur en font partie.	Le nom est concis mais descriptif. Dans les contextes d’entreprise, des noms plus longs (par exemple, « Système de gestion des commandes clients ») peuvent être utilisés.
2	Acteur humain principal	acteur Client, acteur Livreur	Représente rôles externesqui initient ou participent aux cas d’utilisation.	Les noms sont simples et intuitifs. Évite les stéréotypes inutiles comme<<personne>>sauf si nécessaire pour les grands modèles.
3	Acteur avec alias	acteur "Personnel du restaurant" comme Restaurant	Permet de raccourcir un nom d’acteur long et descriptif pour plus de clarté dans les connexions.	Très efficace lorsque les noms d’acteurs contiennent des espaces ou sont verbeux. Réduit le désordre et améliore la lisibilité.
4	Acteur système externe	acteur "Processus de paiement" comme PaymentGW	Modélisesystèmes tiersavec lesquels la plateforme interagit.	Pas de stéréotype«système»est utilisé — acceptable dans les diagrammes légers. Toutefois, l’ajout de«système»peut clarifier l’intention dans les systèmes complexes.
5	Généralisation d’acteur	`Client <	— RegClient`	Indique qu’unclient enregistréest une version spécialisée d’unclient invité.
6	Association ordinaire	Client --> (Parcourir les restaurants)	Montre que l’acteurinitieouparticipe àle cas d’utilisation.	Ligne pleine = communication. La direction est implicite du acteur au cas d’utilisation (pas besoin de flèche).
7	Relation «include»	(Passer une commande) ..> (Traiter le paiement) : <<include>>	Traiter le paiementesttoujours requislorsqu’on passe une commande.	La flèche pointede l’incluant → inclus. C’est crucial :Passer une commande inclut Traiter le paiementcomme une étape obligatoire.
8	Relation «extend»	(Passer une commande) <.. (Appliquer un code promo) : <<extend>>	Appliquer un code promo estfacultatifet ne se produit que dans certaines conditions.	La flèche pointede l’extension → la base. Le cas d’utilisation de base (Passer une commande) peut être étendu conditionnellement.
9	Généralisation du cas d’utilisation	`(Traiter le paiement) <	— (Paiement par carte)<br>(Traiter le paiement) <	— (Paiement par portefeuille numérique)`
10	Note	note à droite de PaymentGW note en bas de (Appliquer le code promo)	Fournit explication contextuelle sur l’implémentation ou les règles métier.	Les notes sont sous-utilisées mais extrêmement précieuses. Elles évitent les malentendus (par exemple, en précisant que PaymentGW est externe).
11	Acteurs en dehors de la frontière	Tous acteur déclarations précèdent le rectangle	Met en évidence que aucun acteur ne fait partie du système — séparation claire des préoccupations.	L’un des deux agencements standards. Préféré lorsque les acteurs sont nombreux ou externes.
12	Direction du diagramme	direction de gauche à droite	Améliore l’agencement lorsque plusieurs acteurs se trouvent à gauche.	Améliore la lisibilité. Particulièrement efficace avec 4 à 8 acteurs. Alternative : agencement du haut vers le bas pour un nombre réduit d’acteurs.

---

4. Décisions clés en matière de modélisation et justifications

✅ Pourquoi les acteurs sont situés à l’extérieur de la frontière du système

• Meilleure pratique: Les acteurs représentent des rôlesà l’extérieurdu système.

• Pourquoi cela importe: Évite toute confusion entre les composants du système et les entités externes.

• Exemple: Chauffeurn’est pas un module de la plateforme — il s’agit d’un rôle tiers qui interagit avec elle.

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

---

✅ Pourquoi utiliserClient <|-- ClientEnregistréau lieu de dupliquer les liens

• Sans généralisation, vous devriez dessiner :

  Client --> (Parcourir les restaurants)
  ClientEnregistré --> (Parcourir les restaurants)
  ClientEnregistré --> (Passer une commande)
  

• Avec la généralisation, vous n’avez besoin que de :

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

• Résultat: Diagramme plus propre 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

Relation	Objectif	Direction	Exemple
<<inclure>>	Sous-flux obligatoire	Depuis y compris → inclus	Passer une commande doit inclure Traiter le paiement
<<étendre>>	Extension facultative	Depuis extension → base	Appliquer le code promo étend Passer la commande seulement si le code est valide

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

• inclure: Base ..> Incluse

• étendre: Extension <.. Base

---

✅ Pourquoi Traiter le paiement a 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 principal.

• La généralisation permet de comportement partagé et 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 un outil visuel — il répond à des questions critiques d’ordre commercial et technique :

Question	Réponse du diagramme
Qui sont les principaux utilisateurs ?	Clients, Clients enregistrés, Personnel des restaurants, Livreurs, Passerelle de paiement
Les utilisateurs non enregistrés peuvent-ils passer des commandes ?	❌ Non — uniquement ClientEnregistré peut Passer une commande. Client ne peut que Parcourir les restaurants.
Le paiement est-il toujours requis ?	✅ Oui — Passer une commande inclut Traiter le paiement. Obligatoire.
Les clients peuvent-ils appliquer des codes promotionnels ?	✅ Oui — mais uniquementfacultativementvia<<étendre>>. Uniquement si un code valide est saisi.
Quelles méthodes de paiement sont prises en charge ?	Carte et portefeuille numérique (via généralisation). Un système externe gère le traitement réel.
Qui gère le paiement ?	ExternePaymentGW — non inclus dans la plateforme.
Les restaurants peuvent-ils gérer leurs menus ?	✅ Oui —Restaurant l’acteur interagit avecGérer le menu et Accepter / Préparer la commande.

✅ Valeur métier: Le diagramme communique clairementce que fait le système, qui l’utilise, etquels comportements sont obligatoires ou facultatifs.

---

6. Principes courants de modélisation illustrés

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

Principe	Application
Utilisez des noms de cas d’utilisation orientés vers les objectifs	Passer une commande, Suivre une commande, Appliquer un code promotionnel — tous commencent par un verbe et décrivent un objectif utilisateur.
Maintenez le diagramme lisible	Seulement10 cas d’utilisation sont affichés — idéal pour la plupart des domaines d’entreprise (5 à 12 est recommandé).
Systèmes externes comme acteurs	PaymentGW est modélisé comme un acteur, et non comme un cas d’utilisation. Cela sépare correctement les préoccupations.
Utilisez des notes pour clarifier les ambiguïtés	Les notes expliquent quePaymentGW est externe et que le code promotionnel est facultatif — essentiel pour éviter les malentendus.
Utilisez la généralisation d’acteur pour réduire le brouillard	`Client <
Utilisezinclure et étendrecorrectement	Clarté entre le comportement obligatoire et le comportement facultatif.

📌 Avertissement: De nombreux diagrammes mal utilisent <<extend>> 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 des recommandations constructives pour une amélioration :

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

acteur "Processus de paiement" comme PaymentGW <<systeme>>

• Pourquoi: Rend explicite le fait qu’il s’agit d’un système externe, et non d’un rôle humain.

• Avantage: Réduit l’ambiguïté, notamment dans les grands modèles.

🔧 2. Clarifier Appliquer le code promotionnel Condition d’extension

Actuellement :

note en bas de (Appliquer le code promotionnel)
  Facultatif – uniquement lorsque un code valide est saisi
fin note

• Meilleur: Utiliser une notation conditionnelle ou garde dans le <<étendre>> flèche :

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

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

🔧 3. Considérer l’ajout d’un Voir l'historique des commandes Cas d’utilisation

• Actuellement manquant, mais probablement important pour les clients et les restaurants.

• Pourrait être ajouté comme un ClientEnregistré cas d’utilisation.

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

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

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

• Avantage: Améliore la scalabilité et la lisibilité.

---

8. Que faire ensuite ?

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

🔄 Option 1 : Vue centrée sur le restaurant

Modéliser le même domaine à partir du point de vue du restaurant:

• Se concentrer sur Gérer le menu, Accepter / Préparer la commande, Voir les commandes, Mettre à jour le statut.

• Afficher Restaurant comme acteur principal.

• Inclure Client comme acteur secondaire (par exemple, Client envoie la commande → Restaurant la reçoit).

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

🔄 Option 2 : Ajouter plus de points d’extension

Améliorer Passer une commande avec :

• Appliquer le bon de réduction (si le code promotionnel est invalide → <<étendre>> avec message d’erreur)

• Demander des instructions spéciales (optionnel)

• Planifier la commande (pour livraison future)

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

Cas d’utilisation	<<inclure>>	<<étendre>>
Passer la commande → Traiter le paiement	✅ Obligatoire	❌ Pas facultatif
Passer la commande → Appliquer le code promotionnel	❌ Pas obligatoire	✅ Conditionnel
Connexion → Vérifier l'identité	✅ Toujours nécessaire	❌ Non applicable
Payer → Appliquer la réduction	✅ Toujours	✅ Seulement si une réduction existe

📌 Règle de base:

• Utiliser <<inclure>> lorsque le comportement doit avoir lieu.

• Utiliser <<étendre>> lorsque le comportement pourrait avoir lieu sous 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 la 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 dans Traiter le paiement (par exemple, carte refusée → réessayer ou passer au portefeuille).

---

9. Conclusion

Cette étude de cas démontre que un diagramme de cas d’utilisation bien conçu va bien au-delà d’un simple croquis visuel — c’est un outil de communication stratégique qui :

• Clarifie le périmètre du système,

• Capture les règles métier,

• Guide le développement,

• Empêche les malentendus.

Le Plateforme de livraison de nourriture diagramme est un excellent 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 — nomenclature orientée vers les objectifs, utilisation correcte de inclure/étendre, généralisation des acteurs, et utilisation stratégique des notes — vous pouvez créer des diagrammes de cas d’utilisation qui sont à la fois préciset actionnable.

---

✅ Points clés finaux

Principe	Appliqué ici ?	Pourquoi cela importe-t-il
Utilisez des noms de cas d’utilisation orientés vers les objectifs	✅ Oui	Améliore la clarté et le focus utilisateur
Gardez la taille du diagramme raisonnable	✅ Oui (10 cas d’utilisation)	Évite le surmenage cognitif
Systèmes externes comme acteurs	✅ Oui	Séparation correcte des préoccupations
Utilisez des notes pour le contexte	✅ Oui	Évite les malentendus
Utilisez la généralisation pour réduire la redondance	✅ Oui	Rend le diagramme évolutif et maintenable
Correct<<inclure>> et <<étendre>> direction	✅ Oui	Assure un modèle de comportement précis

---