Memoria Fergus

Proyecto Final de Carrera
Ingenierı́a Informática
Curso 2008-2009
Gestión global y obtención automática de los

horarios de un Máster
Fergus Reig Gracia
Junio de 2009
Director: Eduardo Mena Nieto
Departamento de Informática e Ingenierı́a de Sistemas

Centro Politécnico Superior
Universidad de Zaragoza
A mis abuelos, tı́os y tı́as, primas y primo y a Marı́a.
El sudor ahorra sangre, la sangre ahorra vidas, y el cerebro ahorra ambas cosas.
Erwin Rommel
iii
iv
Agradecimientos
A Eduardo Mena, por predestinarme para este proyecto mediante el examen de DBDR
y por toda su ayuda durante el largo camino que vino después.
A Susana por ser, en parte, precursora de este PFC y hacer retroinformática para
recuperar la información que necesitaba.
A Max por resolver todas mis dudas haciendo gala de su particular forma de entender
las relaciones humanas.
A mis compañeros de prácticas desde Iván y Héctor en la primera, hasta Roberto e Ig-
nacio en la última, pasando por mis compañeros más asiduos Ricardo, Jacobo y Pablo. Sin
olvidarme del resto de compañeros de prácticas Rubén, Noelia, Rafael, Eduardo, Carlos,
Alberto, Adrián. . . ni de todos aquellos compañeros que no pudieron compartir prácticas
conmigo pero siempre lo desearon Javier, Héctor, Esther. . .
A mis profesores, de todos he aprendido algo y de la mayorı́a mucho, a todos ellos,
muchas gracias por enseñarme a aprender.
Y a todos los que han respondido en alguna ocasión a las preguntas que me acechaban,
sin olvidarme de aquellos a quienes ni siquiera he tenido que preguntar porque han dejado
sus conocimientos al alcance de todos en la red de redes.
v
vi
Resumen
Cada año se imparten un gran número de másteres en el Centro Politécnico Superior,

y la búsqueda de un horario ideal, o al menos aceptable, es una tarea que se repite para
cada uno de ellos.
A dı́a de hoy el proceso de elaboración de estos horarios se realiza, por parte del
coordinador de cada máster, de una forma completamente manual. No es de extrañar
que el proceso sea tedioso si consideramos el sinfı́n de restricciones a tener en cuenta
(disponibilidad de laboratorios y profesores, coordinación entre las diferentes asignaturas,
preferencias de profesores, etc.) y que en la definición de estas hay muchas personas in-
teresadas, especialmente profesores y alumnos, que deben ponerse de acuerdo para buscar
una solución que satisfaga a todos.
Atendiendo a esta problemática el objetivo de este proyecto es crear una herramienta
que ayude a la gestión de los horarios de los másteres en los centros universitarios, simpli-
ficando no solo su construcción, sino también su posterior gestión y la interacción entre
todas las personas y entidades que deben colaborar.
Utilizando la aplicación desarrollada los profesores de cada asignatura pueden co-
laborar vı́a web con el coordinador del máster a la hora de introducir en el sistema las
restricciones temporales, las dependencias entre cursos, la disponibilidad de aulas y demás
problemáticas de todo tipo que afectan a la generación de horarios.
Cuando el sistema posee la información requerida genera de forma automática los ho-
rarios, informando de cuáles han sido las restricciones cuya satisfacción ha sido imposible,
si las ha habido.
Los horarios hallados automáticamente pueden ser regenerados con nuevos parámetros
o modificados manualmente para recoger incidencias puntuales.
Una vez generados los horarios la web de la aplicación, puede usarse como página de
información general sobre el máster para los posibles alumnos, para guardar los datos
de los alumnos ya matriculados, para comunicar a alumnos y profesores cambios en los
horarios y, en general, para realizar las tareas más generales que forman parte de la gestión
integral del máster.
vii
viii
Índice
1. Introducción 3
1.1. Estructura de la aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Puntos de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Aplicación web 7
2.1. Exigencias a la web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.1. Vista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.2. Controlador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.3. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4. Problemas encontrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3. Calendario 15
3.1. Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Visión general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1. Cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.2. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3. Tareas realizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.1. Lectura y actualización de la base de datos . . . . . . . . . . . . . . 20
3.3.2. Deshacer y rehacer acciones . . . . . . . . . . . . . . . . . . . . . . 22
ix
3.4. Problemas de implementación . . . . . . . . . . . . . . . . . . . . . . . . . 23
4. Algoritmo de generación de horarios 25

4.1. Entrada y salida del algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.1. Datos de entrada . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1.2. Datos de salida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.1. Cromosoma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.2. Operadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.3. Función de evaluación . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3. Reflexiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5. Conclusiones 33
5.1. Utilidad del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2. Reflexión personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3. Trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Bibliografı́a 36
A. Usuarios y entidades 41
A.1. Tipos de usuario y sus privilegios . . . . . . . . . . . . . . . . . . . . . . . 41
A.1.1. Coordinador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
A.1.2. Profesor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
A.1.3. Alumno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
A.1.4. Invitado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
A.2. Entidades del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
A.2.1. Curso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
A.2.2. Máster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.2.3. Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
A.2.4. Aula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
x
B. Desarrollo del proyecto 49
B.1. Hitos del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
B.2. Empleo del tiempos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
B.3. Diagrama de Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
C. Base de datos 55
C.1. Modelo entidad relación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
C.1.1. Usuarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
C.1.2. Curso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
C.1.3. Máster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
C.1.4. Cuatrimestre y aula . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
C.1.5. Evento y mensaje . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
C.1.6. Participa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
C.2. Claves de la implementación . . . . . . . . . . . . . . . . . . . . . . . . . . 61
C.2.1. InnoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
C.2.2. Disparadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
C.3. Problemas encontrados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
D. Elección de las tecnologı́as 65

D.1. Generación del contenido dinámico de la web . . . . . . . . . . . . . . . . . 65
D.2. Construcción de calendarios interactivos . . . . . . . . . . . . . . . . . . . 66
D.2.1. Google Calendar . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
D.2.2. Calendarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
D.2.3. Solución elegida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
D.3. Generación de horarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
D.3.1. Aplicaciones ya existentes . . . . . . . . . . . . . . . . . . . . . . . 68
D.3.2. Elección del tipo de algoritmo . . . . . . . . . . . . . . . . . . . . . 69
D.3.3. Elección de la tecnologı́a . . . . . . . . . . . . . . . . . . . . . . . . 70
xi
E. Tecnologı́as utilizadas 71
E.1. GWT para la construcción de calendarios . . . . . . . . . . . . . . . . . . . 71
E.1.1. Google Web Toolkit . . . . . . . . . . . . . . . . . . . . . . . . . . 71
E.1.2. FRT GWT Library . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
E.2. Algoritmos genéticos usando JGAP . . . . . . . . . . . . . . . . . . . . . . 73
E.2.1. Algoritmos genéticos . . . . . . . . . . . . . . . . . . . . . . . . . . 73
E.2.2. Java Genetic Algorithms Package . . . . . . . . . . . . . . . . . . . 74
E.2.3. JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
E.3. MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
E.4. Java orientado a la generación web . . . . . . . . . . . . . . . . . . . . . . 76
E.4.1. JavaServer Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
E.4.2. Struts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
E.4.3. Jmaki . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
E.5. Programación con restricciones . . . . . . . . . . . . . . . . . . . . . . . . 77
E.5.1. Choco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
E.5.2. ECLiPSe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
E.6. Modelo Vista Controlador . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
F. Software de apoyo 81
G. Algoritmos genéticos 83
G.0.1. Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
G.0.2. Caracterı́sticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
G.0.3. Funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
H. Eficiencia de la generación de horarios 87

H.1. Resultados de los experimentos . . . . . . . . . . . . . . . . . . . . . . . . 88
H.2. Análisis de los resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
I. Manual de usuario 91
xii
I.1. Tipos de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
I.2. Cabecera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
I.3. Página principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
I.4. Página de un máster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
I.4.1. Información principal . . . . . . . . . . . . . . . . . . . . . . . . . . 94
I.4.2. Cuatrimestres del máster . . . . . . . . . . . . . . . . . . . . . . . . 95
I.4.3. Coordinadores del máster . . . . . . . . . . . . . . . . . . . . . . . 96
I.4.4. Cursos del máster . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
I.4.5. Profesores del máster . . . . . . . . . . . . . . . . . . . . . . . . . . 97
I.4.6. Alumnos del máster . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
I.4.7. Información relevante . . . . . . . . . . . . . . . . . . . . . . . . . . 98
I.4.8. Cambios pendientes de ser aprobados . . . . . . . . . . . . . . . . . 99
I.4.9. Calendario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
I.5. Página de un curso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
I.5.1. Información principal . . . . . . . . . . . . . . . . . . . . . . . . . . 101
I.5.2. Aulas del curso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
I.5.3. Alumnos del curso . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
I.5.4. Cursos que son prerrequisitos . . . . . . . . . . . . . . . . . . . . . 103
I.5.5. Profesores del curso . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
I.5.6. Información relevante . . . . . . . . . . . . . . . . . . . . . . . . . . 104
I.5.7. Datos para la generación de horarios . . . . . . . . . . . . . . . . . 105
I.5.8. Calendario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
I.6. Página de un aula . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
I.7. Página de un usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
I.8. Página de identificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
I.9. Calendarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
I.9.1. Tipos de calendarios . . . . . . . . . . . . . . . . . . . . . . . . . . 108
I.9.2. Tipos de eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
xiii
I.9.3. Colores de los calendarios . . . . . . . . . . . . . . . . . . . . . . . 109
I.9.4. Ventana de edición de eventos . . . . . . . . . . . . . . . . . . . . . 109
I.9.5. Panel de calendarios . . . . . . . . . . . . . . . . . . . . . . . . . . 110
I.9.6. Manejo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
I.10. Alertas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
J. Manual del administrador 115

J.1. Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
J.2. MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
J.2.1. Configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
J.2.2. Creación de la base de datos . . . . . . . . . . . . . . . . . . . . . . 117
J.2.3. Base de datos a utilizar . . . . . . . . . . . . . . . . . . . . . . . . . 117
J.3. NetBeans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
J.4. Tareas a realizar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
K. Versión de evaluación 119

K.1. Cuentas disponibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
K.2. Limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
xiv
Índice de figuras
1.1. Diagrama que muestra las diferentes partes del sistema y su interacción . . 4
2.1. Diagrama que muestra la interacción entre los paquetes que componen la
aplicación web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Aspecto visual fijado durante la etapa inicial de diseño para la página que
muestra un máster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Ejemplo de la función de autocompletado . . . . . . . . . . . . . . . . . . . 10
2.4. Traza de eventos parcial de la página de un máster, utilizada durante la

etapa de diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Captura de Google Calendar . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2. Captura del calendario de la aplicación . . . . . . . . . . . . . . . . . . . . 17
3.3. Diagrama que muestra la interacción entre los paquetes que componen el
calendario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Esquema del cromosoma utilizado . . . . . . . . . . . . . . . . . . . . . . . 28
4.2. Ejemplo del tipo del cromosoma utilizado . . . . . . . . . . . . . . . . . . . 29
4.3. Diagrama de clases “resumido” del algoritmo genético . . . . . . . . . . . . 31
B.1. Distribución del tiempo invertido en el proyecto . . . . . . . . . . . . . . . 50
B.2. Distribución del tiempo invertido en la aplicación web . . . . . . . . . . . . 51
B.3. Distribución del tiempo invertido en el calendario GWT . . . . . . . . . . . 51
B.4. Distribución del tiempo invertido en el algoritmo genético . . . . . . . . . . 52
B.5. Diagrama de Gantt del proyecto . . . . . . . . . . . . . . . . . . . . . . . . 53
xv
C.1. Modelo entidad relación “resumido” de la base de datos . . . . . . . . . . . 56
C.2. Modelo de la entidad Usurio . . . . . . . . . . . . . . . . . . . . . . . . . . 57
C.3. Modelo de la entidad Curso . . . . . . . . . . . . . . . . . . . . . . . . . . 57
C.4. Modelo de la entidad Master . . . . . . . . . . . . . . . . . . . . . . . . . . 58
C.5. Modelo de las entidades Cuatrimestre y Aula . . . . . . . . . . . . . . . . . 59
C.6. Modelo de las entidades Evento y Mensaje . . . . . . . . . . . . . . . . . . 59
C.7. Modelo entidad relación de la relación Participa . . . . . . . . . . . . . . . 61
C.8. Modelo entidad relación que muestra la relación entre las entidades Máster
y Curso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
E.1. Esquema de funcionamiento de GWT . . . . . . . . . . . . . . . . . . . . . 72
G.1. Esquema del algoritmo genético simple . . . . . . . . . . . . . . . . . . . . 86
I.1. Cabecera de las páginas, que se muestra si no se está identificado . . . . . 92

I.2. Cabecera de las páginas, que se muestra si se está identificado . . . . . . . 92
I.3. Lista de másteres disponibles . . . . . . . . . . . . . . . . . . . . . . . . . 93
I.4. Página principal de un máster para un coordinador . . . . . . . . . . . . . 94
I.5. Cuadro que muestra la información principal de un máster, para usuarios
no coordinadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
I.6. Cuadro que muestra información sobre los cuatrimestres de un máster, para
usuarios no coordinadores . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
I.7. Cuadro que muestra información sobre los cuatrimestres de un máster, para
usuarios coordinadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
I.8. Ejemplo de sugerencias del sistema al añadir coordinadores . . . . . . . . . 97
I.9. Cuadro que muestra información sobre los cursos de un máster, para usua-
rios coordinadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
I.10. Cuadro que muestra información sobre los alumnos de un máster . . . . . . 98
I.11. Cuadro que muestra los cambios pendientes de aprobación en los calenda-
rios de los cursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
I.12. Cuadro que muestra el calendario de un máster para un coordinador . . . . 101
I.13. Informe de la generación de un horario . . . . . . . . . . . . . . . . . . . . 102
xvi
I.14. Cuadro que muestra el calendario de un máster para un coordinador . . . . 102
I.15. Cuadro que muestra la información principal de un curso para un coordinador103
I.16. Cuadro que, para no coordinadores, muestra la información sobre las aulas
de un curso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
I.17. Cuadro que muestra los alumnos matriculados y el formulario para agregar
uno nuevo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
I.18. Cuadro que muestra los profesores de un máster para usuarios con derechos
de edición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
I.19. Cuadro que muestra los datos para la generación del horario del curso . . . 105
I.20. Cuadro con la información principal de un aula . . . . . . . . . . . . . . . 106
I.21. Página personal de un alumno . . . . . . . . . . . . . . . . . . . . . . . . . 107
I.22. Página personal de un profesor . . . . . . . . . . . . . . . . . . . . . . . . 107
I.23. Página de autentificación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
I.24. Cuadro de diálogo de edición de eventos . . . . . . . . . . . . . . . . . . . 110
I.25. Panel que muestra los calendarios disponibles . . . . . . . . . . . . . . . . 111
I.26. Vista diaria del calendario . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
I.27. Vista semanal del calendario . . . . . . . . . . . . . . . . . . . . . . . . . . 113
I.28. Vista mensual del calendario . . . . . . . . . . . . . . . . . . . . . . . . . . 114
I.29. Vista anual del calendario . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
xvii
xviii
Índice de tablas
C.1. Representación un máster en la base de datos (campos clave) . . . . . . . . 62

C.2. Representación de un curso en la base de datos (campos clave) . . . . . . . 62
H.1. Resultados del Programa Oficial de Posgrado en Ingenierı́a Informática . . 88

H.2. Resultados del máster en Ingenierı́a Biomédica . . . . . . . . . . . . . . . . 89
1
2
1. Introducción
La problemática de la búsqueda de horarios óptimos se presenta de forma reiterada

en el Centro Politécnico Superior y prácticamente en cualquier centro educativo.
Aunque dependiendo del tamaño del centro, el esfuerzo necesario para su obtención
variará enormemente, casi en cualquier caso la realización manual de esta búsqueda, e
incluso hallar las restricciones a aplicar, son un trabajo más que tedioso.
Un caso particular de esta problemática se puede encontrar actualmente en los horarios
de los másteres del CPS, que actualmente son definidos de forma completamente manual.
Este caso particular es el que intenta solucionar este proyecto, siendo la aplicación
desarrollada una herramienta para la gestión de másteres, ası́ como para la generación
automática de sus horarios.
Para poder satisfacer los ambiciosos objetivos presentados en el párrafo anterior hemos
exigido al sistema que tenga las siguientes caracterı́sticas:
Gestión y actualización vı́a web del conjunto de la aplicación, de forma concurrente,

intuitiva, rápida y segura.
Almacenamiento de los datos de interés relativos a los másteres, especialmente los

concernientes a aulas, alumnos, profesores y cursos.
Uso de calendarios interactivos para mostrar, editar y gestionar la información de

forma intuitiva y sencilla.
Introducción distribuida de datos según un sistema de cuentas que permita a cada

persona implicada modificar sus datos personales y los de las entidades sobre las
que tenga privilegios.
Sistema de alertas para informar a coordinadores, profesores y alumnos de aquellos

cambios que les afecten de alguna manera, siendo el coordinador el responsable de
dar el visto bueno de aquellos que puedan generar nuevos conflictos.
Obtención automática de horarios óptimos para los diferentes másteres a partir de

los datos introducidos por todos los usuarios.
3
1. Introducción 1.1 Estructura de la aplicación
Para comprobar que el sistema cumple los objetivos señalados, la aplicación ha sido
probada utilizando conjuntos de restricciones y datos reales de algunos de los másteres
que actualmente se imparten en el CPS.
1.1. Estructura de la aplicación
El presente proyecto, cuyas caracterı́sticas principales ya se han descrito en este capı́tu-

lo, se puede dividir en cuatro partes claramente diferenciadas que una vez realizado un
análisis y un diseño iniciales de manera conjunta, pueden desarrollarse de forma separada.
En la Figura 1.1 se pueden distinguir las partes que forman la aplicación y las relaciones
entre ellas y con el exterior. El sistema consta de las siguientes partes:
Figura 1.1: Diagrama que muestra las diferentes partes del sistema y su interacción
Aplicación web: Comprende la parte de la aplicación que se ocupará de interactuar

con el cliente, a excepción del calendario web que por su complejidad y peculiarida-
des es considerado una parte independiente.
Mediante una interfaz de usuario muy simple nos permite ver, editar y crear cursos,
aulas, alumnos, profesores y coordinadores. A través de ella se realizarán actua-
lizaciones y consultas concurrentes sobre los datos referentes a los másteres y se
ordenará la generación de horarios.
El contenido dinámico de la web se genera mediante tecnologı́as Java, como JSP.
Calendario web: Es el calendario online que muestra y permite editar los horarios
de los másteres.
4
1. Introducción 1.2 Puntos de la memoria
El uso de tecnologı́as AJAX ha permitido el desarrollo de un calendario mediante el

que los usuarios pueden ver, editar, crear, sugerir, borrar y arrastrar y soltar eventos
de una fecha a otra, todo ello en función de nuestros permisos, desde una misma
página y sin que esta deba recargarse en ningún momento.
Ofrece varias vistas diferentes, diaria, semanal, mensual y anual y puede cargar los
eventos de diferentes calendarios dinámicamente.
Para su implementación se han utilizado librerı́as de componentes de interfaz de
usuario basadas en Google Web Toolkit.
Generador de horarios: Es el algoritmo encargado de generar los horarios cumpliendo

las restricciones introducidas previamente por los usuarios, en la medida en que esto
sea posible.
Leyendo las restricciones establecidas, nos devolverá, en cuestión de unos pocos
minutos, el horario del máster y una lista con las restricciones que no se han podido
satisfacer, si las hay.
Para desarrollar el algoritmo se han utilizado técnicas de programación genética,
para lo que se han usado librerı́as Java.
Base de datos: Guardará la información necesaria para el funcionamiento de las

demás partes del sistema, es decir, todos los datos acerca de los diferentes másteres.
El gestor utilizado para la base de datos de la aplicación ha sido MySQL.
1.2. Puntos de la memoria
El presente documento consta de 5 capı́tulos, siendo el primero de ellos la introducción,

consistente en este mismo capı́tulo.
Los capı́tulos 2, 3 y 4 corresponden cada uno de ellos a una de las partes en las que
hemos dividido el proyecto, tal y como se explica en el Capı́tulo 1.1, desarrollándose en
el Capı́tulo 2 la aplicación web, en el 3 el calendario y en el 4 el algoritmo de generación
de horarios.
La otra parte mencionada en la descripción del sistema, la base de datos, se ha descrito
en el Anexo C, por ser una parte menos innovadora técnicamente que las otras y por
considerarse que es posible comprender la aplicación sin un estudio detallado de ella.
En cada uno de estos capı́tulos se explica en profundidad el desarrollo de una parte
del proyecto, detallándose el proceso desde la obtención de los requisitos, hasta la imple-
mentación y los problemas encontrados, pasando por el diseño.
El Capı́tulo 5 consiste en la conclusión, que cierra la memoria con una revisión sobre
la utilidad real de la aplicación finalmente obtenida, las reflexión personal del autor y
5
1. Introducción 1.2 Puntos de la memoria
la propuesta de posibles trabajos que se podrı́an llevar a cabo para seguir ampliando y
mejorando la aplicación.
Aunque la memoria es comprensible por ella misma, se adjuntan a ella varios anexos
cuya lectura es muy recomendable para profundizar tanto en el conocimiento de la apli-
cación desarrollada, como en el proceso de elaboración del proyecto:
El Anexo A enumera las acciones realizables por cada tipo de usuario de entre los que
se pueden dar de alta en la aplicación y comenta cuáles son las entidades principales del
sistema.
En el Anexo B se describe el desarrollo del proyecto, centrándose en los tiempos que
ha costado realizar cada una de las tareas que ha implicado, para lo que muestra los hitos
y el diagrama de Gantt del proyecto.
Sobre el Anexo C ya se ha comentado anteriormente que describe la base de datos del
sistema y su proceso de desarrollo.
Leyendo el Anexo D se conocerá el proceso de elección de las diferentes tecnologı́as
utilizadas y porque se ha decidido utilizar estas, antes que alguna de entre las otras muchas
disponibles.
El Anexo E describe las tecnologı́as sobre las que se ha creı́do que, por ser tecnologı́as
poco conocidas sobre las que los lectores pueden tener pocos conocimientos o por ser muy
importantes en el desarrollo de la aplicación, debı́an ser explicadas en detalle.
El Anexo F presenta muy brevemente el software de apoyo utilizado durante la ela-
boración de este proyecto, desde las herramientas de diseño, a las utilizadas durante la
redacción de esta memoria.
El Anexo G amplia la breve información dada en el Anexo E acerca de los algoritmos
genéticos, métodos adaptativos cuya comprensión es fundamental para poder entender en
su conjunto el proyecto desarrollado.
El Anexo H muestra información sobre la eficiencia del algoritmo de generación de
horarios, mediante datos obtenidos en pruebas con datos reales.
El Anexo I consiste en el manual de usuario de la aplicación, aunque se espera que la
aplicación resulte tan intuitiva que evite la necesidad de su consulta, es muy posible que
sea de gran utilidad en algunos casos puntuales.
El Anexo J consiste en el manual para el administrador de la aplicación, que será de
obligada lectura para que la aplicación pueda ponerse en funcionamiento de forma adecua-
da, también da algunas pautas a quienes intenten desarrollar mejoras para la aplicación,
aunque no es su función principal resolver esta cuestión y a quienes se encuentren en esta
situación se les recomienda consultar con el autor.
Finalmente, el Anexo K da unas breves indicaciones sobre el uso de la versión de
prueba de la aplicación.
6
2. Aplicación web
Se ha denominado aplicación web a la parte del sistema que se ocupa vı́a web de
la interacción con el usuario, sin incluir el calendario desarrollado en GWT que por su
complejidad y caracterı́sticas distintivas cuenta con un capı́tulo propio.
Aunque todas las partes de la aplicación se desarrollaron de forma, más o menos,
paralela se puede decir que la parte que ahora comentamos y detallamos, fue la que se
diseñó y se comenzó a implementar en primer lugar y la que fue definiendo los requisitos
de las demás partes, especialmente del algoritmo de búsqueda de horarios óptimos y de
la base de datos del sistema.
2.1. Exigencias a la web
La web es la puerta que conecta a los usuarios con las funciones que ofrece la aplicación,
a través de ella tendrán accesos a todas las funciones y consultarán y modificarán todos
los datos sobre los que tengan privilegios.
De ahı́ que los requisitos básicos con que debe cumplir la web se extraigan directamente
de conocer las entidades que podrá crear, editar y modificar cada tipo de usuario y las
acciones que podrá realizar, estos datos se encuentran disponibles en el Apéndice A.
Una vez considerados estos requisitos especı́ficos, ya solo resta exigirle que su uso sea
tan sencillo e intuitivo como para no requerir de un aprendizaje, que funcione correcta-
mente en la mayorı́a de los navegadores conocidos, que minimice los tiempos de carga
necesarios, que proteja los datos privados de los usuario de la vista de las personas no
autorizadas y que cumpla los mismos principios generales de usabilidad que son deseables
para cualquier web [1, 2].
2.2. Diseño
El diseño de la web se basa en el patrón Modelo Vista Controlador, que se presenta

