ANÁLISIS Y DISEÑO DE UN CASO DE USO

“Reasignar Citas”
A lo largo de este documento os voy a contar paso a paso cómo realizar el análisis y el
diseño del caso de uso de Reasignar Citas de un médico que hemos trabajado en el aula.

Flujo de Eventos
=============

Reasignar Citas - El médico da su número de colegiado e indica el día

para el que quiere cancelar sus citas.
Antes de cancelar una cita se intenta reasignar a otro
médico, siempre que tenga una cita NO ASIGNADA a la misma hora.
- Hay que generar un listado con todas las citas canceladas o
Medico
reasignadas (nombre del paciente, teléfono, fecha y hora cita,
y si se ha podido, el nombre del nuevo médico asignado)

Fig. 1 Caso de Uso - Reasignar Citas

Paciente Medico Cabecera

-dni : String -suPaciente 1
-numColegiado : int
-nss : String -nombre : String
-nombre : String -maxPacientes : int
-telefono : String 0..1 -suMedico

-tiene Cita *
-fechaYHora : Date
* -tiene

Fig. 2 Modelo del Dominio

Análisis
El primer paso es realizar el Diagrama de Colaboración. Para su realización, lo primero
que tenemos que hacer es tener claro qué vamos a representar. En el diagrama de
colaboración sólo se muestra uno de los diferentes caminos que haya en el flujo de
eventos del caso de uso. En este caso, vamos a realizar diagrama de colaboración del
Caso de Uso Reasignar Citas suponiendo que hay citas libres para la reasignación1.

Para poder hacer correctamente el diagrama de colaboración necesitamos saber qué

clases tenemos y cómo se relacionan entre ellas. Esa información nos viene dada en el
modelo de dominio. Partiendo del modelo de dominio superior, las clases que vamos a
utilizar son las siguientes:

1
En el enunciado nos dicen que cada médico ya tiene sus citas creadas, por lo que cada objeto tendrá una
lista de citas y las citas podrán tener paciente asignado o no (según si están libres u ocupadas)
En este caso se ha optado por implementar las relaciones entre Paciente y Cita y entre
Médico y Cita de manera doble. Esto es, el Paciente y el Médico tienen una ListaCitas,
y una Cita guarda la referencia tanto al Médico como al Paciente. Obviamente no es la
mejor solución para este caso de uso, pero así veremos el trabajo “extra” que supone
tomar una decisión errónea.
Comenzamos dibujando el actor
encargado de realizar el Caso de
Uso y una única clase frontera que
IU_RC
representará a todas las interfaces
gráficas involucradas en este Caso
Medico Cabecera de Uso

Sobre la clase frontera, vamos

indicando la interacción entre el
usuario y la interfaz.

Después del paso 1 tenemos el número de colegiado del médico, pero con eso no
podemos hacer nada. En orientación a objetos no vale con conocer el valor de un
atributo de un objeto, tenemos que conocer cual es la instancia concreta que tiene ese
valor. Para encontrar esa instancia, lo único que podemos hacer es ir preguntando uno a
uno a todos los objetos de tipo Médico a ver qué valor tienen en el atributo
NumColegiado, y cuando lo encontremos, ya sabremos sobre qué instancia concreta
queremos trabajar.
Para trabajar con los objetos, siempre usaremos un gestor como intermediario, nunca
tendremos operaciones que vayan desde la interfaz directamente a un objeto entidad.
Así que tenemos que tener un gestor (le llamaremos Gestor de Médicos, ya que va a
trabajar con la entidad llamada médicos) que nos ofrezca una operación, que lo que
haga sea ir buscando uno por uno en todos los objetos de tipo Médico y mirando a ver
qué valor tiene su atributo NumColegiado y esa operación devolverá como resultado, la
instancia de tipo médico que tiene ese número de colegiado. Los gestores que definamos
conocerán todas las instancias que existan de los objetos de aquella clase que gestionen.

Si tiene que buscar un valor

entre los objetos de tipo
médico, le tendremos que
decir qué valor tiene que
buscar

Iremos uno a uno por todos los objetos de tipo

médico. Esta operación no tendrá parámetros,
ya que cada objeto nos dará su número de
colegiado
Una vez que ya sabemos cual es el objeto de tipo médico con el que tenemos que
trabajar, necesitaremos obtener sus citas. Para ello haremos uso del atributo ListaCitas
que tienen los médicos. Pero realmente sólo nos interesan las citas de un médico en un
día concreto (en la fecha que ha introducido en el paso 1). Por lo tanto, y aprovechando
que yo decido qué hace cada operación y cómo funciona, voy a definirme una
operación ObtenerCitas, que dado un médico y una fecha, me devuelve una lista con las
citas de ese médico en esa fecha. Perfectamente podría haber decidido hacerlo de otra
manera y obtener todas las citas del médico, y luego filtrar las de la fecha concreta que
me interesan, o cualquier otra forma.
Lo que hay que tener en cuenta es que hay que ser consecuente con las decisiones
tomadas si mi operación ObtenerCitas me devuelve las citas de una fecha concreta,
además de ir al objeto médico y obtener su atributo ListaCitas, tendré que ir accediendo
a los objetos de esa lista y consultar su fecha para ver si tienen que formar parte del
resultado o no.

