12. Asociación entre actores y casos de uso
12.1 Introducción
En un diagrama de casos de uso UML, la asociación es la línea que conecta un actor con un caso de uso. Su función es indicar que ese actor participa en esa funcionalidad del sistema.
Aunque parece un elemento muy simple, suele generar confusiones. Muchas personas interpretan la línea como una secuencia de pasos, una llamada técnica, una relación de dependencia o una dirección de datos. En un diagrama de casos de uso, la asociación no significa eso.
La asociación solo comunica que existe una interacción entre el actor y el caso de uso. Los detalles de esa interacción se explican en la especificación textual.
12.2 Qué significa una asociación
Una asociación significa que el actor participa en el caso de uso. Esa participación puede consistir en iniciar la funcionalidad, entregar datos, recibir información, validar una operación o colaborar con el sistema durante el proceso.
Por ejemplo, si el actor Paciente está asociado con el caso de uso Solicitar turno, significa que el paciente interactúa con el sistema para solicitar una reserva. La línea no explica cuántos pasos hay, qué pantallas aparecen ni qué datos se ingresan.
12.3 Qué no significa una asociación
Es importante evitar interpretaciones incorrectas. Una asociación no indica orden, prioridad, navegación, herencia, flujo de datos ni dependencia técnica. Tampoco representa que el actor sea dueño del caso de uso.
La línea de asociación solo dice que actor y caso de uso se comunican o participan de una misma interacción.
12.4 Lectura correcta de la asociación
La asociación debe leerse como una relación de participación. En el ejemplo, el Paciente participa en Solicitar turno, el Médico participa en Consultar agenda y el Servicio de mensajería participa en Enviar confirmación. Cada línea conecta un actor externo con una funcionalidad del sistema, sin indicar el orden interno de los pasos.
12.5 Asociación con el actor principal
El actor principal normalmente aparece asociado al caso de uso porque es quien busca lograr el objetivo principal. En Solicitar turno, el Paciente se asocia con ese caso porque utiliza el sistema para obtener una reserva.
Esta asociación ayuda a reconocer para quién existe la funcionalidad. Si un caso de uso no tiene actor principal claro, probablemente necesite revisión.
12.6 Asociación con actores secundarios
Los actores secundarios también pueden asociarse con casos de uso cuando participan en la interacción. Por ejemplo, un Servicio de mensajería puede asociarse con Enviar confirmación o participar como actor secundario en Solicitar turno si el sistema lo utiliza para notificar al paciente.
La asociación con actores secundarios permite visualizar dependencias externas importantes. Si un sistema externo falla, puede afectar el flujo del caso de uso.
12.7 Cuándo dibujar una asociación
Conviene dibujar una asociación cuando el actor participa directamente en el caso de uso. Algunas preguntas útiles son:
- ¿El actor inicia el caso de uso?
- ¿El actor entrega datos al sistema durante el caso de uso?
- ¿El actor recibe información o una notificación relevante?
- ¿El sistema consulta a ese actor o sistema externo?
- ¿El actor debe autorizar, validar o confirmar algo?
- ¿Sin ese actor el caso de uso no podría completarse como está definido?
12.8 Cuándo no dibujar una asociación
No conviene dibujar una asociación si el actor no participa realmente en el caso de uso. Que un actor esté interesado en el resultado no siempre significa que interactúe con el sistema durante esa funcionalidad.
Por ejemplo, un director de clínica puede estar interesado en que se registren turnos, pero si no interactúa con el caso de uso Solicitar turno, no debería asociarse a ese caso. Podría tener otros casos de uso propios, como Consultar reporte de turnos.
12.9 Asociación y dirección
En los diagramas de casos de uso, la asociación se dibuja normalmente como una línea simple sin flecha. UML permite algunas variantes, pero para cursos introductorios y modelos claros suele ser suficiente una línea sin dirección.
Agregar flechas puede hacer que el lector piense que se está indicando una secuencia, un flujo de datos o una llamada. Si no hay una razón clara para usarlas, es mejor evitarlas.
12.10 Asociación no es flujo de pasos
Un error frecuente es intentar leer el diagrama como si fuera un flujo: primero el actor A, luego el caso de uso B, después otro actor. Ese no es el propósito del diagrama.
El orden de pasos pertenece al flujo principal y a los flujos alternativos de la especificación textual. Si se necesita modelar secuencia temporal, conviene usar texto, diagramas de actividad o diagramas de secuencia, no asociaciones de casos de uso.
12.11 Ejemplo: sistema de turnos
En un sistema de turnos médicos, las asociaciones podrían organizarse así:
| Actor | Caso de uso asociado | Motivo de la asociación |
|---|---|---|
| Paciente | Solicitar turno | Interactúa con el sistema para reservar una consulta. |
| Paciente | Cancelar turno | Solicita dejar sin efecto una reserva existente. |
| Médico | Consultar agenda diaria | Obtiene la lista de pacientes asignados. |
| Recepcionista | Registrar turno presencial | Registra una reserva en nombre de un paciente. |
| Servicio de mensajería | Enviar confirmación | Recibe la orden de notificar al paciente. |
12.12 Múltiples actores asociados al mismo caso
Un caso de uso puede tener más de un actor asociado. Esto ocurre cuando varias entidades externas participan en la interacción.
Por ejemplo, en Solicitar turno puede participar el Paciente como actor principal y un Servicio de mensajería como actor secundario. Si además se valida cobertura, podría participar una Obra social o Sistema de cobertura.
Cuando hay varios actores, la especificación textual debe aclarar qué rol cumple cada uno.
12.13 Un actor asociado a varios casos
Un actor también puede estar asociado a varios casos de uso. Esto es normal cuando un mismo rol tiene varios objetivos frente al sistema.
Por ejemplo, el Paciente puede estar asociado a Solicitar turno, Consultar turnos y Cancelar turno. Cada asociación representa una interacción diferente con el sistema.
12.14 Evitar diagramas saturados
Cuando hay muchos actores y casos de uso, el diagrama puede llenarse de líneas cruzadas. Si esto ocurre, conviene dividir el modelo en diagramas más pequeños por área, actor principal o módulo funcional.
Un diagrama claro vale más que un diagrama completo pero ilegible. La asociación debe ayudar a comprender, no a producir ruido visual.
12.15 Validar asociaciones
Para validar una asociación, conviene revisar si se puede explicar con una frase simple:
Si no se puede justificar la relación, quizá la asociación no debería estar en el diagrama.
12.16 Errores frecuentes
Al dibujar asociaciones entre actores y casos de uso, suelen aparecer estos errores:
- Usar flechas para indicar el orden de ejecución.
- Asociar actores que solo están interesados en el resultado, pero no interactúan.
- Olvidar actores secundarios que participan mediante sistemas externos.
- Conectar actores con otros actores como si fueran pasos de proceso.
- Conectar casos de uso entre sí usando líneas simples sin significado claro.
- Incluir demasiadas asociaciones y volver ilegible el diagrama.
- Interpretar la asociación como flujo de datos o dependencia técnica.
12.17 Qué debes recordar de este tema
- La asociación conecta un actor con un caso de uso.
- Indica participación o comunicación, no secuencia de pasos.
- Normalmente se representa con una línea simple sin flechas.
- Puede asociarse el actor principal y también actores secundarios.
- Un caso de uso puede tener varios actores asociados.
- Un actor puede participar en varios casos de uso.
- Las asociaciones deben mantenerse claras y justificadas.
12.18 Conclusión
La asociación es uno de los elementos más simples del diagrama de casos de uso, pero también uno de los más importantes. Permite mostrar quién participa en cada funcionalidad y ayuda a comprender la relación entre el sistema y su entorno.
Usarla correctamente evita interpretaciones equivocadas y mantiene el diagrama enfocado en la interacción externa. En el próximo tema estudiaremos las relaciones de inclusión y el uso correcto de <<include>>.