¿Cuál es la diferencia entre incluir y extender en el diagrama de casos de uso?

¿Cuál es la diferencia entre includey extenden un diagrama de caso de uso ?

Extender se usa cuando un caso de uso agrega pasos a otro caso de uso de primera clase.

Por ejemplo, imagine que "Retirar efectivo" es un caso de uso de un cajero automático (ATM). "Evaluar tarifa" ampliaría Retirar efectivo y describiría el "punto de extensión" condicional que se crea cuando el usuario del cajero automático no realiza operaciones bancarias en la institución propietaria del cajero automático. Observe que el caso de uso básico "Retirar dinero en efectivo" es independiente, sin la extensión.

Incluir se utiliza para extraer fragmentos de casos de uso que se duplican en múltiples casos de uso. El caso de uso incluido no puede estar solo y el caso de uso original no está completo sin el incluido. Esto debe usarse con moderación y solo en los casos en que la duplicación sea significativa y exista por diseño (en lugar de por coincidencia).

Por ejemplo, el flujo de eventos que ocurre al comienzo de cada caso de uso de cajero automático (cuando el usuario ingresa su tarjeta de cajero automático, ingresa su PIN y se muestra el menú principal) sería un buen candidato para una inclusión.

Esto puede ser polémico, pero "incluye siempre y las extensiones son a veces" es un error muy común que casi se ha convertido en el significado de facto. Aquí hay un enfoque correcto (en mi opinión, y comparado con Jacobson, Fowler, Larmen y otras 10 referencias).

Las relaciones son dependencias

La clave para incluir y extender las relaciones de casos de uso es darse cuenta de que, común con el resto de UML, la flecha punteada entre los casos de uso es una relación de dependencia. Usaré los términos 'base', 'incluido' y 'extendido' para referirme a los roles de casos de uso.

incluir

Un caso de uso base depende de los casos de uso incluidos; sin ellos, el caso de uso base está incompleto ya que los casos de uso incluidos representan subsecuencias de la interacción que puede ocurrir siempre O a veces. (Esto es contrario a un concepto erróneo popular sobre esto, lo que sugiere su caso de uso siempre sucede en el escenario principal y, a veces, sucede en flujos alternativos, simplemente depende de lo que elija como su escenario principal; los casos de uso se pueden reestructurar fácilmente para representar un flujo diferente como escenario principal y esto no debería importar).

En la mejor práctica de dependencia unidireccional, el caso de uso base conoce (y se refiere a) el caso de uso incluido, pero el caso de uso incluido no debe 'saber' sobre el caso de uso base. Es por eso que los casos de uso incluidos pueden ser: a) casos de uso base por derecho propio yb) compartidos por varios casos de uso base.

ampliar

