31. Paquetes y organización de casos de uso en sistemas grandes

31.1 Introducción

Cuando un sistema es pequeño, puede alcanzar con un único diagrama y una lista corta de casos de uso. Pero en sistemas grandes, la cantidad de actores, funcionalidades, relaciones y reglas puede crecer rápidamente.

Para mantener el modelo comprensible, conviene organizar los casos de uso en paquetes, áreas funcionales o vistas separadas. Esta organización permite navegar el sistema por partes y evita diagramas enormes, saturados de líneas y difíciles de validar.

Organizar no significa cambiar el comportamiento del sistema. Significa presentar la información de una manera más clara y mantenible.

31.2 Qué es un paquete

En UML, un paquete es un contenedor lógico que agrupa elementos relacionados. En casos de uso, puede usarse para reunir funcionalidades de una misma área, módulo, proceso, actor o versión.

Por ejemplo, en un sistema de turnos médicos, pueden existir paquetes como Gestión de turnos, Administración de agendas, Gestión de pacientes, Notificaciones y Reportes.

31.3 Organización por paquetes funcionales

En sistemas grandes, los paquetes permiten separar casos de uso por áreas funcionales. Así, en lugar de mostrar todo en un único diagrama, se puede trabajar con una vista general y luego con diagramas más específicos para cada paquete.

31.4 Por qué organizar casos de uso

Organizar casos de uso ayuda a:

• Mantener diagramas legibles.
• Facilitar la revisión con usuarios de distintas áreas.
• Separar responsabilidades funcionales.
• Planificar entregas por módulos o versiones.
• Detectar casos duplicados o solapados.
• Administrar mejor cambios y trazabilidad.

31.5 Organización por área funcional

Una forma frecuente es agrupar los casos de uso por área funcional. Cada paquete representa un conjunto de funcionalidades relacionadas.

Ejemplo en un sistema de turnos médicos:

• Turnos: Solicitar turno, Modificar turno, Cancelar turno, Consultar turnos.
• Agendas: Administrar agenda, Configurar horarios, Bloquear disponibilidad.
• Pacientes: Registrar paciente, Actualizar datos, Consultar datos administrativos.
• Notificaciones: Enviar confirmación, Enviar recordatorio.
• Reportes: Generar reporte de turnos, Consultar estadísticas de asistencia.

31.6 Organización por actor

También se puede organizar por actor principal. Esta vista resulta útil cuando se revisa el sistema con un tipo específico de usuario.

Ejemplo:

• Paciente: Solicitar turno, Consultar turnos, Cancelar turno.
• Médico: Consultar agenda diaria, Consultar historial de turnos.
• Recepcionista: Registrar turno presencial, Modificar turno, Registrar paciente.
• Administrador: Configurar horarios, Registrar profesional, Administrar permisos.

Esta organización ayuda a validar si cada actor tiene cubiertos sus objetivos principales.

31.7 Organización por proceso de negocio

En algunos sistemas conviene agrupar por procesos de negocio. Por ejemplo, en una clínica podrían existir procesos como Gestión de atención, Gestión administrativa, Gestión de pagos y Gestión de comunicación con pacientes.

Esta vista es útil cuando el análisis comienza desde procesos amplios y luego baja a casos de uso concretos.

31.8 Organización por versión

Cuando el sistema se entrega por etapas, puede ser útil organizar casos de uso por versión o incremento.

Ejemplo:

• Versión 1: Solicitar turno, Consultar turnos, Cancelar turno.
• Versión 2: Enviar recordatorios, Modificar turno, Registrar turno presencial.
• Versión 3: Reportes avanzados, integración con obra social, estadísticas.

Esta organización ayuda a conectar el modelo con la planificación.

31.9 Vista general y vistas detalladas

En sistemas grandes conviene tener una vista general que muestre los paquetes principales y luego vistas detalladas para cada paquete.

La vista general responde qué grandes áreas funcionales existen. Las vistas detalladas muestran actores, casos de uso y relaciones dentro de cada área.

31.10 Evitar diagramas gigantes

