30. Granularidad: cuándo dividir o unir casos de uso

30.1 Introducción

La granularidad indica el tamaño o nivel de detalle de un caso de uso. Un caso de uso puede ser demasiado grande, demasiado pequeño o estar en un nivel adecuado para comunicar un objetivo del actor.

Definir bien la granularidad es importante porque afecta el diagrama, la especificación textual, la planificación, las pruebas y la comprensión del alcance. Si los casos de uso son demasiado grandes, mezclan varios objetivos. Si son demasiado pequeños, se convierten en pasos o detalles de interfaz.

El desafío consiste en encontrar unidades de comportamiento que tengan sentido para el actor y que entreguen un resultado reconocible.

30.2 Qué significa granularidad

La granularidad responde a la pregunta: ¿qué tan grande debe ser este caso de uso? No existe una medida exacta, pero sí criterios prácticos.

Un caso de uso adecuado suele representar un objetivo completo del actor. Tiene inicio, desarrollo y resultado. Puede describirse con un nombre claro, como Solicitar turno, Cancelar turno o Consultar agenda diaria.

30.3 El equilibrio de granularidad

Un modelo claro evita los extremos. Un caso de uso demasiado grande, como Gestionar turnos, puede ocultar varios objetivos. Un caso demasiado pequeño, como Seleccionar fecha, puede ser solo un paso. Un caso adecuado, como Solicitar turno, representa una interacción completa y útil.

30.4 Casos de uso demasiado grandes

Un caso de uso es demasiado grande cuando reúne varios objetivos que podrían existir por separado. Suele tener nombres amplios como Gestionar, Administrar, Procesar o Manejar.

Ejemplos de casos demasiado grandes:

• Gestionar turnos.
• Administrar clínica.
• Manejar pedidos.
• Procesar atención del paciente.
• Gestionar usuarios y permisos.

Estos nombres pueden ser útiles como agrupaciones o módulos, pero muchas veces no son buenos casos de uso individuales.

30.5 Cuándo dividir un caso de uso

Conviene dividir un caso de uso cuando:

• Incluye varios objetivos independientes.
• Participan actores principales distintos con metas diferentes.
• El flujo principal se vuelve muy largo y mezcla procesos.
• Algunas partes pueden priorizarse, desarrollarse o probarse por separado.
• El nombre es demasiado general y no expresa un objetivo concreto.
• Las reglas de negocio cambian mucho entre partes del proceso.

30.6 Ejemplo de división

El caso Gestionar turnos puede dividirse en varios casos más claros:

• Solicitar turno.
• Consultar turnos.
• Modificar turno.
• Cancelar turno.
• Registrar turno presencial.
• Administrar agenda.

Cada uno representa un objetivo más específico, con actor, flujo y resultado propios.

30.7 Casos de uso demasiado pequeños

Un caso de uso es demasiado pequeño cuando describe una acción mínima que no entrega valor propio al actor. Muchas veces son pasos del flujo, validaciones, campos o acciones de interfaz.

Ejemplos:

• Ingresar documento.
• Seleccionar fecha.
• Presionar confirmar.
• Mostrar mensaje.
• Validar campo obligatorio.

Estas acciones pueden ser importantes, pero normalmente pertenecen al flujo de un caso mayor.

30.8 Cuándo unir casos de uso

Conviene unir casos de uso cuando:

• Por separado no entregan valor reconocible al actor.
• Son pasos consecutivos inseparables de un mismo objetivo.
• Tienen el mismo actor principal y forman una interacción única.
• Separarlos produce un diagrama lleno de detalles innecesarios.
• La especificación se vuelve repetitiva y fragmentada.

30.9 Ejemplo de unión

Los supuestos casos Seleccionar especialidad, Seleccionar fecha, Seleccionar horario y Confirmar solicitud pueden formar parte de un único caso de uso llamado Solicitar turno.

Separarlos como casos independientes haría que el modelo describa pasos de interfaz en lugar de objetivos del actor.

30.10 Criterio del objetivo del actor

El criterio más importante es el objetivo del actor. Si el nombre del caso de uso expresa algo que el actor reconocería como una meta completa, probablemente la granularidad sea adecuada.

