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

Quelle est la différence entre includeet extenddans un diagramme de cas d'utilisation ?

Étendre est utilisé lorsqu'un cas d'utilisation ajoute des étapes à un autre cas d'utilisation de première classe.

Par exemple, imaginez que «retirer de l'argent» est un cas d'utilisation d'un guichet automatique (ATM). «Évaluer les frais» étendrait le retrait d'espèces et décrirait le «point d'extension» conditionnel qui est instancié lorsque l'utilisateur du GAB ne fait pas de banque dans l'institution propriétaire du GAB. Notez que le cas d'utilisation de base "Retirer de l'argent" est autonome, sans l'extension.

Inclure 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 autonome et le cas d'utilisation d'origine n'est pas complet sans celui inclus. Cela devrait être utilisé avec parcimonie et uniquement dans les cas où la duplication est importante et existe par conception (plutôt que par coïncidence).

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

Cela peut être controversé, mais «les inclus sont toujours et les étend sont parfois» est une idée fausse très courante qui a presque maintenant pris le relais comme sens de facto. Voici une approche correcte (à mon avis, et comparée à 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 avec le reste d'UML, la flèche pointillée entre les cas d'utilisation est une relation de dépendance. J'utiliserai les termes «base», «inclus» et «étendant» 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 lui, 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 toujours se produire OU parfois. (Cela est contraire à une idée fausse répandue à ce sujet, ce que votre cas d'utilisation suggère se produit toujours dans le scénario principal et se produit parfois dans des flux alternatifs dépend simplement de ce que vous choisissez comme scénario principal; les cas d'utilisation peuvent facilement être restructurés pour représenter un flux 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 doit 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

Le cas d'utilisation étendu dépend du cas d'utilisation de base; il étend littéralement le comportement décrit par le cas d'utilisation de base. Le cas d'utilisation de base doit être un cas d'utilisation entièrement fonctionnel à part entière («inclus» bien sûr) sans les fonctionnalités supplémentaires du cas d'utilisation étendu.

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

1. Le cas d'utilisation de base représente la fonctionnalité «indispensable» d'un projet tandis que le cas d'utilisation étendu représente un comportement facultatif (devrait / pourrait / vouloir). C'est là que le terme facultatif est pertinent - facultatif s'il faut construire / livrer plutôt que facultatif s'il s'exécute parfois 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 ajoutera des fonctionnalités supplémentaires décrites par le cas d'utilisation étendu. Cela peut contenir des séquences qui sont toujours ou parfois exécutées après la livraison de la phase 2 (là encore contrairement à une idée fausse répandue).
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 flux alternatifs.

Un aspect important à considérer est que le cas d'utilisation étendu peut «insérer» le comportement à plusieurs endroits dans le flux du cas d'utilisation de base, et pas seulement à un seul endroit comme le fait un cas d'utilisation inclus. Pour cette raison, il est hautement improbable qu'un cas d'utilisation étendu convienne pour étendre plus d'un cas d'utilisation de base.

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

SOMMAIRE

J'espère avoir montré que l'idée fausse courante de «comprend toujours, étend parfois» est soit fausse, soit au mieux simpliste. Cette version a en fait plus de sens si vous considérez tous les problèmes de directionnalité des flèches que l'idée fausse présente - dans le modèle correct, c'est juste de la dépendance et ne change pas potentiellement si vous refactorisez le contenu du cas d'utilisation.

J'utilise souvent cela pour me souvenir des deux:

Mon cas d'utilisation: je vais en ville.

comprend -> conduire la voiture

étend -> remplir l'essence

"Faire le plein d'essence" peut ne pas être requis à tout moment, mais peut éventuellement être requis en fonction de la quantité d'essence restant dans la voiture. "Conduire la voiture" est une condition préalable, donc j'inclus.

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

Un comportement en prolonge un autre s'il fait partie du comportement, mais pas nécessairement, par exemple, recherchez la réponse.

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

Un comportement est inclus dans un autre s'il fait partie du comportement inclus, par exemple connexion à l'échange de pile.

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

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

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

S'étend

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

Extend est destiné à être utilisé lorsqu'il existe un comportement supplémentaire qui doit être ajouté, éventuellement de manière conditionnelle , au comportement défini dans un ou plusieurs UseCases.

La UseCase étendue est définie indépendamment de la UseCase étendue et est significative indépendamment de la UseCase étendue . D'un autre côté, l' extension UseCase définit généralement un comportement qui n'est pas nécessairement significatif en soi . Au lieu de cela, 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 une relation DirectedRelationship entre deux UseCases, indiquant que le comportement de l' UseCase inclus (l'ajout) est inséré dans le comportement de l'UsageCase inclus (l' includeCase ). C'est aussi une sorte de NamedElement afin qu'il puisse avoir un nom dans le contexte de son propre UseCase (le includingCase). Le UseCase inclus peut dépendre des modifications produites par l'exécution du UseCase inclus. Le UseCase inclus doit être disponible pour que le comportement du UseCase inclus soit complètement décrit.

La relation Inclure est destinée à être utilisée lorsqu'il existe des parties communes du comportement de deux ou plusieurs UseCases. Cette partie commune est ensuite extraite dans une UseCase distincte, pour être incluse par toutes les UseCases de base ayant cette partie en commun . Étant donné que l'utilisation principale de la relation Inclure est la réutilisation de parties communes, ce qui reste dans une UseCase de base n'est généralement pas complet en soi mais dépend des parties incluses pour être significatif. Cela se reflète dans le sens 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 le comportement modélisé par un autre cas d'utilisation , tandis que la relation d'extension est destinée à ajouter des parties aux cas d'utilisation existants ainsi qu'à la modélisation des services système facultatifs » (Overgaard et Palmkvist, Use Cases: Patterns and Blueprints. Addison -Wesley, 2004).

Cela se lit comme suit:

Inclure = réutilisation de la fonctionnalité (c'est-à-dire que la fonctionnalité incluse est utilisée ou pourrait être utilisée ailleurs dans le système). Inclure indique donc une dépendance à un autre cas d'utilisation.

Étend = ajouter (pas réutiliser) la fonctionnalité et également toute fonctionnalité facultative . Les extensions peuvent donc désigner l'une des deux choses suivantes:
1. ajouter 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és nouvelles et / ou optionnelles

Vous trouverez le plus souvent la 2e utilisation (c'est-à-dire la 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 lui-même, plutôt que d'être une extension. C'est du moins mon expérience. (Julian C souligne que vous voyez parfois la 1ère utilisation (c'est-à-dire l'ajout de nouvelles fonctionnalités) des extensions lorsqu'un projet entre dans sa 2ème phase).

Pour simplifier,

pour include

1. Lorsque le cas d'utilisation de base est exécuté, le cas d'utilisation inclus est exécuté à CHAQUE FOIS .
2. Le cas d'utilisation de base nécessitait l'achèvement du cas d'utilisation inclus pour être terminé.

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

(connexion) --- << inclure >> --- > (vérifier le mot de passe)

pour que le processus de connexion réussisse, "vérifier le mot de passe" doit également réussir.

pour extend

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

un exemple typique: entre la connexion et afficher le message d'erreur (ne s'est produit que parfois)

(connexion) < --- << étendre >> --- (afficher un message d'erreur)

"afficher le message d'erreur" ne se produit parfois que lorsque le processus de connexion a échoué.

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

Inclure [5]

Un cas d'utilisation inclus appelle ou invoque celui inclus. 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 pointe de flèche.

Étendre [6]

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

Rendons cela plus clair. Nous utilisons includechaque 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 des achats en ligne qu'après s'être connecté à son compte. En d'autres termes, il ne peut faire aucun achat tant qu'il n'est pas connecté à son compte.

Un utilisateur ne peut pas télécharger à partir d'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?

Il s'agit d'une conséquence conditionnée. Je ne peux pas faire ça si auparavant je ne faisais pas ça .

Au moins, je pense que c'est la bonne façon que nous utilisons Include. J'ai tendance à penser que l'exemple avec ordinateur portable et garantie ci-dessus est le plus convaincant!

chaque fois qu'il existe des conditions préalables à un cas d'utilisation, optez pour include.

pour les cas d'utilisation ayant une authentification, le pire des cas, ou sont facultatifs alors optez pour extend ..

exemple: pour un cas d'utilisation de recherche d'admission, de rendez-vous, de réservation de billet VOUS DEVEZ REMPLIR UN FORMULAIRE (formulaire d'inscription ou de feedback) .... c'est là qu'inclut vient ..

exemple: pour un cas d'utilisation vérifiant la connexion ou la connexion à votre compte, votre authentification est un must.pensez également aux pires scénarios. où étendre vient jouer ...

ne pas abuser inclure et étendre dans les diagrammes.

GARDEZ-LE SIMPLE SILLY !!!

Attention aussi à la version UML: cela fait longtemps que << uses >> et << includes >> ont été remplacés par << include >>, et << extend >> par << extend >> AND generalization .
Pour moi, c'est souvent le point trompeur: à titre d'exemple, le message et le lien de Stéphanie concernent une ancienne version:

Lors du paiement d'un article, vous pouvez choisir de payer à la livraison, de payer via paypal ou de payer par carte. Ce sont toutes des alternatives au cas d'utilisation "payer pour l'article". 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 l'article"! Dans l'UML de nos jours, le "paiement à la livraison" est une extension, et le "paiement via paypal" / "le paiement par carte" sont des spécialisations.

"Inclure" est utilisé pour étendre le cas d'utilisation de base et c'est une condition incontournable, c'est-à-dire que l'exécution du cas d'utilisation inclus doit s'exécuter avec succès pour terminer l'utilisation de la base.

Par exemple, considérons un cas de service de messagerie, ici "Login" est un cas d'utilisation inclus qui doit être exécuté pour envoyer un courrier électronique (cas d'utilisation de base)

"Exclure" d'autre part 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 appeler / appeler le cas d'utilisation étendu.

Par exemple, considérez "Achat d'ordinateur portable" comme cas d'utilisation de base et "Garantie supplémentaire" comme cas d'utilisation d'extension, ici vous pouvez exécuter le cas d'utilisation de base "Achat d'ordinateur portable" même sans prendre de garantie supplémentaire.

C'est une excellente ressource avec une grande explication: qu'est-ce qui est inclus dans le cas d'utilisation? Qu'est-ce que Extend au cas d'utilisation?

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 les parties communes des comportements de deux cas d'utilisation ou plus

É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: Affinement des relations entre 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 spéciaux de dépendances: <<extend>>et <<include>>, pour lesquels Poséidon propose ses propres boutons (voir ci-dessous).

• Étendre la relation: une 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 système: la bordure 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 à l'intérieur du rectangle.

Les deux <include>et <extend>dépendent de la classe de base mais <extend>sont facultatifs, c'est-à-dire qu'ils sont dérivés de la classe de base mais du point de vue des utilisateurs, ils peuvent être utilisés ou non.

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

par exemple:

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

1: Le retrait, le dépôt d'espèces et la vérification du compte sont effectués <extend>car cela dépend de l'utilisateur, qu'il s'agisse de retirer ou de déposer ou de vérifier. Ce sont des choses facultatives que l'utilisateur fait.

2: "Entrez le code PIN, placement de la carte, retrait de la carte" ce sont les choses qui relèvent du <include>fait que l'utilisateur doit et doit placer une carte et entrer un code PIN valide pour vérification.

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ère que vous utilisiez: Mon cas d'utilisation: je vais en ville.

étend -> conduire la voiture

comprend -> remplir l'essence

On m'apprend que la relation étendue continue le comportement d'une classe de base. Les fonctionnalités de la classe de base doivent être présentes. La relation d'inclusion, d'autre part, s'apparente à des fonctions qui peuvent être appelées. Mai est en gras.

Cela peut être vu à partir de la réutilisation agilemodeling dans les modèles de cas d'utilisation

La différence entre les deux a été expliquée ici. Mais ce qui n'a pas été expliqué, c'est le fait que <<include>>et<<extend>> ne devrait tout simplement pas être utilisé du tout.

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

Chaque fois que je vois des gens utiliser l'une de ces relations, c'est lorsqu'ils essaient de faire une décomposition fonctionnelle. Et c'est tout à fait 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 indiquera également clairement que la «connexion» n'est pas du tout un cas d'utilisation.)

À cet égard, il est très improbable de trouver des cas d'utilisation autonomes qui sont inclus ou étendent d'autres cas d'utilisation. Finalement, vous pouvez utiliser <<extend>>pour montrer le caractère facultatif de votre système, c'est-à-dire un schéma de licence qui permet d'inclure des cas d'utilisation pour certaines licences ou de les omettre. Mais sinon, évitez-les.

Extends est utilisé lorsque vous comprenez que votre cas d'utilisation est trop complexe. Vous extrayez donc les étapes complexes dans leurs propres cas d'utilisation "d'extension".

Inclut est utilisé lorsque vous voyez un comportement courant dans deux cas d'utilisation. Vous extrayez donc le comportement commun dans un cas d'utilisation "abstrait" distinct.

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

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, eh bien, il est impossible de vérifier la commande sans d'abord vous connecter à votre compte. Donc, le flux d'événements le voudrait ...

La relation d' extension est utilisée pour ajouter une étape supplémentaire au flux d'un cas d'utilisation, qui est généralement une étape facultative ...

Imaginez que nous parlions toujours de votre compte Amazon. Supposons que le cas de base est Order et le cas d'utilisation de l'extension est Amazon Prime . L'utilisateur peut choisir de simplement commander 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é.

Cependant, notez que l'utilisateur n'a pas à sélectionner Amazon Prime, ce n'est qu'une option, il peut choisir d'ignorer ce cas d'utilisation.

J'aime à penser que "comprend" comme une condition préalable / 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 comprend. Je vais donner l'exemple d'un site Web de commerce électronique qui vend des articles aux clients. Il n'y a aucun moyen de payer un article sans d'abord sélectionner cet article et le mettre dans le panier. Cela implique que le cas d'utilisation "Payer pour l'article" inclut "sélectionner l'article".

Il existe différentes utilisations des extensions, mais j'aime à y penser comme une alternative qui peut ou non être utilisée. Par exemple - toujours sur le site de commerce électronique. Lors du paiement d'un article, vous pouvez choisir de payer à la livraison, de payer via paypal ou de payer par carte. Ce sont toutes des alternatives au cas d'utilisation "payer pour l'article". 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