en el Anexo E.6.
7
2. Aplicación web 2.2 Diseño
Su influencia se puede apreciar en la Figura 2.1, que es una parte de la Figura 1.1, y
muestra los paquetes que componen la aplicación web y las interacciones entre ellos, con
el resto de la aplicación y con los usuarios.
Figura 2.1: Diagrama que muestra la interacción entre los paquetes que componen la aplicación web
La “Vista” está formada por las páginas JSP que conforman la parte de la aplicación
visible por el usuario. Los motivos que llevaron a la utilización de JSP se presentan en el
Anexo D.1.
El “Controlador” es un paquete que principalmente responde a los eventos que recibe
del usuario por medio de la “vista”, realizando los cambios pertinentes en el “Modelo” y
actualizando la “Vista” a partir de los datos que le transmite el “Modelo”.
El “Modelo” consiste en un paquete, formado principalmente por las funciones orien-
tadas a leer y actualizar la base de datos de másteres.
2.2.1. Vista
La primera etapa del diseño consistió en definir el aspecto visual aproximado de cada
página web en cada una de las situaciones en que podı́a ser necesario mostrarla.
La Figura 2.2 presenta un ejemplo de esta fase, e ilustra varias de las problemáticas
cuyas soluciones se comentarán a continuación.
La excesiva longitud de las páginas que se muestran en la figura hace intuir uno de los
problemas con los que topó el diseño de las diferentes páginas, su gran tamaño.
La solución a este problema consistió en dividir las páginas en secciones que se pueden
mostrar y ocultar a voluntad de forma independiente. Esta solución demostró ser muy
acertada al proporcionar el beneficio adicional de reducir el tiempo de carga inicial de la
página.
8
Figura 2.2: Aspecto visual fijado durante la etapa inicial de diseño para la página que muestra un máster
9
Como también se puede ver en la figura, para añadir coordinadores y cursos a un

máster solo contamos con una única casilla, esto es ası́ porque para reforzar la facilidad
de uso se utilizan casillas con la función de autocompletado [3], es decir, con sugerencia
en tiempo real de las opciones posibles a partir de la información contenida en la base de
datos, tal y como se muestra en la Figura 2.3.
Figura 2.3: Ejemplo de la función de autocompletado
De esta forma para añadir una entidad ya existente el usuario simplemente deberá ha-
cer clic sobre su nombre y, en el caso de que la entidad que desea añadir no haya sido
creada todavı́a, deberá pinchar sobre “Crear uno nuevo” y rellenar el formulario que se
desplegará.
Esta fórmula se ha utilizado, por facilitar tanto el diseño de la web, como su posterior
utilización, en tantos campos como ha sido posible, principalmente a la hora de añadir
profesores, coordinadores, cursos y aulas.
Por último, podemos apreciar en la imagen que la página cuenta con campos consisten-
tes en fechas, para rellenar estos campos, se decidió utilizar calendarios desplegables para
una mayor comodidad de los usuarios, aunque por supuesto también se permite rellenar
manualmente dichos campos.
Una de las prioridades del diseño fue que la gran variedad de páginas que el servidor
necesitarı́a enviar al cliente no se reflejase en la creación de muchas páginas diferentes que
dificultasen la compresión y el mantenimiento del código.
De ahı́ que las vistas de másteres, cursos y demás objetos se generen, cada una, en
tiempo de ejecución a partir de la misma página JSP sea cual sea el tipo de usuario
autentificado en el servidor, consiguiéndose que todas las páginas principales se generen
a partir de solamente 6 ficheros JSP.
Por supuesto, las partes de las páginas que se repiten en varias de ellas, como es el
caso de los encabezamientos y pies de página, son generadas a partir de un sola página
JSP.
10
En cuanto a la forma de navegar entre las páginas que componen la web del proyecto,
se ha optado por la estrategia que se ha creı́do más sencilla para los usuarios. Cada vez que
se hace referencia a una entidad con página propia, en una de las páginas de la aplicación,
esta referencia es también un enlace que permite desplazarse hasta su página.
Utilizando estos enlaces y el enlace a la página de inicio que se encuentra en la cabecera
de todas las páginas, se ha conseguido que los usuarios nunca necesiten más de 4 pasos
para llegar a una de ellas, aunque la aplicación cuente con miles de páginas visitables en
ese momento.
2.2.2. Controlador
Para definir las funciones principales que debı́a satisfacer el paquete controlador se rea-
lizaron diagramas de secuencia, como el de la Figura 2.4, considerando todas las acciones
desencadenables en el sistema.
Estos diagramas son especialmente fructı́feros en este caso, ya que la tarea principal del
“Controlador” es recibir instrucciones de la “Vista”, que deberá transmitir al “Modelo”,
transformadas en acciones concretas para, a continuación, recibir la respuesta del “Mo-
delo” y comunicar a la “Vista” como debe actualizarse en función de los datos extraı́dos
de la base de datos por el “Modelo”.
Figura 2.4: Traza de eventos parcial de la página de un máster, utilizada durante la etapa de diseño
Se puede observar que al hacer las peticiones no se pasa el usuario activo como parte
de los datos, esto es porque se ha decidido que el usuario sea almacenado, en la máquina
cliente, mediante cookies en el momento de acceder al sistema. De ahı́ es de donde el
“Controlador” leerá el usuario siempre que sea relevante en su toma de decisiones.
11
Como es apreciable en la Figura 2.2, los diferentes formularios que contienen las páginas
cuentan con un botón “Modificar”, este se utilizará para guardar los cambios realizados
en cada uno de los formularios de la página.
Una de las decisiones más importantes que se tuvieron que tomar durante el diseño
del “Controlador” fue el tipo de acción que desencadenarı́an dichos botones, planteándose
si esta acción debı́a provocar la recarga de la página o, por el contrario, debı́a actualizarse
la página sin necesidad de recargarla.
En el primer caso, la opción principal era que el “Controlador” lo formasen princi-
palmente extensiones de las clases Action y ActionForm de Struts, que se presenta en el
Anexo E.4.2.
La ventajas principales del uso de esta herramienta frente a otras eran:
Es una herramienta de soporte para el desarrollo de páginas web, orientada al patrón

Modelo Vista Controlador.
El autor del proyecto ya la conocı́a, al haber desarrollado en 2008 un extenso trabajo
[4] sobre esta estructura, para la asignatura Sistemas de Información [5].
Es una herramienta muy utilizada, tanto por su sencillez, como por la robustez de
su implementación.
En el segundo, caso se planteó el uso de JMaki, que se comenta en el Anexo E.4.3,

siendo la ventaja principal que conllevaba su utilización el hacer el uso la aplicación más
fluido, al no obligar a múltiples recargas de página.
Considerándose los tiempos de carga de la aplicación bastante pequeños y no supo-
nerse las modificaciones operaciones muy habituales se optó por el uso de Struts como
herramienta principal. Si bien se utiliza JMaki para algunas acciones puntuales, como
a la hora de mostrar las restricciones que no ha podido cumplir un horario generado
automáticamente y su porcentaje de optimicidad.
2.2.3. Modelo
El “Modelo” lo conforman el conjunto de funciones de más bajo nivel de la aplicación.

La mayor parte de las funciones del “Modelo” responden a necesidades especı́ficas
de consultas y actualizaciones de la base de datos, que se han extraı́do de diagramas de
secuencia como el de la Figura 2.4.
Para conectarse a la base de datos se usará un “agrupamiento de conexiones”1 [6],
es decir, mantendremos un número de conexiones abiertas que serán reutilizadas en las
diferentes consultas y actualizaciones de la base de datos.
1
Más conocido por el término Ingles “connection pool”.
12
2. Aplicación web 2.3 Implementación
Esta técnica mejora enormemente el rendimiento al ahorrar el abrir y cerrar conexiones

constantemente y permitir optimizar el uso de las conexiones ya abiertas.
Aunque el actualizar y consultar la base de datos supone la práctica totalidad de las
acciones de esta parte del sistema, esta también realiza otras tareas fundamentales como:
Lectura de los ficheros de configuración de la aplicación.
Envı́o de emails, tanto para comunicar a los nuevos usuarios que han sido dados de
alta en el sistema, como para, de forma periódica, comunicarles los cambios en el
sistema.
Generación aleatoria de las claves de los nuevos usuarios.
2.3. Implementación
La implementación de esta parte de la aplicación no ha chocado con grandes dificul-

tades, ya que ha resultado sencillo consultar manuales y ejemplos de las funcionalidades
que se querı́an desarrollar.
Al contarse con esta ventaja, se ha intentado sacar el máximo partido a las diferentes
herramientas disponibles, utilizando todas las funcionalidades con las que contaban.
Ejemplo de esto es la utilización de algunas interesantes funcionalidades de Struts y
JSP:
Se ha diseñado e implementado una etiqueta JSP, para facilitar la creación de las

URLs que enlazan unas páginas con otras.
Se ha utilizado Tiles [7] para crear plantillas de las páginas web.
Se han utilizado ficheros “properties” y Bean [8] para brindar a la aplicación soporte
multilenguaje.
De librerı́as para facilitar la implementación de las funcionalidades deseadas:
XStream 1.3 [9] para la lectura de ficheros XML.
Commons Pool 1.4 [6] para la gestión de las conexiones a bases de datos.
JavaMail 1.4.1 [10] para el envı́o de emails.
Otras librerı́as como JMaki, que por su mayor relevancia han sido comentadas am-
pliamente en el Anexo E.
13
2. Aplicación web 2.4 Problemas encontrados
Y de algunas funciones Javascript orientadas a mejorar la experiencia de usuario, para

las que se toman como punto de partida funciones publicadas bajo licencias libres, ese es
el caso de:
Los formularios con autocompletado [3].
Los calendarios usados para la selección de fechas en los formularios web [11].
2.4. Problemas encontrados
La mayor dificultad radicó en la elección de las caracterı́sticas de los másteres y cursos

que iban a ser especificables por los usuarios del sistema.
Para esto fueron necesarias un gran número de reuniones entre el proyectando y el
director del proyecto, que hacı́a las veces de futuro usuario de la aplicación.
Estas reuniones fueron muy fructı́feras al tener el director un interés real en que la
aplicación fuese realmente útil para resolver el problema al que se orienta, por sufrir
personalmente los problemas a los que se intenta dar respuesta en los másteres en los que
ejerce como docente.
Una vez fijadas las caracterı́sticas de másteres y cursos que considerarı́a el sistema, no
fue fácil encontrar un equilibrio entre la deseada facilidad de uso que se le pedı́a a la web
y la gran cantidad de datos que iba a ser necesario introducir.
Una dificultad añadida ha sido la inexperiencia del proyectando a la hora de utili-
zar algunos de los lenguajes y técnicas implicadas, lo que ha causado que el tiempo de
desarrollo se alargase.
14
3. Calendario
La inclusión en la aplicación de un calendario que sirviese tanto para conocer los

horarios como para modificarlos era uno de los requisitos más importantes del proyecto.
A este calendario se le han exigido unas funcionalidades y un modo de uso similares
a los de Google Calendar [12], claro referente hoy en dı́a en cuanto a calendarios web o
a los de algunas populares aplicaciones de escritorio, como el ya descatalogado Microsoft
Schedule+ [13].
3.1. Requisitos
Las caracterı́sticas principales que se le exigen al calendario web son:
Posibilitar el deshacer y rehacer los últimos cambios.
Mostrar diferentes calendarios de forma simultánea.
Permitir elegir de que calendarios se desean ver y editar los eventos, de entre la lista
de calendarios disponible en cada momento y teniendo en cuenta los permisos del
usuario activo.
Edición y creación de eventos de forma completamente visual (aumentar el tamaño

del cuadro que representa el evento para aumentar su duración, arrastrar eventos
entre diferentes fechas . . . ).
La creación y edición de eventos se realizará desde la misma pantalla en la que se

está mostrando el calendario, sin necesidad de pasar por otras páginas.
No se necesita recargar la página en la que se encuentra el calendario tras la reali-

zación de ninguna acción.
Su funcionamiento debe ser sencillo y muy intuitivo, de forma que no se necesite un

aprendizaje para su utilización.
15
3. Calendario 3.2 Visión general
Posibilitar la copia y el pegado de eventos mediante el uso del botón derecho del
ratón.
Permitir crear o editar eventos sólo a los usuarios con permisos suficientes para el
calendario seleccionado.
Guardará los cambios realizados en los calendarios por usuarios sin plenos derechos
sobre ellos en forma de sugerencias, que más tarde deberán ser autorizadas para
convertirse en modificaciones definitivas (esto último no se hará desde el calendario).
Distinguirá los permisos del usuario sobre los diferentes calendarios, dándoles a los
eventos de estos diferentes colores.
Al hacer clic sobre un evento debe desplegar un panel que informe (permitiendo, o
no, editar el evento, dependiendo del caso) de los datos más relevantes acerca del
evento seleccionado.
Funcionar de forma correcta y prácticamente sin diferencias apreciables en los na-

vegadores más populares.
Tener disponibles vistas diaria, semanal, mensual y anual.
Permitir la creación de eventos periódicos.
Debe cargar los eventos desde una base de datos y guardar en ella las modificaciones
que se realicen.
No deben surgir problemas por el uso concurrente del sistema en varias máquinas
diferentes, aun en el caso de que se editen los mismo eventos en paralelo.
Es importante destacar que no se perdió de vista en ningún momento el objetivo de

que el resultado final se pareciera en aspecto y funcionalidad a Google Calendar, que fue
tomado como referente de eficiencia y facilidad de uso.
Se puede comprobar hasta qué punto se ha cumplido este objetivo, comparando la
captura de Google Calendar que se muestra en la Figura 3.1, con la captura de la versión
final del calendario desarrollado que se puede ver en la Figura 3.2.
3.2. Visión general
La interacción entre las diferentes partes del calendario y entre el calendario y el resto
de la aplicación y los usuarios, queda patente en la Figura 3.3, que es una parte de la
Figura 1.1.
16
Figura 3.1: Captura de Google Calendar
Figura 3.2: Captura del calendario de la aplicación
17
Figura 3.3: Diagrama que muestra la interacción entre los paquetes que componen el calendario
El calendario se ha programado utilizando el framework 1 de desarrollo GWT, par-

tiendo de la librerı́a FRT GWT Library, los motivos de la elección de estas tecnologı́as se
presentan en el Anexo D.2 y sus caracterı́sticas más reseñables en el Anexo E.1.
Se ha intentado desarrollar el calendario siguiendo el patrón Modelo Vista Controlador,
pero sólo ha sido posible separar la parte relativa a la“Vista” de la parte relativa “Contro-
lador” dentro de las limitaciones impuestas por el código desarrollado de antemano por
los creadores de las librerı́as utilizadas.
3.2.1. Cliente
La parte de la aplicación a la que hemos llamado “Cliente” en la Figura 3.3, está for-
mada por lo que según el patrón Modelo Vista Controlador, englobarı́a la “Vista” y el
“Controlador”.
Esta parte ha sido construida partiendo del ejemplo de uso de la librerı́a FRT GWT
Library y utiliza una versión de dicha librerı́a que ha sido completamente remodelada
para adaptarla a las necesidades especı́ficas del proyecto.
Se ejecuta en el navegador del cliente y es la que trata con el usuario directamente,
siendo la parte más importante del calendario, tanto por tamaño, como por complejidad.
Como podemos ver en la Figura 3.3, leerá datos de la página que contiene el calen-
dario. Estos datos son necesarios para decidir qué calendarios se deben cargar, y son los
siguientes:
1. El usuario que ha accedido a la aplicación.

1
En castellano, estructura de soporte definida.
18
3. Calendario 3.3 Tareas realizadas
2. En qué tipo de página se encuentra integrado, de entre las que pueden contener un
calendario, siendo las posibilidades máster, curso, aula y usuario.
3. A que máster, curso, aula o usuario pertenece la página en cuestión.
Sólo necesitará interactuar con el servidor para leer y actualizar la base de datos, cosa
que hará a través del “Modelo”, que al igual que en el caso de la aplicación web será la
parte del sistema que se ocupará de todas las tareas de este tipo.
3.2.2. Modelo
Es la parte de la aplicación encargada de interactuar con la base de datos, ocupándose

tanto de las lecturas como de las escrituras.
Aunque sus funciones serán diferentes, su aspecto será muy similar al del paquete
“Modelo” de la parte web, que se comentó en el Capı́tulo 2.2.3 y, al igual que este, se
valdrá de un pool de conexiones para optimizar las conexiones con la base de datos.
De hecho, se planteó la posibilidad de crear una librerı́a que contuviese la parte re-
lativa al “Modelo” de toda la aplicación y que fuese compartida tanto por la web, como
por el calendario. Pero esta idea se desestimó al comprobarse que no existı́an funciones
redundantes entre ambas partes, más allá de la propia conexión a la base de datos.
3.3. Tareas realizadas
El punto de partida para la creación de la aplicación es la librerı́a FRT GWT Library

y el ejemplo de uso que proporcionan sus creadores. Esto nos ahorra en gran medida la
labor de desarrollo de la parte visual del calendario y de la interacción con el cliente,
estando ya implementadas:
Las vistas diaria, semanal y mensual, que sólo necesitarán ser adaptadas a las ne-
cesidades especı́ficas de nuestro caso.
La interfaz con tecnologı́a AJAX que nos permite arrastrar y soltar eventos de una
fecha a otra y modificar gráficamente su duración haciendo más grandes o más
pequeños los recuadros que los representan; además de lanzar los paneles de edición
y creación de eventos al pinchar sobre diferentes zonas del calendario.
La gestión interna de los eventos que permite guardar en memoria los eventos crea-
dos.
19
Partiendo del código mencionado ha hecho falta añadir las funcionalidades necesarias
hasta satisfacer los requisitos presentados en el Capı́tulo3.1. Para conseguir esto, las tareas
principales a desarrollar han sido:
Actualizar la interfaz para que se ajuste al modelo deseado, especialmente la parte

relativa a la creación, edición y visualización de eventos y las vistas diaria, semanal
y mensual.
Añadir una vista anual a las disponibles.
Modificar la gestión interna de los eventos y realizar los cambios necesarios para que
estos se carguen y guarden en una base de datos.
Integrar el calendario en las páginas JSP desarrolladas y hacer que lea de estas la
información que necesite.
Hacer que cargue los calendarios requeridos en cada momento y permita al usuario
elegir cuáles desea visualizar y editar de entre los disponibles.
Decidir independientemente para los eventos de cada calendario si son editables o

no. Y, en caso de serlo, si dicho cambio necesita ser autorizado antes de ser definitivo
y de ser reflejado en los calendarios.
Poder deshacer y rehacer acciones.
Permitir crear eventos periódicos.
La mayor parte del trabajo invertido en esta parte del proyecto se ha dedicado a
implementación y depuración, siendo las tareas de diseño dignas de mención escasas, a
continuación se comentan algunas de las más interesantes.
3.3.1. Lectura y actualización de la base de datos
Ya se ha comentado en el Capı́tulo 3.2.2, que las tareas de lectura y escritura de la

base de datos son menester del paquete al que hemos llamado “Modelo”.
Al arrancar la parte “Cliente”, envı́a al “Modelo” el identificador del usuario y los
datos de la página dentro de la que se ha cargado el calendario. Con estos datos, el
servidor, devuelve la lista de calendarios que se deben cargar y los permisos que se tienen
sobre ellos.
Edición: Podemos modificar los eventos.
20
Edición parcial: Los cambios en el calendario se enviarán a los usuarios designados

para su autorización, y hasta que sean aceptados no se reflejarán en la base de datos,
pero sı́ en la versión local del calendario.
Visión: Podemos ver los eventos.
También informa el servidor de si el calendario se mostrará desde el principio o no,

