Caso de uso

Como en el artculo anterior, lo primero es hacer la descripcin de un caso de

uso que nos meta en materia, y nos ayude a entender cul es la funcionalidad
que tenemos que proporcionar (o, en este caso, una descripcin de los
procesos que tenemos que modelizar). Bueno, en realidad la descripcin que
hago es ms parecida a una historia de usuario de eXtreme Programming que
al caso de uso tpico de UML, pero nos entendemos
Si en el artculo anterior el actor principial del caso de uso es un alumno que
acude a la escuela, en este caso es el responsable formativo o Director of
studies (aqu hay una buena descripcin del puesto). Es la persona, en un
centro de formacin, encargada de la elaboracin de los horarios, la gestin de
las incidencias (que ahora veremos) y la asignacin de profesores y aulas a los
grupos que se formen.
Su necesidad es la de tener controlados todos los horarios del centro de
formacin. Es decir, tiene que poder saber dnde est cada profesor en todo
momento, qu clases no se han impartido y por qu y saber qu profesores hay
disponibles y qu aulas estn libres en un momento determinado.
Tambin necesita saber cuntas horas ha trabajado cada profesor en un mes y
cuntas horas un profesor tena que haber trabajado, y el motivo de las
cancelaciones.
As, el director de estudios (DOS, de aqu en adelante) recibe la peticin de
formar un grupo nuevo para uno de los cursos definidos en el ejemplo anterior,
porque se han matriculado muchos alumnos y no hay plazas suficientes. El
DOS entonces primero decide el horario que tendr el grupo. En el caso de este
ejemplo, el curso para el que hay que crear el grupo define 3 horas por semana
(es lo que se llama un curso extensivo), que se impartirn Lunes, Mircoles y
Viernes de 19:00 a 20:00. Con esta informacin definida, el DOS necesita
buscar un profesor que est disponible en ese horario, y un aula que tambin
lo est. Una vez localizada toda la informacin necesaria para montar el
horario, hay dejar anotado el nombre de los alumnos que asistirn a este
grupo.
Con toda esta informacin definida, el grupo puede empezar. Normalmente, se
le proporciona al profesor a principio de mes una hoja de asistencia, que es
un informe en el que se detallan el horario de cada grupo con sus alumnos,
para que el profesor pueda hacer un seguimiento de la asistencia de los
alumnos y de las incidencias que puedan aparecer.
Una vez el grupo ha comenzado, y los alumnos estn asistiendo a clase, al
director de estudios se le pueden presentar varias situaciones que tiene que
manejar:
1. El grupo cambia de profesor, de horario o de aula. Quiz porque el
profesor se vaya de la empresa o por la razn que sea, de vez en cuando
hay que cambiar el profesor de un grupo. Sin embargo, a la hora de

aplicar este cambio es importante tener en cuenta que debemos

mantener la informacin histrica. Es decir, cuando haya un cambio de
horario debemos saber qu profesor haba antes y cul hay ahora, y
cundo se produjo el cambio. Para el clculo de total de horas
trabajadas, es imprescindible.
2. Entran alumnos nuevos, u otros dejan el grupo, cuando los
alumnos se dan de alta y se incorporan al grupo, o quiz cuando un
alumno cambia de grupo porque el horario le viene mejor. Como en el
caso anterior, tendramos que saber por qu grupos ha pasado el
alumnos y cundo se ha incorporado a cada grupo.
3. Una clase no se imparte, por ejemplo porque el profesor se ha puesto
enfermo y no se ha encontrado sustituto a tiempo, o porque el centro
estaba cerrado. En este caso, tenemos que saberlo, porque el n de
horas trabajadas por el profesor tendr que cambiar, y hay algunos
casos (cuando se ha contratado un n de horas de formacin concreto)
en los que esa clase debe recuperarse en otro momento, ya sea otro da
de la semana o quiz alargando la duracin del grupo un poco.
4. Un profesor sustituye a otro. Es el caso en el que un profesor se pone
enfermo, o se ha cogido un da libre, y otro profesor le sustituye. En este
caso tenemos que saber quin tena que dar la clase (ha impartido una
hora menos) y quin ha dado la clase en realidad (hay impartido una
hora ms).
5. Un grupo se cierra. Se dan de baja todos los alumnos o (lo que es ms
comn), se dan de baja tantos alumnos que no compensa mantener el
grupo abierto, as que se renen dos grupos con pocos alumnos y se
crea un grupo con un n de alumnos ms acorde con las necesidades
tanto del centro como de los propios alumnos.
Descripcin de las entidades
Despus de la descripcin del proceso, detallo las entidades (tablas) que
utilizamos para m0delizarlo:

Cursos: podis ver la descripcin en el artculo anterior.

