29. Caso práctico: modelado UML de un sistema de gestión de turnos

29.1 Introducción

En este tema aplicaremos los diagramas UML estudiados a un caso práctico: un sistema de gestión de turnos médicos. El objetivo no es construir todos los diagramas posibles, sino seleccionar las vistas más útiles para comprender el sistema desde distintas perspectivas.

El caso permitirá revisar alcance funcional, conceptos principales, flujos de trabajo, interacciones, estados, componentes y despliegue. Cada diagrama responde una pregunta distinta y, en conjunto, ofrece una visión más completa del sistema.

29.2 Descripción del sistema

El sistema permite que pacientes soliciten turnos con profesionales médicos. También permite consultar disponibilidad, cancelar turnos, administrar profesionales, configurar agendas y enviar notificaciones de confirmación o recordatorio.

El sistema puede ser usado por pacientes, recepcionistas, médicos y administradores. Además, puede integrarse con un servicio externo de notificaciones para enviar correos o mensajes.

29.3 Vista general del modelado UML

El modelado del sistema de turnos puede organizarse en varias vistas. Los casos de uso muestran actores y funcionalidades. El diagrama de clases muestra conceptos centrales. El diagrama de actividades describe el flujo para solicitar un turno. El diagrama de secuencia muestra la colaboración interna. El diagrama de estados muestra el ciclo de vida de un turno. Los diagramas de componentes y despliegue representan arquitectura e infraestructura.

29.4 Alcance funcional

El primer paso es definir qué funcionalidades principales ofrece el sistema. En este caso, algunas funcionalidades son Solicitar turno, Consultar turnos, Cancelar turno, Gestionar profesionales, Configurar agenda, Registrar atención y Enviar recordatorio.

Esta vista permite acordar el alcance inicial sin entrar en detalles de clases, bases de datos o infraestructura.

29.5 Actores principales

Los actores principales del sistema pueden ser:

• Paciente: solicita, consulta o cancela turnos.
• Recepcionista: registra turnos para pacientes y consulta agendas.
• Médico: consulta su agenda y registra atención.
• Administrador: gestiona profesionales, especialidades y horarios.
• Sistema de notificaciones: envía confirmaciones y recordatorios.

29.6 Diagrama de casos de uso

El diagrama de casos de uso debería mostrar a los actores externos y las funcionalidades principales dentro del límite del sistema. Para este caso, el límite podría llamarse Sistema de gestión de turnos.

El Paciente se relaciona con Solicitar turno, Consultar turno y Cancelar turno. El Administrador se relaciona con Gestionar profesionales y Configurar agenda. El Médico se relaciona con Consultar agenda y Registrar atención.

29.7 Conceptos principales del dominio

Antes de diseñar clases técnicas, conviene identificar conceptos importantes del dominio. Algunos conceptos son Paciente, Profesional, Especialidad, Agenda, Turno, HorarioDisponible, Consultorio y Notificación.

Estos conceptos forman la base para un diagrama de clases conceptual. Ayudan a comprender qué información maneja el sistema y cómo se relacionan los elementos principales.

29.8 Diagrama de clases conceptual

Un modelo conceptual puede indicar que un Profesional pertenece a una Especialidad, que una Agenda corresponde a un Profesional, que una Agenda contiene horarios disponibles y que un Turno vincula Paciente, Profesional, fecha, hora y estado.

En este nivel no es necesario incluir controladores, repositorios ni detalles de base de datos. El objetivo es comprender el dominio del problema.

29.9 Multiplicidades importantes

Las multiplicidades ayudan a expresar reglas. Un Profesional puede tener una o varias Agendas. Un Paciente puede tener cero o muchos Turnos. Cada Turno pertenece a un Paciente y se asigna a un Profesional. Una Especialidad puede tener muchos Profesionales.

Estas reglas deben validarse con el contexto real. Por ejemplo, puede existir una regla que impida reservar dos turnos en el mismo horario para el mismo profesional.

29.10 Diagrama de actividades: solicitar turno

El flujo de Solicitar turno puede comenzar con seleccionar especialidad, elegir profesional, consultar disponibilidad, seleccionar horario, confirmar datos y registrar turno. Si no hay disponibilidad, el sistema informa la situación y permite cambiar criterios de búsqueda.

Este diagrama permite ver pasos, decisiones y caminos alternativos. También puede incluir carriles para Paciente y Sistema.