la finalidad de esto es que no se muestren un número excesivo de calendarios al mismo
tiempo dificultando la comprensión por parte del usuario de lo que está viendo.
Los calendarios y los permisos que se tengan sobre ellos, son datos que se guardarán a
partir de ese momento en la máquina cliente, de forma que, esta petición no se repetirá a
la base de datos mientras que el usuario no recargue la página.
De este modo, al cargar cualquier vista del calendario, este se conectará con el servidor
enviándole las fechas comprendidas en el rango visible de la vista actual y los calendarios
que quiere ver, devolviendo el “Modelo” la lista de eventos a mostrar.
Esta acción se repite cada vez que cambiamos de vista o de rango de fechas visuali-
zables, podrı́a evitarse el volver a solicitar al servidor los eventos que se encuentra entre
fechas que ya han sido cargadas en una ocasión anterior.
La razón de que esto no se haya evitado, es que de este modo volvemos a actualizar
el calendario respecto a la base de datos, que puede haber sido modificada mientras
nosotros estábamos trabajando en local, ya que su uso es concurrente entre todos los
usuarios. Además esto no es un cuello de botella para la aplicación, cuyo problema de
latencia principal se encuentra en el dibujado de los eventos en la pantalla.
En el caso de que la conexión con la base de datos se rompiese, los datos no se
actualizarı́an al cambiar de vista, se mantendrı́an los ya cargados, lo que evita algunas
situaciones desagradables y permite poder consultar los eventos ya disponibles en caso de
que perdamos la conexión a Internet de forma temporal.
Se partı́a de un calendario en el que ya se podı́an realizar diferentes acciones, lo que se
decidió hacer fue que cada vez que se realizase una acción esta se transmitiese a la base
de datos para que esta se actualizase.
Se primó esta opción sobre realizar varias acciones en local antes de actualizar la
base de datos, lo que en principio podı́a parecer más eficiente, porque desconocemos si el
usuario va a cerrar la web por sorpresa, lo que, construyendo la aplicación de este modo,
tendrı́a como consecuencia la pérdida de las modificaciones realizadas.
En caso de que se haya realizado una operación en local y al intentar actualizar la
base de datos esta devuelva un error, se comunicará al usuario el problema mediante el
panel de “feedback” que se encuentra en la parte superior izquierda del calendario y se
le permitirá seguir trabajando en local. A partir de ahı́, será responsabilidad del usuario
reintentar las modificaciones que fallaron mientras la base de datos estaba caı́da, si ası́ lo
21
desea.
3.3.2. Deshacer y rehacer acciones
Se desea poder deshacer los cambios realizados durante la última sesión de edición del
calendario, al mismo tiempo se quiere que sea posible el rehacer las acciones que se han
deshecho previamente.
La estructura de datos que vamos a utilizar consiste en 4 pilas, a las que llamaremos
Pila1, Pila2, Pila3 y Pila4 para simplificar la comprensión de la explicación posterior:
Pila1: Pila con las acciones realizadas
Pila2: Pila con las acciones contrarias a las realizadas
Pila3: Pila con las acciones desechadas
Pila4: Pila con las acciones contrarias a las desechadas
Al realizar una acción primero la añadiremos a Pila1 y luego calcularemos la acción

opuesta y la añadiremos a Pila2.
De este modo la operación “deshacer” consistirá en leer la última acción almacenada
en Pila2 y ejecutarla.
Para, a continuación, copiar la acción realizada a Pila3 y la acción original a Pila4,
para que, más tarde, sea posible rehacer la acción deshecha.
Se finalizará la operación borrando los datos utilizados de las pilas Pila1 y Pila2, para
que la estructura quede en un estado coherente.
De este modo, ya estamos preparados para realizar la acción “rehacer” que consistirá en
repetir el proceso presentado anteriormente sustituyendo en las explicaciones Pila1 por
Pila3, Pila2 por Pila4 y al contrario.
Estas acciones se realizarán antes de que el cambio se produzca realmente en la base
de datos. Recordemos que las interacciones con la base de datos son ası́ncronas por lo
que no sabemos cuánto rato tendrı́amos que esperar para asegurarnos de que realmente
se realiza la acción, lo que darı́a lugar a retrasos y complicaciones.
Podrı́a reducirse de 4 a 2 el número de pilas utilizadas, si se calculasen los opuestos
de las acciones en el momento en el que son solicitados.
Esto no es posible, ya que no podrı́amos calcular la operación opuesta a una edición
tan sólo conociendo el evento final. Este es el motivo de que deban generarse las acciones
opuestas en el momento inicial, en el que se cuenta con toda la información necesaria.
22
3. Calendario 3.4 Problemas de implementación
3.4. Problemas de implementación
Esta parte del proyecto ha sido la que más tiempo de implementación ha necesitado,
esto ha sido debido más que nada a las dificultades encontradas para realizar tareas que
en principio debı́an ser sencillas.
Tal es el caso de la integración del calendario en las páginas web, para conseguir que
el calendario no tapara el pie de página fue necesario fijar explı́citamente los tamaños de
todos los componentes que conforman su interfaz lo que fue una tarea muy laboriosa.
Otro ejemplo de esto, se produjo al modificar la forma de almacenar los eventos que
duran un dı́a completo. En la librerı́a original se señalaba que un evento duraba todo
un dı́a con un campo especial, durante la etapa de diseño se decidió simplificar esto, de
forma que un evento que ocupase un dı́a completo simplemente fuese señalado como un
evento que comprendiese desde las 0 hasta las 24 horas de ese dı́a, de forma que se podı́a
eliminar el campo que se utilizaba, tan sólo para marcar que un evento duraba todo el dı́a.
A la hora de la implementación, esto acarreó varios problemas difı́cilmente predecibles en
partes muy diversas de la aplicación.
Estos problemas con los que ha topado la implementación a cada paso, han tenido
varias causas, el principal ha sido la falta de documentación y de comentarios en el código
de la librerı́a principal que se estaba utilizando. Esto ha retrasado inútilmente el desarrollo
del calendario y la modificación de partes de las librerı́as que no se adaptaban a las
necesidades de la aplicación.
El segundo motivo ha sido la falta de documentación disponible acerca de GWT.
Si bien es verdad que la documentación puesta a disposición de los programadores por
Google es bastante extensa, al ser esta una tecnologı́a todavı́a poco utilizada, existen
pocos documentos que complementen la documentación oficial en los puntos en los que
serı́a necesario, tal y como si pasa con otros lenguajes o tecnologı́as como Javasctipt,
Apache Struts o Java, en los que es fácil encontrar información de utilidad para resolver
los problemas más comunes.
Los dos problemas mencionados anteriormente unidos al gran número de fallos con-
tenidos en las librerı́as utilizadas y las dificultades para encontrar estos de una forma
automática, han hecho que el desarrollo de esta parte de la aplicación haya tenido un
coste temporal muy superior al previsto inicialmente.
Por último, un problema puntual fue que la versión de GWT utilizada no permitı́a
manejar el botón derecho del ratón, lo que obligó a renunciar a la utilización de este
para copiar y pegar eventos, tal y como se habı́a planteado en los requisitos de sistema,
quedando este como el único requisito inicial de la aplicación que finalmente no ha podido
ser satisfecho.
23
3. Calendario 3.4 Problemas de implementación
24
4. Algoritmo de generación de horarios
A lo largo de este capı́tulo se describirá qué necesidades se querı́an cubrir con el algo-
ritmo de generación de horarios, cuáles fueron las diferentes alternativas que se valoraron
para satisfacer estos objetivos y el porqué de la solución elegida.
Además del diseño y la implementación del sistema y los problemas que se encontraron
durante las diferentes etapas del proceso.
4.1. Entrada y salida del algoritmo
La aplicación tiene que generar a partir de las restricciones introducidas por diferentes
usuarios sobre el máster a tratar, un horario óptimo para este, además de un informe
sobre el cumplimiento de los objetivos.
Con el diseño de la aplicación web finalizado tal y como se explica en el Capı́tulo 2.2,
estaba claro cuáles debı́an ser los datos de entrada y de salida del algoritmo.
4.1.1. Datos de entrada
El algoritmo recibirá, al ser invocado, el identificador del máster a tratar. A partir

de este dato, obtendrá, de la base de datos, el resto de la información que necesita para
calcular el horario.
Como se puede desprender de la Figura 1.1, será de la parte del sistema a la que hemos
llamado “Controlado”, en el Capı́tulo 2.2.2, de quien recibirá el identificador del máster
a tratar y será el paquete “Modelo”, que se ha presentado en el Capı́tulo 2.2.3, quien
interactúe con la base de datos en su nombre, proporcionándole toda la información que
se enumera a continuación.
Información sobre el máster:
Horario del máster (para conocer los festivos. . . ).
25
4. Algoritmo de generación de horarios 4.1 Entrada y salida del algoritmo
Horas de clase que no debe exceder el máster en un dı́a.
Horas de clase consecutivas que no debe exceder el máster.
Fecha de inicio del máster.
Fecha de finalización del máster.
Cursos del máster.
Aulas disponibles para cursos del máster.
Profesores con docencia asignada en el máster.
Cuatrimestres que forman el máster.
Información sobre los profesores implicados en el máster:
Horario del profesor (para conocer las horas que tiene ocupadas. . . ).
Horas de docencia que no desea exceder en un dı́a.
Horas de docencia consecutivas que no desea exceder.
Información sobre las aulas disponibles para el máster.
Horario del aula (para conocer las horas que tiene ocupadas. . . ).
Información sobre los cuatrimestres en que se divide el máster.
Fecha de inicio del cuatrimestre.
Fecha de finalización del cuatrimestre.
Información sobre los cursos que conforman el máster.
Horario del curso (para conocer las posibles recomendaciones horarias de los profe-
sores del curso. . . ).
Cuatrimestre al que está asignado el curso (si lo está a alguno).
Aulas disponibles para este curso.
Cursos del máster que deben impartirse con anterioridad a este.
26
4. Algoritmo de generación de horarios 4.2 Diseño
Profesores que imparten clases de teorı́a y en que orden y, para cada uno de ellos,
cuántas clases imparte.
Profesores que imparten clases de prácticas y en que orden y, para cada uno de ellos,
cuántas clases imparte.
Si las clases de teorı́a y práctica deben obligatoriamente compartir aula y horario, si

deben compartir horario o si las asignaciones de horario y aula para teorı́a y práctica
deben ser independientes.
Si las clases de prácticas se impartirán de forma intercalada a las de teorı́a, de forma

posterior o a partir de que hayan sido impartidas un número dado de clases teorı́a.
4.1.2. Datos de salida
El programa debe informar al usuario del grado de éxito de la ejecución y de los

problemas encontrados y sustituir en la base de datos el antiguo calendario del máster
por uno nuevo, por lo que sus datos de salida serán:
Lista de las restricciones que no han podido ser cumplidas.
Nivel de adecuación de la solución al problema propuesto (porcentaje).
Nuevo horario del máster en cuestión.
Igual que a la hora de obtener los datos, el algoritmo interactuará con la base de datos
por medio del paquete “Modelo”, mientras que el informe de errores se comunicará al
usuario por medio del “Controlador”, que será quien actualice la “Vista” de la página
web, de acuerdo con lo comentado en el Capı́tulo 2.2.
4.2. Diseño
La generación de horarios es un problema NP-completo, al que se han enfrentado

diferentes técnicas de la inteligencia artificial con diversos grados de éxito.
Para la construcción de este algoritmo se probaron varias de ellas, hasta convenir, tras
las reflexiones que se presentan en el Anexo D.3, que la mejor alternativa era el uso de
la programación genética, utilizando la librerı́a JGAP, que permite dejar a un lado la
programación del algoritmo genético en sı́ mismo y posibilita al programador centrase en
el problema concreto al que se enfrenta.
27
Una introducción a los algoritmos genéticos, la librerı́a JGAP y el resto de tecnologı́as

que se han considerando relevantes y de las que se hará uso, a partir de este punto, en
este capı́tulo se puede encontrar en el Anexo E.2.
De este modo, las partes del algoritmo que necesitaron ser diseñadas e implementadas,
fueron las que definen la resolución de un problema concreto mediante el uso de algoritmos
genéticos, que son las siguientes:
La función de evaluación que nos indica qué cromosoma es mejor.
La estructura de los cromosomas y el contenido de los genes.
El operador de apareamiento entre ejemplares.
El operador mutación.
Parametrización del sistema (número de iteraciones, porcentaje de genes que mu-

tarán, individuos que formarán cada generación . . . ).
4.2.1. Cromosoma
El funcionamiento de un algoritmo de este tipo queda definido en gran parte por el

tipo de cromosoma que decidamos construir.
Dado que cada generación estará compuesta de un gran número de individuos, es fácil
deducir que es importante realizar un esfuerzo considerable por conseguir que el tamaño
de los genes sea el menor posible. Sin olvidar, que el cromosoma debe contener toda la
información necesaria para poder reconstruir el horario del máster.
El esquema del cromosoma utilizado es el que se muestra en la Figura 4.1.
Figura 4.1: Esquema del cromosoma utilizado
El esquema principal del cromosoma podrá seguramente comprenderse más claramente

con el ejemplo de la Figura 4.2.
28
Figura 4.2: Ejemplo del tipo del cromosoma utilizado
El cromosoma representa el máster que estamos tratando, siendo cada gen un curso
de este máster.
Cada gen contiene los dı́as de la semana y las horas a las que se imparte el curso y el
aula en el que se imparten las clases.
Si los horarios y/o el aula son diferentes entre las clases de prácticas y las de teorı́a se
crearán 2 genes para la asignatura, uno para la parte teórica y otro para la parte práctica.
Es posible que el cromosoma sea tan sencillo porque la información que se necesita
almacenar es muy poca, ya que en el momento en que queramos reconstruir el horario de
las clases del máster, podemos completar la información contenida en el cromosoma con
todos los conocimientos que ya tenemos sobre el horario en la base de datos.
Es decir, para qué almacenar el profesor que dará la clase número 10, si en la base de
datos se almacena el orden en el que imparten clase los profesores y cuántas clases da cada
uno, con lo que este dato es fácilmente deducible. Se puede aplicar este razonamiento al
resto de información que, en principio, parecerı́a deberse guardar en el cromosoma.
4.2.2. Operadores
Una vez fija la estructura del cromosoma y de sus genes, es fácil decidir cuál debe ser
el operador de apareamiento, consistirá simplemente en intercambiar algunos genes de un
individuo con los de otro.
Para que se converja a una solución con la rapidez deseada, cuántos genes y qué genes
se intercambiarán debe decidirse de forma completamente aleatoria.
El otro operador a definir es la mutación, que consistirá en modificar algunos genes del
29
4. Algoritmo de generación de horarios 4.3 Reflexiones
cromosoma, modificando el aula en el que se imparten y/o el número de clases semanales

y/o el dı́a y la hora de esas clases.
En este caso es aún más importante, si cabe, el hecho de que todas las decisiones
tomadas sean aleatorias, ya que esta operación es la encargada de diversificar la población
evitando que el algoritmo converja hacia mı́nimos locales.
4.2.3. Función de evaluación
La función de evaluación toma la información contenida en un cromosoma y en la base

de datos y reconstruye todo el horario para medir la calidad de la solución y asignarle
una puntuación que permita comparar su cualificación con la de las soluciones obtenidas
a partir del resto de cromosomas.
Considerando lo anterior, y teniendo en cuenta que el número de generaciones necesa-
rias para alcanzar la solución puede ser muy alto y que en cada generación realizaremos
un número considerable de evaluaciones, podemos darnos cuenta de que si queremos que
nuestro sistema sea eficiente necesitaremos cargar en memoria, antes de comenzar, los
valores de todos los datos que vamos a necesitar, más tarde y de forma reiterada, en cada
evaluación.
La estructura utilizada para guardar los datos necesarios en memoria, de cara a opti-
mizar las evaluaciones de los cromosomas, es la que se puede ver en el diagrama de clases
de la Figura 4.3, en el que se han omitido los atributos y muchas de las funciones y clases
menos importantes, para mostrara únicamente la estructura principal.
Durante el transcurso de esta fase se percibió que los horarios de los diferentes cursos se
podrı́an generar de forma totalmente independiente haciendo un mı́nimo esfuerzo añadido
de implementación, por lo que se decidió añadir esta funcionalidad a la aplicación.
4.3. Reflexiones
Partiendo del diseño del sistema y de las tecnologı́as elegidas la implementación se

resolvió de forma mecánica sin encontrar dificultades notables.
Contraponiendo esto con el desarrollo del calendario de la aplicación, donde la imple-
mentación fue muy tediosa, se puede ilustrar cómo la buenas elecciones durante el diseño
y acerca de las tecnologı́as a utilizar, pueden reducir enormemente el tiempo dedicado al
desarrollo de un producto software.
Aun ası́, como en el desarrollo de toda aplicación se han presentado algunas dificulta-
des:
El primer problema fue elegir el algoritmo a utilizar y una vez elegido qué herramientas
30
Figura 4.3: Diagrama de clases “resumido” del algoritmo genético
utilizar de cara a la implementación. Ante la ausencia de comparaciones creı́bles entre las

diferentes opciones, la única forma de decidir ha sido “probar” e intentar el desarrollo con
las opciones que parecı́an mejores. Lo que ha sido una tarea bastante ardua.
El siguiente problema, si es que se puede considerar ası́, fue el desconocimiento de la
librerı́a a utilizar que ha debido ser comprendida antes de comenzar la implementación,
con la consiguiente inversión en tiempo.
Probar el buen funcionamiento del programa también fue un problema debido a lo
indeterminista de la solución y a la gran cantidad e entradas posibles con muy diferentes
problemáticas.
Esto se solventó, aprovechando que el algoritmo es capaz de funcionar parcialmente
antes de que todas las funciones estén terminadas. Realizando tests sobre las funciones
por separado y el sistema completo, al tiempo que se desarrollaba la implementación,
utilizando para ello JUnit que se comenta en el Anexo E.2.3.
31
32
5. Conclusiones
Una vez finalizado el largo periodo de desarrollo, llega el momento de comprobar hasta
qué punto se han cumplido los objetivos propuestos.
El proyecto desarrollado no sólo cumple las especificaciones iniciales, sino que además
da respuesta a unas necesidades reales y cuenta con partes de software que pueden ser
reutilizadas en otros proyectos.
5.1. Utilidad del proyecto
Este proyecto partı́a de la necesidad planteada por algunos profesores del Centro Po-
litécnico Superior de mejorar el modo actual de obtención de los horarios de los másteres,
que se calculan actualmente de forma manual y rudimentaria.
Este proyecto ha intentado responder a sus necesidades, proporcionandoles una herra-
mienta que facilita la colaboración entre ellos a la hora de especificar los requisitos de los
horarios a construir, generandolos automáticamente y permitiendo su posterior consulta
y gestión.
El trabajo a realizar a sido enorme, por lo que algunos aspectos, como el atractivo
visual de la parte web, no se han podido cuidar en exceso para no alargar demasiado el
tiempo de desarrollo.
Sin embargo, se puede afirmar que la herramienta desarrollada responde a los objetivos
propuestos y está lista para ser utilizada en el momento en que los coordinadores de algún
máster lo consideren adecuado.
Además 2 de las partes más relevantes de este proyecto, el calendario principal y la
herramienta de generación de horarios, cuya eficiencia se puede apreciar en las tablas del
Anexo H, podrı́an ser reutilizadas en nuevos proyectos, ya que responden a problemáticas
muy comunes para las que no se encontraron buenas soluciones ya implementadas.
33
5. Conclusiones 5.2 Reflexión personal
5.2. Reflexión personal
La realización de este proyecto me ha llevado prácticamente el periodo docente de un

curso con dedicación a tiempo completo.
Gran parte de este tiempo, cuya utilización se detalla en el Anexo B, lo he dedicado
a ampliar mis conocimientos acerca de tecnologı́as que desconocı́a.
El tener que aprender a usar una nueva tecnologı́a antes de poder dar el siguiente paso
en el desarrollo, ha sido una tónica constante a lo largo de todo el proceso, desde GWT al
empezar a pensar en las mejores opciones a la hora de implementar un calendario, hasta
LaTeX para escribir esta memoria.
La oportunidad de desarrollar un proyecto de cierta envergadura de forma individual
desde sus inicios hasta su final, me ha hecho profundizar en bastantes de las cosas que me
habı́an enseñado durante la carrera, que ya creı́a haber aprendido en su momento, pero
que en realidad nunca habı́a tenido que llevar a la práctica.
Por último, otra de las tareas que ha supuesto un porcentaje muy alto del tiempo
de desarrollo y de la que también he aprendido mucho, ha sido el tener que elegir las
tecnologı́as a usar como base del proyecto a desarrollar. Tarea que, ahora, considero una
de las más delicadas de entre las que se deben tomar durante la elaboración de un producto
software, capaz de decidir el éxito o el fracaso del desarrollo de una aplicación.
Por otro lado, las dificultades superadas para llevar el proyecto hasta su finalización
me han dado más confianza en mı́ mismo como ingeniero y me han ayudado a orientarme
de cara al papel que quiero jugar en el mercado laboral al que pronto me enfrentaré.
5.3. Trabajos futuros
Algunos de los trabajos a realizar para mejorar la aplicación de cara a que en caso de
implantación real del sistema su utilización fuese más cómoda, o diese respuesta a nuevas
necesidades, serı́an entre otros:
Generar conjuntamente los horarios de varios másteres, lo que permitirı́a obtener

mejores resultados globales al considerar el algoritmo de forma simultánea las res-
tricciones de todos los másteres.
Posibilitar la importación y exportación de calendarios en formato iCalendar[14],
con lo que se conseguirı́a que la aplicación fuese mucho más abierta.
Aumentar las funcionalidades del sistema, permitiendo gestionar a través de él las
notas de los alumnos u otros datos relevantes para los másteres, que se pudiesen
considerar de interés.
34
5. Conclusiones 5.3 Trabajos futuros
Automatizar las tareas que realiza el administrador.
Una vez implantado el sistema, las mejoras necesarias deberı́an ser respuestas a las
peticiones y quejas de los usuarios, estas mejoras o ampliaciones de la aplicación serı́an
casi ilimitadas, puesto que el objetivo de este proyecto es la gestión integral de los másteres
de diferentes centros y este es un objetivo enormemente ambicioso y difı́cil de cumplir en
su conjunto para un caso general.
Las propuestas anteriores van dirigidas a adaptar mejor el sistema al uso para el que ha
sido diseñado, pero también se podrı́a trabajar para que sea aplicable a otros problemas
de diferentes tipos, algunas de las mejoras posibles en esta dirección serı́an:
Adaptar la aplicación para gestionar no sólo los horarios de másteres, sino también
cualquier otro tipo de horarios.
Preparar la librerı́a de creación de horarios para que su utilización en cualquier otra

aplicación y la agregación de nuevos módulos sea más sencilla.
Preparar el calendario desarrollado para que pueda utilizarse fácilmente en nuevos

proyectos.
35
36
Bibliografı́a
[1] Principios generales de usabilidad en sitios web. http://www.ainda.info/

principios_generales.html. Última consulta: 10/05/2009.
[2] Ten Usability Heuristics. http://www.useit.com/papers/heuristic/heuristic_

list.html. Última consulta: 10/05/2009.
[3] Jamie McConnell. AutoCompleter Tutorial. http://nodstrum.com/2007/09/19/

autocompleter/. Última consulta: 10/05/2009.
[4] Fergus Reig Gracia. Apache Struts. http://www.scribd.com/doc/16208187/

Pequeno-tutorial-de-Apache-Struts, 2008. Última consulta: 08/06/2009.
[5] Sistemas de Información. http://nacho.cps.unizar.es/docencia/SI/si.html.

Última consulta: 08/06/2009.
[6] Commons Pool. http://commons.apache.org/pool/. Última consulta: 08/06/2009.
[7] Struts Tiles. http://struts.apache.org/1.x/struts-tiles/. Última consulta:

08/06/2009.
[8] Struts Bean. http://struts.apache.org/1.2.x/userGuide/struts-bean.html.

