¿Cuál es la diferencia entre incluir
y extender
en un diagrama de casos de uso?
Extender se utiliza cuando un caso de uso añade pasos a otro caso de uso de primera clase.
Por ejemplo, imagínese que "Retirar dinero" es un caso de uso de un cajero automático. "Evaluar la comisión" extendería "Retirar dinero" y describiría el "punto de extensión" condicional que se instanciaría cuando el usuario del cajero automático no realizara operaciones bancarias en la institución propietaria. Obsérvese que el caso de uso básico "Retirar efectivo" se mantiene por sí solo, sin la extensión.
Incluir 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. Se debe utilizar con moderación y sólo en los casos en los que la duplicación es significativa y existe por diseño (y no por coincidencia).
Por ejemplo, el flujo de eventos que se produce al principio de cada caso de uso de cajero automático (cuando el usuario introduce su tarjeta de cajero, su PIN y se le muestra el menú principal) sería un buen candidato para una inclusión.
Esto puede ser polémico, pero el "incluye siempre y extiende a veces" es un concepto erróneo muy común que casi se ha impuesto ahora como el significado de facto. Aquí hay un enfoque correcto (en mi opinión, y comprobado con Jacobson, Fowler, Larmen y otras 10 referencias).
La clave para Incluir y extender las relaciones de los casos de uso es darse cuenta de que, al igual que 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 los casos de uso.
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 pueden ocurrir siempre O a veces. (Esto es contrario a una idea errónea popular sobre esto, lo que su caso de uso sugiere que siempre sucede en el escenario principal y a veces sucede en flujos alternativos simplemente depende de lo que usted elija como escenario principal; los casos de uso pueden ser fácilmente reestructurados para representar un flujo diferente como escenario principal y esto no debería importar).
En la mejor práctica de dependencia de una vía, el caso de uso base conoce (y se refiere a) el caso de uso incluido, pero el caso de uso incluido no debería "conocer" el caso de uso base. Por eso los casos de uso incluidos pueden ser: a) casos de uso base por derecho propio y b) compartidos por varios casos de uso base.
El caso de uso extendido depende del caso de uso base; extiende literalmente el comportamiento descrito por el caso de uso base. El caso de uso base debe ser un caso de uso completamente funcional por sí mismo (por supuesto, se incluyen los "includes") sin la funcionalidad adicional del caso de uso extendido.
Los casos de uso ampliados pueden utilizarse en varias situaciones:
Un aspecto importante a tener en cuenta es que el caso de uso que se extiende puede "insertar" un comportamiento en varios lugares del flujo del caso de uso base, no en un solo lugar como hace un caso de uso incluido. Por esta razón, es muy poco probable que un caso de uso que se extiende sea adecuado para extender más de un caso de uso base.
En cuanto a la dependencia, el caso de uso que se extiende depende del caso de uso base y, de nuevo, es una dependencia unidireccional, es decir, el caso de uso base no necesita ninguna referencia al caso de uso que se extiende en la secuencia. Eso no significa que no se puedan demostrar los puntos de extensión o añadir una referencia x al caso de uso de extensión en otra parte de la plantilla, pero el caso de uso base debe poder funcionar sin el caso de uso de extensión.
Espero haber mostrado que la idea errónea común de "los includes son siempre, los extends son a veces" es errónea o, en el mejor de los casos, simplista. Esta versión en realidad tiene más sentido si consideras todas las cuestiones sobre la direccionalidad de las flechas que presenta el concepto erróneo - en el modelo correcto es sólo dependencia y no cambia potencialmente si refactorizas el contenido del caso de uso.
Siempre que haya requisitos previos para un caso de uso, hay que optar por la inclusión.
Para los casos de uso que tienen autenticación, en el peor de los casos, o son opcionales, entonces vaya para extender...
ejemplo: para un caso de uso de búsqueda de admisión, cita, reserva de entradas DEBE RELLENAR UN FORMULARIO (formulario de registro o de comentarios)....aquí es donde entra include..
ejemplo: para un caso de uso de verificación de inicio de sesión o registro en su cuenta, su autenticación es una necesidad. también pensar en el peor de los casos. como la devolución de libro con multa... no conseguir una reserva... pagar la factura después de la fecha de vencimiento... aquí es donde extender viene a jugar...
no sobrecargue el uso de include y extend en los diagramas.
¡NO TE PASES DE LA RAYA, TONTO!