El caso de uso extendido depende del caso de uso base; literalmente extiende el comportamiento descrito por el caso de uso base. El caso de uso base debe ser un caso de uso completamente funcional por derecho propio ('incluye incluidos, por supuesto) sin la funcionalidad adicional del caso de uso extendido.

Los casos de uso extensivos se pueden usar en varias situaciones:

1. El caso de uso base representa la funcionalidad "imprescindible" de un proyecto, mientras que el caso de uso extendido representa un comportamiento opcional (debería / podría / querer). Aquí es donde el término opcional es relevante: opcional si se debe construir / entregar en lugar de opcional si a veces se ejecuta como parte de la secuencia de casos de uso base.
2. En la fase 1, puede entregar el caso de uso base que cumpla los requisitos en ese punto, y la fase 2 agregará la funcionalidad adicional descrita por el caso de uso extendido. Esto puede contener secuencias que siempre o algunas veces se realizan después de la entrega de la fase 2 (de nuevo, contrariamente al concepto erróneo popular).
3. Se puede usar para extraer subsecuencias del caso de uso base, especialmente cuando representan un comportamiento complejo 'excepcional' con sus propios flujos alternativos.

Un aspecto importante a considerar es que el caso de uso extendido puede 'insertar' el comportamiento en varios lugares en el flujo del caso de uso base, no solo en un solo lugar como lo hace un caso de uso incluido. Por esta razón, es muy poco probable que un caso de uso extendido sea adecuado para extender más de un caso de uso base.

En cuanto a la dependencia, el caso de uso extendido depende del caso de uso base y nuevamente es una dependencia unidireccional, es decir, el caso de uso base no necesita ninguna referencia al caso de uso extendido en la secuencia. Eso no significa que no pueda demostrar los puntos de extensión o agregar una referencia x al caso de uso extendido en otra parte de la plantilla, pero el caso de uso base debe poder funcionar sin el caso de uso extendido.

RESUMEN

Espero haber demostrado que la idea errónea común de "incluye siempre, las extensiones son a veces" es incorrecta o, en el mejor de los casos, simplista. Esta versión realmente tiene más sentido si considera todos los problemas sobre la direccionalidad de las flechas que presenta la idea errónea: en el modelo correcto es solo dependencia y no cambia potencialmente si refactoriza el contenido del caso de uso.

A menudo uso esto para recordar los dos:

Mi caso de uso: voy a la ciudad.

incluye -> conducir el coche

se extiende -> llenar la gasolina

"Llenar la gasolina" puede no ser necesario en todo momento, pero opcionalmente puede ser requerido en función de la cantidad de gasolina que queda en el automóvil. "Conducir el automóvil" es un requisito previo, por lo tanto, estoy incluido.

Los casos de uso se utilizan para documentar el comportamiento, por ejemplo, responda esta pregunta.

Un comportamiento extiende a otro si es adicional pero no necesariamente parte del comportamiento, por ejemplo, investiga la respuesta.

También tenga en cuenta que investigar la respuesta no tiene mucho sentido si no está tratando de responder la pregunta.

Un comportamiento se incluye en otro si es parte del comportamiento de inclusión, por ejemplo, iniciar sesión para intercambiar pilas.

Para aclarar, la ilustración solo es cierta si desea responder aquí en el desbordamiento de pila :).

Estas son las definiciones técnicas de UML 2.5 páginas 671-672.

Destaqué lo que creo que son puntos importantes.

Se extiende

Una extensión es una relación de una UseCase extendida (la extensión) a una UseCase extendida (la ExtendedCase) que especifica cómo y cuándo el comportamiento definido en la UseCase extendida se puede insertar en el comportamiento definido en la UseCase extendida. La extensión tiene lugar en uno o más puntos de extensión específicos definidos en UseCase extendido.

Extender está destinado a usarse cuando hay algún comportamiento adicional que debería agregarse, posiblemente condicionalmente , al comportamiento definido en uno o más UseCases.

El caso de uso prolongado se define independientemente del caso de uso que se extiende y es significativo con independencia del caso de uso se extiende . Por otro lado, el UseCase extendido generalmente define un comportamiento que puede no ser necesariamente significativo por sí mismo . En cambio, UseCase extendido define un conjunto de incrementos de comportamiento modular que aumentan la ejecución de UseCase extendido bajo condiciones específicas.

...

Incluye

Incluir es una relación dirigida entre dos UseCases, lo que indica que el comportamiento de la UseCase incluida (la adición) se inserta en el comportamiento de la UseCase incluida (la incluyendoCase). También es un tipo de NamedElement para que pueda tener un nombre en el contexto de su propietario UseCase (el includeCase). UseCase incluido puede depender de los cambios producidos al ejecutar UseCase incluido. UseCase incluido debe estar disponible para que se describa completamente el comportamiento de UseCase incluido.

La relación Incluir está pensada para usarse cuando hay partes comunes del comportamiento de dos o más UseCases. Esta parte común se extrae luego en una UseCase separada, para ser incluida por todas las UseCases básicas que tienen esta parte en común . Como el uso principal de la relación Incluir es para la reutilización de partes comunes, lo que queda en UseCase base generalmente no está completo en sí mismo, sino que depende de que las partes incluidas sean significativas. Esto se refleja en la dirección de la relación, lo que indica que UseCase base depende de la adición, pero no al revés.

...

Creo que es importante entender la intención de incluye y extiende:

"La relación de inclusión está destinada a reutilizar el comportamiento modelado por otro caso de uso , mientras que la relación de extensión está destinada a agregar partes a casos de uso existentes , así como a modelar servicios de sistema opcionales " (Overgaard y Palmkvist, Casos de uso: patrones y planos. Addison -Wesley, 2004).

Esto me dice como:

Incluir = reutilización de la funcionalidad (es decir, la funcionalidad incluida se usa o podría usarse en otra parte del sistema). Incluir, por lo tanto, denota una dependencia en otro caso de uso.

Se extiende = agregando (no reutilizando) la funcionalidad y también cualquier funcionalidad opcional . Extiende, por lo tanto, puede denotar una de dos cosas:
1. Agregar nuevas características / capacidades a un caso de uso (opcional o no)
2. Cualquier caso de uso opcional (existente o no).

Resumen:
Incluir = reutilización de funcionalidad
Extiende = funcionalidad nueva y / u opcional

La mayoría de las veces encontrará el segundo uso (es decir, la funcionalidad opcional) de las extensiones, porque si la funcionalidad no es opcional, la mayoría de las veces está integrada en el caso de uso, en lugar de ser una extensión. Al menos esa ha sido mi experiencia. (Julian C señala que a veces se ve el primer uso (es decir, agregar nuevas características) de extensiones cuando un proyecto entra en su segunda fase).

Simplificar,

para include

1. Cuando se ejecuta el caso de uso base, el caso de uso incluido se ejecuta CADA VEZ .
2. El caso de uso base requería completar el caso de uso incluido para poder completarlo.

un ejemplo típico: entre iniciar sesión y verificar contraseña

(inicio de sesión) --- << incluir >> --- > (verificar contraseña)

para que el proceso de inicio de sesión sea exitoso, "verificar contraseña" también debe ser exitoso.

para extend

1. Cuando se ejecuta el caso de uso base, el caso de uso extendido se ejecuta solo A VECES
2. El caso de uso extendido solo ocurrirá cuando se cumplan ciertos criterios.

Un ejemplo típico: entre el inicio de sesión y el mensaje de error del show (solo sucedió a veces)

(inicio de sesión) < --- << extender >> --- (mostrar mensaje de error)

"mostrar mensaje de error" solo ocurre a veces cuando falla el proceso de inicio de sesión.

Creo que lo que msdn explicó aquí es bastante fácil de entender.

Incluir [5]

Un caso de uso incluido llama o invoca al incluido. La inclusión se utiliza para mostrar cómo un caso de uso se divide en pasos más pequeños. El caso de uso incluido está en el extremo de la punta de flecha.

Extender [6]

Mientras tanto, un caso de uso extendido agrega objetivos y pasos al caso de uso extendido. Las extensiones operan solo bajo ciertas condiciones. El caso de uso extendido está en el extremo de la punta de flecha.

Hagamos esto más claro. Usamos includecada vez que queremos expresar el hecho de que la existencia de un caso depende de la existencia de otro.

EJEMPLOS

Un usuario puede hacer compras en línea solo después de haber iniciado sesión en su cuenta. En otras palabras, no puede hacer compras hasta que haya iniciado sesión en su cuenta.

Un usuario no puede descargar desde un sitio antes de que el material haya sido cargado. Por lo tanto, no puedo descargar si no se ha subido nada.

¿Lo entiendes?

Se trata de consecuencia condicionada. No puedo hacer esto si anteriormente no hice eso .

Al menos, creo que esta es la forma correcta que usamos Include. Tiendo a pensar que el ejemplo con Laptop y la garantía de arriba es el más convincente.

siempre que haya requisitos previos para un caso de uso, vaya a incluir.

para los casos de uso que tienen autenticación, el peor de los casos, o son opcionales, entonces vaya a extender.

ejemplo: para un caso de uso de solicitar admisión, cita, reserva de boletos, DEBE LLENAR un formulario (formulario de registro o comentarios) ... aquí es donde se incluye include ..

ejemplo: para un caso de uso que verifique el inicio de sesión o inicie sesión en su cuenta, su autenticación es imprescindible. También piense en los peores escenarios, como devolver el libro con multa ... NO obtener una reserva ... pagar la factura DESPUÉS DE LA FECHA DE VENCIMIENTO ... esta es donde extender viene a jugar ...

no use en exceso incluir y extender en los diagramas.

¡MANTÉNGALO SIMPLE TONTO!

También tenga cuidado con la versión UML: ha pasado mucho tiempo ahora que << usos >> e << incluye >> han sido reemplazados por << incluir >>, y << se extiende >> por << se extiende >> Y generalización .
Para mí, ese es a menudo el punto engañoso: como ejemplo, la publicación y el enlace de Stephanie trata sobre una versión anterior:

