36. Casos de uso y diseño de clases, servicios y componentes

36.1 Introducción

Los casos de uso pertenecen principalmente al análisis funcional: describen qué necesita lograr un actor y cómo debe responder el sistema. El diseño de clases, servicios y componentes pertenece a la solución técnica: define cómo se organizará internamente el software para cumplir ese comportamiento.

Ambos niveles están relacionados, pero no son lo mismo. Un caso de uso no debe convertirse en una descripción de clases, tablas o servicios internos. Sin embargo, sí aporta información muy valiosa para tomar decisiones de diseño.

En este tema veremos cómo los casos de uso pueden orientar el diseño sin reemplazarlo.

36.2 Del análisis al diseño

El análisis responde qué debe hacer el sistema. El diseño responde cómo se organizará la solución para hacerlo. Los casos de uso se ubican como puente entre ambos mundos.

Por ejemplo, si el caso de uso Solicitar turno indica que el sistema debe validar disponibilidad, registrar una reserva y enviar una confirmación, el diseño deberá contemplar responsabilidades para buscar horarios, crear reservas, aplicar reglas y comunicarse con un servicio de notificaciones.

36.3 Qué información aporta un caso de uso al diseño

Un caso de uso aporta:

• Objetivo funcional.
• Actores y sistemas externos.
• Datos de entrada y salida.
• Reglas de negocio.
• Flujo principal y variantes.
• Excepciones y recuperación.
• Requisitos no funcionales relevantes.
• Necesidades de auditoría, seguridad o integración.

Estos elementos ayudan a identificar responsabilidades, interfaces y componentes necesarios.

36.4 Del caso de uso a elementos de diseño

El caso de uso orienta el diseño al mostrar qué responsabilidades deben existir. A partir de sus pasos, reglas, datos e integraciones pueden identificarse clases del dominio, servicios de aplicación, componentes de infraestructura e interfaces con sistemas externos.

36.5 Clases del dominio

Las clases del dominio representan conceptos importantes del negocio. Se descubren a partir del modelo de dominio y de los casos de uso.

En un sistema de turnos, podrían aparecer clases como:

• Paciente.
• Profesional.
• Agenda.
• Turno.
• Especialidad.
• Sede.

Estas clases no se definen solo porque aparezcan sustantivos en un texto, sino porque representan conceptos relevantes con reglas y relaciones propias.

36.6 Servicios de aplicación

Un servicio de aplicación coordina pasos para cumplir un caso de uso. No debería contener todos los detalles del negocio si esos detalles pertenecen a clases del dominio, pero puede orquestar la operación.

Por ejemplo, un servicio SolicitudDeTurnoService podría coordinar la búsqueda de disponibilidad, la validación de reglas, la creación del turno y el envío de confirmación.

36.7 Componentes

Un componente agrupa responsabilidades relacionadas y puede corresponder a una parte más grande del sistema. Por ejemplo:

• Componente de gestión de turnos.
• Componente de agendas.
• Componente de notificaciones.
• Componente de seguridad.
• Componente de reportes.

Los paquetes de casos de uso pueden sugerir componentes, aunque no siempre coinciden exactamente.

36.8 Interfaces con sistemas externos

Cuando un caso de uso menciona actores secundarios que son sistemas externos, el diseño debe considerar interfaces o adaptadores para comunicarse con ellos.

Ejemplos:

• Servicio de mensajería para enviar confirmaciones.
• Sistema de cobertura médica para validar autorizaciones.
• Pasarela de pago para confirmar operaciones.
• Sistema contable para informar facturación.

36.9 Reglas de negocio en el diseño

Las reglas de negocio identificadas en los casos de uso deben ubicarse en el diseño de forma coherente. Algunas reglas pueden estar en clases del dominio, otras en servicios de aplicación o políticas específicas.

Por ejemplo, la regla "un profesional no puede tener dos turnos en el mismo horario" debe implementarse en un lugar central y probado, no repetirse de manera desordenada en varias pantallas.

36.10 Datos de entrada y salida

Los datos de entrada y salida del caso de uso ayudan a diseñar objetos de transferencia, formularios, respuestas de servicios o contratos de API.

