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

Question

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

Answer 1

Étendre le site 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 distributeur automatique de billets (DAB). L'option "Évaluer les frais" prolongerait l'option "Retirer de l'argent" et décrirait le processus d'évaluation des frais. conditionnel "point d'extension" qui est instancié lorsque l'utilisateur du DAB n'effectue pas de transactions bancaires auprès de l'institution propriétaire du DAB. Notez que le cas d'utilisation de base "Retirer de l'argent" est autonome, sans l'extension.

Inclure est utilisé pour extraire les fragments de cas d'utilisation qui sont dupliqué dans de multiples cas d'utilisation. Le cas d'utilisation inclus ne peut pas être autonome et le cas d'utilisation original n'est pas complet sans le cas d'utilisation inclus. Ce cas doit être utilisé avec parcimonie et uniquement dans les cas où la duplication est importante et existe à dessein (plutôt que par coïncidence).

Par exemple, le flux d'événements qui se produit au début de chaque cas d'utilisation d'un guichet automatique (lorsque l'utilisateur insère sa carte de guichet, saisit son code PIN et voit apparaître le menu principal) serait un bon candidat pour un include.

Answer 2

Cela peut prêter à controverse, mais l'idée que "les inclusions sont toujours et les extensions sont parfois" est une idée fausse très répandue qui s'est presque imposée comme la signification 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 entre les cas d'utilisation est de réaliser que, comme dans le reste d'UML, la flèche en pointillé entre les cas d'utilisation est une relation de dépendance. J'utiliserai les termes "base", "inclus" et "étendre" pour désigner les rôles des cas d'utilisation.

inclure

Un cas d'utilisation de base dépend du ou des cas d'utilisation inclus ; sans lui/leur, 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. (Contrairement à 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 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 à) le 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

Le cas d'utilisation d'extension est dépendant 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 pleinement fonctionnel en soi (les "include" sont inclus bien sûr) sans la fonctionnalité supplémentaire 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 le comportement facultatif (devrait/pourrait/souhaiterait). C'est là que le terme "facultatif" est pertinent - facultatif de construire/livrer plutôt que facultatif de s'exécuter parfois dans le cadre de la séquence du 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. Celui-ci peut contenir des séquences qui sont toujours ou parfois exécutées après la livraison de la phase 2 (encore une fois, contrairement à une idée reçue).
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 à prendre en compte est que le cas d'utilisation étendu peut "insérer" un 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 très peu probable qu'un cas d'utilisation d'extension soit adapté pour étendre plus d'un cas d'utilisation de base.

Quant à la dépendance, le cas d'utilisation étendu dépend du cas d'utilisation de base et il s'agit là encore d'une dépendance à sens unique, c'est-à-dire que le cas d'utilisation de base n'a pas besoin de 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.

RÉSUMÉ

J'espère avoir montré que l'idée fausse et courante selon laquelle "les inclusions sont toujours, les extensions sont parfois" est soit fausse, soit au mieux simpliste. Cette version a en fait plus de sens si vous considérez toutes les questions sur la directionalité des flèches que l'idée fausse présente - dans le modèle correct, c'est juste une dépendance et cela ne change pas potentiellement si vous remaniez le contenu du cas d'utilisation.

Answer 3

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

Mon cas d'utilisation : Je vais en ville.

comprend -> conduire la voiture

s'étend -> remplir l'essence

"Faire le plein d'essence" peut ne pas être requis à tout moment, mais peut l'être facultativement en fonction de la quantité d'essence restante dans la voiture. "Conduire la voiture" est un prérequis, c'est pourquoi je l'inclus.

Answer 4

Je pense qu'il est important de comprendre l'intention des includes et des extends :

"La relation d'inclusion est destinée à réutilisation de comportement modélisé par un autre cas d'utilisation tandis que la relation d'extension est destinée à en ajoutant les parties des cas d'utilisation existants ainsi que pour le modelage en option services système" (Overgaard et Palmkvist, Use Cases : Patterns and Blueprints. Addison-Wesley, 2004).

Cela me semble être :

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

Prolonge = en ajoutant (pas de réutilisation) de la fonctionnalité et également tout en option fonctionnalité. Les extensions peuvent donc désigner l'une des deux choses suivantes :
1. en ajoutant nouveau caractéristiques/capacités à un cas d'utilisation (facultatif ou non)
2. tout en option les cas d'utilisation (existants ou non).

Résumé :
Inclure = réutilisation de la fonctionnalité
Extends = fonctionnalité nouvelle et/ou optionnelle

Vous trouverez le plus souvent la deuxième utilisation (c'est-à-dire la fonctionnalité optionnelle) des extensions, car si la fonctionnalité n'est pas optionnelle, elle est le plus souvent 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 fait remarquer que l'on voit parfois la première utilisation (c'est-à-dire l'ajout de nouvelles fonctionnalités) des extensions lorsqu'un projet entre dans sa deuxième phase).

Answer 5

Soyons plus clairs. Nous utilisons include chaque fois que l'on veut 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 pas faire d'achats avant de s'être connecté à son compte.

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

Vous comprenez ?

C'est une question de conséquence conditionnée. Je ne peux pas faire ceci si je n'ai pas fait cela auparavant. .

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