40. Caso práctico: sistema de gestión de turnos

40.1 Introducción

En este tema aplicaremos lo aprendido sobre casos de uso a un sistema de gestión de turnos. El objetivo es pasar de una descripción general del problema a una lista ordenada de actores, casos de uso, reglas, flujos y validaciones.

El ejemplo se basa en una clínica o consultorio donde los pacientes solicitan turnos, el personal administra agendas y los profesionales consultan sus citas. Aunque el dominio es simple, permite trabajar con actores diferentes, restricciones reales y varios flujos alternativos.

40.2 Descripción del sistema

El sistema permitirá gestionar turnos médicos. Un paciente podrá solicitar, consultar o cancelar un turno. Una recepcionista podrá registrar pacientes, asignar turnos y modificar citas. Un profesional podrá consultar su agenda diaria. El sistema deberá evitar superposiciones y respetar los horarios disponibles.

Esta descripción inicial no es todavía un caso de uso. Es el punto de partida para identificar objetivos de usuario y delimitar el comportamiento esperado.

40.3 Límite del sistema

El sistema de gestión de turnos se encarga de registrar pacientes, administrar agendas, reservar horarios, cancelar turnos y consultar información. No se encarga de atender al paciente, realizar diagnósticos, cobrar una consulta ni administrar la historia clínica completa.

Definir este límite evita mezclar procesos externos con funcionalidades que realmente deben ser implementadas.

40.4 Vista general del caso práctico

La imagen representa el sistema de gestión de turnos como un límite central. Fuera del sistema se ubican los actores principales: Paciente, Recepcionista, Profesional y Administrador. Dentro del sistema aparecen los casos de uso más importantes: solicitar turno, cancelar turno, consultar agenda, registrar paciente y administrar disponibilidad.

40.5 Actores identificados

Los actores representan roles que interactúan con el sistema para lograr un objetivo.

• Paciente: solicita, consulta o cancela turnos.
• Recepcionista: registra pacientes y gestiona turnos en nombre de ellos.
• Profesional: consulta su agenda y la lista de pacientes citados.
• Administrador: configura profesionales, especialidades, horarios y disponibilidad.
• Sistema de notificaciones: recibe datos para enviar recordatorios o confirmaciones.

40.6 Casos de uso principales

A partir de los objetivos de los actores, podemos identificar los casos de uso principales:

• Solicitar turno.
• Cancelar turno.
• Consultar turno.
• Registrar paciente.
• Modificar datos del paciente.
• Consultar agenda del profesional.
• Administrar disponibilidad horaria.
• Enviar recordatorio de turno.

40.7 Caso de uso: Solicitar turno

Este es uno de los casos de uso centrales del sistema porque representa el objetivo más importante del paciente.

• Actor principal: Paciente.
• Objetivo: reservar un turno disponible con un profesional o especialidad.
• Precondición: existe disponibilidad cargada en la agenda.
• Resultado esperado: el turno queda registrado y asociado al paciente.

40.8 Flujo principal de Solicitar turno

1. El paciente ingresa al sistema.
2. El sistema muestra las especialidades disponibles.
3. El paciente selecciona una especialidad.
4. El sistema muestra profesionales y horarios disponibles.
5. El paciente selecciona un horario.
6. El sistema solicita confirmación.
7. El paciente confirma la reserva.
8. El sistema registra el turno y muestra el comprobante.

40.9 Flujos alternativos

• Horario no disponible: si otro usuario reservó el horario antes de confirmar, el sistema informa la situación y muestra nuevas opciones.
• Paciente no registrado: si el paciente no existe, el sistema solicita los datos mínimos para registrarlo.
• Cancelación durante la reserva: si el paciente abandona el proceso, el sistema no registra ningún turno.

40.10 Reglas de negocio

• No puede existir más de un turno para el mismo profesional en el mismo horario.
• Un paciente no puede tener dos turnos simultáneos.
• La cancelación puede requerir una anticipación mínima.
• Solo se pueden reservar horarios publicados como disponibles.
• Algunas especialidades pueden requerir derivación previa.

40.11 Caso de uso: Cancelar turno

El caso de uso Cancelar turno permite liberar un horario reservado. Puede ser iniciado por el paciente o por la recepcionista, según las reglas de la organización.

El resultado esperado es que el turno quede marcado como cancelado y que el horario vuelva a estar disponible si corresponde.

40.12 Caso de uso: Consultar agenda

El profesional necesita consultar su agenda para conocer los pacientes citados, los horarios y el estado de cada turno. Este caso de uso no tiene como objetivo modificar la agenda, sino visualizarla de manera clara.

Si el sistema permite filtrar por fecha, especialidad o estado, esos comportamientos pueden formar parte del mismo caso de uso o describirse como extensiones.

40.13 Caso de uso: Administrar disponibilidad

El administrador define los días, horarios, duración de turnos, profesionales y excepciones. Este caso de uso afecta directamente a Solicitar turno, porque determina qué opciones estarán disponibles para los pacientes.

Debe prestarse especial atención a feriados, ausencias, horarios especiales y cambios temporales.

40.14 Relación entre casos de uso

Algunos casos de uso se relacionan entre sí. Solicitar turno puede incluir la validación de datos del paciente. Cancelar turno puede disparar una notificación. Administrar disponibilidad condiciona los horarios que se muestran al solicitar un turno.

Estas relaciones ayudan a comprender dependencias, pero no deben usarse para complicar innecesariamente el modelo.

40.15 Tabla resumida

40.16 Errores frecuentes en este caso práctico

• Confundir al profesional con el sistema.
• Incluir tareas internas de programación como si fueran casos de uso.
• Olvidar reglas de superposición de horarios.
• No considerar cancelaciones, ausencias o cambios de agenda.
• Describir pantallas en lugar de objetivos del usuario.

40.17 Qué debes recordar de este tema

• Un caso práctico ayuda a conectar teoría con decisiones concretas de análisis.
• El sistema de turnos tiene actores con objetivos diferentes.
• Solicitar turno es un caso de uso central, pero depende de reglas y disponibilidad.
• Los flujos alternativos son esenciales para describir situaciones reales.
• El modelo debe ser claro antes de transformarse en diseño o código.

40.18 Conclusión

El sistema de gestión de turnos muestra cómo los casos de uso permiten ordenar necesidades reales de usuarios. Al identificar actores, objetivos, reglas y flujos, el equipo obtiene una base clara para diseñar, desarrollar y probar la solución.

Este ejemplo también demuestra que un buen caso de uso no se limita al flujo ideal. Debe contemplar excepciones, restricciones y resultados observables.