Profesores: el personal que imparte las clases.

Grupos: La oferta de horarios y das entre los que los alumnos pueden
elegir para asistir a clase, dentro de cada curso.

Horarios: Dentro de cada grupo, tenemos que almacenar su horario

(que puede tener una estructura compleja, por ejemplo: Lunes y
Mircoles de 19:00 a 20:00 y Viernes de 13:00 a 14:00, es ms comn
de lo que parece). Adems, hay que almacenar el historial de horarios
por los que ha pasado el grupo, incluyendo los profesores.

Clases: Cada uno de los das de clase dentro del horario del grupo. Por
ejemplo, si tenemos un horario Lunes de 19:00 a 20:00, entre el 1 y el
30 de Abril, tendr que haber un registro para cada Lunes entre esas dos
fechas, para que despus podamos gestionar si las clases se han
impartido o no, cada una por separado.

Tipos de tarea: Hay situaciones en las que es conveniente diferenciar

qu se hace en los horarios del grupo. Podemos tener grupos de
formacin, como los que se describen en todo el artculo, pero tambin
podemos tener grupos que gestionen las tareas administrativas de los
profesores (preparacin de clases, etc.) o incluso la agenda del personal
no docente, simplemente diferenciando por tipo de tarea.

Tipos de cancelacin: Necesitamos saber cuando una clase no se

imparte, as que nos har falta una gestin de motivos de cancelacin, y
por tanto una entidad que los defina.

Alumnos: ya la vimos en el artculo anterior.

Alumnos en grupos: Tenemos que almacenar la informacin de qu

alumnos estn apuntados a qu grupos y, adems, nos hace falta saber,
segn el caso de uso, cundo entr y cundo sali cada alumno de su
grupo.

Asistencia: Para cada una de las clases, tenemos que saber qu

alumnos estaban apuntados a ella, y para cada uno de ellos, si asisti a
clase o no.

Grficamente:

Con PK se marcan las claves primarias, y con FK, las claves ajenas algunas
lneas se cruzan, no lo puedo evitar. Las flechas indican que una tabla es hija
de otra, con la punta de flecha apuntando al padre.
Como podis ver, slo estn indicados los campos que forman el modelo de
datos las claves primarias y las claves ajenas, que en cualquier caso deben
estar ocultas al usuario final. En la siguiente seccin describiremos los campos
de cada tabla.
Campos
Como siempre, slo pongo los campos que considero ms relevantes para la
descripcin del modelo de datos, y no repito los campos de clave ajena para

las relaciones, que ya estn descritos en el grfico. La definicin de cursos y

grupos es la misma que en la que hay en el artculo de matriculacin:
Cursos

nombre: varchar(100)

descripcion: Memo. Se utilizar, en el contrato que se imprime para el

cliente, para hacer una descripcin larga del curso en el que el alumno
se est matriculando. En uno de los sistemas que tenemos, en lugar de
tener un campo memo, tenemos una tabla separada en la que se
guardan, por tipologas, distintos campos memo, que se imprimen en
distintos lugares del contrato.

fecha_inicio: date

fecha_fin: date

Profesores

nombre, primer_apellido, segundo_apellido: varchar(100)

nombre_completo: es una costumbre crear un campo calculado que

almacene el nombre completo del profesor. As, las bsquedas se hacen
sobre este campo y es ms fcil encontrar al profesor en cuestin.

direccin: Memo

telefono, telefono_movil: varchar(50). No os quedis cortos con el

tamao de los campos, ms vale pasarse que dejarlo con 9 dgitos y
descubrir que tienes que poner el +34 delante para poder mandar SMS
despus.

NIF_NIE, Pasaporte: en campos separados

Grupos

nombre: varchar(100)

codigo: varchar(20). Siempre viene bien tener una codificacin adems

del nombre. Por ejemplo, en algunos sistemas lo utilizamos para guardar
el cdigo del grupo en la Fundacin Tripartita.

fecha_inicio: date

fecha_fin: date. Por defecto, las del curso al que pertenece el grupo, y
adems estas fechas no pueden estar fuera de las fechas del curso al
que pertenecen.

lugar: varchar(100) de imparticin del grupo. En general, hacemos una

gestin de aulas, pero eso lo ampliar en otro artculo.

notas: memo, del grupo

horario: varchar(100) del grupo. En realidad, el horario se trata como

una tabla por debajo de esta, pero no voy a entrar en tanto nivel de
detalle ahora.

maximo_alumnos: Integer. Mximo nmero de alumnos permitidos en el

grupo.

numero_alumnos: Integer. Es el nmero de alumnos existentes en el

grupo. Este campo es de slo lectura para el usuario, y es calculado, a
travs de una serie de Triggers en la base de datos, para poder saber
rpidamente el nmero de alumnos activos en cada grupo sin tener que
estar sumando.