Un paciente reconoce Solicitar turno como objetivo. Difícilmente reconozca Validar campo fecha como un objetivo por sí mismo.

30.11 Criterio del valor entregado

Un caso de uso debe entregar algún valor observable. Ese valor puede ser una reserva creada, un reporte generado, un pago registrado, una solicitud enviada o información consultada.

Si al finalizar el supuesto caso no queda un resultado claro, puede ser una señal de que es demasiado pequeño o de que está mal definido.

30.12 Criterio de prueba

Un buen caso de uso suele poder probarse como una unidad funcional. Esto no significa que sea una única prueba, sino que puede verificarse si el objetivo se cumple.

Si el caso es tan pequeño que solo prueba un campo aislado, quizá pertenece a una validación. Si es tan grande que requiere probar medio sistema, quizá debe dividirse.

30.13 Criterio de planificación

La granularidad también afecta la planificación. Casos de uso adecuados permiten priorizar y entregar funcionalidades con valor. Si los casos son demasiado grandes, cuesta estimar. Si son demasiado pequeños, la planificación se llena de detalles de bajo nivel.

Por ejemplo, Solicitar turno puede ser una unidad razonable para análisis y planificación. Gestionar clínica es demasiado amplio; Seleccionar fecha es demasiado pequeño.

30.14 Diferencia entre caso de uso y subflujo

Algunas partes de un caso de uso pueden separarse como subflujos dentro de la especificación textual sin convertirse en casos de uso independientes.

Por ejemplo, "buscar disponibilidad" puede ser un subflujo dentro de Solicitar turno si solo tiene sentido allí. En cambio, si esa búsqueda se reutiliza en varios casos y tiene entidad propia, podría analizarse como caso incluido mediante <<include>>.

30.15 Ejemplo aplicado a turnos médicos

La siguiente tabla muestra posibles ajustes de granularidad:

30.16 Preguntas para decidir

Para decidir si dividir, unir o mantener, conviene preguntar:

• ¿El actor reconoce esto como un objetivo completo?
• ¿Entrega un resultado observable?
• ¿Tiene un actor principal claro?
• ¿El flujo es demasiado largo o mezcla varios objetivos?
• ¿Es solo un paso dentro de otro caso de uso?
• ¿Se puede priorizar o probar como unidad funcional?
• ¿Separarlo mejora la claridad o solo agrega ruido?

30.17 Errores frecuentes

Al trabajar con granularidad, suelen aparecer estos errores:

• Crear casos de uso a partir de cada pantalla o botón.
• Usar nombres demasiado generales como Gestionar todo.
• No dividir procesos grandes con varios objetivos.
• Dividir pasos pequeños que no entregan valor propio.
• Confundir subflujos con casos de uso independientes.
• Usar <<include>> para resolver cualquier problema de granularidad.
• No validar la granularidad con usuarios y equipo técnico.

30.18 Lista de revisión

Antes de cerrar una lista de casos de uso, conviene revisar:

• ¿Hay casos demasiado generales?
• ¿Hay casos que son solo pasos de interfaz?
• ¿Cada caso tiene actor principal?
• ¿Cada caso entrega valor observable?
• ¿Hay casos duplicados o muy solapados?
• ¿Los casos pueden priorizarse y probarse?
• ¿El diagrama resultante es legible?

30.19 Qué debes recordar de este tema

• La granularidad define el tamaño o nivel de detalle de un caso de uso.
• Un caso demasiado grande mezcla varios objetivos.
• Un caso demasiado pequeño suele ser un paso del flujo.
• Conviene dividir cuando hay objetivos independientes.
• Conviene unir cuando las partes no entregan valor por separado.
• El objetivo del actor y el valor observable son criterios centrales.
• Una buena granularidad mejora diagramas, especificaciones, planificación y pruebas.

30.20 Conclusión

Definir la granularidad correcta es una de las habilidades más importantes al trabajar con casos de uso. No se trata de hacer más o menos documentos, sino de representar objetivos en unidades claras y útiles.

Cuando los casos de uso tienen el tamaño adecuado, el modelo se entiende mejor, se valida con más facilidad y se convierte en una mejor base para desarrollo y pruebas. En el próximo tema estudiaremos paquetes y organización de casos de uso en sistemas grandes.