Posted inUML

Maitriser les relations de cas d’utilisation UML : la puissance et le danger de «include» et «extend»

Dans le monde des exigences logicielles et de la modélisation des systèmes, UML (Langage de modélisation unifié) reste une pierre angulaire pour visualiser le comportement des systèmes. Parmi ses fonctionnalités les plus puissantes mais souvent mal comprises figurent les «include» et  «extend»  relations entre les cas d’utilisation. Ces mécanismes sont conçus pour réduire la duplication, gérer la variabilité, et améliorer la modularité dans les modèles de cas d’utilisation. Toutefois, leur mauvaise utilisation est fréquente — entraînant des diagrammes excessivement complexes, de la confusion parmi les parties prenantes et une perte de concentration sur la valeur pour l’utilisateur.

 

 

Cet article fournit un guide complet, pratique et appuyé par des experts pour comprendre, appliquer et éviter les pièges courants de «include» et «extend». Nous explorerons leurs véritables sémantiques, les comparer côte à côte, examiner pourquoi elles tombent dans le même piège que les DFD (décomposition fonctionnelle), et proposer meilleures pratiques modernes pour les équipes 2025–2026 — en particulier celles travaillant dans des environnements agiles, lean ou hybrides.

🔹 Sémantiques fondamentales : ce que signifient vraiment «include» et «extend» Vraiment signifient

✅ «include» : Réutilisation obligatoire – Le sous-flot «toujours requis»

Définition:
La relation «inclure» représente un flux secondaire obligatoire qui est factorisé pour être réutilisé dans plusieurs cas d’utilisation.obligatoire, toujours exécutéflux secondaire qui est factorisé pour être réutilisé dans plusieurs cas d’utilisation.

📌 Caractéristiques principales :

  • Toujours exécuté: Le cas d’utilisation inclus s’exécute à chaque fois que le cas d’utilisation de base est appelé.

  • Le cas d’utilisation de base est incomplet sans lui: Sans le comportement inclus, le cas d’utilisation de base ne peut pas accomplir sa finalité.

  • Direction de dépendance: La flèche pointedu cas de base → inclus.

  • Signification autonome: Le cas d’utilisation inclus est généralementsans sens seul—il n’a de sens que comme partie d’un processus plus large.

  • Analogie: Comme un appel defonctionousous-routineen programmation — essentiel pour la routine principale.

🧠 Mnémotechnique classique :

« Pour faireConnexion, vous devezAuthentifier l’utilisateur.”
« Pour faireRetirer de l’argent, vous devez Valider le code PIN.”

Ce sont des étapes non négociables. Vous ne pouvez pas vous connecter sans authentification. Vous ne pouvez pas retirer de l’argent sans valider le code PIN.

💡 Quand l’utiliser :

  • Lorsqu’une comportement commun, complexe et réutilisable apparaît dans deux ou plusieurs cas d’utilisation.

  • Exemples :

    • Authentifier l'utilisateur

    • Enregistrer le journal d'audit

    • Envoyer une notification

    • Valider le format d'entrée

✅ Règle de base : Utilisez « inclure » uniquement lorsque le comportement réutilisé est important, non trivial, et apparaît dans ≥2–3 cas d’utilisation.

✅ « étendre » : Variation facultative – Le « complément conditionnel »

Définition:
La relation «étendre» définitoptionnel, conditionnel ou variantcomportement quise connecte àun point d’extension spécifiquepoint d’extensiondu cas d’utilisation de base.

📌 Caractéristiques principales :

  • Exécuté conditionnellement: Ne s’exécute que dans certaines circonstances.

  • Le cas d’utilisation de base est complet en lui-même: Le flux normal fonctionne sans l’extension.

  • Direction de dépendance: La flèche pointede l’extension → base (vers l’arrière).

  • Signification autonome: Le cas d’utilisation d’extension estpresque jamais significatif en lui-même—il n’a de sens qu’dans son contexte.

  • Analogie: Comme uncrochet, plugin, ou unconseil de programmation orientée aspect (AOP)—il ajoute un comportement à un point défini.