Horarios

fecha_inicio, fechafin : date. Por defecto, sern las del grupo con el que
estamos trabajando, pero si cambiamos de horario a mitad del grupo,
habr que cerrar el horario anterior (cambiar fecha_fin) y crear un
horario nuevo.

L,M,X,J,V: Boolean. Aqu hay dos formas de hacerlo puedes poner

campos booleanos para cada da de la semana, y si el horario tiene L =
s y X = s, entonces el horario es Lunes y Mircoles, o poner un campo
da de tipo entero y tener un registro de horario para cada da de la
semana. Me inclino por la primera solucin, que hemos utilizado en
nuestro sistemaAtenea que por la segunda, que es la que utilizamos
en Bravo. Los das de la semana no son algo que vaya a cambiar, y el
interface y la forma de mostrar el horario es ms fcil de implementar y
ms intuitivo para el usuario cuando usas una sla fila que cuando tienes
3 para el mismo horario.

hora_inicio, hora_fin: Time

id_profesor: por defecto, es el profesor definido como profesor del grupo,

pero podemos tener la situacin en la que haya dos profesores en el
mismo grupo (como pasa muy a menudo con los seminarios y los cursos
intensivos).

id_tipo_tarea: Integer. Es el tipo de tarea por defecto que tendrn todas

las clases del horario. Tambin existe la posibilidad de poner un tipo de
cancelacin por defecto, como hemos hecho en Atenea. Lo vemos ms
abajo, en las clases.

Clases

fecha: Date. A estas alturas, ya no tenemos fecha de inicio y fecha de

fin esto es ya cada uno de los das de clase individuales, y por tanto lo
que hay es una fecha

hora_inicio, hora_fin: Time. Por defecto sern las del horario al que
pertenece la clase. Estn tambin en la tabla de clases porque eso te

permite gestionar excepciones, del tipo que la clase de hoy dura media
hora ms para recuperar parte de una clase anterior que se cancel,
cosas as.

id_tipo_tarea: el tipo de tarea del horario, por defecto. Igual que antes,
est replicado en esta tabla para permitir excepciones.

id_tipo_cancelacion: Tenemos dos formas de proceder podemos definir

un tipo de cancelacin por defecto, que ser el que tengan todas las
clases (nosotros utilizamos clase impartida, para indicar que no ha
habido cancelacin), o tambin podemos poner el tipo de cancelacin en
el horario, de forma que todas las clases de ese horario tendrn ese tipo
de cancelacin y luego nosotros cambiamos el tipo de cancelacin para
las clases que no se imparten.

Notas pedaggicas: Memo. Suele ser buena idea poner un campo de

notas pedaggicas que, el profesor, al rellenar la asistencia (lo vemos
ms abajo) puede completar. Esto hace que, cuando un profesor tiene
que hacerse cargo de un grupo que ya ha empezado, puede leer las
notas que dej el otro profesor (lo que se llama el Class Record) y
saber por dnde van y qu es lo siguiente que hay que hacer.

Tipos de Tarea

nombre: varchar(100)

lectiva, transporte, administrativa : boolean. Con estos campos podemos

sumar despus fcilmente las horas segn los tipos de tarea. Por
ejemplo, podemos tener un tipo de tarea Horas lectivas y otra Horas
lectivas en Sbado, que se pagan de distinta forma y queremos tener
controladas, pero sin embargo todas son horas lectivas, y a la hora
calcular totales de horas, las queremos agrupadas.

Tipos de cancelacin

Nombre : varchar(100)

clase_impartida: boolean. As podemos tener distintos tipos de

cancelacin que indican que la clase no se ha impartido, y luego sumar
todas juntas para saber cuntas horas se han impartido y cuntas no.

implica_pago_profesor: Segn el tipo de cancelacin y el convenio, hay

tipos de cancelacin que, aunque no cuenten como clase impartida, s
que se van a pagar al profesor.

implica_cobo_cliente: En el caso de los grupos para empresa o en los

individuales, normalmente se factura por horas (lo veremos en el artculo
sobre facturacin), y en estos casos se da la circunstancia de que las
cancelaciones no son slo por parte del profesor o del centro de
formacin: en estos casos, es posible (de hecho, es lo ms comn) que
sea el cliente el que cancele la clase. Normalmente, se definen en este

caso dos tipos de cancelacin: Cancelacin en plazo, que es cuando el