[9] XStream. http://xstream.codehaus.org/. Última consulta: 08/06/2009.
[10] JavaMail. http://java.sun.com/products/javamail/. Última consulta:

08/06/2009.
[11] Animus Pactum Consulting Inc. Flooble Dynamic Calendar. http://www.flooble.

com/scripts/calendar.php, 2004. Última consulta: 10/05/2009.
[12] Google Calendar. http://www.google.com/calendar/. Última consulta:

10/05/2009.
[13] F.J. Perricone. Microsoft Schedule+. http://www.xs4all.nl/~bogaarts/

schdmenu.htm#starting-head, 2001. Última consulta: 10/05/2009.
37
[14] Internet Calendaring and Scheduling Core Object Specification. http://tools.
ietf.org/html/rfc2445. Última consulta: 08/06/2009.
[15] The InnoDB Storage Engine. http://dev.mysql.com/doc/refman/5.1/en/

innodb.html. Última consulta: 08/06/2009.
[16] PHP. http://www.php.net/. Última consulta: 10/05/2009.
[17] ASP. http://www.asp.net/. Última consulta: 10/05/2009.
[18] API de Google Calendar. http://code.google.com/intl/es-ES/apis/calendar/.

[19] Herramienta de ayuda de Google Calendar integrable. http://www.google.com/

calendar/embedhelper. Última consulta: 10/05/2009.
[20] Karl O’Keeffe. Monket Calendar. http://monket.net/wiki-v2/Monket_Calendar.

[21] Webical. http://code.google.com/p/webical/. Última consulta: 10/05/2009.
[22] FTR GWT Library. http://code.google.com/p/ftr-gwt-library/. Última con-

sulta: 10/05/2009.
[23] Lilaberg. http://www.lilaberg.com/index_esp.htm. Última consulta:

08/06/2009.
[24] Unitime. http://www.unitime.org/. Última consulta: 10/05/2009.
[25] International Timetabling Competition. http://www.cs.qub.ac.uk/itc2007/.

[26] Tablix. http://www.tablix.org/. Última consulta: 10/05/2009.
[27] David E. Goldberg. Genetic Algorithms in search optimization & Machine Learning.
The University of Alabama, 1989.
[28] Zbigniew Michalewicz. Genetic Algorithms + Data Structures = Evolution Programs.

Springer, 1996.
[29] Adolfo Sánchez Domı́nguez. Generación de horarios en el Centro Politécnico Superior.

Universidad de Zaragoza, 1998.
[30] Sergio Lapeña Navajas. Generación de calendarios de exámenes en el Centro Po-

litécnico Superior. Universidad de Zaragoza, 1999.
[31] Choco. http://choco.sourceforge.net/. Última consulta: 10/05/2009.
[32] ECLiPSe. http://www.eclipse-clp.org/. Última consulta: 10/05/2009.
38
[33] Susana Abadı́n. DIEM: Diseño e integración de exposiciones en museos. Universidad
de Zaragoza, 2002.
[34] GAUL. http://gaul.sourceforge.net/index.php. Última consulta: 10/05/2009.
[35] Google Web Toolkit. http://code.google.com/intl/es-ES/webtoolkit/. Última

consulta: 10/05/2009.
[36] Gmail. http://mail.google.com/mail/. Última consulta: 08/06/2009.
[37] Uri Boness y Roald Bankras Bram Smeets. Beginning Google Web Toolkit. Apress,
2008.
[38] Apache License 2.0. http://www.apache.org/licenses/LICENSE-2.0.html. Últi-

ma consulta: 10/05/2009.
[39] Google Code. http://code.google.com/intl/es-ES/. Última consulta:

08/06/2009.
[40] Java Genetic Algorithms Package. http://jgap.sf.net. Última consulta:

08/06/2009.
[41] GNU Lesser General Public License. http://www.gnu.org/licenses/lgpl.html.

[42] Mozilla Public License 1.1. http://www.mozilla.org/MPL/MPL-1.1.html. Última

consulta: 10/05/2009.
[43] Vincent Massol with Ted Husted. JUnit In action. Manning, 2004.
[44] Klauss Meffer. JUnit Profi-Tipps. entwickler.press, 2006.
[45] GNU General Public License. http://www.gnu.org/copyleft/gpl.html. Última

consulta: 10/05/2009.
[46] Netbeans IDE. http://www.netbeans.org/. Última consulta: 10/05/2009.
[47] Hans Bergsten. JavaServer Pages. O’Reilly, 2003.
[48] Jason Hunter y William Crawford. Java Servlet Programming. O’Reilly, 2001.
[49] Chuck Cavaness. Jakarta Struts. Anaya, 2006.
[50] Federico Barber y Miguel A. Salido. Introducción a la Programación de Restriccio-

nes. Technical report, Departamento de Sistemas Informáticos y Computación de la
Universidad Politécnica de Valencia y Departamento de Ciencias de la Computación
e Inteligencia Artificial de la Universidad de Alicante, 2003.
[51] W.F. Clocksin y C.S. Mellish. Programming in Prolog: Using the ISO Standard.
Springer, 2003.
39
[52] MySQL. http://www.mysql.com/. Última consulta: 10/05/2009.
[53] MySQL Query Browser. http://dev.mysql.com/doc/query-browser/es/index.

html. Última consulta: 08/06/2009.
[54] phpMyAdmin. http://www.phpmyadmin.net/home_page/. Última consulta:

08/06/2009.
[55] Tomcat. http://tomcat.apache.org/. Última consulta: 10/05/2009.
[56] TortoiseSVN. http://tortoisesvn.net/. Última consulta: 10/05/2009.
[57] Gantt Project. http://www.ganttproject.biz/. Última consulta: 10/05/2009.
[58] Dia. http://live.gnome.org/Dia. Última consulta: 10/05/2009.
[59] EDGE Diagrammer. http://www.pacestar.com/edge/. Última consulta:

10/05/2009.
[60] Microsoft Office. http://office.microsoft.com/es-es/. Última consulta:

10/05/2009.
[61] LEd. http://www.latexeditor.org/. Última consulta: 10/05/2009.
[62] MiKTeX. http://miktex.org/. Última consulta: 10/05/2009.
[63] BibTeX. http://www.bibtex.org/. Última consulta: 10/05/2009.
[64] John H. Holland. Adaptation in Natural and Artificial Sistems. The University of
Michigan, 1975.
[65] Juan Alonso Ramos. Configuración de una Aplicación Web en Tomcat con codifica-
ción UTF-8. http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?
pagina=tomcatUTF8, 2007. Última consulta: 10/05/2009.
40
Anexo A. Usuarios y entidades
De forma extremadamente concisa se podrı́an resumir los requisitos de la aplicación

en permitir a los diferentes tipos de usuario:
Conocer todos los datos que les sean permitidos de las entidades que componen el
sistema.
Modificar y crear todas las entidades sobre las que tengan permisos necesarios, de
entre las que forman parte del sistema.
Ası́ que los requisitos de la aplicación, se obtienen casi directamente de los datos que
pueden consultar, editar, crear y eliminar en el sistema cada uno de los tipos de usuario.
A.1. Tipos de usuario y sus privilegios
Existen 4 tipos de usuario diferentes en la aplicación, coordinador, profesor, alumno

e invitado, a continuación se enumeran las acciones que pueden realizar y los datos que
pueden consultar las personas que se encuentra bajo cada uno de estos roles.
A.1.1. Coordinador
Una persona es considerada coordinadora, si ejerce como tal en uno o más másteres,
solo gozará de las atribuciones propias de los coordinadores en las páginas referentes a los
másteres de los que es coordinador y las referentes a sus cursos.
Si un usuario, por las tareas que desempeña, es coordinador y al mismo tiempo profesor
será considerado coordinador a todos los efectos, es decir, en un máster y sus cursos se es
coordinador antes que profesor.
Las atribuciones de un coordinador son:
Ver la lista de másteres y cursos que forman parte del sistema.
41
A. Usuarios y entidades A.1 Tipos de usuario y sus privilegios
Conocer los másteres de los que es coordinador.
Ver y editar todos los datos referentes a los másteres.
Ver y editar todos los datos referentes a los cursos.
Crear profesores o buscar entre los ya creados y añadirlos como docentes a un curso
o como coordinadores a un máster.
Crear aula o buscar entre las ya creadas y añadirlas como disponibles a un curso.
Editar y ver el calendario y los datos de las aulas que ha creado.
Editar y ver los calendarios de másteres y cursos.
Ser informado vı́a email de los cambios realizados en los horarios de cursos y máste-
res.
Autorizar o rechazar las modificaciones propuestas por los profesores para los hora-
rios de los cursos, decidiendo si finalmente se realiza la modificación o no.
Generar los horarios de las clases de los másteres de forma automática.
Visitar y editar su calendario y perfil.
Ver los datos públicos de coordinadores, profesores y alumnos.
A.1.2. Profesor
Un usuario es considerado profesor, si es docente de uno o más cursos, sólo gozará de

las atribuciones propias de los profesores en las páginas referentes a cursos de los que es
profesor, siempre que no sea coordinador de los mismos, en cuyo caso será considerado
coordinador a efectos de las acciones que podrá realizar.
Las atribuciones de un profesor son:
Conocer los cursos de los que es profesor.
Ver los datos públicos referentes a los másteres.
Ver y editar todos los datos referentes a los cursos.
Ver el calendario y los datos de las aulas y editarlos en caso de que sea su creador.
Crear profesores o buscar entre los ya creados y añadirlos como docentes a un curso.
42
A. Usuarios y entidades A.1 Tipos de usuario y sus privilegios
Crear aula o buscar entre las ya creadas y añadirlas como disponibles a un curso.
Ver los calendarios de los cursos y proponer modificaciones a los coordinadores.
Ser informado vı́a email de los cambios realizados en los horarios de los cursos.
Visitar y editar su calendario y perfil.
Ver los datos públicos de coordinadores, profesores y alumnos.
A.1.3. Alumno
Se considera alumno a quien está matriculado en uno o más cursos, este rango sólo se
ostentará en esos cursos y en los másteres que los comprenden.
Las atribuciones de un alumno son:
Conocer los cursos de los que es alumno.
Ver los datos públicos referentes a los cursos.
Ver los datos de las aulas.
Ver los calendarios de los cursos.
Ser informado vı́a email de los cambios realizados en los horarios de los cursos.
Visitar y editar su perfil.
Ver los datos públicos de los coordinadores y profesores y, si se le permite explı́ci-

tamente, los de los alumnos.
A.1.4. Invitado
Una persona será considerada una invitada, cuando no esté autentificada en el sistema
o si estándolo navega por páginas no relacionadas con los cursos o másteres en los que
está implicada.
Las atribuciones de los invitados en el sistema son:
43
A. Usuarios y entidades A.2 Entidades del sistema
Autentificarse en el sistema (si aun no lo está).
Ver los datos públicos referentes a los cursos.
Ver los datos públicos de las aulas.
Ver los datos públicos de coordinadores y profesores.
A.2. Entidades del sistema
En la sección anterior se ha hecho referencia con frecuencia a datos públicos y privados

de diferentes entidades, en esta sección se detallarán dichos atributos.
A.2.1. Curso
Para un curso los datos privados serán:
Si las clases de teorı́a se realizan en el mismo aula o no que las de prácticas.
Si las clases de teorı́a se realizan en el mismo horario o no que las de prácticas.
Número de clases de teorı́a tras las que comienzan a impartirse las prácticas.
Lista de alumnos matriculados.
Y los públicos:
Nombre del curso.
Nombre del máster al que pertenece.
Año en el que se imparte o comienza su impartición.
Web del curso, si tiene otra a parte de la de la aplicación.
Horas de teorı́a del cursos.
Horas de práctica del curso.
Duración de las clases de teorı́a.
Duración de las clases de práctica.
44
Temario del curso.
Bibliografı́a relevante.
Criterios de evaluación.
Recursos que se utilizarán como herramientas docentes.
Idioma en que se imparte.
Departamento al que pertenece.
Metodologı́a de enseñanza.
Objetivos del curso.
Comentarios adicionales.
Cuatrimestre del máster en el que se imparte.
Lista de profesores.
Su calendario.
A.2.2. Máster
En el caso de un máster los datos privados serán:
Número máximo de horas seguidas de clase.
Número máximo de horas diarias de clase.
Si los alumnos tienen permisos para ver las lista de alumnos de sus asignaturas.
Lista de alumnos matriculados.
Su calendario, que contendrá las restricciones horarias impuestas por los coordina-
dores de cara a la generación de horarios.
Cambios propuestos por los profesores pendientes de aprobación pos los coordina-
dores.
Porcentaje de éxito obtenido durante la generación de horarios y restricciones que

no han podido satisfacerse.
Y lo públicos:
45
Nombre del máster.
Año en el que se imparte o comienza su impartición.
Web del máster, si tiene otra a parte de la de la aplicación.
Fecha de inicio del máster.
Fecha de finalización del máster.
Objetivos que persigue el máster.
Estructura del máster.
Información general.
Caracterı́sticas de la tesis de máster o doctoral.
Becas que se pueden solicitar.
Preguntas frecuentes.
Proceso de admisión.
Requisitos de admisión.
Comentarios adicionales sobre el máster.
Lista de cursos que lo componen.
Lista de coordinadores.
Lista de profesores.
Lista de cuatrimestres que lo componen y sus fechas de inicio y final.
A.2.3. Usuario
En el perfil de un usuario sus datos públicos serán:
Nip, que será también su nombre de usuario en la aplicación.
Nombre y apellidos del usuario.
Dirección de correo electrónico.
Web, si la tiene (en caso de tratarse de un profesor).
Área y departamento a los que está inscritos (en caso de tratarse de un profesor).
46
Cursos en los que imparte clase (en caso de tratarse de un profesor).
Másteres de los que es coordinador (en caso de tratarse de un profesor).
Y los privados:
Contraseña de acceso a la aplicación.
Número máximo de horas seguidas de clase (en caso de tratarse de un profesor).
Número máximo de horas diarias de clase (en caso de tratarse de un profesor).
Calendario personal, con las restricciones que impone a su docencia y sus eventos
personales (en caso de tratarse de un profesor).
A.2.4. Aula
Para finalizar, para un aula todos sus datos serán públicos:
Nombre del aula.
Edificio en el que se encuentra.
Descripción del aula.
Cursos que se imparten en ella.
Su calendario, con las restricciones horarias que condicionan su uso.
47
48
Anexo B. Desarrollo del proyecto
El proyecto se ha desarrollado a lo largo de un periodo muy extenso de tiempo, desde

febrero de 2008 hasta junio de 2009, más o menos un año y medio.
Al no haberse trabajando en él de forma continuada durante todo el periodo, el tiempo
realmente empleado podrı́a considerarse el equivalente a un curso académico.
B.1. Hitos del proyecto
A continuación se describe, de forma superficial, el trabajo realizado cada uno de los

meses que ha durado la realización este proyecto.
Aunque se va a proceder a comentar las tareas principales desarrolladas casa mes,
es importante mencionar que algunas tareas se han desarrollado durante varios meses o
incluso durante todo el tiempo que ha durado el proyecto, aunque sólo sean nombradas
en el momento en el que se trabajo en ellas con mayor intensidad.
En febrero de 2008 se inició el proyecto y se comenzaron a estudiar algunos entornos
que se querı́an utilizar como es el caso de Struts, ya que se consideró interesante el conocer
las herramientas disponibles antes de comenzar con el proyecto en sı́.
El trabajo en el PFC fue aparcado hasta septiembre de 2008 debido a la absorción,
por parte de otras actividades académicas, de gran parte del tiempo del proyectando.
Octubre se dedicó a establecer los requerimientos de la aplicación, realizándose gran
cantidad de reuniones con el director del proyecto, Eduardo Mena, que interpretaba el
papel de cliente y futuro usuario de la aplicación. Además, se fijó cuál serı́a el aspecto
visual de la aplicación web a desarrollar.
En noviembre se realizó el diseño de la aplicación web y de la base de datos, cuyas
versiones preliminares, se finalizó a lo largo de diciembre.
Ya en enero de 2009 se fijaron los requisitos del calendario, dedicándose gran parte
de este mes a la búsqueda y elección de la tecnologı́a que se utilizarı́a para su desarrollo.
49
B. Desarrollo del proyecto B.2 Empleo del tiempos
Febrero y marzo se dedicaron a la implementación del calendario, trabajo cuya

finalización se vio retrasada en varias ocasiones por diferentes problemas con las librerı́as
utilizadas, tal y como se ha comentado en el Anexo 3.4.
En el mes de abril se cerraron los requisitos del algoritmo de búsqueda de horarios,
se buscó la mejor forma de llevar esta tarea a la práctica y se llevó a cabo su diseño e
implementación.
Durante el mes de mayo y hasta mediados de junio se realizaron las pruebas
del sistema, especialmente las referentes a la generación de horarios y se procedió a la
redacción y revisión de la esta memoria.
B.2. Empleo del tiempos
La Figura B.1 muestra la división aproximada del tiempo de trabajo entre las diferentes
partes de la aplicación.
Figura B.1: Distribución del tiempo invertido en el proyecto
Esta gráfica permite apreciar, tal y como ya se ha comentado anteriormente, que el

calendario, que en principio no deberı́a haber sido una de las partes más trabajosas de la
aplicación, ha terminado copando gran parte del tiempo de desarrollo.
Las figuras B.2, B.3 y B.4 muestran, para cada componente de la aplicación, el por-
centaje de tiempo invertido en las diferentes fases de su desarrollo.
Las gráficas no se han obtenido a partir de los dı́as empleados en cada parte del
proyecto, sino a partir de las horas de trabajo invertidas.
Aun ası́, al ser las notas tomadas acerca de las horas de trabajo no demasiado de-
50
B. Desarrollo del proyecto B.2 Empleo del tiempos
Figura B.2: Distribución del tiempo invertido en la aplicación web
Figura B.3: Distribución del tiempo invertido en el calendario GWT
51
B. Desarrollo del proyecto B.3 Diagrama de Gantt
Figura B.4: Distribución del tiempo invertido en el algoritmo genético
talladas, deberı́an considerarse tan solo una aproximación a los tiempos empleados, que
puede resultar de gran utilidad para comprender cuál ha sido el proceso de desarrollo del
sistema.
B.3. Diagrama de Gantt
Por último, se adjunta en la Figura B.5 el diagrama de Gantt de todo el proceso.

El diagrama refleja el trabajo realizado desde septiembre de 2008 hasta junio de 2009,
que son las 2 fechas que comprenden el trabajo real en la aplicación. Dejándose fuera el
periodo comprendido entre la aceptación del proyecto y agosto de 2008, por no avanzarse
apenas en la construcción de la aplicación durante esos meses.
Dentro del periodo considerado de diseño se incluye tanto el tiempo dedicado a la elec-
ción de las tecnologı́as a utilizar, como el tiempo dedicado a estudiar dichas tecnologı́as,
antes de poder comenzar con la implementación.
52
Figura B.5: Diagrama de Gantt del proyecto
53
54
Anexo C. Base de datos
El sistema posee una única base de datos que contiene tanto los datos de interés para
los usuarios acerca de los másteres y las entidades relacionadas con ellos, como los datos
necesario para la generación de los horarios y los datos generados por esta.
A la hora de diseñar la base de datos se ha puesto mucho interés en que el modelo fuese
fácilmente ampliable, ante próximas mejoras de la aplicación, para que no se convirtiese
la base de datos en un cuello de botella que obstaculizase cambios futuros en el sistema.
Por su carácter libre, y gratuito, para proyectos de las caracterı́sticas del desarrollado,
se ha utilizado MySQL, que se presenta en el Anexo E.3, como gestor de bases de datos.
Esta opción era la más recomendada por su flexibilidad y rapidez, además de por ser
uno de los gestores mejor conocidos por la persona que iba a realizar el diseño de la base
de datos y la posterior implementación de las tablas SQL.
C.1. Modelo entidad relación
La Figura C.1 contiene el diagrama entidad relación de la base de datos desarrollada,

en él se muestra el diseño final de la base de datos.
Se han omitido en el diagrama los atributos que no son claves de ninguna entidad,
para mejorar la legibilidad, estos atributos se mostrarán cuando se comente cada entidad
en mayor detalle.
Es necesario completar el diagrama con los siguientes comentarios:
Un profesor/coordinador puede no dar clase en ningún curso o no ser coordinador

de ningún máster, pero obligatoriamente tendrá que hacer una de las 2 cosas para
estar presente en el sistema.
Un evento debe estar relacionado con un profesor, un coordinador, un aula, un curso

o un máster.
55
C. Base de datos C.1 Modelo entidad relación
Figura C.1: Modelo entidad relación “resumido” de la base de datos
C.1.1. Usuarios
El diagrama de la Figura C.2 nos permite ver qué guardamos en la base de datos 2
tipos de usuarios: los alumnos y los profesores.
Se distingue entre alumno y profesor, aunque la clase alumno no necesitarı́a una enti-
dad propia según la base de datos actual.
Esto se ha hecho para poder fácilmente ampliar la información guardada sobre los
alumnos, por ejemplo, con sus notas, si esto se decidiese durante una ampliación del
sistema. Esta es una de las mejoras más importantes, de entre las que se proponen en el
Capı́tulo 5.3.
Los profesores podrán, dependiendo de sus relaciones activas, ser coordinadores o
profesores, ser diferentes cosas para diferentes cursos y másteres o ser ambas cosas para
un mismo curso.
Los campos max h dia y max h seguidas hacen referencia al máximo número de horas
de clase seguidas y en un dı́a que no deben superar los cursos de un máster.
56
Figura C.2: Modelo de la entidad Usurio
C.1.2. Curso
El diagrama de la Figura C.3 muestra los atributos de la entidad curso, en la parte

derecha se pueden ver los atributos de interés para los usuarios que no son utilizados por
la aplicación en ninguna tarea interna.
Figura C.3: Modelo de la entidad Curso
Y en la parte izquierda se ven los que si son de interés para la aplicación, principalmente
por ser necesarios para la generación de horarios.
Los campos h teoria y h practicas contienen las horas de teorı́a y de práctica de las
que consta la asignatura, mientras que los campos h clase teor y h clase pract indican las
horas que dura una clase de teorı́a y una de práctica respectivamente.
Por su parte, los campos mismo aula y mismo horario, indican si el aula de las clases
57
de teorı́a y de las clases de práctica es la misma o si es el horario el que no varı́a. En el caso

de que el horario no varı́e, se ha tomado la decisión de considerar que el aula tampoco lo
hará.
Por último, el campo empezar prac, indica cuantas clases teóricas deben impartirse
antes del comienzo de la primera clase práctica.
C.1.3. Máster
La entidad máster cuyos atributos se pueden ver en la Figura C.4 es la más importante
de la base de datos, de ella dependen como entidades débiles 1 algunas entidades relevantes,
como los curso y los cuatrimestres.
Figura C.4: Modelo de la entidad Master
De nuevo, se muestran en la parte derecha los atributos meramente informativos y

