15. Generalización de actores y de casos de uso
15.1 Introducción
En los diagramas de casos de uso UML, la generalización permite representar una relación entre un elemento general y elementos más específicos. Puede aplicarse tanto a actores como a casos de uso.
La idea es similar a una relación de herencia: un actor especializado puede participar en los mismos casos de uso que el actor general, y además puede tener casos propios. De manera parecida, un caso de uso especializado puede conservar el comportamiento general de otro y agregar o ajustar detalles.
La generalización puede simplificar diagramas cuando existen roles o comportamientos con una base común, pero debe usarse con cuidado. Si se aplica sin necesidad, el modelo se vuelve más complejo y menos claro.
15.2 Qué significa generalizar
Generalizar significa identificar algo común entre varios elementos y representarlo en un elemento más amplio. Especializar significa tomar ese elemento general y crear variantes más concretas.
Por ejemplo, Usuario registrado puede ser un actor general, mientras que Paciente y Médico pueden ser actores especializados si comparten ciertos casos de uso, como Iniciar sesión o Actualizar datos personales.
15.3 Representación UML
La generalización se representa con una línea continua y una flecha triangular vacía que apunta hacia el elemento más general. El elemento especializado queda en el origen de la línea y el elemento general queda en la punta de la flecha.
Si Paciente y Médico son tipos de Usuario registrado, las flechas salen desde Paciente y Médico hacia Usuario registrado.
15.4 Generalización en un diagrama de casos de uso
En el ejemplo, Usuario registrado representa un actor general que puede iniciar sesión y actualizar sus datos. Paciente y Médico son actores especializados: heredan esas interacciones comunes y además pueden participar en casos propios, como Solicitar turno o Consultar agenda diaria.
15.5 Generalización de actores
La generalización de actores se usa cuando varios actores comparten casos de uso o características de participación. En lugar de repetir las mismas asociaciones para cada actor, se puede crear un actor más general.
Ejemplo:
- Usuario registrado: puede iniciar sesión, cerrar sesión y actualizar sus datos.
- Paciente: además puede solicitar turnos y cancelar turnos.
- Médico: además puede consultar su agenda diaria.
Paciente y Médico heredan las asociaciones del actor general Usuario registrado.
15.6 Cuándo conviene generalizar actores
Conviene usar generalización de actores cuando:
- Varios actores comparten casos de uso comunes.
- Hay una relación clara de tipo "es un tipo de".
- La generalización reduce repetición en el diagrama.
- El actor general representa un rol real y comprensible.
- Los actores especializados agregan casos de uso propios.
Si no existe una relación clara de especialización, es mejor usar actores separados sin generalización.
15.7 Generalización no es agrupación visual
Un error común es usar generalización solo para ordenar visualmente el diagrama. No debe usarse para agrupar actores que parecen parecidos, sino para representar una relación real de especialización.
Por ejemplo, Paciente y Servicio de mensajería no deberían generalizarse bajo un actor común llamado Participante del sistema, porque no comparten una naturaleza útil ni una relación de herencia funcional clara.
15.8 Generalización de casos de uso
La generalización también puede aplicarse a casos de uso. Un caso de uso especializado conserva el comportamiento general de otro caso de uso y agrega o redefine detalles.
Por ejemplo, Realizar pago podría ser un caso de uso general, mientras que Realizar pago con tarjeta y Realizar pago por transferencia podrían ser casos especializados si comparten un objetivo común pero tienen diferencias específicas.
15.9 Cuándo conviene generalizar casos de uso
La generalización de casos de uso conviene cuando hay variantes de un mismo objetivo general y esas variantes tienen comportamiento común significativo.
Ejemplos posibles:
- Realizar pago como caso general; Realizar pago con tarjeta y Realizar pago por transferencia como especializaciones.
- Registrar usuario como caso general; Registrar paciente y Registrar profesional como especializaciones.
- Consultar agenda como caso general; Consultar agenda diaria y Consultar agenda mensual como especializaciones.
Si las variantes son simples alternativas dentro de un mismo flujo, puede ser más claro documentarlas como flujos alternativos.
15.10 Diferencia con <<include>> y <<extend>>
La generalización no significa lo mismo que inclusión ni extensión. Cada relación comunica una idea distinta.
| Relación | Idea principal | Ejemplo |
|---|---|---|
| Generalización | Un elemento especializado es un tipo de otro más general. | Paciente es un tipo de Usuario registrado. |
| <<include>> | Un caso de uso incorpora obligatoriamente otro comportamiento. | Solicitar turno incluye Validar disponibilidad. |
| <<extend>> | Un caso de uso agrega comportamiento condicional a otro. | Programar recordatorio extiende Solicitar turno. |
15.11 Ejemplo con actores en sistema de turnos
En un sistema de turnos médicos, podría existir un actor general Usuario autenticado. Ese actor participa en casos como Cerrar sesión o Actualizar datos personales.
Luego pueden existir actores especializados:
- Paciente: solicita, consulta y cancela turnos.
- Médico: consulta la agenda diaria.
- Administrador: configura horarios y profesionales.
La generalización evita repetir asociaciones comunes si realmente todos los actores especializados comparten esos casos.
15.12 Ejemplo con casos de uso
Supongamos que el sistema permite registrar distintos tipos de personas. Puede existir un caso general Registrar persona y casos especializados Registrar paciente y Registrar profesional.
El comportamiento común podría incluir cargar datos personales, validar documento y guardar información básica. Los casos especializados podrían agregar datos de cobertura médica o matrícula profesional.
15.13 Preguntas antes de usar generalización
Antes de usar generalización, conviene preguntar:
- ¿Existe una relación clara de tipo "es un tipo de"?
- ¿El elemento especializado hereda asociaciones o comportamiento común?
- ¿La generalización reduce repetición real?
- ¿El modelo será más claro después de agregarla?
- ¿Los usuarios del modelo entenderán la relación?
- ¿No sería más simple mantener elementos separados?
15.14 No abusar de la generalización
La generalización puede ser útil, pero no debe usarse en exceso. Un diagrama con muchas jerarquías puede volverse difícil de leer, especialmente para usuarios no técnicos.
En casos de uso, la claridad suele ser más importante que la elegancia formal del modelo. Si la generalización no ayuda a comprender mejor, probablemente no haga falta.
15.15 Errores frecuentes
Al usar generalización, suelen aparecer estos errores:
- Usarla solo para agrupar visualmente actores.
- Crear actores generales que no representan un rol real.
- Confundir generalización con inclusión o extensión.
- Dibujar la flecha en sentido incorrecto.
- Generalizar casos de uso que no comparten comportamiento significativo.
- Crear jerarquías demasiado profundas para modelos simples.
- Usarla cuando una tabla o una explicación textual sería más clara.
15.16 Qué debes recordar de este tema
- La generalización representa una relación entre un elemento general y uno especializado.
- Puede aplicarse a actores y a casos de uso.
- La flecha triangular vacía apunta hacia el elemento general.
- Un actor especializado hereda asociaciones del actor general.
- Un caso de uso especializado conserva comportamiento común y agrega diferencias.
- No debe usarse solo para ordenar visualmente el diagrama.
- Debe usarse solo cuando mejora la claridad del modelo.
15.17 Conclusión
La generalización permite representar relaciones de especialización en diagramas de casos de uso. Puede simplificar modelos cuando varios actores o casos comparten comportamiento común y tienen diferencias específicas.
Sin embargo, debe usarse con moderación. Un modelo simple y claro suele ser mejor que una jerarquía compleja que pocos entienden. En el próximo tema veremos errores frecuentes en diagramas de casos de uso y cómo evitarlos.