Por ejemplo, Solicitar turno puede requerir un comando o solicitud con paciente, especialidad, profesional opcional, fecha y horario seleccionado. También puede devolver una respuesta con código de reserva, fecha, hora y estado.

36.11 Excepciones y diseño robusto

Las excepciones documentadas en el caso de uso ayudan a diseñar respuestas robustas. Si el horario ya no está disponible, el diseño debe contemplar cómo detectar esa situación y cómo informar una respuesta adecuada.

Si un servicio externo no responde, el diseño debe decidir si reintenta, registra pendiente, cancela la operación o muestra un mensaje específico.

36.12 Requisitos no funcionales y arquitectura

Los requisitos no funcionales asociados a casos de uso pueden influir fuertemente en la arquitectura. Por ejemplo, requisitos de rendimiento, disponibilidad, seguridad o auditoría pueden modificar decisiones técnicas.

Si Solicitar turno debe soportar muchas reservas simultáneas, el diseño debe considerar concurrencia y consistencia. Si maneja datos sensibles, debe contemplar permisos y privacidad.

36.13 Ejemplo aplicado a Solicitar turno

Un caso de uso Solicitar turno podría orientar este diseño:

36.14 No diseñar demasiado pronto

Aunque los casos de uso orientan el diseño, no conviene introducir decisiones técnicas antes de entender el comportamiento. Si el análisis se llena de nombres de clases, tablas o frameworks, puede perder claridad para los usuarios.

Primero se debe comprender qué debe hacer el sistema. Luego se decide cómo organizar la solución.

36.15 No derivar clases mecánicamente

No todo sustantivo de un caso de uso debe convertirse en clase. Algunos términos son datos simples, estados, mensajes, filtros o detalles temporales.

El diseño requiere criterio: se crean clases cuando representan conceptos con identidad, comportamiento, reglas o relaciones importantes.

36.16 Casos de uso y responsabilidades

Una forma útil de pasar del caso de uso al diseño es identificar responsabilidades. Por ejemplo:

• Buscar disponibilidad.
• Validar reglas de reserva.
• Crear turno.
• Registrar auditoría.
• Enviar confirmación.
• Responder ante conflicto de horario.

Luego el diseño decide qué clases, servicios o componentes asumen esas responsabilidades.

36.17 Errores frecuentes

Al relacionar casos de uso y diseño, suelen aparecer estos errores:

• Convertir el caso de uso en una descripción técnica interna.
• Derivar clases automáticamente desde cada sustantivo.
• Ignorar reglas de negocio al diseñar servicios.
• No considerar excepciones y recuperación.
• Olvidar actores secundarios que implican integraciones.
• Diseñar componentes solo por capas técnicas y no por responsabilidades funcionales.
• No actualizar el diseño cuando cambia el caso de uso.

36.18 Lista de revisión

Antes de pasar de casos de uso a diseño, conviene revisar:

• ¿El caso de uso tiene flujo principal claro?
• ¿Están identificadas reglas de negocio?
• ¿Se conocen datos de entrada y salida?
• ¿Hay actores secundarios o sistemas externos?
• ¿Se documentaron excepciones relevantes?
• ¿Existen requisitos no funcionales que afecten el diseño?
• ¿Las responsabilidades principales están claras?

36.19 Qué debes recordar de este tema

• Los casos de uso describen comportamiento funcional.
• El diseño define cómo se organizará la solución técnica.
• Los casos de uso revelan responsabilidades, datos, reglas e integraciones.
• No deben mezclarse detalles de implementación dentro de la especificación funcional.
• Las clases del dominio surgen del análisis del dominio, no de convertir sustantivos mecánicamente.
• Los servicios pueden coordinar pasos de un caso de uso.
• Los requisitos no funcionales pueden influir en componentes y arquitectura.

36.20 Conclusión

Los casos de uso son una entrada fundamental para el diseño, porque explican qué comportamiento debe soportar el sistema. A partir de ellos se identifican responsabilidades, datos, reglas, integraciones y escenarios que la solución técnica debe cubrir.

La clave es mantener separados análisis y diseño, pero conectados. En el próximo tema estudiaremos cómo derivar casos de prueba desde casos de uso.