🧠 Mnémotechnique classique :

« Pendant que vous faites Réserver un vol, vous pourriezvouloir Sélectionner un siège préféré.”
« Pendant que vous faites Payer par carte de crédit, vous pourriezdevoir Saisir le code 3D Secure.”

Ce sont des améliorations facultativesaméliorations facultatives—non obligatoires pour le flux principal.

💡 Quand l’utiliser :

  • Pour modéliserdes chemins alternatifs, des exceptions, ou des fonctionnalités facultatives.

  • Lorsqu’un cas d’utilisation présentedes comportements variésbasés sur des conditions (par exemple, rôles des utilisateurs, états du système, préférences).

  • Exemples :

    • Appliquer la réduction (étend Passer la commande)

    • Demander un remboursement (étend Traiter le paiement)

    • Générer un reçu PDF (étend Terminer la transaction)

✅ Règle de base: Utilisez «étendre» avec parcimonie — uniquement pour variations significatives avec des points d’extension.

🔍 Comparaison rapide : «inclure» vs «étendre»

Aspect «inclure» «étendre»
Exécution Toujours Parfois / de manière conditionnelle
Le UC de base est complet seul ? ❌ Non — dépend de ce qui est inclus ✅ Oui — complet sans extensions
Direction de la dépendance Base → Inclus Extension → Base
Direction de la flèche Pointe vers le cas d’utilisation inclus Pointe vers le cas d’utilisation de base
Objectif principal Réutilisation obligatoire, étapes partagées Gérer les flux optionnels ou variants
Analogie Appel de fonction / sous-routine Point d’ancrage / plugin / conseil AOP
Signification autonome ? Rarement Presque jamais
Meilleur pour Préoccupations réutilisables, complexes et transversales Comportement conditionnel, optionnel ou alternatif

⚠️ Le « piège de la décomposition » : Pourquoi les diagrammes de cas d’utilisation déraillent

Tout commeDFD (diagrammes de flux de données)souffrent dupiège de la décomposition fonctionnelle, les diagrammes de cas d’utilisation sontsujets à la même maladie mortelle: sur-décomposition.

📉 Le piège de la décomposition fonctionnelle du DFD (résumé) :

  • Les équipes continuent de diviser les processus en bulles de plus en plus petites.

  • Les diagrammes explodent en dizaines de petites fonctions de bas niveau.

  • Le le but initial—livrer de la valeur à l’utilisateur—est perdu.

  • Finissent par ressembler à pseudo-code ou conception d’algorithme interne, pas le comportement de l’utilisateur.

🧨 Le cas d’utilisation « maladie de la décomposition fonctionnelle » :

  • Chaque petite étape devient un cas d’utilisation à part entière :

    • Saisir le nom d'utilisateur

    • Saisir le mot de passe

    • Cliquer sur le bouton de connexion

    • Valider le format

    • Afficher le message d'erreur

  • «inclure» est appliqué libéralement pour décomposer chaque action.

  • Résultat : un hiérarchie profonde de cas d’utilisation (A → B → C → D…) sans objectif clair de l’acteur.

  • Les diagrammes deviennent impossible à maintenir, confus, et inutile pour les parties prenantes.

❌ Drapeau rouge: Si votre diagramme de cas d’utilisation comporte plus de 15 à 20 cas d’utilisation, ou si la plupart des cas d’utilisation de base comportent entre 2 et 4 étapes, vous êtes probablement dans le piège.

🛠️ Pourquoi cela se produit : erreurs courantes et malentendus

