6. Diagramas de casos de uso: visión general del sistema
6.1 Introducción
El diagrama de casos de uso es uno de los diagramas UML más conocidos. Su objetivo es mostrar, en forma general, qué servicios ofrece un sistema y qué actores externos interactúan con él. Es una vista de alcance funcional: ayuda a comprender qué se espera del sistema desde afuera.
Este diagrama no explica cómo se implementa el software, cómo será la base de datos ni qué pantallas tendrá la interfaz. Tampoco reemplaza la especificación textual de cada caso de uso. Su valor principal está en ofrecer una visión rápida del sistema, sus límites y sus funcionalidades principales.
6.2 Qué representa un diagrama de casos de uso
Un diagrama de casos de uso representa la relación entre actores y funcionalidades. Los actores están fuera del sistema y los casos de uso están dentro del límite del sistema. Las líneas de asociación indican qué actores participan en cada funcionalidad.
Por ejemplo, en un sistema de turnos médicos, el actor Paciente puede participar en los casos de uso Solicitar turno, Consultar turno y Cancelar turno. El actor Administrador puede participar en Gestionar profesionales, Configurar horarios y Generar reportes.
6.3 Visión general de un sistema mediante casos de uso
Un diagrama de casos de uso organiza el sistema alrededor de sus actores externos y de los objetivos que esos actores buscan cumplir. El rectángulo representa el límite del sistema, los actores quedan fuera de ese límite y los óvalos ubicados dentro representan funcionalidades observables. Esta vista permite discutir alcance, responsabilidades y servicios principales sin entrar todavía en detalles de diseño o implementación.
6.4 Actores
Un actor es una entidad externa que interactúa con el sistema. Puede ser una persona, otro sistema, una organización, un dispositivo o un servicio externo. Lo importante es que el actor se encuentra fuera del sistema que se está modelando.
El actor no representa necesariamente a una persona concreta, sino un rol. Una misma persona puede actuar como Paciente en una operación y como Administrador en otra, si cumple ambos roles. También puede ocurrir que muchas personas distintas cumplan el mismo rol de actor.
6.5 Casos de uso
Un caso de uso representa una funcionalidad del sistema orientada a un objetivo. Se dibuja como un óvalo y se nombra normalmente con un verbo en infinitivo más un objeto o resultado, por ejemplo Registrar cliente, Solicitar turno, Realizar pago o Consultar historial.
El nombre debe expresar una intención completa y comprensible. No conviene nombrar casos de uso como botones, pantallas o pasos internos. Por ejemplo, Ingresar contraseña es un paso; Iniciar sesión es un objetivo más completo.
6.6 Límite del sistema
El límite del sistema se representa con un rectángulo que contiene los casos de uso. Su función es separar lo que pertenece al sistema de lo que queda fuera. Esta frontera ayuda a discutir responsabilidades: qué debe resolver el sistema y qué corresponde a actores externos o sistemas vecinos.
Definir mal el límite del sistema produce confusión. Si el límite es demasiado amplio, se incluyen responsabilidades que no corresponden. Si es demasiado estrecho, se dejan afuera funcionalidades que sí debería cubrir el sistema.
6.7 Asociaciones entre actores y casos de uso
La asociación indica que un actor participa en un caso de uso. Se representa con una línea simple entre el actor y el óvalo. No expresa flujo, orden, navegación de pantalla ni dependencia técnica. Solo indica participación o comunicación.
Una asociación debe tener sentido desde el punto de vista del objetivo. Si un actor no inicia ni recibe información relevante durante el caso de uso, probablemente no debería estar asociado a ese óvalo.
6.8 Relaciones entre casos de uso
Además de asociaciones con actores, UML permite expresar algunas relaciones entre casos de uso. Las más conocidas son <<include>>, <<extend>> y la generalización. Estas relaciones deben usarse con cuidado porque pueden volver confuso un diagrama que debería ser de alto nivel.
<<include>> indica que un caso de uso siempre reutiliza el comportamiento de otro. <<extend>> indica que un comportamiento opcional o condicional puede agregarse a otro caso de uso. La generalización indica una especialización entre actores o entre casos de uso.
6.9 Cuándo usar este diagrama
El diagrama de casos de uso es útil al inicio de un proyecto o de una funcionalidad importante, cuando se necesita acordar el alcance general. También sirve para explicar el sistema a personas que no necesitan conocer detalles técnicos.
Puede utilizarse para descubrir actores faltantes, detectar funcionalidades omitidas, organizar conversaciones sobre requisitos, dividir el sistema en áreas y preparar la documentación detallada de cada caso de uso.
6.10 Qué no debe incluir
Un diagrama de casos de uso no debe incluir clases, tablas, pantallas, botones, algoritmos, mensajes internos ni detalles de arquitectura. Tampoco conviene representar cada paso pequeño como un caso de uso separado.
Por ejemplo, Validar DNI, Mostrar formulario o Presionar botón confirmar no suelen ser buenos casos de uso. Son pasos internos dentro de objetivos más completos, como Registrar paciente o Solicitar turno.
6.11 Relación con la especificación textual
El diagrama de casos de uso ofrece una vista general, pero no contiene todo el comportamiento. Para funcionalidades importantes, se necesita una especificación textual que describa actor principal, objetivo, precondiciones, flujo principal, alternativas, excepciones, reglas de negocio y resultado esperado.
Ambas formas se complementan. El diagrama ayuda a ver el conjunto; la especificación textual ayuda a entender cada funcionalidad con precisión.
6.12 Ejemplo: sistema de turnos médicos
En un sistema de turnos médicos, algunos actores posibles son Paciente, Médico, Recepcionista, Administrador y Sistema de notificaciones. Algunos casos de uso posibles son Solicitar turno, Cancelar turno, Consultar agenda, Registrar disponibilidad, Gestionar profesionales y Enviar recordatorio.
El diagrama permitiría observar rápidamente qué actores se relacionan con qué funcionalidades. Si el actor Sistema de notificaciones aparece asociado a Enviar recordatorio, queda claro que existe una comunicación con un sistema externo.
6.13 Granularidad de los casos de uso
La granularidad indica el tamaño o alcance de cada caso de uso. Un caso de uso demasiado pequeño se parece a un paso de interfaz. Uno demasiado grande mezcla objetivos distintos y se vuelve difícil de especificar.
Una buena regla práctica es preguntarse si el caso de uso entrega un resultado reconocible para el actor. Si no entrega valor por sí mismo, tal vez sea un paso dentro de otro caso de uso.
6.14 Diagrama simple antes que diagrama complejo
Conviene comenzar con un diagrama simple que muestre actores principales, casos de uso principales y límite del sistema. Luego se pueden agregar relaciones adicionales solo si aclaran el modelo.
Un diagrama de casos de uso lleno de relaciones <<include>> y <<extend>> puede perder su principal ventaja: comunicar rápidamente el alcance funcional.
6.15 Criterios de revisión
- ¿El límite del sistema está claro?
- ¿Los actores están fuera del sistema?
- ¿Los casos de uso representan objetivos completos?
- ¿Los nombres usan verbos claros y comprensibles?
- ¿Las asociaciones indican participación real?
- ¿El diagrama evita detalles internos de implementación?
- ¿El nivel de detalle permite comprender el alcance sin saturar la vista?
6.16 Errores frecuentes
- Colocar actores dentro del límite del sistema.
- Representar pantallas, formularios o botones como casos de uso.
- Usar nombres técnicos que no expresan objetivos del actor.
- Crear casos de uso demasiado pequeños o demasiado grandes.
- Confundir asociaciones con orden de ejecución.
- Usar relaciones
<<include>>y<<extend>>sin necesidad real. - Pensar que el diagrama reemplaza la especificación textual.
6.17 Qué debes recordar de este tema
- El diagrama de casos de uso muestra una visión general del sistema desde afuera.
- Los actores representan roles externos que interactúan con el sistema.
- Los casos de uso representan objetivos funcionales con valor para un actor.
- El límite del sistema separa responsabilidades internas y externas.
- Las asociaciones indican participación, no flujo ni navegación.
- El diagrama debe mantenerse simple y orientado al alcance funcional.
- La especificación textual complementa al diagrama cuando se necesita detalle.
6.18 Conclusión
El diagrama de casos de uso es una herramienta útil para visualizar el alcance funcional de un sistema. Permite identificar actores, objetivos y responsabilidades generales sin entrar en detalles técnicos. Su claridad depende de mantener una vista simple, con nombres adecuados y un límite de sistema bien definido.
En el próximo tema comenzaremos con los diagramas de clases, que permiten representar clases, atributos, operaciones y responsabilidades.