13. Relaciones de inclusión: uso correcto de <<include>>
13.1 Introducción
En un diagrama de casos de uso UML, la relación <<include>> se utiliza cuando un caso de uso incorpora obligatoriamente el comportamiento de otro caso de uso. Es una forma de indicar que una parte común del comportamiento se separa para ser reutilizada o para mejorar la claridad del modelo.
La inclusión no representa una opción, ni una excepción, ni una variante ocasional. Si el caso de uso base se ejecuta, el caso de uso incluido también debe ejecutarse como parte necesaria de ese comportamiento.
Usar correctamente <<include>> evita duplicar pasos en varias especificaciones y permite destacar comportamientos comunes, como autenticar usuario, validar datos, calcular total o generar comprobante, siempre que realmente sean obligatorios dentro de los casos que los incluyen.
13.2 Qué significa incluir
Incluir significa que un caso de uso necesita ejecutar otro caso de uso para completarse. El caso de uso incluido forma parte del flujo del caso base. No es algo que pueda ocurrir o no según una condición opcional; es una parte necesaria.
Por ejemplo, si varios casos de uso requieren verificar que el usuario esté autenticado antes de continuar, puede modelarse un caso de uso común llamado Autenticar usuario e incluirlo desde otros casos.
13.3 Representación UML
La relación <<include>> se representa con una línea discontinua y una flecha abierta que apunta desde el caso de uso base hacia el caso de uso incluido. Sobre la línea se coloca el texto <<include>>.
La dirección de la flecha es importante: apunta al comportamiento que se incluye. Si Solicitar turno incluye Validar disponibilidad, la flecha va desde Solicitar turno hacia Validar disponibilidad.
13.4 Inclusión obligatoria en un caso de uso
En el ejemplo, Solicitar turno necesita validar disponibilidad para poder completar la reserva. Esa validación no es opcional: si el sistema no comprueba que el horario está libre, no puede registrar el turno correctamente. Por eso puede modelarse como una relación <<include>> desde Solicitar turno hacia Validar disponibilidad.
13.5 Caso base y caso incluido
En una relación de inclusión hay dos partes:
- Caso base: es el caso de uso principal que necesita incorporar otro comportamiento.
- Caso incluido: es el caso de uso reutilizado o separado que se ejecuta como parte del caso base.
Si el caso base es Solicitar turno y el caso incluido es Validar disponibilidad, entonces Validar disponibilidad se ejecuta dentro del proceso de solicitar el turno.
13.6 Cuándo conviene usar <<include>>
Conviene usar inclusión cuando se cumplen estas condiciones:
- El comportamiento incluido es obligatorio para el caso base.
- El comportamiento se repite en varios casos de uso.
- Separarlo mejora la claridad del modelo.
- El comportamiento incluido tiene sentido como unidad identificable.
- La especificación sería más difícil de mantener si se duplicara en varios lugares.
No alcanza con que dos casos de uso sean parecidos. Debe existir una parte común que realmente se ejecuta como parte de ellos.
13.7 Reutilización de comportamiento común
Uno de los usos más frecuentes de <<include>> es evitar repetir el mismo comportamiento en varios casos de uso. Por ejemplo, en una tienda en línea, Realizar compra, Consultar pedidos y Cancelar pedido podrían incluir Autenticar usuario si todos requieren que el cliente esté identificado.
En ese caso, la autenticación se documenta una vez y se reutiliza desde distintos casos base. Esto reduce duplicación y ayuda a mantener la documentación consistente.
13.8 Ejemplo en sistema de turnos médicos
En un sistema de turnos médicos, podrían aparecer inclusiones como estas:
| Caso base | Caso incluido | Motivo |
|---|---|---|
| Solicitar turno | Validar disponibilidad | No se puede reservar un horario sin comprobar que esté libre. |
| Modificar turno | Validar disponibilidad | El nuevo horario también debe estar disponible. |
| Cancelar turno | Autenticar usuario | El sistema debe confirmar quién solicita la cancelación. |
| Consultar agenda diaria | Autenticar usuario | Solo usuarios autorizados deben acceder a la agenda. |
13.9 No usar <<include>> para opciones
Un error frecuente es usar <<include>> para representar comportamiento opcional. Si algo ocurre solo en ciertas condiciones, probablemente no corresponde usar inclusión.
Por ejemplo, en Solicitar turno, enviar un recordatorio por SMS podría depender de que el paciente haya aceptado recibir mensajes. Si esa acción no ocurre siempre, no debería modelarse como inclusión obligatoria. Podría documentarse como flujo alternativo o evaluarse como una extensión, según el caso.
13.10 No usar <<include>> como secuencia
La relación <<include>> tampoco debe usarse para dibujar todos los pasos del flujo principal. Un caso de uso no se descompone en cada clic, validación o pantalla mediante inclusiones.
Por ejemplo, no conviene crear inclusiones para Ingresar documento, Seleccionar fecha, Presionar confirmar y Mostrar mensaje. Esos elementos suelen ser pasos dentro del flujo textual, no casos de uso incluidos.
13.11 Inclusión y granularidad
Para que un caso incluido sea útil, debe tener una granularidad razonable. Si es demasiado pequeño, ensucia el diagrama. Si es demasiado grande, puede ocultar el propósito del caso base.
Un buen caso incluido representa una unidad de comportamiento común y significativa. Por ejemplo, Autenticar usuario puede ser razonable; Ingresar contraseña normalmente no lo es.
13.12 Inclusión y especificación textual
Cuando un caso de uso incluye otro, la especificación textual del caso base debe indicar en qué punto se ejecuta el caso incluido. No alcanza con dibujar la relación en el diagrama.
Ejemplo dentro del flujo principal de Solicitar turno:
5. Si el horario está disponible, el sistema registra la reserva.
Si la validación puede fallar, esa situación debe documentarse como flujo alternativo o excepción.
13.13 Diferencia con <<extend>>
La diferencia principal es que <<include>> representa comportamiento obligatorio, mientras que <<extend>> representa comportamiento opcional, condicional o agregado en determinados puntos.
Si el caso base siempre necesita ejecutar el otro comportamiento, se analiza una inclusión. Si el comportamiento aparece solo en ciertas condiciones, puede corresponder una extensión o simplemente un flujo alternativo textual.
13.14 Preguntas para decidir si usar <<include>>
Antes de usar inclusión, conviene responder:
- ¿El caso base siempre necesita este comportamiento?
- ¿El comportamiento incluido se repite en varios casos de uso?
- ¿Separarlo mejora la comprensión?
- ¿Tiene sentido como unidad funcional?
- ¿Evita duplicación real en la especificación?
- ¿No estoy usando la inclusión para representar pasos pequeños?
13.15 Errores frecuentes
Al usar <<include>>, suelen aparecer estos errores:
- Usarlo para comportamiento opcional.
- Usarlo para representar todos los pasos de un flujo.
- Dibujar la flecha en sentido incorrecto.
- Crear casos incluidos demasiado pequeños.
- Separar comportamientos que no se reutilizan ni aportan claridad.
- Olvidar explicar la inclusión en la especificación textual.
- Confundir inclusión con asociación entre actor y caso de uso.
13.16 Qué debes recordar de este tema
- <<include>> indica que un caso de uso incorpora obligatoriamente otro comportamiento.
- La flecha apunta desde el caso base hacia el caso incluido.
- La inclusión suele usarse para reutilizar comportamiento común.
- No debe usarse para comportamiento opcional.
- No debe usarse para descomponer cada paso del flujo.
- El caso incluido debe tener sentido como unidad de comportamiento.
- La especificación textual debe indicar dónde se ejecuta el caso incluido.
13.17 Conclusión
La relación <<include>> es útil cuando se necesita mostrar que un caso de uso incorpora siempre otro comportamiento. Bien usada, mejora la claridad y evita duplicación. Mal usada, vuelve el diagrama innecesariamente complejo.
La regla práctica es simple: usar inclusión solo cuando el comportamiento incluido sea obligatorio y aporte claridad real. En el próximo tema estudiaremos las relaciones de extensión y el uso correcto de <<extend>>.