en la izquierda los que son utilizados para la generación de horarios óptimos o en alguna
toma de decisión interna de la aplicación.
Los atributos f ini y f fin nos restringen el periodo lectivo del máster, por su parte
max h dia y max h seguidas indican las horas de clase diarias o consecutivas cuyo número
no debe superarse.
El campo ver alumno nos indica si los alumnos tendrán acceso a la lista de matriculados
en la asignatura o no, de cara a la visualización de contenidos en la página web.
1
Es decir, la clave de máster es parte de la clave de las otras entidades.
58
C.1.4. Cuatrimestre y aula
La Figura C.5 muestra 2 entidades, en primer lugar la entidad cuatrimestre, que

representa una división temporal de un máster y cuyos parámetros nos indican la duración
temporal de dicha división.
Figura C.5: Modelo de las entidades Cuatrimestre y Aula
Se considera de interés comentar que la entidad cuatrimestre se añadió al diseño una

vez iniciada la implementación de la aplicación, al descubrirse, durante la realización de
pruebas con datos reales, que algunos másteres dividen su actividad lectiva en periodos,
a los que llaman cuatrimestres, a pesar de que tengan duraciones muy variadas.
En segundo lugar se puede ver la entidad aula, a la que se identifica por su nombre y
edificio.
El aula está relacionada con su creador, para poder conocer que usuario es su autor a
la hora de decidir los permisos de edición sobre ella, esto podı́a verse en la Figura C.1.
C.1.5. Evento y mensaje
Finalmente la Figura C.6 presenta otras 2 entidades.
Figura C.6: Modelo de las entidades Evento y Mensaje
En primer lugar la entidad evento, que hace referencia tanto a las horas de clase de
un curso, como a los dı́as de fiesta de un máster, pasando por cualquier otra información
referente a un máster, un curso, un aula o un profesor que sea interesante guardar en un
calendario.
Todos los eventos relacionados con una entidad forman lo que podrı́amos considerar su
calendario. La creación de esta entidad calendario se desechó por ser innecesaria, ya que
59
para conocer el calendario de una entidad simplemente se deben buscar todos los eventos
relacionados con ella.
Los campos fecha ini y fecha fin nos muestran cuándo empieza y finaliza el evento,
estas fechas deben formar parte de un mismo dı́a.
El nivel es uno de los campos más relevantes, indica el tipo del evento, que puede ser:
Sin relevancia: La aplicación no tendrá en cuenta estos eventos.

Hora de clase: La aplicación o un usuario han fijado la impartición de una clase,
este evento sólo debe crearse relacionado con un curso.
Periodo no lectivo: Indica a la aplicación que no debe colocar horas de clase en el
rango que comprende y a los usuarios, de que se trata de un dı́a de fiesta o de horas
fuera del horario lectivo, este evento sólo debe crearse relacionado con un máster o
un curso.
Hora poco recomendada: Se indica a la aplicación que hay que evita en la medida
de los posible colocar una clase en esta hora.
Hora recomendada: Se recomienda a la aplicación colocar una hora de clase en esta
fecha.
Hora muy recomendada: Se recomienda encarecidamente a la aplicación el colocar
una hora de clase en el rango señalado.
La entidad mensaje es la segunda que se muestra en la figura, se utiliza para almace-

nar las modificaciones sugeridas sobre el calendario de un curso, que han propuesto los
profesores y que aun están pendiente de aprobación por los coordinadores.
Esta entidad estará relacionada con un evento, si la modificación a la que hace refe-
rencia es de borrado o modificación. En caso de de tratarse de una operación de creación,
no podrá existir dicha relación puesto que el evento aun no habrá sido creado.
Es por este caso, por el que es necesario que exista una relación entre mensaje y curso,
ya que en el resto de casos se podrı́a conocer el curso al que se modifica, por medio del
evento relacionado.
C.1.6. Participa
La Figura C.7 nos muestra los parámetros de la relación participa, que nos indica que
un profesor da clase en un curso dado.
La relación permite expresar, si el profesor imparte clases de teorı́a, de práctica o de
ambas, en que orden imparte clases de cada una de ellas en relación al resto de profesores
que también imparten clase en la asignatura y cuántas clases imparte.
60
C. Base de datos C.2 Claves de la implementación
Figura C.7: Modelo entidad relación de la relación Participa
Para que exista la relación es obligatorio que al menos uno de los campos, h teo
o h prac, sea no vacı́o y distinto de 0. Estos campos indican el número de horas que
impartirá ese profesor en la asignatura.
Si rellenamos h teo estaremos obligados a rellenar orden teo, que nos indica en que
posición, de entre el conjunto de profesores, comenzará ese profesor a impartir clases de
teorı́a. La misma relación existe entre h prac y orden prac.
C.2. Claves de la implementación
A partir del modelo entidad relación mostrado en la Figura C.1, se ha procedido a la

obtención del modelo relacional y a la normalización de la base de datos, como últimos
pasos previos a la escritura de las sentencias SQL.
La implementación de la base de datos se ha intentado mantener fiel al diseño, al
mismo tiempo que se primaba la eficiencia.
C.2.1. InnoDB
InnoDB [15] es una técnica de almacenamiento de datos disponible en MySQL, su

caracterı́stica principal es que soporta transacciones de tipo ACID2 , bloqueo de registros
e integridad referencial.
Que posee integridad referencial, quiere decir, que se puede exigir a una entidad que
2
Acrónimo de Atomicity, Consistency, Isolation and Durability: Atomicidad, Consistencia, Aislamiento
y Durabilidad en español.
61
C. Base de datos C.2 Claves de la implementación
uno de sus campos tenga un valor que coincida con el valor de un campo especı́fico de
otra de las entidades.
Por ejemplo, en nuestra base de datos, partiendo del modelo entidad relación de las
entidades máster y curso, que se muestra en la Figura C.8, obtendrı́amos la Tabla C.1
para los másteres y la Tabla C.2 para los cursos.
Figura C.8: Modelo entidad relación que muestra la relación entre las entidades Máster y Curso
Nombre Año ...

Biologı́a 2010 ...
Tabla C.1: Representación un máster en la base de datos (campos clave)
Máster Año Curso ......

Biologı́a 2010 Ácidos ......
Matemáticas 2010 Factoriales ......
Tabla C.2: Representación de un curso en la base de datos (campos clave)
El uso de InnoDB permite exigir a la tabla de cursos que el contenido de sus campos
máster y año coincida con el nombre y año de un máster existente. Esta es la única forma
de que la implementación realizada sea consistente con el diseño de partida y de forzar
que no se da la paradoja de que existan cursos pertenecientes a másteres inexistentes.
De esa forma el curso “Ácidos” serı́a correcto ya que pertenece a un máster existen-
te, mientras que el curso “Factorial” no podrı́a crearse al no existir un máster llamado
“Matemáticas” en el año 2010.
62
C. Base de datos C.3 Problemas encontrados
C.2.2. Disparadores
Los disparadores o triggers son procedimientos que se ejecutan cuando se cumple una
condición establecida al realizar una operación de inserción, actualización o borrado en
una base de datos.
Se han desarrollado disparadores para realizar las comprobaciones pertinentes sobre
los datos que se creen o actualicen y asegurar que los datos introducidos cumplen las
restricciones apropiadas.
Se ha hecho esto, por ser más sencillo y eficiente que realizar las comprobaciones desde
el código Java en el servidor web.
Algunas de las restricciones ası́ impuestas son, que la fecha de inicio de un máster tiene
que ser inferior a la fecha de finalización y que los nombre de los alumnos y profesores
deben ser cadenas que contengan algún carácter distinto del espacio.
Los disparadores también se han usado para crear las estructuras relacionadas con una
entidad en el momento de crear esta y para destruirlas al destruir esta.
Por ejemplo, en el momento de creación de un máster usamos un disparador para
generar un cuatrimestre asociado, que obligatoriamente debe existir, de esta forma no nos
tenemos que preocupar una y otra vez de realizar esta tarea.
C.3. Problemas encontrados
La base de datos es la misma para las 3 partes que componen la aplicación y cada una
de las ellas tiene necesidades diferentes, por lo que ha sido necesario buscar soluciones de
compromiso, especialmente durante la etapa de diseño.
Además, la base de datos ha tenido que estar en funcionamiento desde que se inició la
construcción de la aplicación hasta la finalización del proyecto, debiendo estar terminada
al mismo tiempo que las primeras versiones de la aplicación web, cuando los diseños, tanto
del algoritmo genético, como del calendario, estaban poco avanzados. Esto dificultó mucho
la obtención de un diseño óptimo.
63
C. Base de datos C.3 Problemas encontrados
64
Anexo D. Elección de las tecnologı́as
Una de las partes más importantes de cualquier proyecto software es la elección de las
tecnologı́as, que, entre las disponibles, se seleccionarán para apoyar su desarrollo.
Esto es ası́, porque sin la reutilización de herramientas, ideas y código ya realizados
por otros, cada proyecto deberı́a comenzar desde el mismo punto de partida, bloqueando
cualquier intento de progreso.
En este anexo, se van a comentar los procesos de elección de las diferentes tecnologı́as
que se han tomado como punto de partida para cada una de las partes de la aplicación.
D.1. Generación del contenido dinámico de la web
Las tecnologı́as utilizables para desarrollar las páginas web del proyecto eran muchas,
principalmente: PHP [16], ASP [17], GWT y JSP.
Al valorar GWT como la mejor opción de desarrollo para el calendario que se integrarı́a
en la web (tal y como se explica en el Anexo D.2), era deseable implementar también las
páginas web en esta tecnologı́a. De modo que se aumentase la cohesión y se facilitasen las
comunicaciones y la integración entre ambas partes del sistema.
Pero la aplicación no necesitaba una cantidad suficiente de código Javascript, ni tenı́a
la complejidad necesaria, para justificar el uso de GWT, cuyas caracterı́sticas se explican
en el Anexo E.1.1.
Entre las tres opciones más populares, PHP, ASP.NET y JSP, la balanza se inclinó del
lado de JSP, que se comenta en el Anexo E.4.1, siendo las razón principal, el permitir
implementar todas las partes de la aplicación en el mismo lenguaje, ya que las demás
partes del sistema se implementan en Java, que es el lenguaje madre de JSP.
Frente ASP.NET contaba, además, con la portabilidad como gran ventaja, al no es-
tar definida la plataforma en la que correrı́a el servidor de la aplicación y funcionar las
aplicaciones ASP “solamente” en sistemas operativos de la familia Windows.
65
D. Elección de las tecnologı́as D.2 Construcción de calendarios interactivos
D.2. Construcción de calendarios interactivos
Al repasar las exigencias que se le hacen al calendario de la aplicación en el Capı́tulo

3.1, quedaba claro que por su complejidad, no era una tarea que pudiera abordarse desde
sus inicios, sin partir de librerı́as o código ya desarrollado previamente.
Ya que esta tarea, aunque pudiese afrontarse, estarı́a muy por encima de la carga de
trabajo recomendable para un proyecto final de carrera, como el que se está desarrollando,
aun más teniendo en cuenta que el calendario es sólo una parte del total de la aplicación.
Teniendo este punto claro, se inició la búsqueda de las posibles herramientas y código,
utilizables como punto de partida.
D.2.1. Google Calendar
La primera opción fue intentar utilizar el propio Google Calendar, incrustándolo en la

página desarrollada.
Se estudió la API 1 de Google Calendar [18], llegándose a la alentadora conclusión de
que cubrı́a las necesidades que se esperaban encontrar durante la etapa de desarrollo, en
cuanto a interacción del calendario con la base de datos y la web de la aplicación.
Lamentablemente, las posibilidades de integración del famoso calendario de Google
en la página que se habı́a construido eran muy limitadas [19]: Puesto que Google sólo
permite a los desarrolladores web incrustar en sus páginas una versión de su calendario
que no permite la creación y edición de eventos, con lo que se hacı́a imposible satisfacer
la mayor parte de las restricciones iniciales siguiendo por este camino.
D.2.2. Calendarios
Desechada la opción anterior, se buscaron calendarios que poder instalar en el servidor

de la aplicación web.
El número de calendarios que se encontraron fue muy elevado, pero la exigencia de que
pudiera ser editable sin la necesidad de abandonar la página actual y, muy especialmente,
el deseo de poder arrastrar los eventos de una fecha a otra sin recargar la página, dejó fuera
a la gran mayorı́a de los candidatos iniciales.
Tras un análisis detallado de una decena de opciones, las que más se acercaron a los
requisitos exigidos fueron:
1
Del inglés Application Programming Interface, traducido al castellano como interfaz de programación
de aplicaciones.
66
D. Elección de las tecnologı́as D.2 Construcción de calendarios interactivos
Monket Calendar [20]

Este calendario reunı́a practicamente todas las funcionalidades deseadas, sin embar-
go contaba con algunos problemas importantes:
El estar escrito en PHP, ya que se preferı́a el lenguaje Java, por ser este el
lenguaje utilizado en las demás partes del proyecto.
El no haber sido actualizado desde enero 2008 y la consiguiente falta de compa-
tibilidad con algunas de las últimas versiones de los navegadores más populares.
Webical [21]
Este es un caso similar al anterior, con la salvedad de estar basado en Java. Com-
partı́a con Monket Calendar su mayor handicap, el ser un proyecto abandonado
desde principios de 2008, sin haberse alcanzado una versión estable del mismo.
FTR GWT Library [22]

FTR GWT Library, que se ha descrito en el Anexo E.1.2, no es un calendario
propiamente dicho, sino una librerı́a que brinda la mayor parte de los elementos
necesarios para construir la interfaz gráfica de un calendario.
Cuenta con un ejemplo de uso que, a pesar de sus limitaciones y defectos, puede
utilizarse como base para la creación de calendarios que usen la librerı́a.
Es un proyecto basado en GWT y por lo tanto escrito en Java, tal y como se estaba
buscando.
Además GWT es el lenguaje en el que está escrito Google Calendar que, como ya
se ha comentado anteriormente, es el calendario de referencia para el que se desea
construir, lo que es otra indudable ventaja.
El proyecto está actualmente muy activo, pero aún se encuentra en sus primeras
versiones. Por supuesto, aún se encontraba en un estado más embrionario en el
momento en el que se tomó una decisión acerca de esta cuestión.
D.2.3. Solución elegida
Podrı́a decirse que ninguna de las opciones de las que se podı́a partir era realmente
buena. Lo que se querı́a construir era algo muy especı́fico, además de complejo y poco
común y no existen aun herramientas adecuadas.
Sin embargo, al ser necesario decantarse por una de las opciones anteriores, se optó por
la utilización de FTR GWT Library.
Opción que parecı́a mucho más acertada, ya que:
Se partı́a, en principio, de una aproximación al desarrollo de calendarios mucho más

cercana al objetivo marcado en cuanto a funcionalidades.
67
D. Elección de las tecnologı́as D.3 Generación de horarios
Se basaba en GWT, lo que nos aseguraba que su funcionamiento no diferirı́a entre

los navegadores más utilizados.
Al estar escrito en Java, nos permitı́a escribir la práctica totalidad del código de este
proyecto en el mismo entorno de desarrollo y el mismo lenguaje de programación.
D.3. Generación de horarios
A la hora de encarar la construcción del generador de horarios nos encontramos 3

elecciones muy importantes, que marcarı́an el diseño y la implementación posteriores.
En primer lugar, se intentó encontrar un programa ya existente que pudiese responder
a las necesidades planteadas en el Capı́tulo 4.
Una vez se llegó a la conclusión de que esta aplicación no se iba a encontrar y era
necesario realizar una nueva, se planteó la duda de que tipo de algoritmo o metodologı́a
debı́a utilizarse.
Tomada esta decisión fue también fundamental decidir en que nos apoyarı́amos para
realizar dicha implementación.
Aunque estas 2 últimas decisiones deberı́an ser secuenciales, al ser las tecnologı́as ya
realizada alrededor de un tipo de programación, un valor fundamental a la hora de decidir
si el uso de este es aconsejable o no, se entremezcló la toma de ambas decisiones.
D.3.1. Aplicaciones ya existentes
Debido al gran número de ámbitos en los que se plantean problemáticas similares a la

que estamos intentando resolver, se encontraron gran cantidad de aplicaciones disponibles.
La utilización de uno de estos programas ya disponibles, se planteó como una buena
opción, condicionada a que el esfuerzo a realizar para que el programa encontrado encajase
dentro del sistema desarrollado fuese muy inferior, al que se intuı́a, se necesitarı́a para
desarrollar un algoritmo propio.
Algunas de las más potentes eran herramientas de pago, como es el caso de [23], o bajo
licencias que no permitı́an su utilización en el caso que estamos tratando, estas opciones
fueron directamente descartadas.
En segundo lugar, se descartaron las que se encontraban en las primeras fases de
desarrollo o llevaban tiempo abandonadas.
En la tercera criba, se descartaron las que no podı́an encajarse fácilmente en el pro-
blema tratado, por no tener posibilidad de recibir los parámetros de la búsqueda de una
68
forma apropiada o por no ser capaces de resolver problemas de complejidad similar al

planteado.
Después de la criba, algunas de las mejores opciones eran Unitime [24], que fue uno
de los 3 finalistas del International Timetabling Competition [25] de 2007 y Tablix [26]
ambos con APIs disponibles.
Finalmente, fue una prueba práctica con estas opciones, la que reveló que el proceso
de adaptación no serı́a nada sencillo, debido sobre todo a las vagas especificaciones, y que,
por tanto, el coste de integración y de adaptación no era razonable.
D.3.2. Elección del tipo de algoritmo
La generación de horarios es un problema NP-completo al que se ha intentado dar

solución de muy diferentes maneras.
De las aplicaciones que fueron estudiadas según se relata en la sección anterior, la
mayor parte utilizaban algoritmos genéticos para la obtención de los horarios, por lo que
esta fue la primera opción estudiada.
La literatura [27, 28] disponible apoyaba esta opción al considerar la generación de
horarios uno de los campos en los que un algoritmo genético podı́a ser de más utilidad e
incluso, haber sido la opción elegida para generar horarios en 2 proyectos final de carrera
[29, 30] de este mismo centro.
La programación con restricciones, presentada en el Anexo E.5 del anexo, parecı́a, por
sus caracterı́sticas, otra opción muy recomendable para la generación de horarios.
El hecho de que no se encontrasen prácticamente ejemplos prácticos de ello, hizo más
interesante la tarea de probar si era una técnica que podı́a aplicarse eficientemente a este
problema.
Al analizar el problema a resolver y compararlo con las posibilidades de ambos para-
digmas se pudieron apreciar 2 importantes ventajas de los algoritmos genéticos:
En el problema que estamos resolviendo, puede que algunas restricciones no puedan

satisfacerse y que queramos priorizar el cumplimiento de unas sobre otras.
Esto es muy sencillo, casi obligado, al utilizar algoritmos genéticos, pero bastan-
te trabajoso en la mayorı́a de las implementaciones de lenguajes orientados a la
programación con restricciones.
Como se explica en el Capı́tulo 4.2, otra de las necesidades que plantea el problema
a resolver es que el algoritmo decida el número de clases semanales y posteriormente
asigne un horario a cada una.
69
Al igual que en el caso anterior, la programación usando algoritmos evolutivos daba

muchas más facilidades, que la programación mediante restricciones.
Hay que hacer notar que al hablar acerca de las dificultades ofrecidas por la programa-
ción con restricciones, estamos haciendo referencia a 2 intentos reales de implementar el
sistema mediante la librerı́a Choco [31] y el lenguaje ECLiPSe [32], que fueron las opcio-
nes que se consideraron más interesantes para abordar este problema y que se comentan
en el Anexo E.5.
D.3.3. Elección de la tecnologı́a
Una vez decidido que se iba a desarrollar un algoritmo genético se intentó buscar la
mejor forma de afrontar el problema a resolver.
En primer lugar, se planteó el desarrollar desde cero el algoritmo, pero, puesto que
una gran parte del código de este tipo de algoritmo puede mantenerse estático mientras
se cambia su aplicación, parecı́a que hacer esto serı́a una decisión poco inteligente, al
desaprovechar la oportunidad de reutilizar código ya existente.
En segundo lugar, se planteó tomar como punto de partida el algoritmo genético
desarrollado dentro del proyecto [33]. Algoritmo que ya habı́a demostrado su eficiencia
para la distribución de cuadros en museos.
Al comprobarse que su adaptación serı́a complicada por no haber sido diseñado pen-
sado en su reutilización, se comenzaron a buscar librerı́as, si diseñadas con ese fin.
Descartando en un primer paso soluciones no basadas en el lenguaje Java, en el que ya
se estaba desarrollando el resto de la aplicación. Esto dejó fuera algunas de las opciones
más interesantes, como era el caso de GAUL [34], al no ser Java, sino C++, el lenguaje
más popular para este tipo de librerı́as.
Entre las restantes no fue difı́cil ver que la mejor opción, por reputación, número de
usuarios, aplicaciones ya construidas y calidad de los manuales disponibles era JGAP, que
se presenta en el Anexo E.2.2.
70
Anexo E. Tecnologı́as utilizadas
Para cumplir su objetivo global de gestionar los horarios de los másteres, la aplicación
desarrollada ha tenido que dar solución a diferentes problemas, necesitando cada uno de
ellos de tecnologı́as completamente diferente para ser desarrollado.
A continuación se explican, intentando dar una idea general, las tecnologı́as más re-
levantes de entre las utilizadas en el desarrollo de la aplicación, omitiendo aquellas que
pueden considerarse universalmente conocidas.
E.1. GWT para la construcción de calendarios
El calendario, necesario para la visualización y edición de eventos, está escrito en GWT