29.11 Diagrama de secuencia: reservar turno

Una secuencia de diseño puede incluir participantes como InterfazTurnos, ControladorTurnos, ServicioTurnos, RepositorioTurnos y ServicioNotificaciones. El flujo puede comenzar cuando la interfaz solicita reservar un turno al controlador.

El controlador delega en el servicio, el servicio valida disponibilidad, guarda la reserva y solicita enviar confirmación. Esta vista ayuda a revisar responsabilidades internas.

29.12 Diagrama de estados: ciclo de vida del turno

El objeto Turno puede pasar por estados como Disponible, Reservado, Confirmado, Cancelado, Atendido y Ausente. Las transiciones dependen de eventos como reservar, confirmar, cancelar, registrar atención o registrar ausencia.

Este diagrama es útil para validar reglas. Por ejemplo, puede definirse que un turno Atendido no puede cancelarse, o que un turno Cancelado libera el horario correspondiente.

29.13 Diagrama de componentes

Una vista de componentes puede incluir Aplicación web, API de turnos, Servicio de usuarios, Servicio de agenda, Servicio de notificaciones y Base de datos. También puede aparecer un proveedor externo de correo o mensajería.

Este diagrama ayuda a comprender módulos de software, interfaces y dependencias entre servicios.

29.14 Diagrama de despliegue

Una vista de despliegue puede mostrar el navegador del usuario, un servidor web, un servidor de aplicación o contenedor, un servidor de base de datos y un servicio externo de notificaciones. Las conexiones pueden indicar protocolos como HTTPS o una conexión interna a la base de datos.

Este diagrama ayuda a discutir dónde se ejecuta cada parte y qué dependencias de infraestructura existen.

29.15 Coherencia entre vistas

Los nombres deben mantenerse coherentes. Si el concepto central se llama Turno, no conviene alternar entre Turno, Reserva y Cita sin aclaración. Si el estado Cancelado aparece en el diagrama de estados, los flujos y secuencias deben contemplar cómo se llega a ese estado.

La coherencia evita que cada diagrama cuente una versión distinta del sistema.

29.16 Selección de diagramas mínimos

Para un primer modelo del sistema, podría alcanzar con cuatro diagramas: casos de uso para alcance, clases conceptual para conceptos principales, actividades para el flujo de solicitar turno y estados para el ciclo de vida del turno.

Si el proyecto avanza hacia diseño técnico, se pueden agregar secuencia, componentes y despliegue. La cantidad de diagramas debe crecer según la necesidad real de comprensión y comunicación.

29.17 Posible conjunto de diagramas

29.18 Criterios de revisión

• ¿Los actores y casos de uso representan el alcance esperado?
• ¿El modelo conceptual usa nombres del dominio?
• ¿Las multiplicidades expresan reglas válidas?
• ¿El flujo de actividades contempla alternativas importantes?
• ¿La secuencia distribuye responsabilidades de manera razonable?
• ¿El diagrama de estados cubre cambios válidos e inválidos del turno?
• ¿Los componentes y el despliegue son coherentes con la solución propuesta?

29.19 Errores frecuentes

• Intentar representar todo el sistema en un único diagrama.
• Mezclar modelo conceptual con diseño técnico sin aclaración.
• Usar nombres distintos para el mismo concepto central.
• Olvidar caminos alternativos, como falta de disponibilidad o cancelación.
• No modelar el ciclo de vida del turno aunque sus estados sean importantes.
• Crear componentes sin responsabilidad clara.
• Agregar diagramas que no responden a ninguna pregunta del caso.

29.20 Qué debes recordar de este tema

• Un caso práctico puede requerir varios diagramas complementarios.
• Cada diagrama debe responder una pregunta específica.
• Los casos de uso ayudan a definir alcance funcional.
• El diagrama de clases conceptual ayuda a comprender el dominio.
• Actividades, secuencias y estados ayudan a comprender comportamiento.
• Componentes y despliegue ayudan a representar arquitectura e infraestructura.
• La coherencia entre nombres, reglas y responsabilidades es fundamental.

29.21 Conclusión

El sistema de gestión de turnos muestra cómo UML permite representar un mismo problema desde varias vistas. No se trata de dibujar por dibujar, sino de elegir diagramas que ayuden a comprender alcance, estructura, comportamiento, interacción y arquitectura.

En el próximo tema realizaremos un trabajo integrador para construir un conjunto coherente de diagramas UML.