El paso 6 tiene que salir del

GestorMédicos, porque es ahí
donde está la operación
ObtenerCitas, y el paso 6 es una
parte de esa operación

Ya tenemos la lista de todas las citas que hay que reasignar (las de ese médico en ese
día). Ahora tal y como nos dice el flujo de eventos del caso de uso, tenemos que intentar
reasignarlas. Para ello el primer paso es buscar una cita el mismo día a la misma hora
que esté libre (recordad que lo primero que hemos decidido es que sí que iba a haber
citas libres para reasignar, pero aún así tendremos que hacer las operaciones para
buscarlas). ¿Cómo sabemos si una cita está libre? Porque no tiene un paciente asignado
en su atributo Paciente.
Por lo tanto, voy a definir una función BuscarCitaLibre, que dada una cita (de las que
hay que reasignar) obtiene otra cita libre el mismo día a la misma hora
 Esta operación se ejecuta
sobre la cita pasada como
parámetro, para saber qué
fecha y hora tenemos que
buscar en las citas libres

Esta operación se ejecuta

sobre cada cita existente para
ver si es el mismo día y a la
misma hora. Si lo es,
ejecutaremos el paso 10 para
ver si está libre

Una vez que ya he encontrado una cita libre el mismo día y a la misma hora, lo que
tengo que hacer es reasignar el paciente. Para ello voy a definir una operación
ReasignarCita, que dada la cita vieja y la nueva, reasigna al paciente de una a otra.

Para obtener la
referencia al paciente de
la cita vieja

Para dejar en la cita

nueva, la referencia a el
paciente

Trabajo Extra: Añadir la

nueva cita a la lista de
Citas del Paciente y
quitar la vieja (antes de
borrarla!)

Quitamos la cita vieja de

la lista de citas del
Médico
Por último necesito obtener la información necesaria para mostrar por pantalla todo lo
que me piden: nombre del paciente, teléfono, fecha y hora de la cita y el nombre del
nuevo médico. Para ello voy a crear una operación ObtenerDatos, que dada una cita me
obtiene los datos que necesito de esa cita.

Hay que saber a qué

objeto de tipo paciente
señala el objeto
CitaNueva

Cuando ya sé cual es el
objeto Paciente, obtengo
su nombre y su teléfono

Obtengo el objeto
Medico de la CitaNueva
y luego pregunto por el
nombre

Y con esto hemos finalizado el diagrama de colaboración del caso de uso Reasignar
Citas.
Diseño
Gracias al diagrama de colaboración hemos identificado qué operaciones nos hacen
falta y dónde tienen que estar, así que nuestro diagrama de clases (modelo del diseño)
quedaría como sigue.

Fig. 3 Modelo de Diseño

Ya tenemos una parte del diseño de un caso de uso, el diagrama de clases, ahora vamos
a realizar la otra parte, el diagrama de secuencia. En el diagrama de secuencia vamos a
representar exactamente cómo va a funcionar el caso de uso, qué operaciones se
ejecutan, dónde se ejecuta cada operación, si se repite, etc. Hay que tener en cuenta que
en el diagrama de secuencia se muestran todas las alternativas al flujo de eventos
principal, por lo que hay que ir indicando si esa parte del diagrama se ejecuta siempre o
sólo cuando se cumple una cierta condición.

Diagrama de Secuencia Orientado a Objetos

En este caso vamos a empezar por el diagrama de secuencia usando Orientación a

Objetos. Dicho diagrama es muy parecido al de colaboración y por eso lo usaremos
como base.
El primer paso del flujo de eventos, al igual que en el diagrama de colaboración, es que
el usuario introduzca su numero de colegiado y la fecha para la que quiere cancelar su
citas. Para ello representamos el actor, la interfaz donde va a introducir los datos e
indicamos el paso.

Ahora viene una de las diferencias entre el diagrama de secuencia y el de colaboración.