utilizando la librerı́a FRT GWT Library.
E.1.1. Google Web Toolkit
Google Web Toolkit[35], también conocido por las siglas GWT, es un framework de
desarrollo en Java publicado por Google Inc.
Su finalidad es facilitar la escritura de aplicaciones AJAX, proceso nada sencillo debido
a la poca estandarización y a la gran variedad de tecnologı́as implicadas.
La gran utilidad de las aplicaciones AJAX, radica en que se ejecutan en el cliente, es
decir, en el navegador de los usuarios, mientras se mantiene la comunicación ası́ncrona
con el servidor en segundo plano. De esta forma, es posible realizar cambios sobre las
páginas, sin necesidad de recargarlas, lo que significa aumentar la interactividad, velocidad
y usabilidad de las aplicaciones.
Al utilizar GWT el programador escribe código Java usando cualquier entorno de
desarrollo (IDE) de Java, como Eclipse o NetBeans, y el compilador lo traducirá a HTML
y JavaScript que se ejecutará en la máquina cliente y Java Servlets que se ejecutarán en
el servidor web, este proceso se puede observar en la Figura E.1.
71
E. Tecnologı́as utilizadas E.1 GWT para la construcción de calendarios
Figura E.1: Esquema de funcionamiento de GWT
Para la comunicación entre el código GWT del lado cliente y el del lado servidor,
utiliza el protocolo de “Llamada a un Procedimiento Remoto”, que permite a un programa
ejecutar código en otra máquina remota, sin tener que preocuparse por las comunicaciones.
Otra ventaja importante que posee, es que el código generado funciona en todos los
navegadores, lo que facilita enormemente el trabajo del programador e incrementa sus-
tancialmente su rendimiento. Ya que escribiendo directamente el código Javascript, de-
berı́amos, en muchos casos, realizar diferentes implementaciones para cada uno de los
navegadores.
Además, no hay que olvidar que, incluso dejando esto a un lado, la depuración de
código Java es mucho más sencilla que la de código Javascript.
Su popularidad ha aumentado rápidamente desde su lanzamiento en 2006, ya que es
usado por gran parte de las conocidas herramientas de Google, como son Gmail [36] y
Google Calendar. Para profundizar más en esta tecnologı́a se puede consultar [37].
En este proyecto se ha utilizado la versión 1.4.62 de GWT, el motivo principal por el
que se escogió esta versión y no una posterior, fue el aumento de la potencia de cómputo
necesaria para la compilación del código, en las versiones más recientes.
Al no utilizarse máquinas de gran potencia en el desarrollo de este proyecto, el tiempo
de compilación del sistema usando la versión 1.5, o superiores, no era asumible.
72
E. Tecnologı́as utilizadas E.2 Algoritmos genéticos usando JGAP
E.1.2. FRT GWT Library
La librerı́a FRT GWT Library [22] es un proyecto de software libre desarrollado bajo
licencia Apache License 2.0 [38] y alojado en Google Code [39].
La finalidad de esta librerı́a, es facilitar la creación de calendarios con un estilo si-
milar al del Google Calendar [12] de Google Inc., para lo que proporciona una serie de
componentes de interfaz de usuario de gran utilidad.
El ejemplo de uso de la librerı́a, es un sencillo calendario, con un funcionamiento
rudimentario y gran cantidad de errores, que es un punto de partida de gran utilidad para
las aplicaciones que vayan a usar la librerı́a.
Mención especial merece la nula documentación, la falta de comentarios en el código
y la gran cantidad de errores que se pueden encontrar en la librerı́a y que complican
bastante su utilización.
La versión de esta librerı́a que se ha utilizado es la 0.95, que era la última versión
disponible en el momento del inicio del proyecto.
E.2. Algoritmos genéticos usando JGAP
El corazón de la aplicación es el algoritmo que encuentra los horarios óptimos para

los másteres, teniendo en cuenta las restricciones planteadas. En este algoritmo se han
empleado las siguientes tecnologı́as.
E.2.1. Algoritmos genéticos
Los algoritmos genéticos, en los que se profundiza más en el Anexo G, son una lı́nea de
la inteligencia artificial cuyas bases fueron sentadas a mediados de los años 70 por John
Henry Holland.
Su lógica se fundamenta en los principios de la teorı́a de la evolución de Darwin, según
la cual los individuos de una población compiten en la búsqueda de recursos y de pareja,
teniendo más posibilidades de sobrevivir y de pasar sus genes a la siguiente generación
los individuos más adaptados.
De forma que, los genes de individuos mejor adaptados se propagan en sucesivas ge-
neraciones, consiguiendo que los individuos vayan mejorando su adaptación al medio.
Por analogı́a, los algoritmos genéticos trabajan con una población de individuos, cada
uno de los cuales, representa una solución factible a un problema dado.
A cada individuo se le asigna un valor o puntuación, dependiendo de cuanto se acerque
73
E. Tecnologı́as utilizadas E.2 Algoritmos genéticos usando JGAP
a la solución deseada. Cuanto mayor sea la puntuación, mayor será la probabilidad de que
el mismo sea seleccionado para reproducirse, cruzándose con otro individuos seleccionados
de igual forma, lo que dará lugar a los individuos de la nueva generación.
Al tiempo que este proceso se repite, se producen en los individuos mutaciones alea-
torias, que introducen en la población caracterı́sticas que posiblemente ningún individuo
tenı́a hasta este momento.
La aplicación reiterada de mutaciones y cruces entre individuos, generación tras ge-
neración, hace que la población de posibles soluciones del problema converja hacia la
solución.
De todo lo anterior se desprende que las partes fundamentales de un algoritmo genético
son, la función de evaluación que asigna una puntuación a cada individuo, el operador
de cruce que debe combinar 2 individuos para dar como resultado uno nuevo mezcla de
ambos, el operador mutación que debe modificar de forma aleatoria el código genético
de los individuos y, especialmente, los cromosomas que conforman la identidad de cada
individuo que deben ser capaces de representar todas las posibles soluciones al problema.
E.2.2. Java Genetic Algorithms Package
El Java Genetic Algorithms Package 1 [40] es un framework 2 , escrito en Java, orientado

a dar soporte a la escritura de programas evolutivos y la implementación de algoritmos
genéticos.
Es software libre publicado bajo las licencias LGPL [41] y MPL 1.1 [42]
Permite a los programadores olvidarse de escribir el código perteneciente a la estruc-
tura del algoritmo genético, permitiendo que se centren en solucionar el problema al que
se enfrentan.
Cuenta con el especial atractivo de tener buenos manuales de referencia, un código
muy depurado y haber sido utilizada por una gran cantidad de aplicaciones conocidas.
A lo largo del desarrollo del proyecto actual, se ha ido utilizando en cada momento
la última versión disponible de esta librerı́a, ya que resulta muy sencilla la actualización.
Siendo la versión 3.4.2, la que se utilizaba en el momento de finalizar el sistema.
1
Al que haremos referencia, de ahora en adelante, mediante las siglas JGAP.
2
Estructura de soporte definida, mediante la cual otro proyecto software puede ser organizado y
desarrollado.
74
E. Tecnologı́as utilizadas E.3 MySQL
E.2.3. JUnit
JUnit [43, 44] es un conjunto de bibliotecas utilizadas en programación para hacer

pruebas unitarias de aplicaciones Java.
Permite evaluar los métodos de las clases Java comprobando que, a partir de un dato
de entrada dado, el método devuelve el resultado esperado.
Gracias a JUnit, se puede probar de forma controlada y metódica el funcionamiento
de las diferentes clases y, lo más importante, se pueden repetir de forma automática las
pruebas después de realizar modificaciones en alguno de los métodos de una clase. Con lo
que nos aseguramos de no haber roto algo que ya funcionase antes.
La versión utilizada de las librerı́as para realizar los tests sobre las clases del proyecto
ha sido la 3.8.2.
E.3. MySQL
MySQL es un sistema de gestión de base de datos relacional, multihilo y multiusuario

que puede trabajar en entornos cliente/servidor o incrustados.
Al decir que es una base de datos relacional, estamos diciendo que almacena todos los
datos en forma de relaciones, pensando en cada relación como si fuese una tabla compuesta
por diferentes registros y columnas.
Para operar sobre las bases de datos utiliza el lenguaje SQL3 , que es el lenguaje más
común para la consulta y modificación de bases de datos relacionales.
Su rapidez, junto a su fiabilidad y su facilidad de uso, hacen de MySQL uno de los
gestores de bases de datos más populares del mundo, con más de 6 millones de usuarios.
Se encuentra disponible bajo licencia GNU GPL [45], siendo necesaria la compra de
licencias por las empresas que quieran incorporarla a sus productos privativos.
La versión utilizada de MySQL durante el desarrollo de la aplicación, a sido la 5.0.51a,
pero el funcionamiento del sistema deberı́a ser igualmente correcto en cualquier versión
posterior.
3
Siglas en Ingles de “Structured Query Language”, traducido al castellano como lenguaje de consulta
estructurado.
75
E. Tecnologı́as utilizadas E.4 Java orientado a la generación web
E.4. Java orientado a la generación web
La página web de la aplicación ha sido generada dinamicamente a partir de código Java,

a excepción de lo que simplemente era código HTML, que debı́a permanecer inmutable
en cada recarga de la aplicación web y de alguna pequeña función Javascript.
Las versiones utilizadas de las tecnologı́as que se citan a continuación, han sido ele-
gidas por ser las más recientes, que contaban con herramientas de soporte integradas en
NetBeans 6.0.1[46], que ha sido el entorno de desarrollo utilizado para la escritura del
código de las páginas web.
E.4.1. JavaServer Pages
JavaServer Pages 4 [47] es una tecnologı́a basada en Java para la generación dinámica
de contenidos web, fue desarrollado por Sun Microsystems, empresa que lo distribuye bajo
licencia libre.
La gran utilidad de JSP, radica en facilitar enormemente la escritura de servlets [48],
permitiendo mezclar el código Java con el HTML de forma muy intuitiva, mediante el uso
de etiquetas predefinidas o de las etiquetas que uno mismo construya.
Los servlets son programas escritos en Java, que se ejecutan normalmente en servidores
web, su finalidad es generar páginas web de forma dinámica, a partir de los parámetros
de las peticiones que reciba del navegador.
La versión utilizada de JSP para generara las páginas del proyecto ha sido la 1.2.
E.4.2. Struts
Struts [49] es una estructura de soporte para el desarrollo de aplicaciones web, bajo el
patrón Modelo Vista Controlador y el lenguaje Java.
El Modelo Vista Controlador, en el que se profundiza más en el Anexo E.6, es un patrón
de arquitectura de software cuyo uso es muy frecuente en el desarrollo de aplicaciones web
y cuya caracterı́stica principal es separar los datos de una aplicación, la interfaz de usuario,
y la lógica de control, en tres componentes distintos.
Struts es software libre desarrollado por Apache Software Foundation desde el año
2000, momento desde el cual su popularidad no ha hecho más que crecer.
Una de sus caracterı́sticas más identificables, es el uso de ficheros a los que llama
Action para definir que hacer al recibir una petición desde una página web y ficheros a
4
JSP, a partir de ahora.
76
E. Tecnologı́as utilizadas E.5 Programación con restricciones
los que bautiza como ActionForms para recoger los datos de los formularios web.
Cuenta con sus propias etiquetas JSP, de cara a facilitar tareas, como la internacio-
nalización de las páginas creadas y la reutilización de código.
La gran mayorı́a de las funcionalidades de Struts están orientadas a facilitar el diseño
y programación de la parte del sistema a la que el Modelo Vista Controlador, llama
“Controlador”.
Se ha utilizado en el desarrollo de la aplicación la versión 1.2.9 de Struts.
E.4.3. Jmaki
JMaki es un marco de trabajo para el desarrollo de aplicaciones web basadas en el uso

de AJAX.
Genera de forma automática el código Javascript necesario, dando patrones para la
interacción de este con el servidor y proporcionando una serie de widgets 5 de gran utilidad.
Su caracterı́stica más importante es el manejo de eventos de publicación y suscripción,
pero también da soporte a otras necesidades, como el diseño de plantillas CSS o la creación
de componentes de interfaz de usuario.
JMaki puede ser utilizado en conjunción con varias tecnologı́as del lado del servidor,
incluyendo PHP, Phobos y JavaServer Pages.
Por su funcionalidad, podrı́a ser comparable a GWT, del que se habló en el Anexo
E.1.1, la diferencia radica en que JMaki es mucho más rápido tanto en su aprendizaje,
por su sencillez, como en la ejecución de su código, por su pequeño tamaño. Por su parte,
GWT, es mucho más completo y potente.
Por lo que, GWT estará indicado para el desarrollo de aplicaciones de gran compleji-
dad, mientras que el uso de JMaki será mucho más fructı́fero si lo que se desea es brindar
a la web en desarrollo la posibilidad de responder dinámicamente a unos pocos eventos.
La versión utilizada de esta librerı́a en este proyecto ha sido la 1.8.1.
E.5. Programación con restricciones
La programación mediante restricciones [50] es un paradigma de programación, donde

las relaciones entre las diferentes variables son expresadas mediante restricciones.
Utilizando este paradigma modelaremos los problemas a resolver mediante un conjunto
5
Componentes gráficos, o de control, con los cuales el usuario interactúa.
77
E. Tecnologı́as utilizadas E.6 Modelo Vista Controlador
finito de variables, un dominio de valores para cada variable y un conjunto de restricciones

que acotan la combinación de valores que las variables pueden tomar.
El objetivo es encontrar un valor para cada variable, de manera que se satisfagan todas
las restricciones del problema.
Una vez modelado el problema, se utilizarán de forma oculta al programador, técnicas
de consistencia o algoritmos de búsqueda para dar con la solución del problema.
Generalmente es utilizado en la resolución de problemas NP-completos, especialmente
en el área de la planificación de tareas.
Para implementar algoritmos basados en programación con restricciones, existen mul-
titud de opciones, dos de las más importantes, que fueron las estudiadas para el desarrollo
de esta aplicación son:
E.5.1. Choco
Choco [31] es la librerı́a Java, de carácter libre, más popular para la programación
basada en restricciones.
E.5.2. ECLiPSe
ECLiPSe [32] es un lenguaje de programación basado en Prolog [51] que posee su

propio entorno de desarrollo y que ha sido liberado recientemente.
E.6. Modelo Vista Controlador
El Modelo Vista Controlador, o simplemente MVC, es un patrón de arquitectura de

software que separa los datos de una aplicación, la interfaz de usuario y la lógica de
control, de la siguiente forma:
Modelo: Representa la información con la que opera el sistema.
Vista: Es la interfaz de usuario, muestra los datos de la foma apropiada para que el
usuario pueda interactuar con ellos.
Controlador: Responde a las acciones del usuario produciendo cambios en el modelo,

que generalmente también se reflejan en la vista.
78
El uso de este modelo es muy frecuente en el desarrollo de aplicaciones web, como es

el caso de su uso durante el desarrollo del presente proyecto. Para este caso podrı́amos
concretar la descripción de sus partes de la siguiente forma:
Modelo: La parte de la aplicación que interactúa directamente con la base de datos.
Vista: Páginas HTML, que pueden ser generadas dinámicamente a partir de páginas
JSP, PHP o de otras tecnologı́as similares.
Controlador: Recibe las peticiones de las páginas web e interactúa con el mode-
lo según le indiquen dichas peticiones, finalmente carga una nueva página web o
actualiza la que se estaba mostrando.
La finalidad de utilizar el patrón MVC es mejorar la calidad del diseño, facilitando la

implementación del código y, sobre todo, su reutilización y mantenimiento.
79
80
Anexo F. Software de apoyo
A continuación se presentan las principales aplicaciones utilizadas como apoyo al desa-

rrollo del proyecto.
Netbeans IDE 6.0.1 [46] como entorno de desarrollo de todo el software que compone
el sistema.
MySQL 5.0.51a [52] como sistema gestor de bases de datos.
MySQL Query Browser [53] y phpMyAdmin [54] para administrar de forma gráfica la
base de datos.
Tomcat 6.0.18 [55] como servidor de la aplicación web.
TortoiseSVN 1.6.1 [56] como sistema de control de versiones.
Gantt Project 2.0.7 [57] para construir el diagrama de Gantt del proyecto.
Dia 0.96.1 [58] y EDGE Diagrammer 6.0 [59] para la realización de los gráficos y
diagramas incluidos.
Microsoft Office Excel 2007 [60] para elaborar las gráficas que muestran el desarrollo
del proyecto.
LaTeX para la confección de esta memoria:
LEd 0.526300 [61] como entorno gráfico para escribir los documentos.
MiKTeX 2.7 [62] como distribución TeX/LaTeX para Microsoft Windows XP.
BibTeX 2.7 [63] para generar la bibliografı́a de esta memoria.
81
F. Software de apoyo
82
Anexo G. Algoritmos genéticos
Los algoritmos genéticos son hoy en dı́a una de las lı́neas más prometedoras de la
inteligencia artificial. En este capı́tulo se va a dar una pequeña explicación de su historia
y su funcionamiento, para una introducción más amplia se puede consultar [28, 27].
G.0.1. Historia
Las bases del funcionamiento de los algoritmos genéticos fueron desarrolladas por John
Holland a mediados de los 70.
Holland, desde pequeño, se preguntaba, cómo podı́a la naturaleza crear seres cada
vez más perfectos. Fue esta inquietud la que le llevó, al iniciarse en el campo de la
programación, a buscar un algoritmo que:
1. Imitara los procesos adaptativos de los sistemas naturales.

2. Diseñara sistemas artificiales que retuviesen los mecanismos de los sistemas natura-
les.
Sus ideas cristalizaron en 1975 en el libro “Adaptation in Natural and Artificial

Sistems”[64], base de la programación evolutiva.
Serı́a uno de sus alumnos David Goldberg quien conseguirı́a aplicar, por primera vez,
los algoritmo genéticos a problemas realmente complejos, popularizándolos y convirtiéndo-
los en una herramienta realmente difundida.
En 1999 se demostrarı́a hasta donde puede llegar su potencial, al patentarse un tipo
de antena, dirigida a un uso muy especı́fico, no diseñada por un ser humano sino por una
algoritmo genético construido a tal efecto.
G.0.2. Caracterı́sticas
Los algoritmos genéticos son programas computacionales cuyo fin es imitar el proceso
de “selección natural”, que según las teorı́as de Darwin rige el curso de la evolución, para
83
G. Algoritmos genéticos
resolver problemas de búsqueda y optimización.

En la naturaleza los individuos de una población compiten entre sı́ en la búsqueda de
recursos tales como comida, agua y refugio. Incluso los miembros de una misma especie
compiten a menudo en la búsqueda de un compañero.
Aquellos individuos que tienen más éxito en sobrevivir y en atraer compañeros tie-
nen mayor probabilidad de generar un gran número de descendientes. Por el contrario,
individuos poco dotados producirán un menor número de descendientes.
Esto significa, que los genes de los individuos mejor adaptados se propagarán en su-
cesivas generaciones hacia un número de individuos creciente.
La combinación de buenas caracterı́sticas provenientes de diferentes ancestros, produce
individuos cuya adaptación es mucho mayor que la de cualquiera de sus antepasados.
De esta manera, las especies evolucionan logrando unas caracterı́sticas cada vez mejor
adaptadas al entorno en el que viven.
Los algoritmos genéticos usan una analogı́a directa con el comportamiento natural.
Trabajan con una población de individuos, cada uno de los cuales representa una solución
factible a un problema dado.
A cada individuo se le asigna un valor o puntuación, relacionado con la calidad de
dicha solución. En la naturaleza esto equivaldrı́a al grado de efectividad de un organismo
para competir por unos determinados recursos.
Cuanto mayor sea la adaptación de un individuo al problema, mayor será la probabi-
lidad de que el mismo sea seleccionado para reproducirse, cruzando su material genético
con otro individuo seleccionado de igual forma.
Por el contrario, cuanto menor sea la adaptación de un individuo, menor será la pro-
babilidad de que dicho individuo sea seleccionado para la reproducción, y por tanto de
que su material genético se propague en sucesivas generaciones.
Los cruces entre ejemplares producirán nuevos individuos – descendientes de los ante-
riores – los cuales heredarán algunas de las caracterı́sticas de sus padres.
De esta manera se produce una nueva población de posibles soluciones, la cual reempla-
za a la anterior y verifica la interesante propiedad de que contiene una mayor proporción
de buenas caracterı́sticas en comparación con la población anterior.
Ası́, a lo largo de las generaciones, las buenas caracterı́sticas se propagan a través de la
población. Favoreciendo el cruce de los individuos mejor adaptados, van siendo exploradas
las áreas más prometedoras del espacio de búsqueda.
Si el algoritmo genético ha sido bien diseñado, la población convergerá hacia una
solución óptima del problema.
84
El poder de los algoritmos genéticos proviene del hecho de que son una técnica robusta,
y pueden tratar con éxito gran variedad de problemas provenientes de diferentes áreas.
Y aunque no se garantiza que el algoritmo genético encuentre la solución óptima del
problema, existen evidencias empı́ricas de que encuentra soluciones de un nivel aceptable,
en un tiempo competitivo con el resto de algoritmos de optimización combinatoria.
Son especialmente recomendados estos algoritmos en problemas para los cuales no
existan técnicas especializadas de resolución y no se conozca ningún algoritmo que de la
solución con certeza en un tiempo razonable.
Las caracterı́sticas fundamentales de los algoritmos genéticos son:
Son algoritmos estocásticos, es decir, ejecuciones distintas pueden dar soluciones

diferentes.
Son algoritmos de búsqueda múltiple, luego dan varias soluciones.
Hacen una barrida del subespacio de posibles soluciones válidas siendo, de entre los
algoritmos estocásticos, de los más explorativos disponibles, lo que consigue que no
sean dependiente de la posición inicial.
Por su grado de penetración casi nulo, la convergencia asociada al algoritmo es

excepcionalmente rápida.
La optimización es función de la representación de los datos, este es el concepto

clave dentro de los algoritmos genéticos, ya que una buena codificación puede hacer
la programación y la resolución muy sencillas.
Es una búsqueda paramétricamente robusta, lo que quiere decir que si la represen-

tación es la adecuada el algoritmo terminará convergiendo.
Los algoritmos genéticos son intrı́nsecamente paralelos. Esto significa que, indepen-
dientemente de que lo hayamos implementado de forma paralela o no, buscan en
distintos puntos del espacio de soluciones de forma concurrente, por lo que, en caso
de necesidad, la paralelización del código es casi inmediata.
G.0.3. Funcionamiento
El esquema de ejecución de un algoritmo genético se muestra en la Figura G.1.

Cada una de las posibles soluciones al problema es representada mediante un cromo-
soma, el conjunto de dichas soluciones formará una población.
Se requiere una función de evaluación que debe ser diseñada para cada problema de
manera especı́fica. Dado un cromosoma particular, la función de evaluación le asigna
85
Figura G.1: Esquema del algoritmo genético simple
un número real, que se supone refleja el nivel de adaptación al problema del individuo
representado por el cromosoma.
Durante la ejecución del algoritmo, serán seleccionados un porcentaje de individuos
como padres para la reproducción. La selección de padres se efectúa mediante el proce-
dimiento de la ruleta sesgada, es decir, al azar usando un procedimiento que favorezca
a los individuos mejor adaptados, asignando a cada individuo una probabilidad de ser
seleccionado que es proporcional a su función de evaluación.
Según este esquema, los individuos bien adaptados se escogerán probablemente varias
veces por generación, mientras que, los pobremente adaptados al problema, no se esco-
gerán más que de vez en cuando. Estos individuos seleccionados serán los que se cruzarán
generando hijos.
Más tarde, sobre algunos de los individuos actuará un operador de mutación. Nueva-
mente evaluaremos cada uno de los individuos (padres e hijos), para después escoger a los
mejores, para que formen la siguiente población.
Las condiciones de parada más habituales para este tipo de algoritmos, son la conver-
gencia del algoritmo genético, el hallazgo de una solución lo suficientemente buena o bien
la superación de un numero máximo de generaciones exploradas.
86
Anexo H. Eficiencia de la generación de
horarios
Se considerará que la generación de horarios es más eficiente en cuanto que se obtengan

