Now Reading: Un guide complet sur les relations Include et Extend dans les diagrammes de cas d’utilisation UML

1
  • 01

    Un guide complet sur les relations Include et Extend dans les diagrammes de cas d’utilisation UML

de_DEen_USes_ESid_IDjapl_PLpt_PTru_RUvizh_CNzh_TW

Un guide complet sur les relations Include et Extend dans les diagrammes de cas d’utilisation UML

Unified Modeling Language, Visual Paradigm, Use Case Modeling8 hours ago

Langage de modélisation unifié (UML) les diagrammes de cas d’utilisation sont des outils puissants pour modéliser les exigences fonctionnelles d’un système. Ils illustrent comment les acteurs (utilisateurs ou systèmes externes) interagissent avec le système à travers des cas d’utilisation, qui représentent des fonctionnalités spécifiques. Deux relations clés dans les diagrammes de cas d’utilisation—Include et Extend—aident à gérer la complexité en structurant et en modularisant le comportement. Ce tutoriel fournit une explication détaillée de ces relations, de leurs objectifs, de leurs caractéristiques et de leurs applications pratiques, accompagnée d’exemples pour assurer une clarté maximale.

Qu’est-ce que les relations Include et Extend ?

Dans les diagrammes de cas d’utilisation UML, Include et Extend les relations Include et Extend vous permettent de décomposer des cas d’utilisation complexes en composants plus petits, réutilisables ou facultatifs. Ces relations améliorent la modularité, réduisent la redondance et augmentent la clarté des diagrammes.

Include” and “Extend” Use Cases - Visual Paradigm Blog

  • Relation Include (<<include>>): Représente un comportement obligatoire qui est toujours exécuté dans le cadre d’un cas d’utilisation de base. Il extrait la fonctionnalité commune partagée entre plusieurs cas d’utilisation dans un composant réutilisable.

  • Relation Extend (<<extend>>): Représente un comportement facultatif ou conditionnel qui étend un cas d’utilisation de base sous des conditions spécifiques, en maintenant le cas d’utilisation de base centré sur sa fonctionnalité principale.

Les deux relations utilisent des flèches pointillées pour relier les cas d’utilisation, avec des étiquettes indiquant <<include>> ou <<extend>>. La direction de la flèche est cruciale, car elle reflète la dépendance entre les cas d’utilisation.

Relation Include (<<include>>)

Objectif

Le InclureLa relation d’inclusion est utilisée pour extraire un comportement commun et obligatoire à partir de plusieurs cas d’utilisation vers un seul cas d’utilisation réutilisable. Cela favorise la réutilisation et simplifie les cas d’utilisation de base en évitant la duplication de fonctionnalités.

Caractéristiques

  • Obligatoire: Le cas d’utilisation inclus est toujours exécuté lorsque le cas d’utilisation de base est exécuté.

  • Réutilisable: Le cas d’utilisation inclus est une fonction autonome et cohérente qui peut être utilisée par plusieurs cas d’utilisation de base.

  • Simplifie les diagrammes: En extrayant les étapes communes, le cas d’utilisation de base reste concis et centré.

  • Direction: La flèche pointe du cas d’utilisation de base vers le cas d’utilisation inclus, indiquant que le cas d’utilisation de base dépend de celui-ci.

Notation

  • Une flèche pointillée étiquetée <<inclure>> relie le cas d’utilisation de base au cas d’utilisation inclus.

Exemple 1 : Système de vente en ligne

Considérez un système de vente en ligne où un client peut Passer une commande ou Annuler une commande. Les deux cas d’utilisation exigent que le client Se connecter au système.

  • Cas d’utilisation de base: Passer une commande, Annuler la commande

  • Cas d’utilisation inclus: Se connecter

  • Explication: La connexion est une étape obligatoire pour placer et annuler une commande. Au lieu de dupliquer la fonctionnalité de connexion dans les deux cas d’utilisation, elle est extraite dans un cas d’utilisation distinctSe connecter cas d’utilisation, qui est inclus par les deux.

Représentation du diagramme:

[Passer commande] ----<<inclure>>----> [Se connecter]
[Annuler la commande] ----<<inclure>>----> [Se connecter]

Exemple 2 : Système de gestion de bibliothèque

Dans un système de bibliothèque, un utilisateur peutEmprunter un livre ou Rendre un livre. Les deux processus nécessitentVérifier l’utilisateur.

  • Cas d’utilisation de base: Emprunter un livre, Rendre un livre

  • Cas d’utilisation inclus: Vérifier l’utilisateur

  • Explication: La vérification de l’identité de l’utilisateur (par exemple, vérifier sa carte de bibliothèque) est une étape obligatoire à la fois pour emprunter et rendre un livre. LeVérifier l’utilisateur le cas d’utilisation est inclus pour éviter la redondance.

Représentation du diagramme:

