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 ?
Extend est utilisé lorsqu'un cas d'utilisation ajoute des étapes à un autre cas d'utilisation de première classe.
Par exemple, imaginons que "Retirer de l’argent" est un cas d’utilisation d’un guichet automatique. "Frais d'évaluation" prolongerait le retrait en espèces et décrivait le "point d'extension" conditionnel qui est instancié lorsque l'utilisateur du guichet automatique ne dépose pas de compte auprès de l'institution propriétaire du guichet automatique. . Notez que le cas d'utilisation de base "Retirer de l'argent" est autonome, sans extension.
Include est utilisé pour extraire les 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 doit ê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 insère sa carte, entre son code PIN et le menu principal) serait un bon candidat pour une inclusion.
Cela peut être litigieux, mais le mot "comprend sont toujours et s'étend parfois" est une idée fausse très répandue qui a presque maintenant pris le sens de la signification de facto. Voici une approche correcte (à mon avis, contre 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 le reste du langage UML, la flèche en pointillé entre les cas d'utilisation est une relation de dépendance. J'utiliserai les termes "base", "inclus" et "extension" pour désigner les rôles de cas d'utilisation.
comprendre
Un cas d'utilisation de base dépend du ou des cas d'utilisation inclus; sans eux, le cas d'utilisation de base est incomplet, car les cas d'utilisation inclus représentent des sous-séquences de l'interaction pouvant se produire toujours OR parfois. (Ceci est contraire à une idée fausse répandue à ce sujet, ce que votre cas d'utilisation suggère de se produire 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 dépendance à sens unique, le cas d'utilisation de base connaît le cas d'utilisation inclus (et y fait référence), 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 en tant que tels 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 (les "inclus", bien sûr) sans les fonctionnalités supplémentaires du cas d’utilisation étendu.
Les cas d'utilisation étendus peuvent être utilisés dans plusieurs situations:
- 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/veut). C’est là que le terme facultatif est pertinent - option permettant de créer/livrer plutôt que si elle s’exécute parfois dans le cadre de la séquence de cas d’utilisation de base.
- Dans la phase 1, vous pouvez fournir le cas d'utilisation de base répondant aux exigences de ce point. La phase 2 ajoute 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 (encore une fois contrairement à l'idée fausse répandue).
- Il peut être utilisé pour extraire des sous-séquences du cas d’utilisation de base, en particulier quand 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" un comportement à plusieurs endroits du 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 soit approprié pour étendre plusieurs 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 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 ni ajouter un 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 commune de "comprend sont toujours, étend sont parfois" est soit faux ou au mieux simpliste. Cette version a plus de sens si vous tenez compte de tous les problèmes de directionnalité des flèches que présente l’idée fausse - dans le bon modèle, c’est une dépendance et ne change pas potentiellement si vous modifiez 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
s'étend -> remplir l'essence
"Faire le plein d'essence" peut ne pas être nécessaire à tout moment, mais peut éventuellement être requis en fonction de la quantité d'essence laissée dans la voiture. "Conduire la voiture" est une condition préalable, donc je suis inclus.
Les cas d'utilisation servent à documenter le comportement, par exemple. répond a cette question.
Un comportement en étend un autre s'il en fait partie, mais ne fait pas nécessairement partie du comportement, par ex. rechercher 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 d'inclusion, par ex. Connectez-vous pour empiler l'échange.
Pour clarifier, l'illustration n'est vraie que si vous voulez répondre ici en dépassement de pile:).
Ce sont les définitions techniques de ML 2.5 pages 671-672.
J'ai souligné ce que je pense être des points importants.
Étend
Une extension est une relation entre une extension UseCase (l'extension) et une extension UseCase (the 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 l’extension UseCase. L'extension a lieu à un ou plusieurs points d'extension spécifiques définis dans le UseCase étendu.
Extend est destiné à être utilisé lorsqu'un comportement supplémentaire doit être ajouté, , éventuellement de manière conditionnelle , au comportement défini dans un ou plusieurs cas d'utilisation.
L'Utilitaire étendu est défini indépendamment de l'Utilisateur étendu et est significatif indépendamment du extension de UseCase . D'autre part, le extension UseCase définit généralement le comportement selon lequel n'est pas nécessairement significatif par lui-même . Au lieu de cela, le UseCase à extension définit un ensemble d’incréments de comportement modulaire qui augmentent l’exécution du UseCase à extension dans des conditions spécifiques.
...
Comprend
Include est un DirectedRelationship entre deux UseCases, indiquant que le comportement de UseCase inclus (l'addition) est inséré dans le comportement du UseCase inclus (le inclusCase). C'est aussi une sorte de NamedElement pour qu'il puisse avoir un nom dans le contexte de son propre UseCase (includeCase). Le dossier UseCase inclus peut dépendre des modifications apportées lors de l’exécution du dossier UseCase inclus. Le UseCase inclus doit être disponible pour que le comportement du UseCase, y compris, soit complètement décrit.
La relation d'inclusion 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 un UseCase séparé, à inclure par tous les UseCases de base ayant cette partie en commun . Comme la relation Include est principalement utilisée pour la réutilisation de parties communes, ce qui reste dans une base UseCase n’est généralement pas complet en soi mais dépend de la les pièces incluses doivent avoir un sens. Cela se reflète dans la direction de la relation, ce qui indique que le UseCase de base dépend de l’ajout 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 n autre cas d'utilisation, alors que la relation d'extension est destinée à ajout parties à des cas d'utilisation existants - ainsi que pour la modélisation facultatif services système "(Overgaard et Palmkvist, Cas d’utilisation: Patterns et Blueprints. Addison-Wesley, 2004).
Cela me lit comme suit:
Inclure = réutiliser 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.
Extends = ajout (pas de réutilisation) et aussi tout facultatif fonctionnalité. Les extensions peuvent donc désigner l'une des deux choses suivantes:
1. ajout de nouvea fonctionnalités/capacités à un cas d'utilisation (facultatif ou non)
2. any facultatif cas d'utilisation (existants ou non).
Sommaire:
Inclure = réutilisation des fonctionnalités
Extend = fonctionnalité nouvelle et/ou optionnelle
Vous trouverez le plus souvent la deuxième utilisation (c'est-à-dire la fonctionnalité facultative) de extend, car si la fonctionnalité n'est pas facultative, elle est généralement intégrée au cas d'utilisation lui-même, plutôt que d'être une extension. Au moins ça a été mon expérience. (Julian C fait remarquer que vous voyez parfois la première utilisation (c'est-à-dire l'ajout de nouvelles fonctionnalités) d'extension lorsqu'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 des achats en ligne qu'après s'être connecté à son compte. En d'autres termes, il ne peut faire aucun achat avant d'avoir ouvert une session sur son compte.
Un utilisateur ne peut pas télécharger depuis un site avant que le contenu 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 cela 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 Laptop et la garantie à partir du haut sont les plus convaincants!
Je pense que ce que msdn a expliqué ici est assez facile à comprendre.
Inclure [5]
Un appel à un cas d'utilisation incluant ou invoque celui qui est inclus. L'inclusion est utilisée pour montrer comment un cas d'utilisation se décompose en étapes plus petites. Le cas d'utilisation inclus se trouve à l'extrémité de la 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 flèche.
Pour simplifier,
pour include
- Lorsque le cas d'utilisation de base est exécuté, le cas d'utilisation inclus est exécuté EVERYTIME.
- Le cas d'utilisation de base nécessitait l'achèvement du cas d'utilisation inclus pour pouvoir être terminé.
un exemple typique: entre login et vérification du mot de passe
(login) --- << include >> ---> (vérifier le mot de passe)
pour que le processus de connexion aboutisse, "verify password" doit également réussir.
pour extend
- Lorsque le cas d'utilisation de base est exécuté, le cas d'utilisation étendu est exécuté uniquement PARFOIS
- Le cas d'utilisation étendu ne se produira que lorsque certains critères seront remplis.
un exemple typique: entre login et show message d'erreur (cela n'arrivait que parfois)
(login) < --- << extend >> --- (affiche un message d'erreur)
"Afficher le message d'erreur" ne se produit parfois que lorsque le processus de connexion a échoué.
à 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, 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 rétroaction) .... c'est ici que include vient ..
exemple: pour un cas d’utilisation vérifiant votre identifiant ou votre connexion à votre compte, votre authentification est un must. Pensez également aux pires scénarios. où extend vient jouer ...
ne pas abuser d'inclure et d'étendre dans les diagrammes.
GARDEZ-LE SIMPLE SILLY !!!
"Inclure" est utilisé pour étendre le cas d’utilisation de base. C’est une condition indispensable, c’est-à-dire que l’exécution du cas d’utilisation inclus doit être exécutée avec succès pour terminer l’utilisation de base.
par exemple. Considérons un cas de service de messagerie. Ici, "Connexion" est un cas d'utilisation inclus qui doit être exécuté pour pouvoir envoyer un courrier électronique (cas d'utilisation de base).
"Exclude", par contre, est un cas d'utilisation facultatif qui étend le cas d'utilisation de base, lequel peut être exécuté avec succès même sans invoquer/appeler le cas d'utilisation d'extension.
par exemple. Considérez "Achat pour ordinateur portable" comme cas d'utilisation de base et "Garantie supplémentaire" comme cas d'utilisation complémentaire, dans ce cas, vous pouvez exécuter le cas d'utilisation de base "Achat pour ordinateur portable" même sans bénéficier de la garantie supplémentaire.
Méfiez-vous également de la version UML: cela fait longtemps que << use >> et << includes >> ont été remplacés par << include >>, et << extend >> par << extend> > ET généralisation.
Pour moi, c'est souvent le point le plus trompeur: à titre d'exemple, l'article et le lien de Stéphanie parlent d'une ancienne version:
Lorsque vous payez un article, vous pouvez choisir de payer à la livraison, avec Paypal ou par carte. Ce sont toutes des alternatives au cas d'utilisation "payer pour un article". Je peux choisir l'une ou l'autre de ces options selon mes préférences.
En fait, il n'y a pas vraiment d'alternative à "payer pour un article"! De nos jours, UML, "paiement à la livraison" est une extension, et "payer avec Paypal"/"paiement par carte" sont des spécialisations.
C'est une excellente ressource avec une bonne explication: Qu'est-ce que l'inclusion au cas d'utilisation?Qu'est-ce que l'extension 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
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".
Includes est utilisé lorsque vous constatez un comportement commun dans deux cas d'utilisation. Donc, vous résumez le comportement courant 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)
<include> et <extend> dépendent tous deux de la classe de base mais <extend> est facultatif, c’est-à-dire qu’elle est dérivée de la classe de base, mais qu’elle peut être utilisée ou non. utilisé.
<include> est incorporé à la classe de base, c’est-à-dire qu’il est obligatoire d’utiliser <include> dans votre cas d’utilisation, sinon cela serait considéré comme incomplet.
par exemple:
Dans la construction de guichets automatiques (selon le point de vue de l'utilisateur):
1: Le retrait, le dépôt en espèces et la vérification du compte relèvent de <extend> car cela dépend de l'utilisateur, qu'il s'agisse de retirer, de déposer ou de vérifier. Ce sont des choses facultatives que l'utilisateur fait.
2: "Entrez le code PIN, placez la carte, le retrait de la carte" sont les éléments qui relèvent de <include> car l’utilisateur doit et doit placer une carte et saisir un code PIN valide pour vérification.
La relation include 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 au préalable à votre compte. Donc, le flux d'événements aimerait tellement ...
La relation extend 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 encore de votre compte Amazon. Supposons que le cas de base est Order et que le cas d'utilisation de l'extension est Amazon Prime . L'utilisateur peut choisir de commander le produit régulièrement ou il a la possibilité de sélectionner Amazon Prime afin que sa commande arrive plus rapidement à un coût plus élevé.
Toutefois, notez que l'utilisateur n'est pas obligé de sélectionner Amazon Prime. Il s'agit simplement d'une option. Il peut choisir d'ignorer ce cas d'utilisation.
Je ne recommande pas l'utilisation de cela pour rappeler les deux:
Mon cas d'utilisation: je vais en ville.
comprend -> conduire la voiture
s'étend -> remplir l'essence
Je préférerais que vous utilisiez: Mon cas d'utilisation: je vais en ville.
s'étend -> conduire la voiture
comprend -> remplir l'essence
On m'apprend que prolonger 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, d'autre part, s'apparentent à des fonctions qui peuvent être appelées. May est en gras.
Ceci peut être vu depuis réutilisation d’agilemodeling dans des modèles de cas d’utilisation
Éléments de diagramme
Acteurs: Aussi appelé rôles. Le nom et le stéréotype d'un acteur peuvent être modifiés dans son onglet Propriétés.
Héritage: Raffinement des 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 aux associations des noms qui parlent.
Dépendances: entre 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:
<<extend>>et<<include>>, pour lesquels Poséidon propose ses propres boutons (voir ci-dessous).Étendre la relation: relation unidirectionnelle entre deux cas d'utilisation. Une relation d'extension entre le cas d'utilisation B et le cas d'utilisation A signifie que le comportement de B peut être inclus dans A.
Inclure 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 réalité pas implémentée en tant qu'é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.
La différence entre les deux a été expliquée ici. Mais ce qui n’a pas été expliqué, c’est que <<include>> et <<extend>> ne devraient tout simplement pas être utilisés 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 secteur des hamburgers, Nice. 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 quand ils essaient de faire une décomposition fonctionnelle. Et c'est carrément faux.
Pour le dire simplement: si vous pouvez répondre sans hésiter à votre chef, "j’ai fait ...", le "..." est votre cas d’utilisation puisque vous avez de l’argent pour le faire. (Cela permettra également de préciser que "login" 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 d’en étendre d’autres. Finalement, vous pouvez utiliser <<extend>> pour afficher les options 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.
J'aime penser à "comprend" en tant que 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 inclut. Je vais donner l'exemple d'un site Web de commerce électronique qui vend des articles à des clients. Vous ne pouvez pas payer pour un article sans d'abord le sélectionner et le mettre dans le panier. Cela implique que le cas d'utilisation "Payer pour un article" inclut "sélectionner un article".
Il y a différentes utilisations de extend, mais j'aime bien y penser comme une alternative qui peut ou peut ne pas être utilisée. Par exemple, toujours sur le site de commerce électronique. Lorsque vous payez un article, vous pouvez choisir de payer à la livraison, avec Paypal ou par carte. Ce sont toutes des alternatives au cas d'utilisation "payer pour un article". Je peux choisir l'une ou l'autre de ces options selon mes préférences.
Pour plus de clarté et pour connaître les règles relatives aux cas d'utilisation, lisez mon article ici:
http://businessanalystlearnings.com/ba-techniques/2013/2/20/use-case-diagram-the-basics