Piège Explication Comment l’éviter
Surutilisation de «include» Considérer chaque sous-étape comme un cas d’utilisation réutilisable. Utilisez uniquement «include» pour important, réutilisable, transversal comportements (par exemple, authentification, journalisation).
Confusion sur la direction de la flèche Dessiner les flèches «include» à l’envers (base ← inclus) ou les flèches «extend» en avant. Souvenez-vous : include = base → inclus; extend = en cours d’extension → base.
Utilisation de «extend» pour les alternatives Modélisation des flux alternatifs à l’intérieur un cas d’utilisation comme «extend» au lieu d’utiliser des alternatives textuelles. Utilisez flux alternatifs textuels pour la plupart des variations. Réservez «étendre» pour extensions réellement optionnelles.
Création de chaînes d’inclusion A → B → C → D → E… Évitez les chaînes profondes. Si vous avez besoin de plusieurs inclu, envisagez le réfactoring en un seul cas d’utilisation réutilisable.
Points d’extension flous Ajout de relations «étendre» sans points d’insertion clairs et nommés. Définissez points d’extension explicites (par exemple, «après confirmation du paiement») dans le cas d’utilisation de base.
Brouillage du diagramme Trop de cas d’utilisation et de relations → bruit visuel. Gardez les diagrammes petits, centrés et axés sur l’acteur. Utilisez plusieurs diagrammes par sous-système.
Confusion des parties prenantes Les parties prenantes non techniques trouvent les relations «inclure/étendre» difficiles à comprendre. Utilisez scénarios textuels ou cartes des histoires utilisateurs pour plus de clarté.
Modélisation au niveau du design Modélisation de l’architecture interne (par exemple, «appeler la base de données») au lieu des objectifs utilisateurs. Restez centrés sur valeur de l’acteur—pas l’implémentation.
Débats sans fin Des équipes discutant de « c’est inclure ou étendre ? » au lieu d’écrire des scénarios. Utilisez heuristiques pratiques et priorisez la clarté à la formalité.

✅ Meilleures pratiques pour 2025–2026 : une approche moderne et agile

Le paysage de l’ingénierie des besoins a évolué. Les équipes agiles, lean et orientées produit s’éloignent de plus en plus des diagrammes UML lourds au profit de techniques légères et centrées sur la valeur techniques.

🎯 Principe fondamental : Concentrez-vous sur la valeur de l’acteur, pas sur la structure interne

❗ Posez cette question avant d’ajouter tout «inclure» ou «étendre»:
« Ce lien aide-t-il l’utilisateur à comprendre l’objectif, ou ne fait-il que décomposer le système ? »

✅ Meilleures pratiques modernes recommandées :

1. Utilisez «inclure» avec parcimonie — uniquement pour les comportements réutilisables majeurs

  • Utilisez uniquement pour préoccupations transversales qui apparaissent dans plusieurs cas d’utilisation.

  • Exemples :

    • Authentifier l'utilisateur

    • Envoyer une notification par courriel

    • Enregistrer un événement de sécurité

    • Appliquer les règles métier

❌ Éviter : Saisir le nom d'utilisateur, Cliquez sur Envoyer, Valider le format du courriel

2. Préférer les flux alternatifs textuels aux «extend»

  • Au lieu de :

    «extend» : Sélectionner le siège préféré → Réserver le vol

  • Utiliser :

    Cas d'utilisation : Réserver un vol
...
Flux alternatif :
  1. L'utilisateur sélectionne l'option « Siège préféré ».
  2. Le système affiche la carte des sièges.
  3. L'utilisateur sélectionne un siège.
  4. Le système applique la préférence de siège.

✅ Pourquoi ? Les flux textuels sont plus faciles à lire, plus flexibles, et moins sujets à une mauvaise utilisation.

3. Garder Diagrammes de cas d’utilisationPetits et centrés

  • Un diagramme par acteur ou sous-système.

  • Limitez à 5 à 10 cas d’utilisation par diagramme.

  • Utilisez diagrammes de paquetage ou diagrammes de contexte pour montrer la structure de haut niveau.

4. Demandez : « Un plan de récit d’utilisateur communiquerait-il mieux cela ? »

  • Si vous utilisez 10+ relations « inclure »/« étendre », envisagez de remplacer le diagramme par :

    • Un plan de récit d’utilisateur

    • Un tableau basé sur des scénarios

    • Un schéma simple avec les chemins clés

