3. Tipos de Relaciones en Casos de Uso
Las relaciones en los diagramas de casos de uso permiten mostrar cómo los diferentes elementos interactúan entre sí. Estas relaciones ayudan a estructurar y organizar los casos de uso, reduciendo la redundancia y mejorando la claridad del diagrama.
3.1. Asociación (actor–caso de uso)
Section titled “3.1. Asociación (actor–caso de uso)”La asociación es el tipo de relación más básico en los diagramas de casos de uso, conectando actores con los casos de uso con los que interactúan.
Características de la asociación
Section titled “Características de la asociación”- Representa la comunicación entre un actor y un caso de uso
- Se dibuja como una línea sólida entre el actor y el caso de uso
- Indica que el actor participa en el caso de uso
- No tiene dirección específica (aunque a veces se usa una flecha para indicar quién inicia la interacción)
En este ejemplo básico, un Usuario se asocia con el caso de uso Realizar Compra, indicando que el usuario puede iniciar o participar en esta funcionalidad.
Este ejemplo muestra un sistema educativo con múltiples actores (Estudiante, Profesor, Administrador) y sus asociaciones con diferentes casos de uso. Tanto estudiantes como profesores pueden consultar calificaciones, mientras que solo los profesores pueden registrar asistencia y subir material, y solo los administradores pueden gestionar usuarios.
Este ejemplo ilustra un sistema hospitalario donde diferentes actores tienen distintas asociaciones con los casos de uso. Los pacientes pueden solicitar citas, los médicos pueden consultar historiales y prescribir medicamentos, las enfermeras pueden registrar signos vitales y consultar historiales, y el personal administrativo puede facturar servicios y también ayudar a solicitar citas.
Multiplicidad en asociaciones
Section titled “Multiplicidad en asociaciones”Aunque no es común mostrarla en diagramas de casos de uso, la multiplicidad puede indicarse para representar cuántas instancias de un actor pueden participar en un caso de uso y viceversa.
En este ejemplo, la notación “1..*” indica que uno o más usuarios pueden participar en una instancia del caso de uso “Realizar Compra”.
En este sistema de reservas de hotel, un cliente puede realizar múltiples reservas de habitaciones (“1” a ”*”), y un agente puede asistir en múltiples reservas y gestionar múltiples reservas existentes.
En este sistema bancario, un cliente puede abrir entre 1 y 5 cuentas (“1..5”), y puede realizar múltiples transacciones (""). Uno o más cajeros (“1..”) pueden procesar múltiples transacciones.
En este sistema de biblioteca, un lector puede tener entre 0 y 5 préstamos activos y devoluciones pendientes. Entre 1 y 3 bibliotecarios pueden gestionar cada préstamo, y un bibliotecario puede catalogar múltiples materiales.
3.2. Inclusión («include»)
Section titled “3.2. Inclusión («include»)”La relación de inclusión se utiliza cuando un caso de uso incorpora el comportamiento de otro caso de uso como parte de su flujo.
Características de la inclusión
Section titled “Características de la inclusión”- El caso de uso base siempre incluye el comportamiento del caso de uso incluido
- Se representa con una flecha discontinua con la etiqueta «include»
- La flecha apunta hacia el caso de uso incluido
- Permite reutilizar funcionalidades comunes
- El caso de uso incluido no es independiente (no tiene valor por sí solo)
Cuándo usar la relación de inclusión
Section titled “Cuándo usar la relación de inclusión”- Para extraer comportamiento común que se repite en varios casos de uso
- Para simplificar casos de uso complejos dividiéndolos en partes más manejables
- Para separar funcionalidades obligatorias que siempre se ejecutan
En este ejemplo, “Realizar Compra” siempre incluye verificar el inventario, procesar el pago y generar una factura.
Este ejemplo muestra un sistema bancario donde “Realizar Transacción” siempre incluye autenticar al usuario, verificar fondos y registrar la operación. Además, el registro de operación siempre incluye notificar al cliente. Participan varios actores: Cliente, Cajero y un Sistema Externo para notificaciones.
En este sistema de reservas de vuelos, el caso de uso “Reservar Vuelo” siempre incluye buscar disponibilidad, seleccionar asiento, procesar el pago y emitir el boleto. Tanto el Cliente como el Agente de Reservas pueden iniciar este caso de uso.
Este ejemplo muestra un sistema de ventas complejo con múltiples actores (Cliente, Vendedor, Almacenista, Sistema Contable, Sistema de Envíos) y numerosos casos de uso incluidos. El caso de uso principal “Procesar Venta” incluye obligatoriamente varios pasos como autenticar usuario, consultar catálogo, verificar disponibilidad, calcular impuestos, procesar pago, generar factura, actualizar inventario, programar envío y registrar comisión del vendedor. Además, hay relaciones de inclusión anidadas: “Verificar Disponibilidad” incluye “Actualizar Inventario” y “Generar Factura” incluye “Calcular Impuestos”.
3.3. Extensión («extend»)
Section titled “3.3. Extensión («extend»)”La relación de extensión se utiliza cuando un caso de uso añade comportamiento opcional a otro caso de uso bajo ciertas condiciones.
Características de la extensión
Section titled “Características de la extensión”- El caso de uso base puede funcionar independientemente del caso de uso que lo extiende
- Se representa con una flecha discontinua con la etiqueta «extend»
- La flecha va desde el caso de uso que extiende hacia el caso de uso base
- La extensión ocurre solo bajo ciertas condiciones
- Define puntos de extensión donde el comportamiento adicional puede insertarse
Cuándo usar la relación de extensión
Section titled “Cuándo usar la relación de extensión”- Para representar comportamiento opcional que no siempre ocurre
- Para manejar flujos alternativos o excepcionales
- Para añadir funcionalidades a un caso de uso sin modificarlo
- Para representar variantes de un caso de uso base
En este ejemplo, “Solicitar Aprobación” extiende “Crear Cuenta” solo cuando se cumple una condición específica.
Este ejemplo muestra un sistema de compras donde el caso de uso “Realizar Compra” puede ser extendido por tres casos de uso diferentes bajo condiciones específicas: “Aplicar Descuento” cuando el total supera $1000, “Aplicar Cupón” cuando el cliente tiene un cupón disponible, y “Ofrecer Envío Gratuito” cuando la compra supera $2000.
En este sistema bancario, el caso de uso “Realizar Retiro” puede ser extendido por “Verificar Identidad Adicional” cuando el monto es mayor a $10,000, por “Notificar Departamento Seguridad” cuando se detecta actividad sospechosa, y por “Ofrecer Préstamo” cuando el saldo queda bajo después del retiro. Cada extensión involucra diferentes actores.
Este ejemplo muestra un sistema de ventas complejo con múltiples actores (Cliente, Vendedor, Gerente de Ventas, Sistema de Marketing, Sistema de Fidelización, Sistema de Crédito) y numerosas extensiones opcionales para el caso de uso principal “Procesar Venta”. Las extensiones incluyen verificar historial crediticio cuando la compra es a crédito, ofrecer garantía extendida para productos electrónicos, aplicar descuento VIP para clientes especiales, inscribir en programa de puntos si el cliente acepta, ofrecer productos relacionados después de agregar productos al carrito, y generar una encuesta de satisfacción al finalizar la compra.
Además, el diagrama muestra extensiones anidadas: “Solicitar Aprobación de Crédito” extiende “Verificar Historial Crediticio” (que a su vez extiende “Procesar Venta”), “Programar Demostración” extiende “Ofrecer Garantía Extendida”, y “Activar Promoción Especial” extiende “Ofrecer Productos Relacionados”. Esto demuestra cómo las extensiones pueden formar cadenas complejas de comportamiento opcional.
3.4. Generalización (entre actores o entre casos de uso)
Section titled “3.4. Generalización (entre actores o entre casos de uso)”La generalización representa una relación de herencia entre actores o entre casos de uso, similar a la herencia en programación orientada a objetos.
Generalización entre actores
Section titled “Generalización entre actores”- Indica que un actor específico hereda las características de un actor más general
- El actor específico puede interactuar con todos los casos de uso del actor general
- Se representa con una flecha con línea continua y punta triangular vacía
- La flecha apunta hacia el actor general (padre)
En este ejemplo, “Usuario Registrado” es un tipo de “Usuario” y hereda todas sus asociaciones. A su vez, “Administrador” es un tipo de “Usuario Registrado” y hereda todas las asociaciones de ambos actores padre.
Este ejemplo muestra un sistema educativo donde “Estudiante” y “Profesor” son tipos de “Miembro Universitario”. A su vez, “Estudiante Graduado” es un tipo específico de “Estudiante” y “Profesor Titular” es un tipo específico de “Profesor”.
Este ejemplo muestra un sistema hospitalario donde “Médico” y “Enfermero” son tipos de “Personal Sanitario”. Además, “Especialista” es un tipo de “Médico” y “Cirujano” es un tipo específico de “Especialista”.
Generalización entre casos de uso
Section titled “Generalización entre casos de uso”- Indica que un caso de uso específico hereda y especializa el comportamiento de un caso de uso más general
- El caso de uso hijo puede añadir o sobrescribir comportamiento del padre
- Se representa con una flecha con línea continua y punta triangular vacía
- La flecha apunta hacia el caso de uso general (padre)
En este ejemplo, “Pagar con Tarjeta” y “Pagar con Efectivo” son tipos de “Realizar Pago”. A su vez, “Pagar con Crédito” y “Pagar con Débito” son tipos específicos de “Pagar con Tarjeta”.
Este ejemplo muestra un sistema de autenticación donde “Autenticar con Contraseña” y “Autenticar con Biometría” son tipos de “Autenticar Usuario”. A su vez, “Autenticar con Huella” y “Autenticar con Facial” son tipos específicos de “Autenticar con Biometría”.
Este ejemplo muestra un sistema de comunicación donde “Enviar Correo” y “Enviar Mensaje Instantáneo” son tipos de “Enviar Mensaje”. A su vez, “Enviar Correo Personal” y “Enviar Correo Masivo” son tipos específicos de “Enviar Correo”.
Cuándo usar la generalización
Section titled “Cuándo usar la generalización”- Para representar jerarquías de actores con diferentes niveles de privilegios
- Para modelar variantes de un caso de uso que comparten comportamiento común
- Para evitar duplicación al representar comportamientos similares
Comparación entre tipos de relaciones
Section titled “Comparación entre tipos de relaciones”| Característica | Asociación | Inclusión («include») | Extensión («extend») | Generalización |
|---|---|---|---|---|
| Propósito principal | Conectar actores y casos de uso | Reutilizar comportamiento obligatorio | Añadir comportamiento opcional | Representar herencia |
| Representación | Línea sólida | Flecha discontinua | Flecha discontinua | Flecha sólida con triángulo |
| Dirección | Sin dirección específica | Hacia el caso de uso incluido | Hacia el caso de uso base | Hacia el elemento general |
| Obligatoriedad | N/A | Siempre ocurre | Condicional | N/A |
| Elementos conectados | Actor y caso de uso | Caso de uso y caso de uso | Caso de uso y caso de uso | Actor y actor, o caso de uso y caso de uso |
Ejemplo completo con diferentes tipos de relaciones
Section titled “Ejemplo completo con diferentes tipos de relaciones”Buenas prácticas al usar relaciones
Section titled “Buenas prácticas al usar relaciones”Usar «include» para:
- Comportamiento común que se repite en varios casos de uso
- Funcionalidades obligatorias que siempre ocurren
- Simplificar casos de uso complejos
Usar «extend» para:
- Comportamiento opcional que depende de ciertas condiciones
- Flujos alternativos o excepcionales
- Funcionalidades que pueden añadirse sin modificar el caso de uso base
Usar generalización para:
- Jerarquías de actores con diferentes niveles de privilegios
- Variantes de un caso de uso que comparten comportamiento común
- Representar relaciones “es un tipo de”
Evitar:
- Relaciones circulares o redundantes
- Abuso de relaciones que compliquen innecesariamente el diagrama
- Mezclar pasos de un caso de uso con casos de uso independientes