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


377

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


Je ne ferais pas un meilleur travail que Scott Ambler pour expliquer comment ils peuvent être réutilisés dans les modèles de cas d'utilisation et en quoi ils diffèrent. Donc, au lieu de le paraphraser, je suggère de lire Réutiliser dans les modèles de cas d'utilisation: & lt; & lt; extend & gt; & gt ;, & lt; & lt; include & gt; & gt ;, and Inheritance .
Pascal Thivent

7
En effet, cette question est liée à la programmation ...
Pascal Thivent

35
@closers: c'est une question valable.
Henk Holterman,

82
Pour faire court -> inclure = Madatory, étendre = Facultatif
Thein

2
@Megamind 'extend = Optional' n'est pas entièrement vrai ... Regardez cet exemple de lien
Shanaka Jayalath

Réponses:


263

É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.


1
Include is used to extract use case fragments that are duplicated in multiple use cases, qu'est-ce qui est extrait dans ces étapes puts in their ATM card, enters their PIN, and is shown the main menu:? Merci
Blaze Tama

2
Je dois être en désaccord avec l'inclusion des étapes de "connexion" étant un bon candidat pour une inclusion . Ces étapes forment un cas d'utilisation qui leur est propre et doivent être liées aux autres cas d'utilisation par des post-conditions -> pré-conditions.
Bruno Brant

22
@Bruno - Personne ne se connecterait à un guichet automatique et s'en irait simplement heureux. Les cas d'utilisation concrets doivent fournir une valeur autonome à l'acteur, sinon ce ne sont que des fonctions dans une décomposition fonctionnelle.
Doug Knesek

@Blaze - Toutes les parties du flux de connexion, y compris ces étapes.
Doug Knesek

1
Comment évaluer les frais peut-il être un UC? Il s'agit d'un flux conditionnel dans un scénario. Ce n'est pas du tout une valeur ajoutée. C'est tout le contraire.
qwerty_so

113

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.


3
serait génial si vous pouviez ajouter des références pour cette revendication
mibollma

1
Désolé, la création d'un diagramme UML de cette manière alors que le logiciel passe par des itérations qui ajoutent de nouvelles fonctionnalités qui ont toujours été censées être requises à l'état final serait simplement déroutante et complexe. Je préfère l'approche de Doug Knesek, beaucoup plus simple à comprendre et à travailler sans créer de confusion ou de complexité inutile.
BigMac66

1
Bien que vous ayez raison de contester les "inclusions sont toujours et les extensions sont parfois" en ce qui concerne les instances de cas d'utilisation, votre choix d'exploiter la sémantique "étendre" pour prendre en charge la livraison incrémentielle peut amener les autres à penser que "étendre" concerne la livraison incrémentielle.
Doug Knesek

81

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.


Mais, "faire le plein d'essence" s'étend en fait "aller en ville", et non l'inverse, non?
Petr Hudeček le

1
Je pense que cela dépend du point de vue Petr. À mon humble avis, «remplir l'essence» peut également prolonger la conduite de la voiture.
Daniel Perník

2
Aller en ville et faire le plein d'essence ressemble à deux choses complètement indépendantes qui pourraient arriver par hasard.
OdraEncoded

1
@OdraEncoded est correct. L'essence de remplissage ne dépend pas d'aller en ville.
nonybrighto

57

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

répondre au cas d'utilisation de la 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.

rechercher la réponse étendre

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

Connectez-vous pour échanger la 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.

...


23

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).


23

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é.


bon exemple!
Pavel Durov

15

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.

entrez la description de l'image ici


Vous devez au moins citer l'essence de votre réponse, pas simplement ajouter un lien vers une réponse. De plus, l'explication à laquelle vous faites référence n'est pas vraiment bonne ou précise non plus.
Geert Bellekens

Bonjour @GeertBellekens, j'ai ajouté quelques détails pour expliquer la différence entre inclure et étendre. À mon humble avis, le diagramme lui-même communique clairement la différence et c'est à cela que sert le diagramme.
Etic

Je suis content que vous ayez ajouté les explications, mais je pense toujours qu'elles ne sont pas très bonnes ou précises. Les gens (même, ou surtout s'ils écrivent pour msdn) devraient cesser d'inventer leurs propres définitions pour quelque chose qui est déjà défini dans une norme.
Geert Bellekens

15

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!


1
À propos de s'étend?
AlphaGoku

8

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 !!!


6

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.


5

"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.


peut-être que le fait de «faire» un paiement servirait de «comprend» pour l'achat d'un ordinateur portable? Je dis cela car il est agréable d'avoir les exemples «ensemble» dans le même scénario. En outre, effectuer un paiement est quelque chose qui serait utilisé dans de nombreux scénarios différents, il semble donc qu'il pourrait être un candidat approprié pour <<include>>.
baxx

Loginn'est pas du tout un cas d'utilisation. C'est une fonction remplie pour remplir une condition préalable.
qwerty_so


4

É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.


4

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.


3

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


Il devrait plutôt se lire "remplir l'essence -> étend" puisque votre UC principal ne s'étend pas "remplir l'essence". Sauf que vous êtes une compagnie pétrolière.
qwerty_so

3

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.


3

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)


1
Extend n'a rien à voir avec un cas d'utilisation qui est tout simplement trop complexe. Cette approche conduira à la construction d'une décomposition fonctionnelle plutôt qu'à un véritable modèle de cas d'utilisation.
Doug Knesek

1
Je pense que les concepts du génie logiciel et, en général, tout ce qui se rapproche des sciences humaines devient beaucoup basé sur l'opinion. J'ai inclus la référence (voir page 248). Ne soyez pas trop dur avec ça mec :)
mrmashal

3

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 ...

entrez la description de l'image ici

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 ...

entrez la description de l'image ici

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.


Quel type de cas d'utilisation devrait Amazon Primeêtre? Il ne contient même pas de verbe.
qwerty_so

0

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


1
Bienvenue dans Stack Overflow! Merci d'avoir posté votre réponse! Veuillez lire attentivement la FAQ sur l' autopromotion. Pas vraiment une mauvaise réponse; mais sachez simplement ce que dit la FAQ sur les publications auto-promotionnelles.
Andrew Barber

Le diagramme UC au bas de votre lien n'est qu'un anti-modèle. Ni compte loginni createcompte ne sont des cas d'utilisation. Les deux sont des fonctions. Par conséquent -1
qwerty_so
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.