En éste último sólo representamos una interfaz para todo el caso de uso; en el de
secuencia representamos tantas interfaces como se necesiten dentro del caso de uso. Y
aunque en este enunciado no nos especificaban cuántas interfaces había, parece lógico
suponer que aquella donde el usuario introduce los datos y aquella en la que se le
muestran los resultados sean interfaces diferentes.
Así que basándonos en esa suposición, cuando el usuario introduce su número de
colegiado y la fecha, se abre otra interfaz que es la que lanza las operaciones necesarias
para obtener la información de las citas reasignadas, canceladas, etc. Y será desde esa
interfaz desde la que continuemos con las operaciones que nos indica el diagrama de
colaboración. A esta nueva interfaz, tendremos que pasarle como parámetros toda la
información que necesite para trabajar. En este caso, el número de colegiado y la fecha
que el usuario haya introducido en la interfaz anterior.

Otra diferencia con el diagrama de colaboración la encontramos en el paso 4. En el

diagrama de secuencia se indican las repeticiones (qué se repite y cuando se repite). De
esta manera representamos que la operación Buscar Médico del Gestor de Médicos lo
que hará es ir buscando uno a uno por todos los objetos de tipo MedicoCabecera y
consultar el valor de su atributo NumColegiado hasta que encuentre uno que coincida
con el valor que le han pasado como parámetro. Ese objeto será el que a partir de ahora
llamaremos elMédico, ya que es el médico concreto con el que queremos trabajar.
La siguiente diferencia viene a partir de la instrucción 12. En el diagrama de secuencia
se representan cada uno de los posibles flujos de eventos del caso de uso. Por eso en
este caso indicamos que hay una serie de operaciones, las que tienen una “a” cuya
ejecución depende del cumplimento de una condición (que se encuentre una cita libre el
mismo día a la misma hora). Las instrucciones 12a, 13a, etc. Sólo se ejecutarán si la
condición se cumple. Y si la condición no se cumple, no hay que hacer nada especial
por lo que no tenemos instrucciones alternativas (que numeraríamos seguidas de una
“b”).

Y por último tenemos las instrucciones de la 19 a la 24 que hay que ejecutarlas

independientemente de que se haya encontrado una cita libre o no. Es por eso que no
llevan ninguna letra. Estas instrucciones lo que hacen es obtener la información
necesaria para mostrar por pantalla. Como esa información es la misma tanto si la cita
se ha reasignado como si no, esas instrucciones no dependen de la condición.

El único cambio entre un caso y el otro sería que en si no se ha reasignado, los datos a
mostrar son los que contiene el objeto CitaVieja, mientras que si la cita ha sido
reasignada, esos datos son los de CitaNueva. Por lo tanto lo que cambiará será el
parámetro. Es por eso que he preferido representar que los datos se obtienen de un
objeto Cita genérico, porque a veces será CitaNueva y otras veces CitaVieja.

Diagrama de Secuencia usando Sistema de Gestión de BD

Para realizar el diagrama de secuencia usando Sistema de Gestión de Bases de Datos, lo

primero que tenemos que tener claro es qué tablas de la Base de Datos tenemos y cual
es el contenido y la forma de estas tablas. Esta información la sacamos del modelo del
dominio. En nuestro ejemplo esas tablas serían las siguientes:

Otra cosa a tener clara es que cuando estamos trabajando con Bases de Datos, el
diagrama de colaboración no nos sirve mas que como una pequeña guía que nos puede
decir cuales son los pasos a seguir, pero nada más. Si estamos trabajando con una Base
de Datos podemos hacer uso de todas las ventajas que nos ofrecen (trabajar con las
claves y no con referencias, posibilidad de unir tablas en una única consulta SQL, etc.).
Por eso el diagrama de secuencia usando SGBD no tiene porqué coincidir en los pasos
con el diagrama de colaboración.
En la operación 3 gracias a las posibilidades que nos ofrece SQL he obtenido casi todos
los datos que necesito para mostrar por pantalla posteriormente. Sólo falta obtener el
nombre del médico.

Al igual que en el diagrama anterior hay una serie de operaciones que sólo se ejecutarán
cuando se cumpla una condición: que haya una cita libre el mismo día a la misma hora.
Y también tenemos una serie de operaciones (de la 18 a la 21) que se van a ejecutar
tanto si hemos encontrado la cita libre o no, pero con una pequeña diferencia.

Si hemos encontrado una cita libre, el número de colegiado que usamos en la consulta
SQL del paso 18 será el número de colegiado que tenga esa cita libre y que lo habremos
obtenido en el paso 15a.

Si no hemos encontrado ninguna cita libre, el número de colegiado del paso 18 será el
que ha introducido el usuario en el primer paso. Por lo tanto, si lo necesitamos en el
paso 18 hay que hacerlo llegar hasta ahí de alguna manera. Esa manera es como un
parámetro de la operación 11. Si la operación 11 encuentra una cita libre, ese número de
colegiado no sirve para nada, pero si no se encuentra la cita libre lo necesitamos para
poder sacar el nombre del médico.