Al pagar un artículo, puede optar por pagar contra reembolso, pagar con PayPal o pagar con tarjeta. Estas son todas las alternativas al caso de uso de "pagar por artículo". Puedo elegir cualquiera de estas opciones según mi preferencia.

De hecho, no existe una alternativa real para "pagar por artículo". En la actualidad, UML, "pagar contra entrega" es una extensión, y "pagar usando paypal" / "pagar con tarjeta" son especializaciones.

"Incluir" se usa para extender el caso de uso base y es una condición obligatoria, es decir, la ejecución del caso de uso incluido debe ejecutarse con éxito para completar el uso base.

por ejemplo, considere un caso de servicio de correo electrónico, aquí "Iniciar sesión" es un caso de uso incluido que debe ejecutarse para enviar un correo electrónico (caso de uso base)

"Excluir", por otro lado, es un caso de uso opcional que extiende el caso de uso base, el caso de uso base puede ejecutarse con éxito incluso sin invocar / llamar al caso de uso extendido.

por ejemplo, considere "Compra de laptop" como caso de uso básico y "Garantía adicional" como caso de uso extendido, aquí puede ejecutar el caso de uso básico "Compra de laptop" incluso sin tomar una garantía adicional.

Este es un gran recurso con una gran explicación: ¿Qué se incluye en el caso de uso? ¿Qué es Extender en caso de uso?

Extender el caso de uso generalmente define un comportamiento opcional. Es independiente del caso de uso extendido

Incluir utilizado para extraer partes comunes de los comportamientos de dos o más casos de uso

Elementos del diagrama

• Actores: también conocidos como Roles. El nombre y el estereotipo de un actor se pueden cambiar en su pestaña Propiedades.

• Herencia: Relaciones de refinamiento entre actores. Esta relación puede llevar un nombre y un estereotipo.

• Casos de uso: pueden tener puntos de extensión.

• Puntos de extensión: Esto define una ubicación donde se puede agregar una extensión.

• Asociaciones: entre roles y casos de uso. Es útil dar a las asociaciones nombres que hablan.

• Dependencias: Entre casos de uso. Las dependencias a menudo tienen un estereotipo para definir mejor el papel de la dependencia. Para seleccionar un estereotipo, seleccione la dependencia del diagrama o del panel de navegación, luego cambie el estereotipo en la pestaña Propiedades. Hay dos tipos especiales de dependencias: <<extend>>y <<include>>, para las cuales Poseidón ofrece botones propios (ver más abajo).

• Relación de extensión: una relación unidireccional entre dos casos de uso. Una relación extendida entre el caso de uso B y el caso de uso A significa que el comportamiento de B puede incluirse en A.

• Incluir relación: una relación unidireccional entre dos casos de uso. Tal relación entre los casos de uso A y B significa que el comportamiento de B siempre se incluye en A.

• Borde del sistema: el borde del sistema en realidad no se implementa como elemento modelo en Poseidon para UML. Simplemente puede dibujar un rectángulo, enviarlo al fondo y usarlo como borde del sistema colocando todos los casos de uso correspondientes dentro del rectángulo.

Ambos <include>y <extend>dependen de la clase base, pero <extend>es opcional, es decir, se deriva de la clase base, pero desde el punto de vista de los usuarios, se puede usar o no.

<include>está incorporado en la clase base, es decir, es obligatorio usarlo <include>en su caso de uso o de lo contrario se consideraría incompleto.

p.ej:

En la construcción de cajeros automáticos (según el punto de vista de los usuarios):

1: Retirada, depósito de efectivo y verificación de la cuenta se ve afectada <extend>porque depende del usuario si desea retirar, depositar o verificar. Estas son cosas opcionales que hace el usuario.

2: "Ingrese el pin, colocando la tarjeta, quitando la tarjeta" estas son las cosas que vienen debajo <include>porque el usuario debe y debe colocar una tarjeta e ingresar un pin válido para la verificación.

No recomiendo el uso de esto para recordar los dos:

Mi caso de uso: voy a la ciudad.

incluye -> conducir el coche

se extiende -> llenar la gasolina

