uml - tipos - ¿Cuál es la diferencia entre incluir y extender en el diagrama de casos de uso?
relaciones casos de uso (19)
¿Cuál es la diferencia entre include y extend en un diagrama de casos de uso ?
"Include" 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 básico)
"Excluir", por otro lado, es un caso de uso opcional que extiende el caso de uso base, el caso de uso base puede ejecutarse exitosamente incluso sin invocar / llamar al caso de uso extendido.
por ejemplo, considere "Compra de computadora portátil" como caso de uso básico y "Garantía adicional" como caso de uso extendido, aquí puede ejecutar el caso de uso base "Compra de computadora portátil" incluso sin tener garantía adicional.
A menudo utilizo esto para recordar los dos:
Mi caso de uso: voy a la ciudad.
incluye -> conducir el coche
se extiende -> llenar la gasolina
El "llenado de gasolina" puede no ser necesario en todo momento, pero opcionalmente puede requerirse en función de la cantidad de gasolina que queda en el automóvil. "Conducir el coche" es un requisito previo, por lo tanto, estoy incluido.
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á pensada para agregar partes a los casos de uso existentes , así como para modelar los servicios del sistema opcionales " (Overgaard y Palmkvist, Casos de uso: patrones y planos. Addison -Wesley, 2004).
Esto me lee como:
Incluir = reutilización de la funcionalidad (es decir, la funcionalidad incluida se usa o podría usarse en otro lugar del sistema). Incluir por lo tanto denota una dependencia en otro caso de uso.
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 / o opcional
Lo más frecuente es que encuentre el segundo uso (es decir, la funcionalidad opcional) de las extensiones, porque si la funcionalidad no es opcional, la mayoría de las veces se integra 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, la adición de nuevas características) de extensiones cuando un proyecto entra en su segunda fase).
Creo que lo que se explica here es bastante fácil de entender.
Incluir [5]
Un caso de uso incluido llama o invoca el 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.
Elementos del diagrama
Actores: también conocidos como roles. El nombre y el estereotipo de un actor se pueden cambiar en la pestaña Propiedades.
Herencia: refinamiento de las relaciones entre actores. Esta relación puede llevar un nombre y un estereotipo.
Casos de uso: Estos 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 hablen.
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 desde el diagrama o el 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 Poseidon ofrece botones propios (ver más abajo).Relación extendida: 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.
Este es un gran recurso con una gran explicación: ¿Qué es incluir en el caso de uso? ¿Qué es Extender en caso de uso?
La extensión del caso de uso generalmente define el 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.
Esto puede ser polémico, pero los "incluir son siempre y las extensiones son a veces" es un error muy común que casi se ha convertido en el significado de facto. Este es 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, al igual que el resto de UML, la flecha de puntos entre los casos de uso es una relación de dependencia. Usaré los términos ''base'', ''incluído'' y ''extendiendo'' para referirme a los roles de casos de uso.
incluir
Un caso de uso básico depende de los casos de uso incluidos; sin él / ellos, el caso de uso básico está incompleto, ya que los casos de uso incluidos representan subsecuencias de la interacción que pueden suceder siempre O a veces. (Esto es contrario a una idea errónea popular acerca de esto, lo que sugiere su caso de uso siempre ocurre en el escenario principal y, a veces, en flujos alternos, simplemente depende de lo que elija como su escenario principal; los casos de uso pueden reestructurarse fácilmente para representar un flujo diferente como el escenario principal y esto no debería importar).
En la mejor práctica de la dependencia de un solo sentido, el caso de uso base conoce (y hace referencia a) el caso de uso incluido, pero el caso de uso incluido no debe "saber" sobre el caso de uso base. Esta es la razón por la que los casos de uso incluidos pueden ser: a) casos de uso de base por derecho propio yb) compartidos por varios casos de uso de 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 básico debe ser un caso de uso completamente funcional por derecho propio (se incluyen las incluidas, por supuesto) sin la funcionalidad adicional del caso de uso extendido.
Extender los casos de uso se puede utilizar en varias situaciones:
- El caso de uso básico representa la funcionalidad "debe tener" de un proyecto, mientras que el caso de uso extendido representa un comportamiento opcional (debería / podría / quiso). Aquí es donde el término opcional es relevante; opcional si se crea / entrega en lugar de opcional si se ejecuta a veces como parte de la secuencia de casos de uso base.
- En la fase 1, puede entregar el caso de uso básico que cumpla con 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 en ocasiones se realizan después de que se entrega la fase 2 (de nuevo, en contra de la idea errónea popular).
- Puede utilizarse 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 altamente improbable 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 es dependiente 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 un X-ref 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 el error común de "incluir siempre son, las extensiones son a veces" es incorrecto o, en el mejor de los casos, simplista. Esta versión realmente tiene más sentido si tiene en cuenta todos los problemas relacionados con la direccionalidad de las flechas que presenta el concepto erróneo: en el modelo correcto es solo dependencia y no cambia potencialmente si refactoriza el contenido de los 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>> simplemente no deben usarse en absoluto.
Si lees a Bittner / Spence, sabes que los casos de uso son sobre síntesis, no análisis. Una reutilización de casos de uso es una tontería. Esto demuestra claramente que has cortado tu dominio incorrectamente. El valor agregado debe ser único per se. La única reutilización del valor agregado que conozco es la franquicia. Así que si estás en el negocio de hamburguesas, bonito. Pero en cualquier otro lugar, su tarea como BA es tratar de encontrar una USP. Y eso debe ser presentado en buenos casos de uso.
Cada vez que veo que las personas utilizan una de esas relaciones es cuando intentan realizar una descomposición funcional. Y eso está mal.
En pocas palabras, si puede responder a su jefe sin dudar "He hecho ...", entonces "..." es su caso de uso, ya que tiene dinero para hacerlo. (Eso también dejará claro que el "inicio de sesión" no es un caso de uso).
En ese sentido, es muy poco probable encontrar casos de uso autónomos que estén incluidos o que 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 permite incluir casos de uso para algunas licencias u omitirlas. Pero si no, simplemente evítalos.
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, es imposible verificar el pedido sin primero iniciar sesión en su cuenta. Así que el flujo de eventos quisiera ...
La relación de extensión se usa para agregar un paso adicional al flujo de un caso de uso, que suele ser un paso opcional ...
Imagina que todavía estamos hablando de tu cuenta amazon. Supongamos que el caso base es Orden y el caso de uso de extensión es Amazon Prime . El usuario puede elegir simplemente ordenar el artículo con regularidad, o, el usuario tiene la opción de seleccionar Amazon Prime para garantizar que su pedido llegue más rápido a un costo más alto.
Sin embargo, tenga en cuenta que el usuario no tiene que seleccionar Amazon Prime, esta es solo una opción, puede optar por ignorar este caso de uso.
Los casos de uso se utilizan para documentar el comportamiento, por ejemplo, responder a esta pregunta.
Un comportamiento se extiende a otro si es adicional, pero no necesariamente parte del comportamiento, por ejemplo, investigue 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 forma parte del comportamiento incluido, por ejemplo, iniciar sesión para intercambiar pilas.
Para aclarar, la ilustración solo es verdadera si desea responder aquí en el desbordamiento de pila :).
Estas son las definiciones técnicas de UML 2.5 páginas 671-672.
Resalté lo que creo que son puntos importantes.
Se extiende
Una extensión es una relación de una UseCase (la extensión) extendida a una UseCase extendida (la extendedCase) que especifica cómo y cuándo se puede insertar el comportamiento definido en la UseCase extendida 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 el UseCase extendido.
Extend está diseñado para usarse cuando hay algún comportamiento adicional que debe agregarse, posiblemente de manera condicional , al comportamiento definido en uno o más UseCases.
El UseCase extendido se define independientemente del UseCase extendido y es significativo independientemente del UseCase extendido . Por otro lado, el UseCase extendido generalmente define un comportamiento que puede no ser necesariamente significativo por sí mismo . En su lugar, el UseCase extendido define un conjunto de incrementos de comportamiento modular que aumentan la ejecución del UseCase extendido en condiciones específicas.
...
Incluye
Include es una relación DirectedRelationship entre dos UseCases, que indica que el comportamiento de la UseCase incluida (la adición) se inserta en el comportamiento de la UseCase incluida (la CaseCase incluida). También es un tipo de NamedElement para que pueda tener un nombre en el contexto de su propiedad UseCase (la que incluye CaseCase). El UseCase incluido puede depender de los cambios producidos al ejecutar el UseCase incluido. El UseCase incluido debe estar disponible para que el comportamiento del UseCase incluido se describa completamente.
La relación de inclusión está diseñada para usarse cuando hay partes comunes del comportamiento de dos o más UseCases. Esta parte común luego se extrae a un UseCase separado, para ser incluida por todas las bases de uso básicas que tengan 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 una Base de uso de Usos 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 el UseCase base depende de la adición, pero no al revés.
...
Me gusta pensar en "incluye" como un requisito / acompañamiento necesario del caso de uso básico. 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 los clientes. No hay forma de pagar por un artículo sin seleccionar primero ese artículo y ponerlo en el carrito. Esto implica que el caso de uso "Pagar por artículo" incluye "seleccionar artículo".
Existen diferentes usos de las extensiones, pero me gusta considerarlo como una alternativa que puede o no ser utilizada. Por ejemplo, todavía en el sitio de comercio electrónico. Cuando pague por un artículo, puede elegir pagar contra entrega, pagar con paypal o pagar con tarjeta. Estas son todas alternativas al caso de uso "pagar por artículo". Puedo elegir cualquiera de estas opciones dependiendo de 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
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 -> conducir el coche
incluye -> llenar la gasolina
Me enseñan 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 pueden llamarse. Mayo está en negrita.
Esto se puede ver en Agilemodeling Reuse en modelos de casos de uso.
Simplificar,
para include
- Cuando se ejecuta el caso de uso básico, el caso de uso incluido se ejecuta TODAS LAS VECES .
- El caso de uso básico requería la finalización del caso de uso incluido para poder completarse.
Un ejemplo típico: entre iniciar sesión y verificar contraseña.
(iniciar sesión) --- << include >> --- > (verificar contraseña)
Para que el proceso de inicio de sesión sea exitoso, "verificar contraseña" también debe ser exitoso.
para extend
- Cuando se ejecuta el caso de uso base, el caso de uso extendido se ejecuta solo ALGUNAS VECES
- El caso de uso extendido ocurrirá solo cuando se cumplan ciertos criterios.
un ejemplo típico: entre el inicio de sesión y mostrar un mensaje de error (solo sucedió a veces)
(inicio de sesión) < --- << extender >> --- (mostrar mensaje de error)
"Mostrar mensaje de error" solo ocurre a veces cuando el proceso de inicio de sesión falla.
También tenga cuidado con la versión UML: hace mucho tiempo que << usos >> y << incluye >> han sido reemplazados por << incluir >>, y << extiende >> por << extender >> Y generalización .
Para mí, ese es a menudo el punto engañoso: como ejemplo, la publicación y el enlace de Stephanie se trata de una versión antigua:
Cuando pague por un artículo, puede elegir pagar contra entrega, pagar con paypal o pagar con tarjeta. Estas son todas alternativas al caso de uso "pagar por artículo". Puedo elegir cualquiera de estas opciones dependiendo de mi preferencia.
De hecho, no hay realmente una alternativa a "pagar por artículo". En la actualidad, UML, "pagar contra entrega" es una extensión, y "pagar con paypal" / "pagar con tarjeta" son especializaciones.
Tanto <include> como <extend> dependen de la clase base, pero <extend> es opcional, es decir, se deriva de la clase base pero en el punto de vista de los usuarios puede usarse o no puede usarse.
<include> se incorpora a la clase base, es decir, es obligatorio utilizar <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 del usuario):
1: El retiro, el depósito de efectivo y la verificación de la cuenta se incluyen en <extend> porque depende del usuario si desea retirar o depositar o chequear. Estas son cosas opcionales que el usuario hace.
2: "Introduzca el pin, coloque la tarjeta, saque la tarjeta" estas son las cosas que se incluyen en <include> porque el usuario debe, y debe, colocar una tarjeta e ingresar un pin válido para la verificación.
Vamos a hacer esto más claro. Utilizamos include cada 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 de un sitio antes de que se haya cargado el material. Por lo tanto, no puedo descargar si no se ha cargado nada.
¿Lo entiendes?
Se trata de consecuencias condicionadas. No puedo hacer esto si antes no lo hice .
Al menos, creo que esta es la forma correcta en que usamos Include . Tiendo a pensar que el ejemplo con la computadora portátil y la garantía de arriba es lo más convincente.
siempre que haya requisitos previos para un caso de uso, vaya a incluir.
para casos de uso con autenticación, el peor de los casos, o son opcionales, entonces vaya a extender.
Ejemplo: para un caso de uso en el que se solicita admisión, cita, reserva de boletos, DEBE LLENAR UN formulario (registro o formulario de comentarios) ... aquí es donde se incluye incluir ...
Por ejemplo: para un caso de uso que verifique el inicio de sesión o el inicio de sesión en su cuenta, su autenticación es una obligación. También piense en los peores escenarios posibles. Como devolver el libro con multa ... NO obtener una reserva ... pagar la factura DESPUÉS DE LA FECHA, FECHA FECHA ... donde la extensión viene a jugar ...
No use en exceso, incluya y amplíe en los diagramas.
¡MANTÉNGALO SIMPLEMENTE SILLY!
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). La "Tarifa de evaluación" extendería el Retiro en 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 de "Retirar efectivo" se mantiene por sí solo, sin la extensión.
Include se utiliza para extraer fragmentos de casos de uso que están duplicados en varios casos de uso. El caso de uso incluido no puede ser independiente y el caso de uso original no está completo sin el incluido. 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 se produce al comienzo de cada caso de uso de ATM (cuando el usuario coloca su tarjeta de cajero automático, ingresa su PIN y se muestra en el menú principal) sería un buen candidato para una inclusión.
Extiende se utiliza cuando entiende que su caso de uso es demasiado complejo. Así que extraes 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. Entonces, abstrae el comportamiento común en un caso de uso "abstracto" separado.
(ref: Jeffrey L. Whitten, Lonnie D. Bentley, Métodos de análisis y diseño de sistemas, McGraw-Hill / Irwin, 2007)