11. Diagrama de casos de uso UML: elementos básicos
11.1 Introducción
El diagrama de casos de uso UML es una representación visual que muestra qué actores interactúan con un sistema y qué funcionalidades principales ofrece ese sistema. Es una vista de alto nivel del comportamiento esperado, no un diseño interno del software.
Este diagrama es útil al comienzo del análisis porque permite conversar sobre alcance, actores, objetivos y funcionalidades sin entrar todavía en detalles de implementación. También ayuda a detectar omisiones, relaciones confusas y límites del sistema mal definidos.
Para construir diagramas claros, primero debemos conocer sus elementos básicos: actor, caso de uso, límite del sistema y asociación.
11.2 Propósito del diagrama
El propósito principal del diagrama es mostrar qué servicios ofrece el sistema a su entorno. No explica paso a paso cómo se realiza cada caso de uso; para eso se utiliza la especificación textual.
Un buen diagrama de casos de uso permite responder preguntas como:
- ¿Qué actores interactúan con el sistema?
- ¿Qué objetivos principales pueden lograr esos actores?
- ¿Qué funcionalidades están dentro del alcance?
- ¿Qué sistemas externos participan?
- ¿Hay casos de uso que parecen faltar o sobrar?
11.3 Elementos básicos del diagrama
Un diagrama básico de casos de uso UML muestra actores fuera del límite del sistema, casos de uso dentro del sistema y líneas de asociación que indican interacción. Esta vista permite entender rápidamente quién usa el sistema y para qué.
11.4 Actor
El actor representa una entidad externa que interactúa con el sistema. Puede ser una persona, un sistema externo, un dispositivo o una organización. En UML se dibuja habitualmente como una figura humana simple, aunque también puede representarse con un rectángulo con el estereotipo correspondiente.
El actor no está dentro del sistema. Se ubica fuera del límite porque no forma parte del software que se está especificando. Su función es mostrar quién participa en los casos de uso.
Ejemplos de actores en un sistema de turnos médicos:
- Paciente.
- Recepcionista.
- Médico.
- Administrador.
- Servicio de mensajería.
11.5 Caso de uso
El caso de uso representa una funcionalidad o servicio que el sistema ofrece a los actores. En UML se dibuja como una elipse con el nombre del caso de uso dentro.
El nombre debe expresar un objetivo claro, normalmente con verbo en infinitivo: Solicitar turno, Cancelar turno, Consultar agenda, Registrar paciente.
La elipse no contiene todos los pasos del caso de uso. Solo muestra que esa funcionalidad existe dentro del alcance del sistema.
11.6 Límite del sistema
El límite del sistema se representa como un rectángulo que contiene los casos de uso. El nombre del sistema suele colocarse en la parte superior del rectángulo.
Todo lo que queda dentro del rectángulo pertenece al sistema que se analiza. Todo lo que queda fuera es externo. Esta separación evita confundir actores, procesos externos o sistemas vecinos con funcionalidades propias del sistema.
11.7 Asociación
La asociación es una línea que conecta un actor con un caso de uso. Indica que el actor participa en esa funcionalidad. No describe dirección de datos, orden de pasos ni detalles técnicos; solo muestra una relación de interacción.
Por ejemplo, si el actor Paciente está conectado con Solicitar turno, significa que el paciente participa en ese caso de uso. Los detalles de cómo solicita el turno se documentan en la especificación textual.
11.8 Qué no muestra el diagrama
El diagrama de casos de uso no muestra todo. No representa clases, tablas, pantallas, algoritmos, arquitectura, orden exacto de pasos ni reglas completas de negocio.
Por ejemplo, una línea entre Paciente y Solicitar turno no explica si el paciente debe iniciar sesión, qué datos ingresa, qué validaciones se realizan o qué ocurre si no hay horarios disponibles. Esa información corresponde a la especificación del caso de uso.
11.9 Ejemplo aplicado a turnos médicos
Un diagrama inicial de un sistema de turnos médicos podría incluir los siguientes actores y casos de uso:
| Actor | Casos de uso relacionados |
|---|---|
| Paciente | Solicitar turno, Consultar turnos, Cancelar turno. |
| Recepcionista | Registrar turno presencial, Modificar turno, Registrar paciente. |
| Médico | Consultar agenda diaria. |
| Administrador | Administrar agenda, Registrar profesional, Configurar horarios. |
| Servicio de mensajería | Enviar confirmación, Enviar recordatorio. |
11.10 Nivel de abstracción
El diagrama debe mantenerse en un nivel de abstracción adecuado. Si se agregan acciones demasiado pequeñas, el diagrama se llena de detalles poco útiles. Si se agregan casos demasiado generales, no queda claro qué funcionalidades reales existen.
Por ejemplo, Solicitar turno es un buen caso de uso para un diagrama inicial. En cambio, Seleccionar fecha suele ser solo un paso, y Gestionar clínica es demasiado amplio para representar una funcionalidad concreta del sistema de turnos.
11.11 Diagrama y alcance
El diagrama de casos de uso es una herramienta muy útil para discutir alcance. Si una funcionalidad aparece dentro del límite del sistema, se entiende que forma parte de lo que debe analizarse. Si un actor aparece fuera, se entiende que participa desde el entorno.
Por eso, antes de usar el diagrama como compromiso de alcance, debe revisarse con cuidado. Un caso de uso agregado por error puede generar expectativas incorrectas.
11.12 Diagrama y comunicación
Una ventaja del diagrama es que puede ser entendido por personas técnicas y no técnicas. Un usuario puede revisar si aparecen sus objetivos principales sin necesidad de leer una especificación extensa.
Sin embargo, el diagrama debe acompañarse con explicación. Si se muestra sin contexto, algunas personas pueden interpretar que las líneas indican navegación de pantallas, flujo de datos o dependencias técnicas, cuando en realidad solo indican participación.
11.13 Recomendaciones de claridad
Para que el diagrama sea claro, conviene aplicar estas recomendaciones:
- Usar nombres de casos de uso orientados a objetivos.
- Ubicar actores fuera del límite del sistema.
- Ubicar casos de uso dentro del límite del sistema.
- No incluir pasos pequeños como casos independientes.
- No incluir módulos internos como actores.
- Mantener el diagrama legible, sin exceso de cruces de líneas.
- Acompañar el diagrama con especificaciones textuales cuando sea necesario.
11.14 Errores frecuentes
Al construir diagramas de casos de uso, suelen aparecer estos errores:
- Dibujar actores dentro del sistema.
- Nombrar casos de uso como pantallas o botones.
- Usar flechas para indicar una secuencia de pasos.
- Representar clases, tablas o módulos internos.
- Agregar demasiados detalles en un diagrama inicial.
- No dibujar el límite del sistema cuando el alcance no está claro.
- Creer que el diagrama reemplaza la especificación textual.
11.15 Qué debes recordar de este tema
- El diagrama de casos de uso UML muestra actores, casos de uso y relaciones de interacción.
- Los actores se ubican fuera del límite del sistema.
- Los casos de uso se representan con elipses dentro del sistema.
- El límite del sistema se representa con un rectángulo.
- La asociación indica participación, no secuencia ni flujo de datos.
- El diagrama resume alcance, pero no detalla comportamiento paso a paso.
- La especificación textual complementa al diagrama.
11.16 Conclusión
El diagrama de casos de uso UML es una herramienta sencilla y poderosa para representar el alcance funcional de un sistema. Sus elementos básicos permiten mostrar quién interactúa con el sistema y qué objetivos principales puede lograr.
Para que el diagrama sea útil, debe mantenerse claro, coherente y enfocado en objetivos de actores. En el próximo tema profundizaremos en la asociación entre actores y casos de uso.