Prefiero que uses: Mi caso de uso: Voy a la ciudad.

se extiende -> conduciendo el coche

incluye -> llenar la gasolina

Me enseñaron que extender la relación continúa el comportamiento de una clase base. Las funcionalidades de la clase base tienen que estar ahí. La relación de inclusión, por otro lado, es similar a las funciones que se pueden llamar. May está en negrita.

Esto se puede ver en la reutilización de modelos ágiles en modelos de casos de uso

La diferencia entre ambos se ha explicado aquí. Pero lo que no se ha explicado es el hecho de que <<include>>, y <<extend>>no debe ser simplemente utiliza en absoluto.

Si lees Bittner / Spence, sabes que los casos de uso tienen que ver con la síntesis, no con el análisis. Una reutilización de casos de uso no tiene sentido. Muestra claramente que ha cortado su dominio incorrectamente. El valor agregado debe ser único per se. La única reutilización del valor agregado que conozco es la franquicia. Entonces, si estás en el negocio de las hamburguesas, está bien. Pero en cualquier otro lugar, su tarea como BA es tratar de encontrar un USP. Y eso debe presentarse en casos de buen uso.

Cada vez que veo personas usando una de esas relaciones es cuando intentan hacer una descomposición funcional. Y eso es completamente incorrecto.

En pocas palabras: si puede responder a su jefe sin dudarlo "He hecho ...", entonces el "..." es su caso de uso, ya que tiene dinero para hacerlo. (Eso también dejará en claro que "iniciar sesión" no es un caso de uso).

A ese respecto, es muy poco probable encontrar casos de uso autónomos que estén incluidos o amplíen otros casos de uso. Eventualmente, puede usar <<extend>>para mostrar la opcionalidad de su sistema, es decir, algún esquema de licencia que permita incluir casos de uso para algunas licencias u omitirlas. Pero de lo contrario, solo evítalos.

Extender se utiliza cuando comprende que su caso de uso es demasiado complejo. Entonces extrae los pasos complejos en sus propios casos de uso de "extensión".

Incluye se utiliza cuando ve un comportamiento común en dos casos de uso. Así que abstraes el comportamiento común en un caso de uso "abstracto" separado.

(ref: Jeffrey L. Whitten, Lonnie D. Bentley, Análisis de sistemas y métodos de diseño, McGraw-Hill / Irwin, 2007)

La relación de inclusión permite que un caso de uso incluya los pasos de otro caso de uso.

Por ejemplo, suponga que tiene una cuenta de Amazon y desea verificar un pedido, bueno, es imposible verificar el pedido sin primero iniciar sesión en su cuenta. Entonces el flujo de eventos quisiera así ...

La relación de extensión se usa para agregar un paso adicional al flujo de un caso de uso, que generalmente es un paso opcional ...

Imagine que todavía estamos hablando de su cuenta de Amazon. Supongamos que el caso base es Order y el caso de uso de la extensión es Amazon Prime . El usuario puede optar por pedir el artículo regularmente o tiene la opción de seleccionar Amazon Prime, lo que garantiza que su pedido llegue más rápido a un costo mayor.

Sin embargo, tenga en cuenta que el usuario no tiene que seleccionar Amazon Prime, esta es solo una opción, puede elegir ignorar este caso de uso.

Me gusta pensar que "incluye" como un prerrequisito / acompañamiento necesario del caso de uso base. Esto significa que el caso de uso base no puede considerarse completo sin el caso de uso que incluye. Daré el ejemplo de un sitio web de comercio electrónico que vende artículos a clientes. No hay forma de que pueda pagar por un artículo sin seleccionarlo primero y ponerlo en el carrito. Esto implica que el caso de uso "Pagar artículo" incluye "seleccionar artículo".

Existen diversos usos de las extensiones, pero me gusta pensar que es una alternativa que se puede usar o no. Por ejemplo, todavía en el sitio de comercio electrónico. Al pagar un artículo, puede optar por pagar contra reembolso, pagar con PayPal o pagar con tarjeta. Estas son todas las alternativas al caso de uso de "pagar por artículo". Puedo elegir cualquiera de estas opciones según mi preferencia.

Para mayor claridad y las reglas que rodean los casos de uso, lea mi artículo aquí:

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