Quelle est la différence entre inclure et étendre dans le diagramme de cas d’utilisation?

Quelle est la différence entre include et extend dans un diagramme de cas d’utilisation ?

    L’extension est utilisée lorsqu’un cas d’utilisation ajoute des étapes à un autre cas d’utilisation de première classe.

    Par exemple, imaginons que «Retirer des espèces» est un cas d’utilisation d’un guichet automatique. “Évaluer les frais” prolongerait le retrait d’argent et décrirait le “point d’extension” conditionnel qui est instancié lorsque l’utilisateur du guichet automatique ne dépose pas à l’institution propriétaire de l’ATM. Notez que le cas d’utilisation de base “Retirer de l’argent” est autonome, sans extension.

    Include est utilisé pour extraire des fragments de cas d’utilisation qui sont dupliqués dans plusieurs cas d’utilisation. Le cas d’utilisation inclus ne peut pas être utilisé seul et le cas d’utilisation d’origine n’est pas complet sans celui inclus. Cela devrait être utilisé avec parcimonie et seulement dans les cas où la duplication est significative et existe par conception (plutôt que par coïncidence).

    Par exemple, le stream d’événements qui se produit au début de chaque cas d’utilisation d’ATM (lorsque l’utilisateur met sa carte ATM, saisit son code PIN et affiche le menu principal) serait un bon candidat pour un inclusion.

    Cela peut être controversé, mais les «inclure sont toujours et s’étendent sont parfois» est une idée fausse très courante qui a presque pris le sens de facto. Voici une approche correcte (à mon avis et vérifiée par rapport à Jacobson, Fowler, Larmen et 10 autres références).

    Les relations sont des dépendances

    La clé pour inclure et étendre les relations de cas d’utilisation est de réaliser que, comme dans le rest de UML, la flèche en pointillés entre les cas d’utilisation est une relation de dépendance. J’utiliserai les termes “base”, “included” et “extend” pour faire référence aux rôles de cas d’utilisation.

    comprendre

    Un cas d’utilisation de base dépend du ou des cas d’utilisation inclus; sans elle, le cas d’utilisation de base est incomplet car le ou les cas d’utilisation inclus représentent des sous-séquences de l’interaction qui peuvent se produire toujours OU parfois. (Ceci est contraire à une idée reçue à ce sujet, ce que votre cas d’utilisation suggère toujours dans le scénario principal et se produit parfois dans des stream alternatifs dépend simplement de votre scénario principal; les cas d’utilisation peuvent facilement être restructurés pour représenter un stream différent) comme scénario principal et cela ne devrait pas avoir d’importance).

    Dans la meilleure pratique de la dépendance à sens unique, le cas d’utilisation de base connaît (et fait référence) au cas d’utilisation inclus, mais le cas d’utilisation inclus ne devrait pas «connaître» le cas d’utilisation de base. C’est pourquoi les cas d’utilisation inclus peuvent être: a) des cas d’utilisation de base à part entière et b) partagés par un certain nombre de cas d’utilisation de base.

    étendre

    L’extension du cas d’utilisation dépend du cas d’utilisation de base; cela étend littéralement le comportement décrit par le cas d’utilisation de base. Le cas d’utilisation de base devrait être un cas d’utilisation entièrement fonctionnel (inclus), bien entendu, sans les fonctionnalités supplémentaires du cas d’utilisation.

    L’extension des cas d’utilisation peut être utilisée dans plusieurs situations:

    1. Le cas d’utilisation de base représente la fonctionnalité «must have» d’un projet, tandis que le cas d’utilisation d’extension représente un comportement facultatif (devrait / pourrait / peut vouloir). C’est là que le terme optionnel est pertinent – facultatif, qu’il s’agisse de générer / diffuser plutôt que facultatif, qu’il soit parfois exécuté dans le cadre de la séquence de cas d’utilisation de base.
    2. Dans la phase 1, vous pouvez fournir le cas d’utilisation de base qui répond aux exigences à ce stade, et la phase 2 appenda des fonctionnalités supplémentaires décrites par le cas d’utilisation étendu. Cela peut contenir des séquences qui sont toujours ou parfois effectuées après la livraison de la phase 2 (contrairement aux idées reçues).
    3. Il peut être utilisé pour extraire des sous-séquences du cas d’utilisation de base, en particulier lorsqu’elles représentent un comportement complexe «exceptionnel» avec ses propres stream alternatifs.

    Un aspect important à prendre en compte est que l’extension du cas d’utilisation peut «insérer» un comportement à plusieurs endroits dans le stream du cas d’utilisation de base, et pas seulement à un seul endroit, comme dans un cas d’utilisation inclus. Pour cette raison, il est hautement improbable qu’un cas d’utilisation prolongé convienne à plusieurs cas d’utilisation de base.

    En ce qui concerne la dépendance, l’extension d’utilisation dépend du cas d’utilisation de base et constitue à nouveau une dépendance unidirectionnelle, c’est-à-dire que le cas d’utilisation de base n’a pas besoin de référence au cas d’utilisation étendu de la séquence. Cela ne signifie pas que vous ne pouvez pas démontrer les points d’extension ou append un x-ref au prolongement du cas d’utilisation ailleurs dans le modèle, mais que le cas d’utilisation de base doit pouvoir fonctionner sans extension du cas d’utilisation.

    RÉSUMÉ

    J’espère que j’ai montré que l’idée fausse commune de «inclure sont toujours, étend sont parfois» est erronée ou, au mieux, simpliste. Cette version a plus de sens si vous considérez tous les problèmes de directionnalité des flèches que présente l’idée fausse – dans le bon modèle, c’est juste la dépendance et elle ne change pas potentiellement si vous refactorisez le contenu du cas d’utilisation.

    Je m’en sers souvent pour me souvenir des deux:

    Mon cas d’utilisation: je vais en ville.

    comprend -> conduire la voiture

    étend -> remplir l’essence

    “Remplir l’essence” peut ne pas être nécessaire à tout moment, mais peut éventuellement être requirejs en fonction de la quantité d’essence laissée dans la voiture. “Conduire la voiture” est une condition préalable.

    Les cas d’utilisation sont utilisés pour documenter le comportement, par exemple répondre à cette question.

    répondre au cas d'utilisation des questions

    Un comportement en prolonge un autre s’il vient en complément du comportement, mais pas nécessairement, par exemple en recherchant la réponse.

    Notez également que la recherche de la réponse n’a pas beaucoup de sens si vous n’essayez pas de répondre à la question.

    rechercher la réponse étendre

    Un comportement est inclus dans un autre si cela fait partie du comportement inclus, par exemple se connecter à un échange de stack.

    connexion à l'échange de pile incluent

    Pour clarifier, l’illustration n’est vraie que si vous voulez répondre ici en débordement de stack :).

    Ce sont les définitions techniques de UML 2.5 pages 671-672.

    J’ai souligné ce que je pense être des points importants.

    Étend

    Un Extend est une relation entre une UseCase (l’extension) étendue et une UseCase étendue (la classe extendedCase) qui spécifie comment et quand le comportement défini dans l’extension UseCase peut être inséré dans le comportement défini dans UseCase étendu. L’extension a lieu à un ou plusieurs points d’extension spécifiques définis dans UseCase étendu.

    Extend est destiné à être utilisé lorsque certains comportements supplémentaires, éventuellement conditionnels , doivent être ajoutés au comportement défini dans un ou plusieurs UseCases.

    UseCase étendu est défini indépendamment de l’extension UseCase et est significatif indépendamment de l’extension UseCase . D’autre part, l’ extension de UseCase définit généralement un comportement qui n’est pas nécessairement significatif en soi . À la place, l’extension UseCase définit un ensemble d’incréments de comportement modulaires qui augmentent l’exécution de UseCase étendu dans des conditions spécifiques.

    Comprend

    Include est un DirectedRelationship entre deux UseCases, indiquant que le comportement de UseCase inclus (l’ajout) est inséré dans le comportement de UseCase incluant (le INCCASE ). C’est aussi une sorte de NamedElement pour qu’il puisse avoir un nom dans le contexte de son propre UseCase (le includeCase). L’utilisation de UseCase peut dépendre des modifications apscopes en exécutant UseCase. Le UseCase inclus doit être disponible pour que le comportement de UseCase, y compris, soit complètement décrit.

    La relation Include est destinée à être utilisée lorsqu’il existe des parties communes du comportement de deux UseCases ou plus. Cette partie commune est ensuite extraite vers un UseCase distinct, à inclure par toutes les UseCases de base ayant cette partie en commun . L’utilisation principale de la relation Include étant la réutilisation des parties communes, ce qui rest dans une base UseCase n’est généralement pas complet en soi, mais dépend des parties incluses pour être significatif. Cela se reflète dans la direction de la relation, indiquant que la base UseCase dépend de l’addition mais pas l’inverse.

    Je pense qu’il est important de comprendre l’intention d’inclure et d’étendre:

    “La relation d’inclusion est destinée à réutiliser un comportement modélisé par un autre cas d’utilisation , alors que la relation d’extension est destinée à append des pièces aux cas d’utilisation existants et à modéliser des services système facultatifs ” (Overgaard et Palmkvist, Cas d’utilisation: Patterns et Blueprints. Addison -Wesley, 2004).

    Cela me lit comme:

    Inclure = réutilisation des fonctionnalités (c.-à-d. La fonctionnalité incluse est utilisée ou pourrait être utilisée ailleurs dans le système). Include dénote donc une dépendance à un autre cas d’utilisation.

    Étend = ajout de fonctionnalités (non réutilisables) et de toutes les fonctionnalités facultatives . S’étend donc peut désigner l’une des deux choses suivantes:
    1. append de nouvelles fonctionnalités / capacités à un cas d’utilisation (facultatif ou non)
    2. tout cas d’ utilisation facultatif (existant ou non).

    Résumé:
    Inclure = réutilisation des fonctionnalités
    Étend = fonctionnalité nouvelle et / ou facultative

    Vous trouverez le plus souvent la deuxième utilisation (c.-à-d. Une fonctionnalité facultative) de extend, car si la fonctionnalité n’est pas facultative, la plupart du temps, elle est intégrée au cas d’utilisation, plutôt que d’être une extension. Au moins c’est mon expérience. (Julian C indique que vous voyez parfois le premier usage (c’est-à-dire l’ajout de nouvelles fonctionnalités) d’une extension quand un projet entre dans sa deuxième phase).

    Rendons cela plus clair. Nous utilisons include chaque fois que nous voulons exprimer le fait que l’existence d’un cas dépend de l’existence d’un autre.

    EXEMPLES:

    Un utilisateur ne peut faire ses achats en ligne qu’après s’être connecté à son compte. En d’autres termes, il ne peut faire aucun achat avant de s’être connecté à son compte.

    Un utilisateur ne peut pas télécharger depuis un site avant que le matériel ait été téléchargé. Donc, je ne peux pas télécharger si rien n’a été téléchargé.

    Tu as compris?

    C’est une conséquence conditionnée. Je ne peux pas le faire si je ne l’avais pas fait auparavant .

    Au moins, je pense que c’est la bonne façon d’utiliser Include . J’ai tendance à penser que l’exemple avec ordinateur portable et la garantie ci-dessus sont les plus convaincants!

    Je pense que ce que msdn a expliqué ici est assez facile à comprendre.

    Inclure [5]

    Un cas d’utilisation incluant appelle ou invoque l’inclusion. L’inclusion est utilisée pour montrer comment un cas d’utilisation se divise en étapes plus petites. Le cas d’utilisation inclus se trouve à l’extrémité de la flèche.

    Prolonger [6]

    Pendant ce temps, un cas d’utilisation étendu ajoute des objectives et des étapes au cas d’utilisation étendu. Les extensions ne fonctionnent que sous certaines conditions. Le cas d’utilisation étendu se situe à l’extrémité de la flèche.

    entrer la description de l'image ici

    chaque fois qu’il y a des conditions préalables à un cas d’utilisation, optez pour l’inclusion.

    pour les utilisations ayant une authentification, scénario le plus défavorable, ou facultatif, alors aller de l’avant.

    exemple: pour un cas d’usage de recherche d’admission, de rendez-vous, de réservation de billets, vous devez remplir un formulaire (formulaire d’inscription ou de rétroaction).

    exemple: pour un cas d’utilisation vérifiant la connexion ou la connexion à votre compte, votre authentification est un must. Pensez également aux scénarios les plus défavorables. où étendre vient jouer …

    ne pas utiliser trop et inclure dans les diagrammes.

    GARDEZ LE SIMPLE SILLY !!!

    “Include” est utilisé pour étendre le cas d’utilisation de base et c’est une condition obligatoire, c’est-à-dire que la condition d’utilisation incluse doit s’exécuter avec succès pour compléter l’utilisation de base.

    Par exemple, considérez un cas de service de messagerie, ici “Login” est un cas d’utilisation inclus qui doit être exécuté pour envoyer un email (cas d’utilisation de base)

    Par contre, “Exclure” est un cas d’utilisation facultatif qui étend le cas d’utilisation de base, le cas d’utilisation de base peut s’exécuter avec succès même sans invoquer / appeler le cas d’utilisation étendu.

    Par exemple, considérez “Achat d’un ordinateur portable” comme cas d’utilisation de base et “Garantie supplémentaire” comme extension d’utilisation, ici vous pouvez utiliser le cas d’utilisation de base “Achat d’ordinateur portable” même sans prendre de garantie supplémentaire.

    Méfiez-vous également de la version UML: cela fait longtemps que < < uses >> et < < includes >> ont été remplacés par < < include >>, et < < extend >> par < < extend >> AND generalisation .
    Pour moi, c’est souvent le point trompeur: par exemple, le post et le lien de Stephanie concernent une ancienne version:

    Lorsque vous payez pour un article, vous pouvez choisir de payer à la livraison, de payer avec PayPal ou de payer par carte. Ce sont toutes des alternatives au cas d’utilisation “pay for item”. Je peux choisir l’une de ces options en fonction de mes préférences.

    En fait, il n’y a pas vraiment d’alternative à “payer pour un article”! Dans UML, “payer à la livraison” est une extension, et “payer avec paypal” / “payer par carte” sont des spécialisations.

    Ceci est une excellente ressource avec une bonne explication: Qu’est-ce que l’inclusion at use case? Qu’est-ce que Extend at use case?

    L’extension du cas d’utilisation définit généralement un comportement facultatif. Il est indépendant du cas d’utilisation étendu

    Inclure utilisé pour extraire des parties communes des comportements de deux ou plusieurs cas d’utilisation

    Les extensions sont utilisées lorsque vous comprenez que votre cas d’utilisation est trop complexe. Donc, vous extrayez les étapes complexes dans leurs propres cas d’utilisation “d’extension”.

    Include est utilisé lorsque vous voyez un comportement courant dans deux cas d’utilisation. Donc, vous abstenez le comportement commun dans un cas d’utilisation “abstrait” séparé.

    (réf: Jeffrey L. Whitten, Lonnie D. Bentley, Analyse des systèmes et méthodes de conception, McGraw-Hill / Irwin, 2007)

    et dépendent tous deux de la classe de base, mais est facultatif, c’est-à-dire dérivé de la classe de base, mais peut être utilisé ou non par les utilisateurs.

    est incorporé dans la classe de base, c’est-à-dire qu’il est obligatoire d’utiliser dans votre cas d’utilisation, sinon il serait considéré comme incomplet.

    par exemple:

    Dans la construction de machines ATM (selon le sharepoint vue des utilisateurs):

    1: Le retrait, le repository d’argent et la vérification du compte relèvent de car il dépend de l’utilisateur s’il doit retirer ou déposer ou vérifier. Ce sont des choses facultatives que l’utilisateur fait.

    2: “Entrez le code PIN, placez la carte, supprimez la carte”, ce sont les éléments qui font partie de car l’utilisateur doit et doit placer une carte et entrer une épingle valide pour vérification.

    Éléments du diagramme

    • Acteurs: également appelés rôles. Le nom et le stéréotype d’un acteur peuvent être modifiés dans son onglet Propriétés.

    • Héritage: Affiner les relations entre les acteurs. Cette relation peut porter un nom et un stéréotype.

    • Cas d’utilisation: Ceux-ci peuvent avoir des points d’extension.

    • Points d’extension: Ceci définit un emplacement où une extension peut être ajoutée.

    • Associations: entre les rôles et les cas d’utilisation. Il est utile de donner des noms aux associations.

    • Dépendances: entre les cas d’utilisation Les dépendances ont souvent un stéréotype pour mieux définir le rôle de la dépendance. Pour sélectionner un stéréotype, sélectionnez la dépendance dans le diagramme ou le volet de navigation, puis modifiez le stéréotype dans l’onglet Propriétés. Il existe deux types particuliers de dépendances: < > et < > , pour lesquels Poseidon propose ses propres boutons (voir ci-dessous).

    • Etendre la relation: relation unidirectionnelle entre deux cas d’utilisation. Une relation étendue entre le cas d’utilisation B et le cas d’utilisation A signifie que le comportement de B peut être inclus dans A.

    • Inclure la relation: une relation unidirectionnelle entre deux cas d’utilisation. Une telle relation entre les cas d’utilisation A et B signifie que le comportement de B est toujours inclus dans A.

    • Bordure du système: La bordure du système n’est en fait pas implémentée comme élément de modèle dans Poséidon pour UML. Vous pouvez simplement dessiner un rectangle, l’envoyer à l’arrière-plan et l’utiliser comme bordure système en plaçant tous les cas d’utilisation correspondants dans le rectangle.

    Je ne recommande pas l’utilisation de ceci pour se souvenir des deux:

    Mon cas d’utilisation: je vais en ville.

    comprend -> conduire la voiture

    étend -> remplir l’essence

    Je préférerais que vous utilisiez: Mon cas d’utilisation: je vais en ville.

    étend -> conduire la voiture

    comprend -> remplir l’essence

    J’ai appris que l’extension de la relation continue le comportement d’une classe de base. Les fonctionnalités de la classe de base doivent être présentes. La relation d’inclusion, par contre, s’apparente à des fonctions pouvant être appelées. Mai est en gras.

    Cela peut être vu à partir d’ agilemodeling Réutilisation dans les modèles de cas d’utilisation

    La relation d’ inclusion permet à un cas d’utilisation d’inclure les étapes d’un autre cas d’utilisation.

    Par exemple, supposons que vous ayez un compte Amazon et que vous souhaitiez vérifier une commande, il est impossible de vérifier la commande sans vous connecter d’abord à votre compte. Donc, le stream des événements aimerait que …

    entrer la description de l'image ici

    La relation d’ extension est utilisée pour append une étape supplémentaire au stream d’un cas d’utilisation, qui est généralement une étape facultative …

    entrer la description de l'image ici

    Imaginez que nous parlions toujours de votre compte amazon. Supposons que le cas de base est Order et que le cas d’utilisation de l’extension soit Amazon Prime . L’utilisateur peut choisir de commander simplement l’article régulièrement, ou l’utilisateur a la possibilité de sélectionner Amazon Prime, qui garantit que sa commande arrivera plus rapidement à un coût plus élevé.

    Toutefois, notez que l’utilisateur n’a pas à sélectionner Amazon Prime, il ne s’agit que d’une option, ils peuvent choisir d’ignorer ce cas d’utilisation.

    J’aime penser à “inclure” comme prérequirejs / accompagnement nécessaire du cas d’utilisation de base. Cela signifie que le cas d’utilisation de base ne peut pas être considéré comme complet sans le cas d’utilisation qu’il inclut. Je vais donner l’exemple d’un site de commerce électronique qui vend des articles aux clients. Il est impossible de payer pour un article sans avoir au préalable sélectionné cet article et l’avoir mis dans le panier. Cela implique que le cas d’utilisation “Pay for Item” inclut “select item”.

    Il y a différentes utilisations des extensions, mais j’aime bien y voir une alternative qui peut ou ne peut pas être utilisée. Par exemple – toujours sur le site de commerce électronique. Lorsque vous payez pour un article, vous pouvez choisir de payer à la livraison, de payer avec Paypal ou de payer par carte. Ce sont toutes des alternatives au cas d’utilisation “pay for item”. Je peux choisir l’une de ces options en fonction de mes préférences.

    Pour plus de clarté et les règles entourant les cas d’utilisation, lisez mon article ici:

    http://businessanalystlearnings.com/ba-techniques/2013/2/20/use-case-diagram-the-basics

    La différence entre les deux a été expliquée ici. Mais ce qui n’a pas été expliqué, c’est que < > et < > ne devraient tout simplement pas être utilisés.

    Si vous lisez Bittner / Spence, vous savez que les cas d’utilisation concernent la synthèse et non l’parsing. Une réutilisation des cas d’utilisation est un non-sens. Cela montre clairement que vous avez coupé votre domaine à tort. La valeur ajoutée doit être unique en soi. La seule réutilisation de la valeur ajoutée que je connais est la franchise. Donc, si vous êtes dans le secteur du hamburger, c’est bien. Mais partout ailleurs, votre tâche en tant que BA consiste à essayer de trouver un USP. Et cela doit être présenté dans de bons cas d’utilisation.

    Chaque fois que je vois des personnes utiliser l’une de ces relations, c’est quand elles essaient de faire une décomposition fonctionnelle. Et c’est complètement faux.

    Pour faire simple: si vous pouvez répondre à votre patron sans hésitation “j’ai fait …” alors le “…” est votre cas d’utilisation puisque vous avez de l’argent pour le faire. (Cela clarifiera également que “login” n’est pas un cas d’utilisation).

    À cet égard, il est très improbable de trouver des cas d’utilisation autonome inclus ou d’étendre d’autres cas d’utilisation. Finalement, vous pouvez utiliser < > pour montrer l’option de votre système, c’est-à-dire un schéma de licence permettant d’inclure des cas d’utilisation de certaines licences ou de les omettre. Mais sinon, évitez-les.

    Pour simplifier,

    pour include

    1. Lorsque le cas d’utilisation de base est exécuté, le cas d’utilisation inclus est exécuté TOUT .
    2. Le cas d’utilisation de base nécessitait l’achèvement du cas d’utilisation inclus pour pouvoir être complété.

    un exemple typique: entre login et vérification du mot de passe

    (login) — < < inclure >> — > (vérifier le mot de passe)

    pour que le processus de connexion aboutisse, “verify password” doit également être réussi.


    pour extend

    1. Lorsque le cas d’utilisation de base est exécuté, le cas d’utilisation étendu est uniquement exécuté
    2. Le cas d’utilisation étendu ne se produira que lorsque certains critères seront remplis.

    un exemple typique: entre le login et le message d’erreur (seulement parfois arrivé)

    (login) < — < < extend >> — (affiche le message d’erreur)

    “Afficher le message d’erreur” ne se produit parfois que lorsque le processus de connexion a échoué.