[Emprunter un livre] ----<<inclure>>----> [Vérifier l'utilisateur]
[Retourner un livre] ----<<inclure>>----> [Vérifier l'utilisateur]

Quand utiliser

  • Lorsque plusieurs cas d’utilisation partagent une étape commune et obligatoire.

  • Lorsque vous souhaitez simplifier les descriptions des cas d’utilisation en extrayant des fonctionnalités réutilisables.

  • Lorsque le cas d’utilisation inclus est significatif indépendamment (par exemple, Se connecter ou Vérifier l’utilisateur peut être compris comme des fonctions autonomes).

Relation d’extension (<<étendre>>)

Objectif

La ExtensionLa relation d’extension est utilisée pour modéliser un comportement facultatif ou conditionnel qui n’est exécuté que dans des circonstances spécifiques. Elle permet au cas d’utilisation de base de rester centré sur sa fonctionnalité principale tout en ajoutant de manière modulaire un comportement facultatif.

Caractéristiques

  • Facultatif/Conditionnel: Le cas d’utilisation d’extension est exécuté uniquement si certaines conditions sont remplies.

  • Dépendant: Le cas d’utilisation d’extension n’a pas de sens en soi et dépend du cas d’utilisation de base.

  • Points d’extension: Le cas d’utilisation de base peut définir des points spécifiques où le comportement d’extension peut être inséré.

  • Direction: La flèche pointe du cas d’utilisation d’extension vers le cas d’utilisation de base, indiquant que le cas d’utilisation d’extension ajoute un comportement au cas de base.

Notation

  • Une flèche pointillée étiquetée <<extend>> relie le cas d’utilisation étendu au cas d’utilisation de base, souvent avec une note précisant la condition ou le point d’extension.

Exemple 1 : Système de distributeur automatique

Dans un système de distributeur automatique, le cas d’utilisation de base estRetirer de l’argent. Un comportement facultatif,Imprimer un reçu, peut se produire si l’utilisateur demande un reçu.

  • Cas d’utilisation de base: Retirer de l’argent

  • Cas d’utilisation étendu: Imprimer un reçu

  • Condition: L’utilisateur choisit d’imprimer un reçu après avoir retiré de l’argent.

  • Explication: Imprimer un reçu n’est pas obligatoire et ne se produit que si l’utilisateur le demande expressément. Le Imprimer un reçu cas d’utilisation étend Retirer de l’argent au point d’extension « L’utilisateur demande un reçu ».

Représentation du diagramme:

[Imprimer un reçu] ----<<extend>>----> [Retirer de l'argent]rn(Remarque : Condition = L'utilisateur demande un reçu)

Exemple 2 : Plateforme de cours en ligne

Dans une plateforme de cours en ligne, un utilisateur peutPasser un quiz. Un comportement facultatif,Demander une piste, se produit si l’utilisateur éprouve des difficultés avec une question.

  • Cas d’utilisation de base: Passer le quiz

  • Cas d’utilisation d’extension: Demander une piste

  • Condition: L’utilisateur demande une piste pendant le quiz.

  • Explication: Demander une piste est facultatif et dépend du besoin de l’utilisateur. Le Demander une piste cas d’utilisation s’étend à Passer le quiz au point d’extension « L’utilisateur a besoin d’aide ».

Représentation du diagramme:

[Demander une piste] ----<<étendre>>----> [Passer le quiz]
(Remarque : Condition = L'utilisateur a besoin d'aide)

Quand l’utiliser

  • Lorsque le comportement est facultatif ou dépend de conditions spécifiques.

  • Lorsque vous souhaitez maintenir le cas d’utilisation de base centré sur sa fonctionnalité principale.

  • Lorsque le cas d’utilisation d’extension n’a pas de sens sans le cas d’utilisation de base (par exemple, Imprimer le reçu n’a pas de sens sans Retirer de l’argent).

Différences clés entre inclure et étendre

Le tableau ci-dessous résume les différences entre Inclure et Étendre relations pour guider leur utilisation :

Critères

Inclure (<<inclure>>)

Étendre (<<étendre>>)

Le comportement est-il obligatoire ?

Oui, exécuté toujours comme partie intégrante du cas d’utilisation de base

Non, exécuté uniquement sous des conditions spécifiques

Le comportement peut-il fonctionner indépendamment ?

Oui, c’est une fonction cohérente et réutilisable

Non, cela dépend du cas d’utilisation de base

Apparaît-il dans plusieurs cas d’utilisation ?

Oui, partagé entre plusieurs cas d’utilisation

Généralement spécifique à un seul cas d’utilisation

Objectif

Encourager la réutilisation et simplifier le cas d’utilisation de base

Ajouter de manière modulaire un comportement facultatif ou exceptionnel

Direction de la flèche

Base → Cas d’utilisation inclus

Étendant → Cas d’utilisation de base

Exemple pratique : Système de gestion de restaurant

Appliquons les deux relations dans un système de gestion de restaurant pour illustrer leur utilisation dans un scénario du monde réel.

Scénario

Un système de restaurant permet aux clients de Commander de la nourriture et Réserver une table. Le système gère également des comportements supplémentaires tels que Payer la facture et Demander à emporter.

Cas d’utilisation

  • Commander de la nourriture: Le client commande de la nourriture depuis le menu.

  • Réserver une table: Le client réserve une table pour manger.

  • Authentifier le client: Vérifie l’identité du client (par exemple, via un compte de fidélité).

  • Payer la facture: Le client paie sa commande (obligatoire pour Commander de la nourriture).

  • Demander à emporter: Une demande facultative de conditionner la commande pour emporter.

Relations

  • Inclure: Les deux Commander de la nourriture et Réserver une table exigent Authentifier le client pour vérifier l’identité du client. Commander de la nourriture inclut également Payer la facture car le paiement est obligatoire après la commande.

  • Étendre: Commander de la nourriture peut être étendu par Demander à emporter si le client choisit de prendre son repas à emporter.

Représentation du diagramme

[Commander de la nourriture] ----<<inclure>>----> [Authentifier le client]
[Commander de la nourriture] ----<<inclure>>----> [Payer la facture]
[Réserver une table] ----<<inclure>>----> [Authentifier le client]
[Demander à emporter] ----<<étendre>>----> [Commander de la nourriture]
(Remarque : Condition = Le client demande à emporter)

Explication

  • Authentifier le client est inclus dans les deux Commander de la nourriture et Réserver une table car il s’agit d’une étape obligatoire pour accéder au système.

  • Payer la facture est inclus dans Commander de la nourriture car le paiement est requis pour finaliser la commande.

  • Demander à emporter étend Commander de la nourriture car il s’agit d’un comportement facultatif qui n’a lieu que si le client demande à emporter.

Meilleures pratiques pour utiliser inclure et étendre

  1. Utilisez inclure avec parcimonie: Extrayez uniquement le comportement dans un cas d’utilisation inclus s’il est partagé par plusieurs cas d’utilisation ou s’il simplifie significativement le cas d’utilisation de base. L’utilisation excessive d’inclusions peut rendre les diagrammes encombrés.

  2. Définissez des points d’extension clairs pour étendre: Précisez les conditions ou les points dans le cas d’utilisation de base où le comportement étendu s’applique afin d’éviter toute ambiguïté.

  3. Gardez les cas d’utilisation centrés: Assurez-vous que le cas d’utilisation de base reste simple et centré sur son objectif principal, en utilisantInclure pour les étapes obligatoires etÉtendre pour les étapes facultatives.

  4. Validez la réutilisabilité pour Inclure: Le cas d’utilisation inclus doit être pertinent et réutilisable dans différents contextes.

  5. Évitez de compliquer les diagrammes: UtilisezInclure etÉtendre uniquement lorsqu’elles apportent de la clarté. Les relations complexes peuvent troubler les parties prenantes.

Péchés courants et comment y remédier

  1. Confondre Inclure et Étendre:

    • Piège: UtiliserInclure pour un comportement facultatif ouÉtendre pour un comportement obligatoire.

    • Solution: Vérifiez toujours si le comportement est obligatoire (utilisezInclure) ou conditionnel (utilisezÉtendre).

  2. Utilisation excessive des relations:

    • Piège: Création de trop nombreux Inclure ou Étendre relations, rendant le diagramme difficile à lire.

    • Solution: Utilisez uniquement ces relations lorsque elles réduisent la redondance ou améliorent la clarté.

  3. Conditions d’extension floues:

    • Piège: Ne pas préciser la condition pour une Étendre relation, entraînant de la confusion.

    • Solution: Incluez toujours une note ou une description de la condition ou du point d’extension.

  4. Inclusion de comportements non réutilisables:

    • Piège: Création d’un cas d’utilisation inclus qui n’est utilisé que par un seul cas d’utilisation de base.

    • Solution: Assurez-vous que le cas d’utilisation inclus est réutilisable ou simplifie significativement le cas d’utilisation de base.

Conclusion

Les Inclure et Étendre relations dans les diagrammes de cas d’utilisation UML sont essentielles pour gérer la complexité et assurer la modularité. Le Inclure relation favorise la réutilisation en extrayant le comportement obligatoire et partagé, tandis que le Étendre relation maintient les cas d’utilisation de base centrés en modélisant des comportements optionnels ou conditionnels. En comprenant leurs objectifs, leurs caractéristiques et leurs bonnes pratiques, vous pouvez créer des diagrammes de cas d’utilisation clairs, maintenables et efficaces qui communiquent la fonctionnalité du système aux parties prenantes.

Référence

Follow
Loading

Signing-in 3 seconds...

Signing-up 3 seconds...