cliente ha avisado de que no va a darse la clase, y entonces no se le
factura, o Cancelacin fuera de plazo, que es el caso tan tpico en el
que el profesor se presenta y no hay nadie a quin darle clase. En este
caso, normalmente, la clase se factura aunque no haya sido impartida,
pero es importante para el DOS saber qu clases han sido canceladas de
esta manera. A final de curso, cuando se evala el avance del alumno,
es importante tener en cuenta a cuntas clases el alumno ha acudido
realmente, no cuntas se le ha facturado al cliente.
Alumnos

nombre: varchar(100). Lo mismo que en clientes, pero lo requerido es

nombre y primer apellido (en clientes es slo nombre por si

primer_apellido: varchar(100)

segundo_apellido: varchar(100)

nombre_completo: varchar(300):

etc. de datos personales (profesin, telfonos, email, etc.)

Alumnos en grupos

fecha_inicio: date

fecha_fin: date. Suele ser una interseccin entre la duracin del grupo y
la de la matrcula, pero cuando el alumno cambia de grupo, para una
matrcula puede haber varios registros de alumnos en grupos. Hay que
tener en cuenta tambin la posibilidad de que en un mismo curso,
pagando ms, un alumno pueda asistir a varios grupos (esto tambin lo
he visto).

Asistencia

asiste: boolean. Normalmente, cuando se crean los registros de

asistencia (que se crean automticamente cuando se crean las clases),
el campo asiste est inicializado a NULL, para que as sepamos que esta
informacin todava no est disponible. Ser el profesor cuando
introduzca la asistencia el que indique si el alumno asiste o no. Mientras
tanto no se sabe.

falta_justificada: boolean. Todo el proceso que est definido en este

artculo se basa en la idea de que la asistencia de los alumnos y la
cancelacin de una clase son cosas separadas, porque la gestionan
personas separadas. La informacin de cancelacin de clases implica
que se indique el motivo de dicha cancelacin, y dicha informacin va a
afecta a la facturacin al cliente y al pago a los profesores, y por tanto
es responsabilidad del DOS. La informacin de asistencia de los alumnos
tiene valor desde el punto de vista acadmico (para calcular los

porcentajes de asistencia de los alumnos a la hora de evaluar el

rendimiento) y se usa en conjuncin con la informacin de calificaciones.
Como actualizar esta informacin es muy trabajoso por el volumen de
datos que representa, los sistemas en general estn pensados para que
sean los profesores los que introduzcan esta informacin. Como la
informacin de cancelaciones puede afectar directamente a sus pagos,
los profesores no la introducen directamente en el sistema. Por tanto,
que todos los alumnos tengan asiste = NO no implica que la clase est
cancelada es lo tendr que introducir el DOS, incluyendo el motivo.
Triggers y procedimientos almacenados
Este proceso, como hemos visto por la definicin de las tablas, tiene muchos
procesos automticos, propios de la base de datos. Principalmente:

Al crear un horario, tiene que haber un trigger que inserte en la base de

datos todas las clases de ese horario, teniendo en cuenta la fecha de
inicio y de fin y los das de clase, e incluyendo la gestin de das no
lectivos si la hemos hecho.

De la misma forma, necesitamos un trigger que al crear clases o incluir

alumnos en grupos inserte en la base de datos los registros de asistencia
de los alumnos y las clases a los que pertenecen.

Es muy importante que estos dos procesos estn incluidos en la base de

datos El trabajo principal de los DOS, y la fuente principal de informacin de
produccin en la empresa es esta parte, y por tanto es muy importante que
estos procesos sean giles. En las primeras versiones de Bravo, este proceso
sea haca en el lado cliente del sistema, y el rendimiento dejaba muchsimo
que desear.
Consideraciones finales
Creo que ms o menos es todo es muy importante que seamos conscientes
de que esta gestin de horarios es muy detallada, y que por tanto implica
mucha gestin para mantenerla al da: adems de dar de alta los grupos, hay
que mantener los cambios de profesor y ser muy preciso con las fechas de
modificacin, hay que introducir las cancelaciones, la asistencia de los
alumnos implica muchas horas de trabajo mantenerlo al da. A la hora de
hacer una implementacin como esta, hay que valorar los beneficios que
reporta. Al principio del artculo he hablado que este modelo est pensado para
centros de enseanza de idiomas, lo cual no es del todo exacto. Este modelo
est pensado para organizaciones que necesitan saber el nmero exacto de
horas que se han trabajado en un periodo de tiempo dado, ya sea para facturar
al cliente (como ocurre en los centros de idioma, en los departamentos de
enseanza para empresas) como para pagar al personal.
No he hablado de la gestin de los contratos de los profesores, o del proceso
de facturacin mismo, que incluir en otros artculos, ni he descrito la manera
de obtener informes de totales de horas (que se basa simplemente en sumar la

duracin de las clases en base a los criterios de fechas, tipos de cancelacin,

tareas, profesores, etc. que se necesiten)