horarios de una calidad mayor, en un tiempo menor.
Se han utilizado 2 casos reales para ver como varı́a la calidad de la solución obtenida,
el número de iteraciones necesarias y el tiempo de búsqueda en función del número de
ejemplares, que establezcamos para la población del algoritmo genético.
El uso de datos reales para las pruebas era obligado para conocer las exigencias que
se le harán al sistema durante su vida útil.
El hecho de que solo se hayan realizado pruebas con 2 másteres se ha debido a que la
introducción de los datos en la aplicación debe hacerse de forma manual, por no contar las
páginas oficiales de los másteres con ningún estándar que facilite su lectura automática,
lo que hace que la introducción de datos sea un laborioso trabajo de muchas horas.
Los datos obtenidos no sólo tienen una utilidad teórica, sino que también indican los
valores con los que se debe configurar la aplicación, de cara a mantener una relación
óptima entre el tiempo de espera, hasta obtener una solución y la calidad de esta.
Los 2 casos reales utilizados son:
El Programa Oficial de Posgrado en Ingenierı́a Informática del curso 2008/20091 .

El máster en Ingenierı́a Biomédica del curso 2008/2009 2 .
Las siguientes cifras dan una idea del tamaño de la base de datos de la aplicación con
los 2 másteres cargados:
120 profesores, algunos de los cuales dan clases en ambos másteres.

71 asignaturas.
1
Sitio oficial en la URL: http://webdiis.unizar.es/POPinformatica/
2
Sitio oficial en la URL: http://i3a.unizar.es/postgrado/index_master.php
87
H. Eficiencia de la generación de horarios
H.1 Resultados de los experimentos
4300 eventos en sus calendarios, tan solo para reflejar los dı́as festivos y las horas
de clase.
6,6 MB de datos, la gran mayorı́a de ellos ocupados por eventos de los calendarios.
El gran número de eventos que conforman los calendarios es el responsable de que,

cada vez que generamos de forma automática el horario de un máster, el tiempo medio
de guardado de los eventos que representan las horas lectivas en la base de datos sea de
unos 18 segundos, para los 2 ejemplos tratados.
H.1. Resultados de los experimentos
Las siguientes tablas H.1 y H.2 muestran los resultados experimentales obtenidos para
cada uno de los másteres sometidos a pruebas.
Ejemplares Iteraciones Éxito ( %) Tiempo (milisegundos)

5 233.1 96.226289572725268 52713
10 252.8 98.07325603276512 133065
15 249.5 98.70594573278724 175693
20 248.1 98.95248228912996 222058
25 277.8 99.23871540845694 293920
30 274.1 99.43361121872924 343875
35 288.8 99.57024905911001 409470
40 265.4 99.58925202014611 430873
45 280.3 99.60026358755813 480482
50 271.6 99.61996015054241 510956
Tabla H.1: Resultados del Programa Oficial de Posgrado en Ingenierı́a Informática
Los resultados mostrados son medias obtenidas tras cientos de repeticiones de los
experimentos, cada campo de las tablas simboliza:
Ejemplares: Número de ejemplares que conforman la población viva en cada gene-

ración, es el factor que se ha fijado en cada experimento para hallar los otros.
Iteraciones: Número de generaciones necesarias para alcanzar el mejor resultado

posible con el número de ejemplares dado, más ejecuciones no mejorarı́an el resultado
obtenido.
Éxito: Porcentaje de éxito del algoritmo genético, este porcentaje se calcula en

función a una solución perfecta hipotética que puede no existir.
88
H. Eficiencia de la generación de horarios H.2 Análisis de los resultados
Ejemplares Iteraciones Éxito ( %) Tiempo (milisegundos)

5 229.1 94.509410773602 49528
10 292.5 95.79666507672879 121711
15 305.5 96.34068805419058 204045
20 327.2 96.76729297636369 259189
25 328.1 96.98105474647926 305490
30 311.6 97.02807052461087 341625
35 279.7 97.16600392565954 356928
40 292.8 97.30863696571224 422520
45 347.0 97.54647445576083 540946
50 303.9 97.54681108106625 551368
Tabla H.2: Resultados del máster en Ingenierı́a Biomédica
Comparar las soluciones obtenidas, con esta solución hipotética, es obligatorio al

no haber un algoritmo conocido que en todos los casos devuelva la mejor solución
posible. En caso de existir dicho algoritmo, el desarrollo de este sistema de generación
de horarios hubiera sido innecesario.
Para poder apreciar en perspectiva los resultados de las pruebas realizadas habrá que
tener en cuenta que las soluciones obtenidas tendrán un porcentaje de éxito compren-
dido entre el 95 % y el 100 % y que podrı́amos considerar inaceptables las soluciones
que obtengan un porcentaje de éxito inferior al 96 %.
Esto es fácilmente entendible observando las listas de restricciones no cumplidas en
cada caso, por ejemplo con un porcentaje de éxito del 95 % estaremos incumpliendo
392 restricciones para el Programa Oficial de Posgrado en Ingenierı́a Informática,
mientras que para un porcentaje de éxito del 99 % inclumplirı́amos solamente 5.
Tiempo: Milisegundos utilizados para dar con la mejor solución posible para el
número de ejemplares dado.
H.2. Análisis de los resultados
Los algoritmos genéticos resultan, en parte, impredecibles y para un mismo problema

y configuración del algoritmo los resultados pueden variar mucho.
Sin embargo, como era razonable esperar, en media, a mayor número de ejemplares por
generación, obtenemos un mejor resultado y necesitamos un tiempo mayor para alcanzar
la solución.
Aunque no se vea reflejado en las tablas, hay que tener en cuenta que también existe
una relación creciente entre el número de ejemplares y la memoria utilizada en el cálculo
89
H. Eficiencia de la generación de horarios H.2 Análisis de los resultados
de la solución.
Un dato curioso es que el número de iteraciones necesarias para llegar a una solución
óptima no parece tener una relación clara con el número de ejemplares vivos, aunque
como el tiempo por ejecución crece rápidamente con el número de ejemplares, el tiempo
de cómputo global si que crece.
El aumento de la calidad del resultado es muy rápido al principio pero se ralentiza
a medida que se va aumentando el número de ejemplares, esto hace que la inversión en
tiempo sea menos rentable al ir creciendo la población.
A la vista de los resultados obtenidos se ha considerado que 45 ejemplares por evolución
es un buen valor para fijar como predeterminado en la aplicación desarrollada, ya que la
relación calidad tiempo no parece recomendar ir más allá.
En cuanto al número de iteraciones máximas se fijará en 500, de forma que en la
mayorı́a de los casos la ejecución finalice por haber convergido a una solución, y sólo se
detenga el proceso de forma artificial en unos pocos casos al rebasarse un número de
ejecuciones, que se podrı́a considerar desmedido.
Si nos olvidamos de las conclusiones generales y nos fijamos en los datos obtenidos
para cada máster, vemos que los resultados del primero han sido mucho mejores que los
del segundo.
Analizando minuciosamente los casos parece posible inferir que al tener el máster en
Ingenierı́a Biomédica horario solo de tarde, le cuesta más al algoritmo colocar las clases
en posiciones válidas del horario. Es decir, que cuanto más restrinjamos el horario lectivo
del curso más le costará al programa encontrar una solución óptima, aun en el caso de
que la proporción de clases y horas disponibles se mantenga constante.
90
Anexo I. Manual de usuario
Este anexo contiene el manual de usuario de la aplicación web, si bien es probable que
su consulta no sea necesaria debido a lo sencillo e intuitivo de su manejo, es posible que
sea de gran utilidad en algún caso concreto.
Algunos colores o textos, o la disposición de algunos elementos, pueden variar mini-
mamente entre las capturas de la aplicación que aquı́ se mostrarán y la versión definitiva
del sistema, estas variaciones serán mı́nimas y no impedirán en ningún caso que la lectura
de este manual aclare cualquier duda acerca del uso de esta aplicación.
Antes de comenzar a detallar el funcionamiento de cada página de la aplicación, se
considera necesario comentar, que sea cual sea la página en la que nos encontremos, si
existe información más detallada sobre cualquier campo que se muestre, podremos acceder
a ella dirigiéndonos a la página que contiene esa información haciendo clic sobre dicho
campo, esta será la forma natural de navegar por los contenidos de la aplicación.
I.1. Tipos de usuario
El aspecto y funcionalidad de la aplicación variarán en función del rol con el cual

está identificado el usuario en cada momento.
Es importante recordar, que el rol del usuario cambiará dinámicamente en función
de la relación que tenga con el contenido de la página visitada, es decir, si un usuario
es profesor de un curso, al entrar en la página de este lo hará como profesor, pero si
a continuación pasa a la página de un curso en el que no es profesor, la aplicación lo
reconocerá como invitado.
Tipos de usuario y principales atribuciones:
Coordinador de un máster: Puede editar su perfil, los másteres de los que es coor-
dinador y los cursos que forman parte de él. Puede crear coordinadores, aulas,
profesores y alumnos. Lo cursos de los que es coordinador aparecerán destacados.
Profesor de un curso: Puede editar su perfil y los cursos de los que es profesor. Puede
91
I. Manual de usuario I.2 Cabecera
crear aulas, profesores y alumnos. Sus ediciones sobre los calendarios de los cursos
deberán ser autorizados por los coordinadores. Lo cursos de los que es profesor
aparecerán marcados.
Alumno de un curso: Sólo puede consultar los datos públicos de la aplicación y

editar su perfil. Los cursos en los que está matriculado aparecerán destacados.
Invitado (no autentificado o no relacionado con la página visitada): Podrá ver los
datos públicos de la web.
Debido a que una persona puede cambiar de rol al pasar de visitar una página a otra,
no se han realizado versiones del manual independientes para cada tipo de usuario, sino
que las explicaciones relativas a todos ellos se encuentran entrelazadas en cada punto, del
mismo modo en el que podrán intercalarse en la aplicación real.
I.2. Cabecera
En la parte superior de todas las páginas se encuentra la cabecera, que en el caso de

no estar autentificado en el sistema, tendrá el aspecto que se muestra en la Figura I.1.
Figura I.1: Cabecera de las páginas, que se muestra si no se está identificado
En el caso de estarlo, la cabecera que se podrá ver, será la de la Figura I.2.
Figura I.2: Cabecera de las páginas, que se muestra si se está identificado
Las funciones de los botones son:
Inicio: Volver a la página de inicio.
Acceder: Ir a la página de autentificación.
Mi perfil: Visitar el perfil del usuario con el que se ha accedido al sistema.
Salir: Cerrar la sesión actual y volver a la página de inicio.
Se podrá comprobar rápidamente, si se está autentificado en el sistema o no y, en caso

de estarlo, como qué usuario, ya que el nip del usuario activo se mostrará en la parte
superior derecha de la pantalla.
92
I. Manual de usuario I.3 Página principal
I.3. Página principal
En la página principal se mostrará la lista de másteres que forman parte del sistema,
de la forma en que se puede ver en la Figura I.3.
Estarán ordenados temporalmente de forma que los más recientes, que son los que más
frecuentemente serán accedidos, aparezcan en la parte superior de la página.
Figura I.3: Lista de másteres disponibles
A la izquierda del nombre aparecerá el perfil del usuario en dicho máster, en caso de no
haber iniciado sesión, el perfil será siempre el de invitado y en caso de estar autentificado
el perfil variará en función de cada máster y de las normas explicadas en el Anexo I.1.
Se deberá hacer clic, con el botón izquierdo del ratón, sobre el máster cuya información
se quiera editar o consultar.
I.4. Página de un máster
La página de un máster contiene una gran cantidad de información, por ello se en-
cuentra dividida en pestañas, que podremos desplegar en el momento que lo deseemos, en
función de que esa información nos sea de interés o no. Esto se ha hecho también, para
reducir los tiempos de carga de la página.
Por eso, al cargar la página, la veremos tal y como se muestra en la Figura I.4.
93
I. Manual de usuario I.4 Página de un máster
Figura I.4: Página principal de un máster para un coordinador
A continuación se explica brevemente la función de cada una de las partes en que se

divide la página.
I.4.1. Información principal
Contiene la información más relevante acerca del máster.

El nombre, el año, la web y el periodo que abarca el máster, serán campos visible por
todos los usuarios, tal como se muestra en la Figura I.5.
El año de inicio, indica el año de comienzo del máster y sirve junto con el nombre para
identificar un máster, ya que solo puede existir un máster por nombre y año.
El campo web, podrá ser editado por los coordinadores y podrá coincidir con la URL
de la página en la que nos encontramos en este momento o ser cualquier otra página que
contenga información relevante acerca del máster, si la hubiera.
Los coordinadores podrán editar las fecha de inicio y de finalización del máster, es-
94
Figura I.5: Cuadro que muestra la información principal de un máster, para usuarios no coordinadores
tas fechas servirán de guı́a a quienes visiten la página, para conocer entre que fechas se
desarrollan las clases del máster y también serán utilizadas durante la generación au-
tomática de horarios, para intentar enmarcar en el periodo que comprenden, las clases de
la asignatura.
El resto de campos serán solamente visibles y editables por coordinadores, pudiendo
especificar estos, de cara a la generación automática, el número de horas de clase que no
se quiere superar en un dı́a y el número de hora de clase consecutivas cuyo número no se
quiere superar.
Además, para proteger la privacidad de los alumnos, se podrá especificar si se desea
que los alumnos puedan ver el nombre, los apellidos y el email de sus compañeros de
máster.
I.4.2. Cuatrimestres del máster
El número de cuatrimestres y las fechas que los comprenden, será información consul-
table por todos los usuarios en el recuadro que se puede ver en la Figura I.6.
Figura I.6: Cuadro que muestra información sobre los cuatrimestres de un máster, para usuarios no
coordinadores
Los coordinadores podrán modificar el número de cuatrimestres si ası́ lo desean, para,

a continuación, ajustar uno por uno, el intervalo que abarca cada uno de ellos.
Para esto se podrá rellenar el campo manualmente o usar un calendario desplegable,
como se muestra en la Figura I.7.
95
Figura I.7: Cuadro que muestra información sobre los cuatrimestres de un máster, para usuarios coordi-
nadores
I.4.3. Coordinadores del máster
Los coordinadores que forman parte de un máster serán visibles por todos los usuarios,
ası́ como su email y página web.
Los coordinadores además, podrán añadir nuevos coordinadores al máster usando el
campo con atocompletado que se encuentra en la parte superior del panel.
Al escribir texto en este campo, se devolverán como candidatos los profesores que se
encuentren dentro de la base de datos de la aplicación, aun no sean coordinadores del
máster y cuyo nombre, apellidos, email o nip comience con el texto escrito.
Si no ha sido creado todavı́a el profesor que se desea añadir, deberemos hacer clic
en “Crear uno nuevo”, opción que aparecerá al escribir cualquier texto en el campo con
autocompletado. Esto se comprenderá con mayor facilidad al visualizar la Figura I.8.
Al hacer esto, se desplegará un formulario en el que rellenaremos los datos del nuevo
profesor, es especialmente importante el email, que será la dirección a la que se envı́e la
contraseña de la cuenta que se creará para el nuevo profesor. El profesor ası́ creado se
añadirá automaticamente al máster como coordinador.
I.4.4. Cursos del máster
Los cursos del máster, junto al cuatrimestre en el que se imparten y nuestro rol en
dicho curso, serán campos visibles por todos los usuarios.
Los coordinadores podrán además, añadir cursos al máster del mismo modo en el que
se explicaba en el punto anterior, como hacerlo para los coordinadores. Esto se muestra
96
Figura I.8: Ejemplo de sugerencias del sistema al añadir coordinadores
en la Figura I.9.
I.4.5. Profesores del máster
Todos los usuarios podrán ver que profesores imparten clase en algún curso del máster
y la web y email de estos.
No se podrán añadir profesores desde esta ventana, los profesores se añadirán desde
las páginas de los cursos y aparecerán automáticamente en el máster que contenga dichos
cursos.
I.4.6. Alumnos del máster
Esta información será visible en un cuadro como el de la Figura I.10 para coordinadores
y profesores del máster, también podrán verla los alumnos si ası́ lo han especificado los
coordinadores.
97
Figura I.9: Cuadro que muestra información sobre los cursos de un máster, para usuarios coordinadores
Figura I.10: Cuadro que muestra información sobre los alumnos de un máster
I.4.7. Información relevante
Esta información estará disponible para todos los usuarios, aunque solo será editable
por los coordinadores.
El contenido de cada punto deberı́a ajustarse lo máximo posible a su tı́tulo, pero
esto dependerá del máster en cuestión, por lo que la información contenida puede variar
mucho.
La finalidad de los datos aquı́ contenidos, es dar una idea acerca de las caracterı́sticas
principales del máster, de cara a que pueda sea consultada por las personas interesadas.
98
I.4.8. Cambios pendientes de ser aprobados
Esta sección sólo es visible por los coordinadores, en ella podrán ver una lista con
todos los cambios en los horarios de las clases de las asignaturas del máster, que hayan
sido propuestos por los profesores de las diferentes asignaturas.
Estos cambios podrán aceptarse, con lo que se realizarán de forma definitiva en el
calendario, o rechazarse, borrándose la sugerencia de cambio de la lista.
Los cambios sugeridos podrán ser la edición, supresión o creación de una clase, los 3
casos pueden verse en la Figura I.11.
I.4.9. Calendario
En la sección que se muestra en la Figura I.12, todos los usuarios podrán ver los
horarios de los cursos que conforman el máster.
Los usuarios registrados podrán editar su horario personal y modificar los horarios de
los cursos del máster, en función de los derechos que tuviesen sobre ellos.
Los coordinadores podrán ver y editar, además de los calendarios nombrados anterior-
mente, el calendario del máster. Para más información sobre la edición del calendario se
debe consultar el Anexo I.9.5.
Otras de las atribuciones de los coordinadores, será la de importar el calendario de
festivo de otro máster. Este calendario lo conforman las horas y dı́as que han sido marcados
como no lectivos.
La utilidad de esto es no tener que introducir, una y otra vez, la lista de dı́as festivos
de un mismo centro o ahorrar el especificar las horas del dı́a que serán lectivas para un
máster, si estas ya se ha especificado para otro.
La opción más importante que tendrán disponible los coordinadores, será generar el
horario del máster automáticamente, pulsando el botón “Generar”, lo que borrará las ho-
ras de clase previamente asignadas a cada curso y les asignará unas nuevas, que cumplirán
en la medida de lo posible con los requisitos introducidos por coordinadores y profesores.
Al terminar la generación del horario, se mostrarán sobre el calendario el porcentaje
de éxito de la operación y la lista de restricciones que no han podido cumplirse, tal y
como se muestra en la Figura I.13.
Los horarios podrán regenerarse tantas veces como se desee, obteniéndose cada vez
resultados diferentes, aunque el porcentaje de éxito alcanzado se mantendrá, más o menos,
constante.
99
I. Manual de usuario I.5 Página de un curso
Figura I.11: Cuadro que muestra los cambios pendientes de aprobación en los calendarios de los cursos
I.5. Página de un curso
En esta página podemos consultar y modificar la información de un curso, al igual que

en el caso de las páginas de másteres la página se divide en pestañas que desplegaremos
según nuestros deseos. Por ello, al cargar la página la podremos ver como en la Figura
I.14.
A continuación se comenta cada parte de la página por separado.
100
Figura I.12: Cuadro que muestra el calendario de un máster para un coordinador
I.5.1. Información principal
Aquı́ se pueden ver los campos que identifican al curso, junto con el cuatrimestre del
máster en el que se imparte. Esta información será visible por todos los usuarios y editable
por profesores y coordinadores, de la forma en que se muestra en la figura I.15.
I.5.2. Aulas del curso
Profesores y coordinadores podrán ver y aumentar la lista de aulas disponibles para

impartir clase de este curso, por su parte el resto de usuarios solamente podrán ver esta
información, del modo en el que se ve en la Figura I.16.
101
Figura I.13: Informe de la generación de un horario
Figura I.14: Cuadro que muestra el calendario de un máster para un coordinador
102
Figura I.15: Cuadro que muestra la información principal de un curso para un coordinador
Figura I.16: Cuadro que, para no coordinadores, muestra la información sobre las aulas de un curso
I.5.3. Alumnos del curso
Los alumnos podrán ver al resto de alumnos del curso, si ası́ lo ha especificado el
coordinador del máster. Por su parte, profesores y coordinadores podrán, además de ver,
añadir alumnos al curso, tal y como se muestra en la Figura I.17.
I.5.4. Cursos que son prerrequisitos
Se muestra la lista de cursos del máster, que es necesario haber cursado con anterio-
ridad a este. Profesores y coordinadores, pueden ampliar dicha lista del mismo modo en
el que ya se ha visto como añadir aulas y alumnos.
I.5.5. Profesores del curso
Los usuarios que no sean profesores, ni coordinadores podrán ver la lista de profesores.
Por su parte, los que si lo sean, podrán, además, añadir profesores ya existentes o crear
nuevos profesores para ser añadidos, tal y como se puede ver en la Figura I.18.
Acerca de los profesores que tienen docencia asignada en el curso, los usuarios auto-
rizados podrán variar cuantas clases de teorı́a y de prácticas dan y el orden en que las
imparten (dentro del total de clases prácticas y teóricas de la asignatura).
En el caso especial, de que se quiera que 2 profesores impartan clase al mismo tiempo,
simplemente se tendrá que hacer coincidir su orden en la impartición de clases.
103
Figura I.17: Cuadro que muestra los alumnos matriculados y el formulario para agregar uno nuevo
Figura I.18: Cuadro que muestra los profesores de un máster para usuarios con derechos de edición
I.5.6. Información relevante
Esta información será visible por todos los usuarios y editable sólo por profesores y
coordinadores.
La información aquı́ mostrada, deberı́a dar una idea general sobre el curso en cuestión,
a las personas interesadas en él.
104
I.5.7. Datos para la generación de horarios
Aquı́ los coordinadores y profesores podrán especificar, las pautas que quieren que
se sigan durante la generación automática de horarios. Pudiendo indicar mediante el
formulario que se muestra en la Figura I.19:
El número de horas de teorı́a y su duración.
El número de horas de práctica y su duración.
Si la impartición de teorı́a y práctica debe ser en el mismo aula, en el mismo aula

y horario o si sus aulas y horarios son independientes.
Cuantas clases de teorı́a quieren darse antes de la primera clase de práctica.
Figura I.19: Cuadro que muestra los datos para la generación del horario del curso
I.5.8. Calendario
Se mostrará el calendario del curso y el del usuario, si lo tuviera.