Un error frecuente es intentar mostrar todo el sistema en un único diagrama. Aunque sea posible, el resultado suele ser difícil de leer y revisar.

Si el diagrama tiene demasiadas líneas cruzadas, actores repetidos y elipses pequeñas, probablemente conviene dividirlo en diagramas por paquetes.

31.11 Nombres de paquetes

Los paquetes deben tener nombres claros y representativos. Conviene usar nombres del dominio o del área funcional, no nombres técnicos internos.

Buenos ejemplos:

• Gestión de turnos.
• Administración de agendas.
• Gestión de pacientes.
• Notificaciones.
• Reportes.

Nombres como Módulo A, Backend 1 o Servicios internos no ayudan a validar funcionalidad con usuarios.

31.12 Casos compartidos entre paquetes

Algunos casos de uso pueden estar relacionados con varios paquetes. Por ejemplo, Autenticar usuario puede ser común a muchas áreas, y Enviar notificación puede ser usado desde Turnos, Pagos o Reportes.

En estos casos se puede crear un paquete de funcionalidades comunes o documentar claramente qué casos de uso reutilizan ese comportamiento.

31.13 Paquetes y trazabilidad

La organización por paquetes facilita la trazabilidad. Si cambia una regla de agenda, probablemente afecte al paquete Administración de agendas y a algunos casos relacionados con Turnos.

Esto ayuda a estimar impacto, actualizar documentación y revisar pruebas asociadas.

31.14 Paquetes y permisos

Muchas veces los paquetes se relacionan con permisos. Por ejemplo, el paquete Administración puede estar disponible solo para administradores, mientras que el paquete Turnos puede estar disponible para pacientes y recepcionistas.

Esta relación no reemplaza la especificación de seguridad, pero ayuda a visualizar qué áreas del sistema usa cada actor.

31.15 Ejemplo de organización

Una posible organización para un sistema de turnos médicos podría ser:

31.16 Criterios para agrupar

Para decidir cómo agrupar, conviene preguntar:

• ¿Estos casos de uso pertenecen a la misma área funcional?
• ¿Comparten actores principales?
• ¿Forman parte del mismo proceso de negocio?
• ¿Se entregarán en la misma versión?
• ¿Comparten reglas de negocio o datos importantes?
• ¿La agrupación ayuda a revisar y mantener el modelo?

31.17 Errores frecuentes

Al organizar casos de uso, suelen aparecer estos errores:

• Crear un único diagrama enorme para todo el sistema.
• Agrupar por tecnología en lugar de funcionalidad.
• Usar nombres de paquetes poco comprensibles para usuarios.
• Duplicar casos de uso en varios paquetes sin aclaración.
• No mantener una vista general del sistema.
• Crear demasiados paquetes pequeños sin necesidad.
• No actualizar la organización cuando cambia el alcance.

31.18 Lista de revisión

Antes de cerrar la organización del modelo, conviene revisar:

• ¿Los paquetes tienen nombres claros?
• ¿Cada caso de uso está ubicado en un lugar lógico?
• ¿La vista general permite entender el sistema?
• ¿Los diagramas detallados son legibles?
• ¿Se evitaron duplicaciones innecesarias?
• ¿La organización ayuda a validar con usuarios?
• ¿La estructura facilita trazabilidad y mantenimiento?

31.19 Qué debes recordar de este tema

• Los paquetes ayudan a organizar casos de uso en sistemas grandes.
• Pueden agruparse por área funcional, actor, proceso o versión.
• La organización debe mejorar la comprensión, no agregar complejidad.
• Conviene usar una vista general y vistas detalladas.
• Los nombres de paquetes deben ser comprensibles para el negocio.
• Un diagrama gigante suele ser menos útil que varios diagramas claros.
• La organización facilita revisión, planificación y trazabilidad.

31.20 Conclusión

En sistemas grandes, organizar los casos de uso es tan importante como identificarlos. Una buena estructura permite mantener el modelo legible, facilitar la revisión y conectar los casos de uso con planificación, permisos y pruebas.

Los paquetes deben usarse como una herramienta de claridad. En el próximo tema estudiaremos la priorización de casos de uso.