16. Errores frecuentes en diagramas de casos de uso
16.1 Introducción
Los diagramas de casos de uso son simples en apariencia, pero esa simplicidad puede llevar a usarlos de manera incorrecta. Un diagrama con errores no solo se ve mal: también puede comunicar mal el alcance, confundir actores, ocultar objetivos reales o generar expectativas equivocadas.
En este tema revisaremos errores frecuentes y formas prácticas de evitarlos. La intención no es memorizar reglas aisladas, sino comprender qué debe comunicar un diagrama de casos de uso: quién interactúa con el sistema y qué objetivos principales puede lograr.
16.2 Olvidar el límite del sistema
Uno de los errores más comunes es no dibujar el límite del sistema cuando el alcance no está claro. Sin ese rectángulo, puede ser difícil saber qué funcionalidades pertenecen al sistema y qué elementos son externos.
El límite ayuda a separar responsabilidades. Los casos de uso van dentro; los actores quedan fuera. Si esta separación no se ve, el lector puede confundir procesos del negocio, usuarios, módulos internos y sistemas externos.
16.3 Ubicar actores dentro del sistema
Los actores representan entidades externas. Por eso no deben colocarse dentro del rectángulo del sistema. Aunque un actor sea empleado de la organización, sigue estando fuera del software que se analiza.
Por ejemplo, Recepcionista puede trabajar en la clínica, pero no forma parte del sistema de turnos. Interactúa con él desde fuera para registrar, modificar o consultar información.
16.4 Comparación entre errores y correcciones
Un diagrama incorrecto suele mezclar actores dentro del sistema, casos de uso nombrados como pantallas, flechas usadas como secuencia y relaciones <<include>> o <<extend>> sin necesidad. Una versión corregida mantiene actores externos, casos de uso orientados a objetivos, asociaciones simples y un límite del sistema claro.
16.5 Nombrar casos de uso como pantallas
Un caso de uso no debe llamarse Pantalla de turnos, Formulario de paciente o Menú de reportes. Esos nombres describen elementos de interfaz, no objetivos de actores.
Nombres más claros serían Solicitar turno, Registrar paciente o Generar reporte. El caso de uso debe expresar qué quiere lograr el actor, no qué pantalla se muestra.
16.6 Nombrar pasos pequeños como casos de uso
Acciones como Ingresar documento, Seleccionar fecha, Presionar aceptar o Mostrar mensaje suelen ser pasos dentro de un flujo, no casos de uso independientes.
Si se modelan todos los pasos como casos de uso, el diagrama se vuelve grande, confuso y poco útil. El detalle de pasos pertenece a la especificación textual.
16.7 Usar nombres demasiado generales
El error opuesto es usar nombres tan generales que no comunican una funcionalidad concreta. Por ejemplo, Gestionar clínica, Administrar sistema o Manejar turnos pueden incluir demasiados objetivos diferentes.
Cuando un caso de uso parece contener muchas acciones, conviene dividirlo. Manejar turnos podría separarse en Solicitar turno, Cancelar turno, Modificar turno y Consultar turnos.
16.8 Confundir asociación con secuencia
Las líneas entre actores y casos de uso no representan orden de ejecución. Indican participación. No se deben usar para mostrar que primero ocurre un caso de uso, luego otro y después una respuesta.
Si se necesita describir el orden de pasos, se debe escribir el flujo principal en la especificación textual o usar otro tipo de diagrama, como un diagrama de actividad.
16.9 Usar flechas innecesarias en asociaciones
En diagramas introductorios, las asociaciones entre actores y casos de uso suelen dibujarse como líneas simples sin flechas. Agregar flechas puede hacer pensar que hay dirección de datos, llamadas técnicas o secuencia temporal.
Si la flecha no comunica algo necesario y acordado, es mejor usar una línea simple.
16.10 Abusar de <<include>>
La relación <<include>> no debe usarse para dividir un caso de uso en todos sus pasos. Solo corresponde cuando un caso base incorpora obligatoriamente otro comportamiento que tiene sentido como unidad separada.
Por ejemplo, Validar disponibilidad puede ser un caso incluido si varios casos lo reutilizan y siempre se ejecuta. En cambio, Seleccionar fecha probablemente sea solo un paso dentro del flujo.
16.11 Abusar de <<extend>>
La relación <<extend>> tampoco debe usarse para cualquier alternativa. Muchas variantes se documentan mejor como flujos alternativos en la especificación textual.
Conviene usar extensión solo cuando el comportamiento condicional es importante, tiene entidad propia y mejora la comprensión del diagrama.
16.12 Confundir actores con módulos internos
Un módulo interno, una clase, una tabla o un componente del sistema no debe aparecer como actor. Los actores son externos al sistema.
Por ejemplo, Base de datos, Controlador de turnos o Módulo de validación no deberían ser actores si forman parte del sistema que se está construyendo. En cambio, Pasarela de pago o Sistema contable externo sí pueden ser actores si están fuera del sistema y se comunican con él.
16.13 Conectar casos de uso sin significado claro
No conviene unir casos de uso con líneas simples sin especificar qué relación representan. Entre casos de uso pueden existir relaciones como <<include>>, <<extend>> o generalización, pero cada una tiene un significado preciso.
Si no se puede explicar por qué dos casos de uso están conectados, probablemente esa línea no debería estar.
16.14 Crear diagramas demasiado grandes
Un diagrama con muchos actores, muchas elipses y muchas líneas cruzadas puede ser técnicamente completo, pero difícil de leer. Cuando el sistema es grande, conviene dividir la vista en varios diagramas.
Se puede separar por módulo, por actor principal, por área funcional o por versión del producto. La claridad del diagrama es parte de su utilidad.
16.15 No acompañar el diagrama con texto
El diagrama de casos de uso no reemplaza la especificación textual. Puede mostrar alcance e interacción, pero no explica precondiciones, flujos, reglas, excepciones ni postcondiciones.
Para casos simples, puede alcanzar con una descripción breve. Para casos importantes o complejos, hace falta una especificación textual más completa.
16.16 Lista de revisión
Antes de dar por válido un diagrama, conviene revisarlo con estas preguntas:
- ¿El límite del sistema está claro?
- ¿Los actores están fuera del sistema?
- ¿Los casos de uso están nombrados como objetivos?
- ¿No hay pasos pequeños convertidos en casos de uso?
- ¿Las asociaciones indican participación y no secuencia?
- ¿Las relaciones <<include>> y <<extend>> están justificadas?
- ¿El diagrama es legible?
- ¿Los casos importantes tienen especificación textual?
16.17 Ejemplo de corrección de nombres
La siguiente tabla muestra errores comunes de nombres y una posible corrección:
| Nombre incorrecto | Problema | Nombre corregido |
|---|---|---|
| Pantalla de turnos | Describe una interfaz. | Consultar turnos |
| Presionar confirmar | Describe un botón. | Confirmar reserva |
| Validar campo fecha | Describe una validación interna. | Solicitar turno |
| Administrar todo | Es demasiado general. | Administrar agenda |
16.18 Qué debes recordar de este tema
- Los actores deben estar fuera del límite del sistema.
- Los casos de uso deben nombrarse como objetivos de actores.
- Las asociaciones no representan secuencia ni flujo de datos.
- No conviene convertir cada paso en un caso de uso.
- <<include>> y <<extend>> deben usarse con un significado preciso.
- Los módulos internos no son actores.
- Un diagrama claro y revisable es más útil que uno grande y confuso.
16.19 Conclusión
La mayoría de los errores en diagramas de casos de uso aparece cuando se olvida el propósito del diagrama: mostrar actores externos, funcionalidades del sistema y relaciones de participación a un nivel comprensible.
Un buen diagrama debe ser claro, coherente y útil para conversar sobre alcance y objetivos. En el próximo tema comenzaremos a estudiar la especificación textual de un caso de uso, donde se describe el comportamiento con mayor precisión.