Los derechos de edición sobre los calendarios serán los que correspondan al usuario
según lo comentado en los anexos I.1 y I.9.
También desde aquı́, los coordinadores podrán generar el horario del curso, si bien se
recomienda generar los horarios de todo el máster al mismo tiempo, ya que el resultado
global obtenido será más óptimo. La forma de generar los horarios será la misma, que la
explicada para las páginas de másteres.
105
I. Manual de usuario I.6 Página de un aula
I.6. Página de un aula
En la página de la Figura I.20 podremos ver nombre, edificio y descripción de un aula.
Figura I.20: Cuadro con la información principal de un aula
Además, si somos los creadores del aula, podremos ver y editar su calendario y su
descripción.
I.7. Página de un usuario
Esta página será solamente editable por el usuario que sea su propietario.
En el caso de los alumnos, mostrará al resto de usuarios autorizados su nip, nombre,
apellidos, email y los cursos en que está matriculado.
Si el usuario activo es un alumno, verá su página como la que se muestra en la Figura
I.21, en ella podrá editar el email en el que reciben los mensajes de la aplicación y que
se muestra al resto de usuarios y su clave de acceso al sistema, además de consultar los
horarios de todos los cursos en los que está matriculado.
Si el usuario es un profesor o coordinador, la página que se mostrará será la de la
Figura I.22 en la que se podrán ver su nip, nombre, apellidos y email, además del área y
departamento a los que pertenece, los cursos de los que es profesor y los másteres de los
que es coordinador.
El profesor propietario de la página, podrá además, editar esta información e informar
a la herramienta de generación de horarios de cuantas horas de clase consecutivas no desea
superar y cual es el número de horas que quiere impartir, como máximo, en un mismo
dı́a. También podrá editar su calendario personal y ver los horarios de sus cursos.
I.8. Página de identificación
Mediante la página que se muestra en la Figura I.23, se realizan las autentificaciones

en el sistema.
106
I. Manual de usuario I.8 Página de identificación
Figura I.21: Página personal de un alumno
Figura I.22: Página personal de un profesor
Para conseguirlo, únicamente hay que dar un usuario y contraseña válidos. El usuario
será siempre el nip de la persona y la contraseña será, en un primer momento, la que
hayamos recibido por correo electrónico al ser dados de alta y, más tarde, la que el propio
usuario haya elegido.
Marcaremos recordarme en este equipo, si no queremos tener que volver a autentifi-
107
I. Manual de usuario I.9 Calendarios
carnos las próximas veces que entremos en el sistema.
Figura I.23: Página de autentificación
I.9. Calendarios
A continuación, se dan las pautas necesarias para el uso correcto de los calendarios de
la aplicación. Esta es la parte del manual cuya lectura es más recomendable, al introducir
conceptos poco corrientes como el de “sugerencia de modificaciones”.
I.9.1. Tipos de calendarios
En las diferentes páginas de la aplicación podemos ver diferentes calendarios, con

diferentes significados.
El horario del máster, es el que deberá contener su horario lectivo y los dı́as festivos,
ası́ como eventos importante para todos sus cursos. Este calendario solo podrá ser editado
por los coordinadores autorizados.
El horario de un curso, contendrá el horario de las clases de ese curso, ası́ como
otros eventos de interés relacionados con él. Este calendario tendrá la peculiaridad de que
podrá ser editado de forma convencional sólo por coordinadores, los profesores podrán
solamente sugerir cambios a los coordinadores.
Esto quiere decir, que cuando un profesor intente realizar una modificación en las
clases de uno de sus cursos, esta modificación no se hará efectiva en la base de datos del
sistema, sino que se enviará a los coordinadores para que decidan si aceptan el cambio o
desean desestimarlo.
El calendario de un usuario contendrá las restricciones temporales que le afecten a él,
de cara a impartir clase en los diferentes cursos en los que participa.
Los calendarios personales, de los profesores y coordinadores, serán modificables y
visibles solo por sus propietarios.
En los horarios de las aulas se harán constar las restricciones horarias para su utiliza-
ción y otros eventos que sean relevantes para su uso. Estos calendarios podrán ser editados
únicamente por el creador del aula, que será un profesor o coordinador.
108
I.9.2. Tipos de eventos
Los eventos de los calendarios pueden ser de los siguientes tipos:
Hora muy recomendada: Durante la duración de este evento se recomienda encare-

cidamente al generador de horarios colocar una clase.
Hora recomendada: Durante la duración de este evento se recomienda al generador

de horarios colocar una clase.
Sin relevancia: Este evento no será tenido en cuenta por el generador de eventos, su
funcionalidad principal es informar a los usuarios, que vean el calendario, de alguna
actividad.
Hora poco recomendada: Este evento marca un periodo en el que, se recomienda al

generador de horarios, no colocar ninguna clase.
Periodo no lectivo: Los eventos de este tipo marcan, principalmente, los dı́as de
fiesta y las horas fuera del horario lectivo.
Hora de clase: El evento es una clase de una asignatura.
I.9.3. Colores de los calendarios
El color de los calendarios nos informa de nuestros privilegios de edición sobre ellos:
Azul: Podemos realizar modificaciones.
Verde: No podemos realizar modificaciones.
Morado: Podemos sugerir modificaciones sobre las horas de clase y modificar libre-
mente los eventos que no sean horas lectivas.
I.9.4. Ventana de edición de eventos
La creación y edición de eventos se realiza mediante el cuadro de diálogo de la Figura

I.24.
Utilizándolo, fijaremos el dı́a que se produce el evento y las horas que comprende (no
pueden crearse eventos que comprendan horas de más de un dı́a).
Para indicar, que un evento dura todo un dı́a, se podrá marcar la casilla de verifica-
ción que se encuentra a la derecha del dı́a, o rellenar los campos horarios normalmente,
especificando que el evento comprende de las 0 a las 24 horas.
109
Figura I.24: Cuadro de diálogo de edición de eventos
Fijaremos también el nombre del evento y daremos una pequeña descripción sobre el.
Podremos además, asignarle un calendario de entre los que estén disponibles en este
momento y un tipo de ente los presentados en el Anexo I.9.2.
Si queremos crear eventos que se repitan de forma periódica, podremos utilizar para
ello las opciones de la parte inferior del cuadro.
Este cuadro de diálogo será también utilizado para borrar eventos, pulsando el botón
pertinente.
I.9.5. Panel de calendarios
En el panel de la Figura I.25, se ven los calendarios disponibles en cada momento, los
calendarios se cargan en función del usuario y de la página visitada.
Los que estén marcados, serán los que se veremos en el calendario y los que podremos
editar, es decir:
Los eventos de los calendarios no marcados, no serán visibles mientras permanezcan

en este estado. Es útil que se desmarquen los calendarios en cuyos eventos no se
está interesado, para hacer la comprensión del calendario más sencilla.
No podremos crear, editar o borrar eventos de calendarios cuya casilla de verificación

no esté marcada.
110
I. Manual de usuario I.10 Alertas
Figura I.25: Panel que muestra los calendarios disponibles
I.9.6. Manejo
Mediante los botones del panel principal podremos elegir entre las diferentes vistas
disponibles, estas serán dı́a, semana, mas y año. Las figuras I.26, I.27, I.28 y I.29 son
capturas de cada una de estas vistas.
En todas ellas, podremos editar y crear eventos, a excepción de la vista anual, en la
que no es posible, ya que su utilidad radica en poder conocer de un solo vistazo cuáles
son los dı́as de un año con eventos marcados.
El desplazamiento temporal se realizará haciendo uso del calendario de la parte su-
perior izquierda o de las flechas que se encontrarán en la parte superior de la vista que
tengamos desplegada en ese momento. Además, se tendrá disponible el botón “Hoy” para
regresar a la fecha actual.
Para ver los datos de un evento, simplemente se tendrá que hacer clic sobre él. Mientras
que, para crear un evento, se deberá hacer clic sobre un espacio libre del calendario,
normalmente sobre la posición en la que se quiera que aparezca el evento.
Para editar eventos, se debe pinchar sobre ellos, para, a continuación, realizar los cam-
bios mediante el cuadro de diálogo presentado en el Anexo I.9.4 o simplemente arrastrar,
alargar o encoger los recuadros que los representan.
I.10. Alertas
Se mandarán alertas por email a los usuarios para comunicarles datos que puedan ser
de su interés urgente.
111
Figura I.26: Vista diaria del calendario
Se recibirá un correo electrónico al ser dado de alta en el sistema, comunicando el

nombre de usuario y la contraseña a utilizar.
Además, todos los dı́as se enviará un email a todos los usuarios con las modificaciones
efectuadas durante el dı́a en los horarios de los cursos de los que son coordinadores,
profesores o alumnos, si las hay.
La dirección de correo en la que se reciben las alertas, puede modificarse desde la
página de perfil de cada usuario.
112
Figura I.27: Vista semanal del calendario
113
Figura I.28: Vista mensual del calendario
Figura I.29: Vista anual del calendario
114
Anexo J. Manual del administrador
La aplicación desarrollada está lista para su uso, aun ası́ siempre será necesario un
administrador que se haga cargo de ella. En una primera fase para su instalación y más
tarde para su mantenimiento.
J.1. Tomcat
La aplicación ha sido probada en la versión 6.0.18 de Apache Tomcat en entornos

Windows y Linux, aunque es lógico suponer que el funcionamiento de la aplicación será el
correcto en otros sistemas y contenedores de Servlets.
Se ha realizado un esfuerzo considerable por evitar modificar ningún fichero de con-
figuración de Tomcat y ası́ facilitar el funcionamiento de la aplicación en entornos con
privilegios restringidos.
Sin embargo, al formar parte de las URLs los nombres de los másteres y cursos y al
poder estos contar con tildes, será necesario especificar en la configuración de Tomcat que
queremos utilizar la codificación UTF-8, que es la que espera recibir la aplicación, para
que las tildes no sean leı́das como caracteres extraños [65].
Para esto, deberemos modificar el fichero DIRECTORIO_INSTALACION_TOMCAT\conf\
server.xml, añadiendo el atributo URIEncoding=“UTF-8” en la etiqueta <Connector
port=“8080” . . . />, ya que es aquı́ donde se especifica el comportamiento que sigue
Tomcat cuando recibe peticiones a través del puerto 8080, que es su puerto por defecto.
El resultado final deberá ser algo similar al que se muestra a continuación:
<Connector p o r t = ‘ ‘8080 ’ ’ maxHttpHeaderSize = ‘ ‘8192 ’ ’
maxThreads = ‘ ‘150 ’ ’ minSpareThreads = ‘ ‘25 ’ ’
maxSpareThreads = ‘ ‘75 ’ ’ enableLookups = ‘ ‘ f a l s e ’ ’
r e d i r e c t P o r t = ‘ ‘8443 ’ ’ acceptCount = ‘ ‘100 ’ ’
connectionTimeout = ‘ ‘20000 ’ ’ disableUploadTimeout = ‘ ‘ t r u e ’ ’
URIEncoding = ‘ ‘UTF−8 ’ ’ />
Una vez hecho esto sólo habrá que copiar los 2 ficheros que forman la aplicación,
115
J. Manual del administrador J.2 MySQL
“ftr-gwt-demo.war” y “HorarioMaster.war” de la carpeta DVDPROYECTO\otrosAnexos\

aplicacion\ a la dirección DIRECTORIO_INSTALACION_TOMCAT\webapps\.
Al lanzar Tomcat ya podremos acceder a la aplicación en la URL URL_TOMCAT\masters
J.2. MySQL
La aplicación ha sido probada en la versión 5.0.51a de MySQL que forma parte de la

versión 1.6.6a de Xampp, corriendo en entornos Windows y Linux.
Por supuesto, es de esperar un funcionamiento correcto para otras versiones de MySQL,
en los sistemas operativos probados, o en cualquier otro.
J.2.1. Configuración
Aunque se ha intentado que la aplicación funcione sin realizar cambios sobre la confi-
guración estándar de MySQL, esto no ha podido evitarse por completo.
Es necesaria la modificadión del fichero DIRECTORIO_INSTALACION_MYSQL\bin\my pa-
ra activar el uso del tipo de tabla “Innodb”.
Para conseguir esto se deberá substituir la lı́nea:
s k i p −innodb
Por el siguiente párrafo:

#s k i p −innodb
# Uncomment t he f o l l o w i n g i f you a r e u s i n g InnoDB t a b l e s
i n n o d b d a t a h o m e d i r = C: /xampp/ mysql / data /
i n n o d b d a t a f i l e p a t h = ibdata1:10M:autoextend
i n n o d b l o g g r o u p h o m e d i r = C: /xampp/ mysql / data /
i n n o d b l o g a r c h d i r = C: /xampp/ mysql / data /
# You can s e t . . b u f f e r p o o l s i z e up t o 50 − 80
# o f RAM but beware o f s e t t i n g memory usage t oo h igh
s e t −v a r i a b l e = i n n o d b b u f f e r p o o l s i z e =16M
s e t −v a r i a b l e = i n n o d b a d d i t i o n a l m e m p o o l s i z e =2M
# S e t . . l o g f i l e s i z e t o 25
s e t −v a r i a b l e = i n n o d b l o g f i l e s i z e =5M
s e t −v a r i a b l e = i n n o d b l o g b u f f e r s i z e =8M
i n n o d b f l u s h l o g a t t r x c o m m i t =1
s e t −v a r i a b l e = i n n o d b l o c k w a i t t i m e o u t =50
d e f a u l t −s t o r a g e −e n g i n e=innodb
116
J. Manual del administrador J.2 MySQL
J.2.2. Creación de la base de datos
Una vez concluido el paso anterior tenemos que lanzar MySQL y crear la base de datos
de la aplicación y el usuario que utilizará para acceder a ella.
De forma predeterminada, la aplicación trabajará con la base de datos “masters”,
situada en la dirección predeterminada de MySQL jdbc:mysql://localhost:3306.
Debemos crear esta base de datos y cargar en ella las tablas y Triggers contenidos en
los ficheros DVDPROYECTO\otrosAnexos\sql\tablas.sql y DVDPROYECTO\otrosAnexos\
sql\triggers.sql.
Si ası́ se desea, se podrán también cargar los datos de ejemplo contenidos en los ficheros
de la carpeta DVDPROYECTO\otrosAnexos\sql\ejemplos\.
Una vez hecho esto crearemos el usuario “usuario” de contraseña “nosena” y le daremos
los permisos necesarios para que pueda realizar las operaciones Select, Insert, Update y
Delete sobre la base de datos de la aplicación.
Con esto se ha finalizado la preparación de la base de datos y la aplicación puede
empezar a funcionar.
Si no queremos usar la base de datos y el usuario predeterminados, deberemos seguir
los pasos que se especifican en el Anexo J.2.3.
J.2.3. Base de datos a utilizar
Uno de los cambios sobre la configuración estándar de la aplicación, que se presen-

tará con mayor frecuencia, será la modificación de los parámetros de conexión a la base
de datos.
Para facilitar esta tarea se ha hecho que la aplicación lea estos parámetros de un fichero
llamado confbd.xml que deberá tener un esquema como el siguiente:
<bd>
<username>Nombre de u s u a r i o</ username>
<password>Contrase ña</ password>
<u r l>D i r e c c i ó n de l a base de d a t o s</ u r l>
</bd>
En caso que se desee utilizar la configuración predeterminada, no es necesario que

exista este fichero, pero en caso de existir deberı́a tener el siguiente aspecto:
<bd>
<username>u s u a r i o</ username>
<password>nosena</ password>
<u r l>j d b c : m y s q l : // l o c a l h o s t : 3 3 0 6 / m a s t e r s ? autoReconnect=t r u e</ u r l>
117
J. Manual del administrador J.3 NetBeans
</bd>
Para que dicho fichero sea cargado al arrancar la aplicación, tiene que encontrase en el
fichero en el que Tomcat (o el servidor utilizado) vaya a buscarlo, normalmente en Tomcat
esta dirección será DIRECTORIO_INSTALACION_TOMCAT\bin.
J.3. NetBeans
Todo el software que se ha elaborado durante este proyecto, ha sido desarrollado en

NeBeans versión 6.0.1, bajo sistemas operativos de la familia Windows.
La aplicación está formada por 3 proyectos NetBeans por lo que se recomienda es-
te entorno de desarrollo para realizar modificaciones en el código fuente. Aunque, por
supuesto, estos proyectos pueden fácilmente migrarse a otros entornos, especialmente a
Eclipse.
Los proyectos se encuentran en la carpeta DVDPROYECTO\otrosAnexos\codigoFuente\.
A pesar de que se ha comentado el código ampliamente, para facilitar su comprensión y
de que este se ha intentado estructurar de forma que facilitase su lectura. La modificación y
ampliación de la aplicación desarrollada puede no ser fácil para quien no esté familiarizado
con ella y la ayuda necesaria para facilitar esta tarea excede los lı́mites de este manual,
por lo que en caso necesario se recomienda contactar con el autor.
J.4. Tareas a realizar
La tarea principal del administrador será mantener la base de datos.

Deberá de crear los másteres y al menos el primer administrados, directamente sobre
la base de datos utilizando sentencias SQL y tan solo con los datos imprescindibles, ya
que el resto de datos deberı́an ser introducidos, desde la aplicación desarrollada, por las
personas indicadas para ello.
Queda a su responsabilidad, el eliminar del sistema aulas o usuarios no asignados a
ningún máster o no accedidos nunca o el eliminar de la base de datos los másteres de años
pasados, que ya no tengan interés.
Ejemplos de todas las sentencias SQL necesarias para estas acciones, se encuentran en
los ficheros de ejemplo a los que ya se hizo referencia en el Anexo J.2.2.
Será también trabajo del administrador, el realizar cualquier otra tarea que pueda
parecer relevante, como la realización de copias de seguridad.
118
Anexo K. Versión de evaluación
La versión de evaluación de la aplicación se encuentra disponible en la URL:

http://fergusreiggracia.no-ip.org/masters/
El servidor de la aplicación es un ordenador personal, que se intentará mantener en
funcionamiento de forma ininterrumpida, pero esto no se puede garantizar al 100
K.1. Cuentas disponibles
Los usuarios pueden acceder a la versión de prueba de la aplicación, con cada uno de
los diferentes perfiles posibles, referidos a los másteres:
Ingenierı́a Biomédica de 2008.

Programa Oficial de Posgrado en Ingenierı́a Informática de 2008.
Las diferentes nombres de usuario y contraseñas son:
Invitado: No es necesario ningún nombre de usuario, ni contraseña.

Alumno: El nombre de usuario será “alumno” y la contraseña “ejemplo”.
Profesor: El nombre de usuario será “profesor” y la contraseña “ejemplo”.
Coordinador: El nombre de usuario será “coordinador” y la contraseña “ejemplo”.
K.2. Limitaciones
La aplicación no enviará emails informando a los usuarios del sistema de las modifica-
ciones realizadas en los calendarios, ni a los nuevos usuarios para comunicarles su nombre
de usuario y contraseña.
119
K. Versión de evaluación K.2 Limitaciones
Esto es obligado, para no molestar a las personas cuyos datos se han tomado para
recrear los diferentes másteres de ejemplo.
120

Memoria Fergus

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Memoria Fergus

Uploaded by

Copyright:

Available Formats

Proyecto Final de Carrera

Gestión global y obtención automática de los

Fergus Reig Gracia

Director: Eduardo Mena Nieto

Departamento de Informática e Ingenierı́a de Sistemas

Cada año se imparten un gran número de másteres en el Centro Politécnico Superior,

4. Algoritmo de generación de horarios 25

D. Elección de las tecnologı́as 65

H. Eficiencia de la generación de horarios 87

J. Manual del administrador 115

K. Versión de evaluación 119

2.3. Ejemplo de la función de autocompletado . . . . . . . . . . . . . . . . . . . 10

2.4. Traza de eventos parcial de la página de un máster, utilizada durante la

3.1. Captura de Google Calendar . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2. Captura del calendario de la aplicación . . . . . . . . . . . . . . . . . . . . 17

4.1. Esquema del cromosoma utilizado . . . . . . . . . . . . . . . . . . . . . . . 28

4.2. Ejemplo del tipo del cromosoma utilizado . . . . . . . . . . . . . . . . . . . 29

4.3. Diagrama de clases “resumido” del algoritmo genético . . . . . . . . . . . . 31

B.1. Distribución del tiempo invertido en el proyecto . . . . . . . . . . . . . . . 50

B.2. Distribución del tiempo invertido en la aplicación web . . . . . . . . . . . . 51

B.3. Distribución del tiempo invertido en el calendario GWT . . . . . . . . . . . 51

B.4. Distribución del tiempo invertido en el algoritmo genético . . . . . . . . . . 52

B.5. Diagrama de Gantt del proyecto . . . . . . . . . . . . . . . . . . . . . . . . 53

E.1. Esquema de funcionamiento de GWT . . . . . . . . . . . . . . . . . . . . . 72

G.1. Esquema del algoritmo genético simple . . . . . . . . . . . . . . . . . . . . 86

I.1. Cabecera de las páginas, que se muestra si no se está identificado . . . . . 92

C.1. Representación un máster en la base de datos (campos clave) . . . . . . . . 62

H.1. Resultados del Programa Oficial de Posgrado en Ingenierı́a Informática . . 88

La problemática de la búsqueda de horarios óptimos se presenta de forma reiterada

Gestión y actualización vı́a web del conjunto de la aplicación, de forma concurrente,

Almacenamiento de los datos de interés relativos a los másteres, especialmente los

Uso de calendarios interactivos para mostrar, editar y gestionar la información de

Introducción distribuida de datos según un sistema de cuentas que permita a cada

Sistema de alertas para informar a coordinadores, profesores y alumnos de aquellos

Obtención automática de horarios óptimos para los diferentes másteres a partir de

1.1. Estructura de la aplicación

El presente proyecto, cuyas caracterı́sticas principales ya se han descrito en este capı́tu-

Aplicación web: Comprende la parte de la aplicación que se ocupará de interactuar

El uso de tecnologı́as AJAX ha permitido el desarrollo de un calendario mediante el

Generador de horarios: Es el algoritmo encargado de generar los horarios cumpliendo

Base de datos: Guardará la información necesaria para el funcionamiento de las

1.2. Puntos de la memoria

El presente documento consta de 5 capı́tulos, siendo el primero de ellos la introducción,

2.1. Exigencias a la web

El diseño de la web se basa en el patrón Modelo Vista Controlador, que se presenta

Como también se puede ver en la figura, para añadir coordinadores y cursos a un

Figura 2.3: Ejemplo de la función de autocompletado

Es una herramienta de soporte para el desarrollo de páginas web, orientada al patrón

En el segundo, caso se planteó el uso de JMaki, que se comenta en el Anexo E.4.3,

El “Modelo” lo conforman el conjunto de funciones de más bajo nivel de la aplicación.

Esta técnica mejora enormemente el rendimiento al ahorrar el abrir y cerrar conexiones

Lectura de los ficheros de configuración de la aplicación.

Generación aleatoria de las claves de los nuevos usuarios.

La implementación de esta parte de la aplicación no ha chocado con grandes dificul-

Se ha diseñado e implementado una etiqueta JSP, para facilitar la creación de las

Se ha utilizado Tiles [7] para crear plantillas de las páginas web.

De librerı́as para facilitar la implementación de las funcionalidades deseadas:

XStream 1.3 [9] para la lectura de ficheros XML.

JavaMail 1.4.1 [10] para el envı́o de emails.

Y de algunas funciones Javascript orientadas a mejorar la experiencia de usuario, para

Los formularios con autocompletado [3].

2.4. Problemas encontrados

La mayor dificultad radicó en la elección de las caracterı́sticas de los másteres y cursos