🔄 Tendance moderne: De nombreuses équipes agiles évitent complètement les diagrammes de cas d’utilisation ou les utilisent uniquement pour la découverte de haut niveau.

5. Utilisez «extend» uniquement pour les variantes significatives

  • Réservez «extend» pourfacultatif, non essentielfonctionnalités telles que :

    • Sontrarement utilisées

    • Sontdépendantes du contexte

    • Sontindépendantesdu but principal

✅ Exemple :
Traiter le paiement (base)
Appliquer l'authentification 3D Secure (extend) — uniquement lorsque requis par la banque

❌ Évitez :
Saisir le numéro de carte → Valider la carte → Traiter le paiement (tous doivent être des étapes du même cas d’utilisation)

📊 Résumé : Les règles d’or de «include» et «extend»

Règle Conseils
1. «include» = Obligatoire Utilisez uniquement pouressentiel, réutilisableétapes qui apparaissent dans ≥2 cas d’utilisation.
2. «extend» = facultatif Utilisez uniquement pourconditionnel, variant ou rarecomportements.
3. Le cas d’utilisation de base doit être complet «extend» : la base fonctionne seule. «include» : la base est incomplète sans elle.
4. Gardez-le simple Si un cas d’utilisation comporte moins de 4 à 6 étapes après «include»/«extend», vous avez surexpliqué.
5. Priorisez la lisibilité Scénarios textuels > diagrammes complexes.
6. Évitez les chaînes Pas A → B → C → D. Réorganisez en un seul cas d’utilisation réutilisable.
7. Connaître son public Les parties prenantes ne s’intéressent pas aux flèches «include»—ils s’intéressent à la valeur.
Posez-vous la question : « S’agit-il d’un objectif utilisateur ou d’une étape interne ? » Si ce n’est pas un objectif pour l’acteur, il ne devrait probablement pas figurer dans un cas d’utilisation.

🎯 Pensée finale : Outils, pas pièges

«include» et «extend» sontdes outils puissants—pas des règles rigides. Ils ont été conçus pour :

  • Réduire la duplication

  • Gérer la variabilité

  • Améliorer la maintenabilité

Mais commela décomposition fonctionnelle dans les diagrammes en flux de données, ils deviennentdes armes dangereuseslorsqu’ils sont trop utilisés. Le vrai danger n’est pas les relations elles-mêmes — c’estperdre de vue l’objectif de l’utilisateur.

🔥 Souviens-toi:
Un cas d’utilisation n’est pas un processus technique.
C’est un histoire sur ce que l’utilisateur souhaite accomplir—et comment le système aide.

En cas de doute, demandez-vous:

« Un utilisateur comprendrait-il cela sans connaître le UML ? »
Sinon, simplifiez.
Si oui, vous êtes sur la bonne voie.

📚 Lecture complémentaire et références

  • Spécification UML (OMG): www.omg.org/spec/UML

  • Martin Fowler – Modélisation des cas d’utilisation: Modèles d’analyse & UML Distillé

  • Ivar Jacobson – L’avantage des objets: Travail fondamental sur les cas d’utilisation

  • Modélisation agile (AM) par Scott W. Ambler

  • Cartographie des user stories par Jeff Patton – Une alternative moderne aux diagrammes complexes

✅ La règle de la phrase unique

Utilisez «include» pour le réemploi obligatoire, «extend» pour la variation facultative, mais uniquement lorsque cela ajoute véritablement de la valeur. Sinon, gardez-le simple.

Parce que, au final, l’objectif n’est pas de dessiner des diagrammes parfaits diagrammes UML—c’est de construire des systèmes qui apportent une véritable valeur aux vrais utilisateurs.

📌 Note de l’auteur (2025–2026):
Alors que les équipes passent vers orienté produit, orienté valeur, et collaboratif développement, le rôle des diagrammes UML traditionnels évolue. «include» et «extend» restent utiles, mais uniquement lorsqu’ils sont utilisés avec modération, clarté et objectifseulement lorsqu’ils sont utilisés avec modération, clarté et objectif. Laissez-les servir l’utilisateur, pas le diagramme.