INGENIERÍA TÉCNICA EN INFORMÁTICA DE GESTIÓN 3.

CURSO TUTOR: Jon Kepa Gerrikagoitia

2. Grupo: Asier Garitano Endika Montejo Asier Rodríguez Jon Pérez de Arrilucea -1-

Gestor de horarios

2

Índice
1. 2. 3. 4. 5.
5.1 5.2

Abstract................................ ................................3 Introducción.......................... ................................4 Descripción del problema.......................................4 Acotación del problema..........................................5 Objetivos del proyecto...........................................6
Mínimos..................................................................6 Límites.............................................. ......................6

6.
6.1 6.2 6.3
6.3.1 6.3.2 6.3.3 6.3.4

Análisis............................. ....................................7
Gestión de la base de datos......................................7 Esquema conceptual................................................8 Análisis funcional.......................................... ...........9
Administrador...................................................... ......................10 Profesor....................................................... ..............................18 Alumno............................................................ ..........................26 Sistema................................................................................. .....28

6.4
6.4.1

Software.......................................................... ......31
Programas.................................................................................. 31

6.5
6.5.1

Análisis técnico..................................... .................32
Comparación entre Bases de Datos...........................................32

7.
7.1
7.1.1 7.1.2 7.1.3

Inteligencia Artificial............................................36
Tabu Search........................................ ...................36
Justificación de Tabú Search.................................................. .....36 Consideración del problema.....................................................37 Uso del Tabu Search.............................................................. .....37

7.2
7.2.1 7.2.2

Ant Algorithm........................................................38
Consideración del problema.....................................................38 Comparación entre “Ant Colony System” y “Max-Min Ant System” 39

7.3
7.3.1 7.3.2

Inteligencia utilizada..............................................42
Descripción.................................................................. ..............42 Priorización de intereses............................................. ...............43

8. 9. 10.

Limitaciones........................................................45 Conclusiones................................................... .....46 Bibliografía.......................................................47 -3-

Gestor de horarios

-4-

Gestor de horarios

1.Abstract
Due to the difficulty of making a manager of intelligent schedules, the School Federation has ordered an application to manage, design and implement the timetables. For the good working of the schedule, a software application will be created (based on a database), which generates these schedules in an automatic way. Not only this, it also would be developed with Oracle Forms a system by which diverse users (students, teachers, administrators) will be able to develop diverse options as those to see the schedule, create restrictions (only the teachers),etc. The administrators will be also in charge to certify the correct working of the application. All these functionalities will be realised by means of forms. In summary, this application will make easier for students as to teachers the fact of making consults or realising changes in the schedule of a school.

Debido a la dificultad de hacer un gestor de horarios inteligente, la Federación de Ikastolas ha encargado una aplicación para gestionar, diseñar e implementar estos horarios. Para el buen funcionamiento del horario, se creará una aplicación software (basada en una base de datos) que genere de forma automática dichos horarios. No solo esto, sino que también se desarrollará con Oracle Forms un sistema por el cual diversos usuarios (alumnos, profesores, administradores) podrán desarrollar diversas opciones como las de ver horarios, crear restricciones (solamente los profesores),... Así mismo el administrador se encargará de certificar el correcto funcionamiento de esta aplicación. Todas estas funcionalidades se realizarán mediante formularios. -5-

Gestor de horarios En resumen, esta aplicación facilitará tanto a alumnos como a profesores el hacer consultas o realizar cambios en el horario de una Ikastola.

2.Introducción
En las siguientes páginas, se explicará todo el proceso de un proyecto. Empezando por el análisis del problema, siguiendo con el diseño del producto y terminando con el resultado y las conclusiones obtenidas durante este proceso. Como en todos los proyectos, detrás del trabajo realizado hay un problema planteado. Lo primero que se ha hecho, ha sido el análisis funcional del problema. En este apartado se expondrán las ideas que había al principio, analizando los objetivos mínimos a cumplir de la aplicación. El siguiente paso será el de seleccionar las herramientas apropiadas para llevar a cabo el proyecto de manera más sencilla y poder cumplir todas las necesidades del usuario. Después, se llevará a cabo el diseño y el desarrollo del producto. Primero se explicará el funcionamiento del proyecto con un esquema genérico. Luego el proyecto se dividirá en partes más pequeñas y se analizarán de forma más sencilla, desde los puntos de vista de los diferentes usuarios que van a utilizar la aplicación. Por último se analizará el resultado logrado del proyecto y las conclusiones obtenidas de este mismo.

3.Descripción del problema
A continuación se expondrá el problema a desarrollar que se ha planteado al principio del curso: La Federación de Ikastolas ha encargado a la empresa X dedicada al desarrollo de Software la gestión, diseño e implementación de una nueva aplicación para dar soporte a la confección de los horarios de los centros educativos de dicha Federación.

-6-

Gestor de horarios El objetivo de dicha aplicación es la de facilitar la confección de los horarios de los distintos grupos y asignaturas. Esta tarea, cada vez consume más recursos del Jefe de Estudios y es un punto clave en la insatisfacción del profesorado. Además cada vez es más versátil la configuración de horarios, con clases que se agrupan o se desdoblan, lo que hace que esta tarea resulte muy costosa y sujeta a errores. Por lo tanto, el objetivo es desarrollar una aplicación para la Gestión de Horarios.

4.Acotación del problema
Debido a la magnitud del problema, se ha llevado a cabo una acotación del mismo teniendo en cuenta los mínimos exigidos, el tiempo disponible y la cantidad de gente trabajando en la solución. Se ha decidido que el proyecto gestionará una sola facultad de una universidad concreta, ya que añadir más facultades sólo implicaría un aumento de los datos, sin aportar nada en la gestión de recursos (profesores y clases). En el caso de que un profesor trabajara en dos facultades distintas, se simularía mediante un concepto de restricciones que se explicará al final. Otra acotación que se ha introducido, es la prioridad de mantener, en la medida de lo posible, los horarios, para la comodidad del alumnado ante un cambio puntual. En este caso se ha usado un concepto de conocimientos del profesorado. Las restricciones albergarán dentro de sí el día y la hora que un profesor no pueda asistir a clase. Otro concepto a remarcar es el conocimiento. Este concepto permite conocer los profesores que hayan impartido una asignatura y tengan el conocimiento para impartirla de una manera puntual si fuera necesario.

-7-

Gestor de horarios

5.Objetivos del proyecto
Una vez concretado el problema, se debe proponer una solución y demostrar su funcionamiento. Este proyecto está planteado para que como alumnos de MGEP se obtengan ciertas cualificaciones y conocimientos. A esta metodología se la denomina como aprendizaje basado en problemas o PBL. En base a ello, y al tiempo disponible para su realización (Fecha límite: 15 de Enero de 2009), se definirán los objetivos mínimos y los límites fijados en torno a ellos.

5.1Mínimos
Este sistema deberá permitir lo siguiente:

Generar automática e inteligentemente los horarios de una universidad teniendo en cuenta las restricciones que tendrá cada recurso. Gestión eficiente de los recursos utilizados. Diseño visual de la aplicación.

• •

5.2Límites
Proyecto centrado en: • • Cambios de horario priorizando los intereses de los estudiantes. Aproximación a la realidad. Por consiguiente, todo lo que se escape a estos conceptos y a la implementación de un sistema básico para la gestión del horario estaría fuera de lo que serían los límites fijados para este proyecto.

-8-

Gestor de horarios

6.Análisis
En el análisis, se explicarán las diferentes posibilidades y vías técnicas para poder prestar una solución adecuada al problema antes citado.

6.1Gestión de la base de datos
Debido a la necesidad que hay en el horario de extraer prácticamente toda la información de la base de datos, se dividirán las diversas funciones y procedimientos del proyecto en diferentes paquetes, los cuales se adaptarán y mejorarán el uso y entendimiento del sistema, permitiendo así las funciones a usar: crear profesor, crear restricción, ver horario,…. La razón de esto es bien clara: evitar la realización de búsquedas innecesarias, por unas más exactas, que ayuden a generar rápida y eficientemente las necesidades de los usuarios.

-9-

Gestor de horarios

6.2Esquema conceptual
Tras este breve análisis, se ha diseñado un boceto conceptual del sistema. Gracias a él, se podrá afianzar lo anteriormente analizado y proseguir con el análisis técnico sobre las tecnologías que harán posible su implementación a este sistema. Como se puede comprobar en la imagen, la base de datos estará centralizada y todos los dispositivos (alumnos, profesores y administrador) se conectarán a ella.

-10-

Gestor de horarios

6.3Análisis funcional
En este apartado se explicarán los principales puntos del problema y analizando el apartado funcional. Después de estudiar la aplicación solicitada por el cliente desde el punto de vista de los diferentes actores, el problema se puede dividir en cuatro grupos funcionales. Estos actores serán el administrador, los profesores, el alumnado y el propio sistema. En el siguiente punto, se analizarán estos actores uno a uno de forma más detallada. -11-

Gestor de horarios En la siguiente imagen, se podrá ver el diagrama de casos de uso del proyecto.

6.3.1Administrador El administrador es el encargado de gestionar el sistema. Su principal función será controlar todos los recursos necesarios de la facultad. Estos recursos serán los de profesor, aula, asignatura y titulación. Será capaz de crear nuevos datos, modificarlos y eliminarlos en la medida de lo necesario de la base de datos. Para poder hacer todos estos cambios en la base de datos, primero tendrá que registrarse, teniendo los privilegios necesarios para hacer esos cambios. Para poder ver de mejor manera las funcionalidades del administrador, se ha creado un diagrama de casos de uso. La parte del administrador de este diagrama se puede ver en la siguiente imagen: -12-

Gestor de horarios

El siguiente paso será el de explicar los casos de uso ya mencionados, es decir, los pasos que tendrá que seguir el usuario para poder realizar las diferentes acciones. Para gestionar los datos, el administrador tiene tres opciones: crear, modificar y borrar datos. Como asignatura, aula, profesor y titulación tienen los mismos los pasos a seguir, solo se expondrán las opciones sobre un recurso. Antes de poder hacer todas esas acciones, el administrador tiene que logarse, por lo que se empezará a explicar ese punto. Para una mejor explicación y comprensión de cada punto, se utilizarán imágenes en forma de ayuda. Lo primero que tendrá que hacer el usuario, será introducir su nombre y contraseña adecuada. Una vez verificados estos datos en la base de datos, si son correctos, se darán los permisos adecuados y si por el contrario son incorrectos, aparecerá un error en pantalla diciendo que los datos son incorrectos y no dará ningún permiso. Aquí se puede observar la actividad de esta acción.

-13-

Gestor de horarios

En la siguiente imagen se puede ver la ventana donde el usuario deberá introducir los datos para poder pasar a hacer las diferentes acciones de la aplicación en modo administrador.

Ahora se pasará a explicar el cómo introducir los datos de una nueva aula. Para ello se introducirán los nuevos datos del aula y si estos datos son erróneos, la aplicación dará un error. Una vez que los -14-

Gestor de horarios datos sean correctos, la aplicación guardará en la base de datos los nuevos datos introducidos. Esto se puede ver mejor en la siguiente imagen mediante un diagrama de actividad.

En el diagrama anterior, aunque aparezcan todos los pasos a seguir, no se pueden ver las acciones respecto al tiempo. En el siguiente diagrama de secuencia se observarán las acciones que sigue la aplicación en tiempo real.

-15-

Gestor de horarios

El administrador introducirá los datos necesarios mediante la pantalla de Oracle Forms y una vez se hayan verificado, se introducirán en la tabla aula de la base de datos. Para asignatura, profesor y titulación se seguirán los mismos pasos que aula metiendo los datos necesarios en las respectivas tablas. En cuanto a crear nuevas aulas, está será la ventana que utilizaremos con este fin.

-16-

Gestor de horarios

Una vez explicado como introducir datos nuevos en la base de datos, el siguiente paso será el de hablar sobre modificar datos ya existentes. Se seguirán los mismos pasos que al crear nuevos recursos. Para modificar los datos, primero se debe seleccionar el aula que se quiere modificar. Una vez se hayan modificado los datos y si estos datos son correctos, se guardarán en la base de datos. Si los datos son erróneos dará un error y no se podrán guardar los datos. Esto se puede ver mejor mediante un diagrama de actividad.

-17-

Gestor de horarios

Como se ha hecho anteriormente, se ayudará a entender la explicación mediante un diagrama de secuencia, para poder ver las acciones respecto al tiempo.

-18-

Gestor de horarios

En este caso también, el administrador será el actor. Como se ha hecho con la secuencia de insertar, el siguiente paso será explicar los pasos que se deben dar para modificar una aula concreta. Primero se verán los datos de todas las aulas introducidas en la base de datos mediante Oracle Forms. Luego se seleccionará el aula que queremos modificar y una vez se hayan modificado los datos necesarios y si los datos son correctos, se modificarán en la base de datos en tabla aula. Igual que a la hora de crear nuevos recursos, se seguirá el mismo proceso con titulación, asignatura y profesor. Para modificar los datos de los recursos, se utilizara la misma ventana que la de introducir datos mencionada anteriormente. La última acción posible es la de borrar las aulas. Se seguirán los mismos pasos que en las anteriores ocasiones. Para una mejor explicación, se usaráun secuencia. diagrama de actividad y un diagrama de

-19-

Gestor de horarios

Primero se pondrán en pantalla los datos de las diferentes aulas. El administrador seleccionara el código del aula que quiera borrar. Si el código es correcto y esa aula no está en uso durante el curso, se borrará de la base de datos. Por el contrario, si el código es erróneo o el aula está siendo usada durante el curso por alguna clase, dará un error.

-20-

Gestor de horarios

Para ayudar a la explicación de esta acción, en la imagen anterior se muestra el diagrama de secuencia. Como ya se ha mencionado anteriormente, gracias al siguiente diagrama podremos ver las acciones respecto al tiempo. En este caso también habrá un actor que será el del administrador. Lo primero que se hace es sacar la información de las aulas mediante Oracle Forms. Una vez seleccionado el código del aula que se desea borrar, se introduce el código y si este es correcto se borrará el aula de la base de datos y si no dará un error. Para hacerse a una idea de cómo borrar los datos de las aulas, se muestra la ventana de Oracle. En pantalla se podrán ver los datos de cada aula y así se podrá seleccionar el identificador del aula que se quiere borrar.

-21-

Gestor de horarios

En los casos de titulación y asignatura el procedimiento es el mismo. El único recurso que tiene una pequeña diferencia es el del profesor. En caso del profesor, a la hora de borrar un profesor, el programa exige contratar un sustituto para poder dar las clases que daba el profesor anterior, ya que en el mejor de los casos habría que modificar todo el horario y en el peor no se podrían reemplazar todas las clases de ese profesor. 6.3.2Profesor Como se ha mencionado anteriormente, otro actor será el profesor. El profesor podrá hacer dos acciones diferentes: ver su horario e introducir y borrar sus propias restricciones, es decir, los días que no puede asistir a clase. El profesor, para poder hacer estas acciones, tendrá que estar registrado. Una vez registrado, tendrá 3 opciones diferentes a elegir: introducir restricciones, borrar restricciones y la de ver su propio horario. En las restricciones, introducirá el día y el intervalo de horas que no podrá asistir a clase y si la falta a clase sería más prolongada, metería el día de la semana que no pueda asistir. En ver horario, podrá ver el horario que tendrá en la semana de la fecha que introduzca. En la siguiente imagen se puede ver los casos de uso que tendrá el profesor: -22-

Gestor de horarios

Ahora se explicarán los pasos que tendrá que dar el actor para realizar las tareas. En este caso el profesor lo primero que tendrá que hacer para poder hacer las acciones será loguearse. Una vez se haya logueado, podrá hacer las siguientes opciones: ver su propio horario e insertar o borrar sus propias restricciones. Como el procedimiento de loguearse se ha explicado anteriormente, se pasará directamente a explicar los otros casos de uso. Primero se explicará como insertar una nueva restricción. Las restricciones serán de dos tipos, puntuales o genéricas. Las restricciones puntuales serán cuando el profesor no pueda asistir a clase en un día una hora concreta y las genéricas, serán las restricciones que duren más de un día concreto. Cada profesor administrará sus propias restricciones. El primer paso será explicar las restricciones puntuales. El profesor, introducirá la fecha y las horas concretas que no pueda asistir a clase. Si estos datos son correctos, se creara una restricción en la base de datos, y si por el contrario fueran erróneos, daría un error en la aplicación. Esto se puede ver mejor en la siguiente imagen mediante un diagrama de actividad.

-23-

Gestor de horarios

Como se ha hecho anteriormente, el diagrama de secuencia expondrá el uso en tiempo real.

-24-

Gestor de horarios

En este caso el actor será el profesor. Tendrá que introducir los datos mediante Oracle Forms. Estos datos se verificarán y una vez que sean los correctos, se insertarán en la tabla restricciones de la base de datos. Lo siguiente será explicar las restricciones genéricas. El profesor introducirá dos fechas, la del principio de la restricción, es decir, desde cuando no va a poder asistir a clase, y la del fin de la restricción, hasta cuando no puede acudir a clase. Además de las fechas, introducirá la hora que no pueda asistir. Si los datos son correctos, los guardará en la base de datos. Se reforzará la explicación con el diagrama de secuencia que se puede ver en la siguiente imagen. En este caso, se usará la función ‘INSERT_RESTRICCIONGENERICO’ (mirar Anexo) para crear la restricción adecuada en la base de datos.

-25-

Gestor de horarios

En este caso también el profesor será el actor. Se introducirán los datos mediante Oracle Forms. Una vez introducidos los datos, los verificará y si estos datos son correctos los guardará en la base de datos mediante la función funcionRestGen (). Si los datos son erróneos, dará un error y no dejará guardar la restricción en la base de datos.

-26-

Gestor de horarios En la imagen anterior se puede ver la ventana de Oracle Forms que se utiliza para poder hacer este procedimiento. En pantalla, da las opciones de introducir las restricciones genéricas o puntuales. Después de analizar como introducir las restricciones, ahora se pasará a analizar como borrar estas restricciones. En este caso también habrá dos tipos de restricciones, genéricas y puntuales. Se comenzará analizando como borrar las restricciones puntuales. El profesor introducirá la fecha concreta y la hora en la que tenía una restricción. Si los datos son correctos, la restricción se borrará de la base de datos. Como se ha hecho anteriormente, para reforzar esta explicación se utilizará un diagrama de actividad.

-27-

Gestor de horarios Esta última imagen también se reforzará con el diagrama de secuencia. En este caso también el actor será el profesor. El profesor introducirá los datos mediante las ventanas de Oracle Forms, que se revisarán en la base de datos mediante el lenguaje PL/SQL. Una vez se hayan verificado los datos, se borrarán de la base de datos mediante la función deleteRestriccion (). Si los datos introducidos son erróneos, dará un error y no se borrará ninguna restricción hasta introducir correctamente los datos.

El siguiente paso será el de explicar cómo borrar las restricciones genéricas. Se seguirán los mismos pasos que con las puntuales, la única diferencia serán los datos utilizados. El profesor esta vez introducirá la hora y la fecha de inicio y de fin de la restricción, así como el día de la semana. Una vez que el programa tenga los datos, se verificarán los datos introducidos y si estos son los correctos, se borrarán esas restricciones de la base de datos. Como ya se ha hecho anteriormente, esta acción se reforzará con un diagrama de secuencia, para poder ver las acciones respecto al tiempo. -28-

Gestor de horarios

El actor principal será el profesor. El mismo profesor se encargará de administrar sus propias restricciones. Una vez que haya introducido mediante Oracle Forms la fecha de inicio y la de fin de la restricción, la hora a borrar y el día de la semana, se verificará si los datos introducidos son los correctos. Si estos son correctos, se borrarán las restricciones que tenga introducidas durante esas dos fechas mediante la función deleteResGen (). Si los datos fuesen incorrectos, el programa no nos dejaría hacer estos cambios en la base de datos.

En este caso también se introducirá la ventana de Oracle Forms que realiza esta acción para tener una imagen más clara.

-29-

Gestor de horarios

Otra acción que podrá hacer el profesor será la del ver su propio horario. En este caso, el profesor tendrá que introducir la fecha de la que desea ver el horario. Cuando pida su horario el sistema cogerá su id y esa fecha y sacará en pantalla las horas que tendrá que impartir clase la semana de la fecha introducida. El profesor seleccionará el botón de ver horario en Oracle Forms y el mismo programa se encargará de sacar los datos en pantalla. Si la fecha introducida fuera errónea o fuera un sábado o domingo, el propio sistema avisaría del error.

-30-

Gestor de horarios

-31-

Gestor de horarios

En la “imagen24” se podrá ver la ventana del horario del profesor. La información que se introducirá será la fecha de la semana que se quiera ver. En la ventana podrá ver las clases que tendrá que impartir, en que clases y las restricciones pertinentes de esa semana. 6.3.3Alumno Otro actor será el alumno, que podrá ver los horarios que tendrán todas las titulaciones de la facultad. El alumno no tendrá que registrarse para poder ver los diferentes horarios. Le aparecerá una ventana con todas las titulaciones posibles, pudiendo elegir su titulación y una vez que haya elegido su titulación le aparecerá el horario de esa titulación en la semana que el alumno indique metiendo la fecha del día que quiera ver.

-32-

Gestor de horarios Este actor solo podrá hacer una acción que es la de ver su propio horario. Lo único que tendrá que hacer será elegir su titulación e indicar la fecha de la semana que quiera ojear. Una vez haya seleccionado esos atributos, el programa sacará a pantalla el horario de esa titulación. En la siguiente imagen se pude ver el diagrama de actividad de esta acción.

-33-

Gestor de horarios

Como se puede ver en la imagen, el actor será el alumno y mediante Oracle Forms seleccionará la titulación. Una vez seleccionada, introducirá la fecha deseada y el programa pedirá el horario a la base de datos y este devolverá los datos a pantalla. Aquí aparecerá el horario que tendrá durante esa semana. En la ventana podrá ver la información de que asignatura tiene, en que clase se imparte y que profesor dará la asignatura.

-34-

Gestor de horarios

6.3.4Sistema El último actor que aparece en la aplicación es el sistema. Este actor podrá realizar dos acciones. La primera de esas acciones será la de generar horarios. El sistema tratará de hacer automáticamente los horarios de cada titulación mediante toda la información anteriormente introducida en la base de datos, teniendo en cuenta las restricciones propias del sistema y las introducidas por cada profesor. Esta será la función principal del proyecto, la más importante y difícil de implementar. La acción de dar permiso, se encargará de dar los permisos a los administradores y a los profesores cuando se registren, comprobando en la base de datos si los datos introducidos son correctos.

-35-

Gestor de horarios

En la siguiente imagen aparece el caso de uso del sistema.

Ahora se explicarán los pasos que hay que dar para poder hacer estas acciones. El sistema se encargará de modificar los horarios automáticamente cuando se introduzca una nueva restricción, tanto genérica como puntual. A la hora de hacer el horario, tendrá en cuenta las restricciones introducidas de cada profesor, las horas dadas por cada asignatura al día y a la semana, la capacidad de cada aula en el momento de rellenar cada hora y la disponibilidad de los profesores. Todo esto es tenido en cuenta con el fin de acercarse lo máximo posible a la realidad. En la siguiente imagen se puede ver el diagrama de actividad de esta acción.

-36-

Gestor de horarios

El administrador pulsará el botón de crear horario y el sistema automáticamente creará los horarios de las titulaciones que estén en la base de datos, siempre y cuando no tengan ya el horario creado y tengan 25 horas de clase exactas. El sistema seleccionará la hora a rellenar, luego cogerá la asignatura, y si esa asignatura no se puede poner en esa hora, volverá atrás y seleccionara otra asignatura. Esto se repetirá hasta encontrar una asignatura que se pueda poner en esa hora. Una vez seleccionada la asignatura, el siguiente paso será seleccionar una clase. En este caso se hará lo mismo que asignatura. Irá probando aulas hasta encontrar una que cuadre con esa asignatura y hora. Seguirá este proceso para rellenar todas las horas de la semana. -37-

Gestor de horarios Al llegar a un punto que ninguna asignatura puede estar en una hora concreta, se volverá atrás en el horario mirando si alguna de las asignaturas ya puestas en el horario encaja en esa hora. Si se da el caso, se haría un intercambio de horas y asignaturas para poder seguir con el proceso. Una vez explicada la acción de generar horario, se pasará a explicar la siguiente acción, la de dar permisos a los usuarios El sistema, mediante una función, comprobará en la base de datos el id y la contraseña metidos por el usuario, y dependiendo de estos datos le dará acceso a un profesor, al administrador o no le dará permiso si estos datos no estuvieran en la base de datos.

6.4Software
Se definirá de qué partes de software necesita el sistema para el buen funcionamiento del mismo. 6.4.1Programas Al trabajar en el lenguaje PL/SQL, no se trabajará con un programa sino con una serie de subprogramas, metidos en diversos paquetes para el buen entendimiento y uso del proyecto. Estos paquetes básicamente se dividirán en inserciones, modificaciones y borrado de las clases de la base de datos, así como en otros paquetes que su labor será la del elaborar el horario inteligente. Es por esto por lo que el usuario que quiera tener acceso a las diferentes consultas, sea administrador, alumno o profesor deberá tener en un terminal instalado la interface del proyecto en Oracle Forms. En el caso de que dicho usuario quiera sacar un informe de los datos, no sólo necesitará la interface sino también el programa que gestionará informes en Oracle Reports.
6.4.1.1Interfaces para el usuario

Existen varias interfaces, las cuales realizarán la labor de ser la parte visual del proyecto hacia los usuarios que utilicen la aplicación. Dentro de estas interfaces, es donde se encuentran las posibilidades antes mencionadas como la de ver horario de los alumnos, ver horario de un profesor y sus restricciones, así como insertar/modificar restricciones normales o genéricas,… para profesores y para el administrador aquellas funcionalidades para el buen mantenimiento de una base de datos. (Véase prototipos de interface gráficos en anexo). -38-

Gestor de horarios

6.4.1.2Gestor de informes

Para crear estos informes, se utilizara otra aplicación de Oracle, llamada Reports. Esta herramienta se usa para diseñar y generar distintos informes en papel, mostrar datos de cualquier origen de datos en numerosos estilos de informe y publicar la salida a cualquier destino. En este trabajo la principal aplicación de esta herramienta será la creación de un informe que muestre el horario de cada titulación. A la aplicación se le pasara el código de la titulación a mostrar, y según este código sacara un horario u otro. Se puede ver un ejemplo en la siguiente imagen.

Aparte de la anterior aplicación, se ha utilizado también para mostrar el horario de cada profesor. Al igual que se ha hecho con los de titulación, a los de profesor también se les pasará el idprofesor y sacar el horario de ese profesor. En este proyecto también se podrían crear más informes, pero se han hecho únicamente de estas dos aplicaciones ya que son las más importantes y en lo que se basa este proyecto, albergando todos los recursos a utilizar.

6.5Análisis técnico
En este apartado nos centraremos en analizar las diferentes tecnologías que podríamos emplear para la construcción del sistema ideado en el análisis conceptual.

-39-

Gestor de horarios 6.5.1Comparación entre Bases de Datos La base de datos es el lugar donde se acumulan los datos que contraen relación entre ellos. Aquí es donde dichos datos se guardan para poder gestionar correctamente todo lo relacionado a ello posteriormente. Hablando de software que se utilizan para crear y gestionar las bases de datos hay que mencionar los siguientes: Oracle, MySQL y Microsoft Access. Microsoft Access es un paquete de office. Esta herramienta está diseñada sobre todo para uso personal y para pequeñas empresas. La razón por la cual este perfil de usuarios la usa es que esta base de datos no consume demasiados recursos y se puede combinar sin ningún tipo de problema con los demás programas de Microsoft. Es adecuado para crear pequeñas aplicaciones y no se necesitan grandes conocimientos de programación. También es de recalcar la simplicidad a la hora de crear una interface mediante Microsoft Access. MySQL es una base de datos bastante amplia en lo que a capacidad respecta, utiliza pocos recursos del ordenador y es un software libre. En el caso de utilizar éste, para programar y hacer los interface gráficos se tendría que utilizar el lenguaje JAVA. El último software a examinar es Oracle. Este es un servidor y una herramienta muy potente en cuanto al manejo y desarrollo de proyectos mediante bases de datos. Además, contiene diferentes aplicaciones, como Oracle Forms que facilita mucho las cosas al programador a la hora de hacer las aplicaciones visuales. Entre las tres opciones analizadas, MySQL y Oracle son las opciones más apropiadas. Oracle por su potencia y por la capacidad de poder tener múltiples usuarios y MySQL por su velocidad y por ser software libre. De todos modos, si se tiene como prioridad la seguridad y la integridad de los datos, Oracle es más apropiada. Este software también puede contener muchos paquetes para facilitar la programación al programador y el entendimiento al usuario.

-40-

Gestor de horarios

6.5.2Diseño y desarrollo La mejor manera de empezar a explicar el diseño, es empezando a hablar sobre la organización de los datos. Primero se hablará sobre la base de datos que se ha creado. Es muy importante diseñar bien la base de datos, ya que se guardarán todos los datos de los recursos para poder crear el horario adecuadamente. Estos datos se cambiarán durante el tiempo. A la hora de crear la base de datos se ha credo un “tablespace” llamado “proiekto_gestion”. El “tablespace” es una unidad lógica de almacenamiento dentro de una base de datos. Esto se ha hecho porque tener abierto más de una aplicación de Oracle consume muchos recursos así como memoria y tiempo. De este modo se puede tener en una sola base de datos de Oracle más de una base de datos, estando cada una de ellas en el “tablespace” que queramos para tener estas perfectamente ordenadas. En las siguientes líneas se hablará sobre crear la base de datos. Para ver más claro la creación se utilizará el campo de definición. Esto se puede ver en la siguiente imagen.

-41-

Gestor de horarios

Se han definido diferentes campos (profesor, asignatura, titulación, hora, horario, restricciones, calendario, aula). Ahora se analizarán los distintos datos que se guardan en los campos. En el campo de profesor se guardarán su nombre, apellido, teléfono, idprofesor y su DNI. El dato principal de este campo será el id que se le asignará a cada profesor, por el cual se le identificará. En asignatura se insertarán el idasignatura, el nombre de la asignatura, de que tipo es la asignatura, las horas de teoría y práctica y el número de alumnos que tendrá. El dato más importante de este campo será el idasignatura, para diferenciarlas entre ellas. En titulación, se meterá el id que se le da a la titulación, la descripción de la titulación, el curso al que pertenecen y el turno que tiene, es decir, si las clases se dan por la mañana o por la tarde. En aula se guardarán los datos relacionados con las aulas así como el qué tipo son, es decir, si la clase está preparada para impartir teoría o hacer prácticas. También aparecerá para cuantos alumnos tiene capacidad el aula. En calendario se asignará a cada día del calendario un número para identificar con más facilidad el día al que asignamos restricciones y horarios. En la tabla restricciones se meterán las restricciones que introducirá cada profesor. Aquí es dónde aparecerán tanto las restricciones puntuales como las genéricas. En otro campo se guardaran los datos relacionados con las horas que se dará clase. En este caso serán 10 horas teniendo en cuenta las horas por la mañana y por la tarde. A cada hora se le asignara un identificador. Por último el campo más importante, el de horario. En este se guardarán todos los horarios de las titulaciones. Estos horarios tendrán una fecha de inicio y otra de fin, ese será el plazo de validez de ese horario. A la hora de introducir nuevas restricciones, este campo se cambiarían los datos donde la fecha seleccionada este dentro de la fecha de validez.

-42-

Gestor de horarios

7.Inteligencia Artificial
El problema que se nos ha propuesto trata sobre la elaboración de un gestor de horarios de manera inteligente (más conocido por CTTP (Class TimeTable Problem)), así que hablando de la inteligencia artificial de este problema se debe comentar que estamos frente a un problema NP (de muchas posibles soluciones y gran complicación). En los posteriores apartados se explicarán posibles maneras de generar la inteligencia artificial y finalmente la que se ha empleado en este proyecto. Para hacer estas comparaciones, se debe aclarar que se hanevaluado varios tipos de búsquedas como “Genetic Algorithm”, “Simulated Annealing”, “Itereated Local Search” y las dos que analizarán, ya que presentan las mejores soluciones: “Tabu Search” y “Ant Algorithm”.

7.1Tabu Search
Al ser el problema del tipo NP la mejor opción es la de utilizar la heurística para realizar las búsquedas y encontrar diversas soluciones. Es por esto que la búsqueda tabú aparentemente sería una solución rápida así como de buena calidad para la solución que se busca para el proyecto. 7.1.1Justificación de Tabú Search El problema CTTP reúne la previsión de los encuentros secuenciales entre los profesores y alumnos para asegurar que las necesidades de ambos se vean realizadas. El sistema Tabú Search, pese a requerir de mucho tiempo y trabajo, es especialmente interesante, puesto que este método local de búsqueda está adaptado para la interactividad entre todas las estructuras de los horarios. Además, los algoritmos del Tabú Search ofrecen normalmente mejores resultados para las posibles soluciones de los problemas del tipo generar horarios en comparación con otro tipo de metas heurísticas. Pese a esto, también se debería de implementar el “adaptive relaxation” o el “random restart”,ya que sin estos el programa podría quedarse atrapado en un bucle infinito. En la denominada como “relajación adaptada”,los costes implicados en el programa se cambian dinámicamente para dirigir el proceso de la búsqueda a nuevamente de las regiones del espacio de búsqueda que aún no han sido visitadas. En cambio, con el “random restart” se generaría una nueva solución cada vez, pero no se guardaría ningún tipo de información anterior a la nueva situación.

-43-

Gestor de horarios 7.1.2Consideración del problema El problema considera repartos con la previsión de encuentros entre los profesores y las clases durante un periodo semanal. El horario se compone de los días “d” de la semana con una cantidad de períodos “h” (diarios), definiéndose el total de registros de una semana como “p” donde p=d x h. También se crearía una cantidad de profesores “t” que tendríanuna cantidad “c” de clases. La relación entre las clases y los profesores se crearía de antemano en una matriz Rt x c donde rij indica el número de lecciones que cada profesor impartirá para la clase “j”. Las clases deberán estar disponibles en el momento de su uso y tener un calendario para el buen manejo de ellas, donde cada profesor deberá indicar su disponibilidad. A los profesores se les daría la opción de pedir un determinado número de lecciones por clase. De esta manera esta solución al problema de CTTP debería satisfacer lo siguiente: 1. Ninguna clase o profesor se puede asignar para dos lecciones en el mismo período. 2. Los profesores serán asignados respetando su disponibilidad. 3. Cada profesor deberá dar el número de clases anteriormente acordadas. 4. Por razones pedagógicas ninguna clase podrá tener más de dos períodos de una misma lección con el mismo profesor por día. Y a estas se podrían añadir las siguientes: 1. El calendario para cada profesor deberá abarcar el menor número de días posible. 2. La opción de dar dos clases seguidas deberá tratarse como una prioridad. 3. Se intentará que no haya ningún tipo de hueco entre clase y clase.

7.1.3Uso del Tabu Search Como bien es sabido,la búsqueda tabú es un método iterativo para la solución de problemas combinatorios. Este sistema hace uso explícitamente de las estructuras de memoria para dirigir una heurística del tipo “colina descendente” para así continuar la -44-

Gestor de horarios exploración de datos sin tener confusión en el caso de que haya una ausencia de movimientos en el sistema. Ahora se pasará a explicar un poco por encima en cómo se implementaría lo argumentado anteriormente. A partir de una solución inicial “x”, el método explora sistemáticamente un sistema N(x) y al tratar éste, seleccionará el mejor movimiento “m” de N(x), el cual nos sacará una nueva solución x’ ЄN(x), aun así, los movimientos que deterioren el coste de del sistema también se tendrán en consideración. Así, para intentar evitar que un ciclo se complete, un mecanismo llamado “memoria a corto plazo” será empleado. El objetivo de esta memoria es el de intentar prohibir los movimientos hacia soluciones ya visitadas teniendo en cuenta los movimientos realizados en el pasado. Estos movimientos se almacenarán en una lista los cuales se manejarán mediante una función en los cuales como anteriormente hemos dicho se certificará que no retornemos a un estado en el cual hayamos estado para así evitar un bucle infinito.

7.2Ant Algorithm
Ahora analizaremos este algoritmo cuya traducción al castellano sería el algoritmo de las hormigas. El motivo por el cual analizaremos el uso de este algoritmo es el que últimamente se le está dando mucho uso y se podría considerar el algoritmo de moda entre los programadores. Se analizarán dos tipos de algoritmos Ant. Uno será el “Ant Colony System” y el otro será uno basado en la inteligencia “MAX- MIN Ant System”. 7.2.1Consideración del problema Primero de todo hablaremos de que en este problema no plantearemos un CTTP sino un sistema UCTP (“University Control Timetable Problem”) el cual en vez de estar ambientado en los horarios de un colegio lo estará en el de una universidad, lo cual no tendrá grandes diferencias. El problema consiste en un sistema de los acontecimientos para ser programadosen un sistema de intervalos de tiempo T= { t1…. tk} (k = 45, 5 days 9 horas al día), un registro de clases R donde se darán las clases (con su respectiva capacidad) y otro registro de alumnos S. Un horario factible será uno en el cual todos los acontecimientos se asignen a un intervalo de tiempo y un aula para poder satisfacer los apremios fuertes siguientes: -45-

Gestor de horarios 1. Ningún estudiante atenderá a más de una clase al mismo tiempo. 2. La clase será lo suficientemente grande para que todos los alumnos matriculados puedan entrar. 3. Una única clase podrá ser dada en el mismo momento en un aula. Se podrían poner muchos apremios débiles pero se han seleccionado los siguientes: 1. Que el estudiante no tenga una sola asignatura en un día. 2. Que el estudiante no tenga más de una clase en la misma hora de un día concreto.

7.2.2Comparación entre “Ant Colony System” y “Max-Min Ant System” Para poder comparar estos dos sistemas se propusieron tres tipos de horarios de tamaño pequeño, medio y grande para saber cómo se comportaban cada cual en cada uno de los casos. Pese a que la idea básica de ambos sistemas es muy parecida, tienen varias diferencias. Después de una lista pre-ordenada de acontecimientos, las hormigas eligen el intervalo de tiempo para un acontecimiento según la probabilidad del evento con el que están tratando, guiados por la información heurística y la información estimada. La información estimada será tratada bajo la forma de matriz de los valores de la feromona: E x T  E+, dónde E serán los eventos y T os intervalos de tiempos. El esquema de abajo servirá para ver como trabajará el sistema analizado.

Imagen 34: El gráfico de la construcción que las hormigas atraviesan al incorporarse una asignación de acontecimientos a intervalos de tiempo

Una vez que cada clase haya sido asignada a un determinado intervalo de tiempo, un algoritmo asignará una clase y una posible solución “C”. Las búsquedas hormigas que vamos a comparar difieren en la manera de utilizar la información existente, la manera -46-

Gestor de horarios en realizar la búsqueda local y la manera de modificar la matriz feromona. El sistema de la hormiga de MAX-MIN introduce límites máximos y mínimos en el valor de la feromona. Si las diferencias entre los valores de la feromona fuesen demasiado grandes, todas las hormigas generarían las mismas soluciones, lo cual significaría el estancamiento del algoritmo. Los límites en los valores de la feromona previenen este estancamiento. La máxima diferencia entre el nivel más alto y el más bajo de la feromona puede ser controlado, y así los niveles de intensificación y los de diversificación de la búsqueda podrán ser equilibrados. La regla de la actualización de la feromona será la siguiente:

dónde ρЄ[0,1]. La actualización de la feromona se finaliza con:

El valor de la actualización de la feromona se ha fijado a 1 después de algunos experimentos con los valores calculaban basado en la calidad real de la solución. La función “q” mide la calidad de una solución C del candidato contando el número de violaciones de sus limitaciones. Así tendremos la definición de la MMAS Tmax=g/(p*(1+q(Coptimal)), dónde “g” será un factor escalar. Debido a que q(Coptimal)=0 Tmax fue fijado como 1/ρ. Dado que el equilibrio de la actualización de la feromona y la evaporación eran necesarias, se usó el factor de escala “g” para controlarlo. En las pruebas realizadas se pudo observar que cuando el valor “g” era muy grande, el valor de la feromona creció más rápidamente de lo que se evaporó y finalmente alcanzó Tmax. Resulta evidente que cualquier valor de la actualización del valor de la feromona fue cercano a Tmax es óptimo. En el sistema de Ant Colony System (ACS) no solo usaremos una regla global para las actualizaciones, sino que también utilizaremos una regla especial. Después de que cada paso para la construcción, una -47-

Gestor de horarios regla local de la actualización se aplicará al elemento de la matriz de la feromona que corresponde al intervalo de tiempo elegido “tchosen” para el acontecimiento dado ei:

El parámetro α Є [0,1] es el parámetro de la feromona de decaimiento, la cual controla la diversificación de la construcción del proceso. El objetivo de la regla de actualización es el de poder seleccionar diferentes espacios de tiempo para un acontecimiento dado ei. Al final de la iteración, la regla global de la actualización se aplica a todas las entradas de la matriz de la feromona:

dónde g es un factor de escala. Como se puede observar esta regla global es muy parecida a la usada por el método MMAS, salvo que en esta no se limita el nivel mínimo ni máximo de la feromona. Otra diferencia importante entre estos dos algoritmos es la manera en la que se usa la información de la heurística. Mientras que en el MMAS no se usa la información heurística, el ACS intenta computar esta información en cada movimiento. En ACS la información heurística es una evaluación de las violaciones de las limitaciones (tanto las duras β como las blandas γ). La última diferencia que se tratará entre los dos algoritmos será la del uso de la búsqueda local. En el caso de MMAS, solamente la solución que implica el menor número de violaciones de las limitaciones será seleccionada por la rutina de búsqueda local. En cambio la búsqueda local en el caso de la búsqueda ACS funciona con una estrategia de dos fases: si la iteración actual es más baja que un parámetro j la rutina funciona para un número de pasos p1, sino, funcionará para un número de pasos s2. En este caso todas las posibles soluciones generadas por las hormigas se optimizarán más a fondo con el uso de la búsqueda local.

Nombre del

MMAS -48-

ACS

Gestor de horarios
parámetro m ρ s(j) τ0 Τmax Τmin α β γ g blandas Tabla1: Parámetros --Factor escalar

Numero de hormigas Feromona de evaporación Número de pasos en la búsqueda local Valor inicial de la matriz de la feromona Nivel máximo de la feromona Nivel mínimo de la feromona --feromona --duras --Peso de las limitaciones ----Decaimiento local de la Peso de las limitaciones

7.3Inteligencia utilizada
En este apartado se procederá a explicar en qué consiste la inteligencia usada para la realización del proyecto. 7.3.1Descripción La inteligencia utilizada en este proyecto está ambientada en varios tipos de búsquedas (especialmente de la búsqueda tabú), pero no sigue ninguna específicamente, debido entre otras cosas a las limitaciones del lenguaje PL/SQL. Una de las cosas a tener en cuenta es la utilización de un filtro para el manejo y generación de un horario inteligente. Ahora se explicará el uso del filtro usado para el proyecto. Los componentes de este filtro serán las limitaciones fuertes que se han considerado apropiadas para un horario universitario: 1. Un profesor no podrá dar más de 3 horas seguidas de clase. 2. Si un profesor tiene clase a primera hora de la mañana, este no podrá tener clase a última hora de la tarde y viceversa. -49-

Gestor de horarios 3. Un profesor no podrá tener dos clases a la vez el mismo día a la misma hora. 4. Un profesor no podrá impartir más de una asignatura por titulación en el mismo semestre. 5. No se le asignará a un profesor una clase si este tiene restricciones a esa hora (ya sean estas genéricas o especificas para un día). 6. Se tendrá en cuenta que el aula asignada a un determinado espacio de tiempo no esté ocupada, así como que su capacidad sea adecuada para albergar al número de alumnos de la asignatura a impartir. 7. Se tendrá en cuenta a la hora de asignar la clase que la hora sea de práctica o de teoría, debido a los recursos de dicho aula. 8. Ninguna asignatura podrá excederse en el número de horas tanto teóricas como prácticas que tiene. El sistema de búsqueda, apoyándose en el filtro arriba descrito, trabajará mediante un método de un bucle recursivo, dónde cuando vea que no pueda asignar ninguna asignatura en una determinada hora debido a que ninguna de estas ha podido pasar el filtro, tratará de hacer cambios entre las horas que quedan por meterse en el calendario con las que ya están puestas. En el caso de que no sea posible generar un horario por conflictos entre las limitaciones (por ejemplo que todos los profesores tengan una restricción en el mismo periodo de tiempo) se lanzará una excepción la cual avisará de la situación del horario y el problema que este tiene, para que así el administrador tome una decisión para que el sistema deje de ser insoluble.

7.3.2Priorización de intereses Otra de las cosas a considerar es que no solo la inteligencia al generar horarios tiene en cuenta los intereses de los profesores sino -50-

Gestor de horarios que también, como veremos a continuación, hemos priorizado los intereses de los estudiantes. El horario será modificado cada vez que se encuentre con la necesidad de cambiarlo debido a la inserción de una restricción por algún profesor. Ahora se explicará brevemente el significado de ambas restricciones: • • Restricciones genéricas: Serán aquellas que afectarán a varias semanas en un mismo intervalo de tiempo y el mismo día. Restricciones puntuales: Serán aquellas que afectarán sólo a un día en un intervalo de horas. Así es que cuando el cambio en el horario es debido a una restricción genérica, se modificará el horario, cambiando la hora afectada y el profesor afectado por otra hora y otro profesor que puedan hacer un cambio en ese horario, dado que tanto para los estudiantes como para los profesores es lo más idóneo. Para hacer este cambio se comprobará que las horas a cambiar puedan ser sustituidas, comprobando que pasa el filtro antes descrito. Sin embargo, lo más novedoso del sistema usado se verá cuando el profesor inserte una restricción puntual. Debido a que este cambio se dará en un plazo de tiempo mínimo y que cabe la posibilidad de que muchos alumnos no estén matriculados en todas las asignaturas de ese trimestre, por lo cual no tendrían manera alguna de enterarse de posibles cambios de horario, se intentará no cambiar la asignatura de hora sino poner a un profesor con el conocimiento de la asignatura, para poder impartirla el día de la restricción. En caso de que esto no sea posible, se seguirá el mismo paso que con las restricciones genéricas, pero como antes se ha dicho, siempre y cuando no sea posible efectuar el cambio antes descrito. La posibilidad de conocer que profesores tienen el conocimiento para impartir una determinada -51asignatura estaráen la tabla

Gestor de horarios “Conocimiento” de la base de datos, la cual por medio de la interface gráfica se meterá los datos y mediante una función se guardarán en la base de datos.

-52-

Gestor de horarios

8.Limitaciones
Se han podido encontrar diversos puntos a mejorar al finalizar el proyecto: 1. No se han considerado limitaciones blandas. Todas las limitaciones con las que se han trabajado han sido del tipo limitaciones duras, las cuales no se podían saltar. Pese a no ser esta una limitación muy importante, sin duda la aplicación de estas hubiese dado al proyecto una flexibilidad mucho mayor. 2. No se han tenido en cuenta las restricciones en aula. Al igual que los profesores podían tener diversas restricciones, se debía haber creado una tabla que tuviese en cuenta las restricciones de las aulas, ya que cualquier día, una clase podría estar ocupada por un acontecimiento que no tuviera nada que ver con los acontecimientos de la universidad, tales como cursillos particulares. 3. Calendario 5 x 5. El calendario con el que se ha trabajado trata de horarios de mañana y tarde de lunes a viernes. Las titulaciones de mañana se impartirán de 7:45 a 13:00 y las de tarde de 13:15 a 16:30. Por lo cual, el número de horas de cada día es de 10 horas teniendo 5 horas cada turno, es decir, un total de 25 horas a la semana cada titulación. El sentido de este se ha realizado para que estudiantes matriculados en dos cursos no les pueda coincidir ninguna hora. 4. Bucle infinito: Al no hacer uso de un historial de las horas metidas en el horario, no tendremos la posibilidad de poder comparar los cambios realizados en el horario con estados pasados, por lo cual podríamos quedarnos en un bucle sin salida. Para haber solventado este error, habría que haberse -53-

Gestor de horarios basado en alguna de las diversas inteligencias que aplican este historial.

-54-

Gestor de horarios

9.Conclusiones
Debido a todo lo expuesto, se ha llegado a la conclusión de que pese a que el sistema usado puede resultar válido, no es el más óptimo para este tipo de problemas NP sobre el manejo y generación de un horario de una universidad. En caso de empezar de nuevo a hacer el proyecto y de tener un límite de tiempo hasta la presentación más amplio, se hubiese reconsiderado la opción de utilizar un tipo de inteligencia que use una memoria, la cual guardaría todos y cada uno de los movimientos que ha tenido el horario a lo largo de su creación para no caer en un bucle infinito. El problema de esta modificación seguramente llegaría con el programa PL/SQL, ya que se tendría una infinidad de registros en su memoria interna y el proceso de generar un horario nuevo sería muy costoso (en tiempo y recursos) para el ordenador. Para esto, una posible adaptación sería la del conectar el programa que trabaja con la base de datos con una aplicación para la programación potente, la cual a poder ser disponga de una memoria virtual. Debido a que JAVA parece ser a día de hoy la aplicación más potente horarios. Otro de los temas más discutidos ha sido el de hacer el calendario fijándose la cantidad de horas por día de una titulación a 5. Sin entrar en si se deberían de poner más que 5 al día o no, parece bastante lógico dar la opción de que estas sean más de 5 y que sea la propia universidad la que decida el número de horas que se quiere tener en un día en concreto. Por último como bien se ha comentado en las limitaciones, se hubiera puesto en marcha un sistema min-max en el cual se hubiese dado un valor a cada profesor según la cantidad de horas a impartir y -55en cuanto a programación orientada a objetos, nos decantaríamos por él para este asunto de los historiales de los

Gestor de horarios la cantidad de restricciones. Mediante este sistema hubiésemos priorizado los intereses de los profesores más ocupados, haciendo un horario que sin ninguna duda, sería beneficioso tanto para los profesores como para los propios alumnos de la universidad que ejecutaría el programa realizado.

-56-

Gestor de horarios

10.Bibliografía
1. Libros
• Mª Jesús Ramos, Alicia Ramos, Fernando Montero, “Desarrollo de Aplicaciones en Entornos de 4º Generación y con Herramientas Case”. Editorial McGrawHill.

2. Artículos •
Haroldo G. Santos, Luiz S. Ochi, and Marcone J.F. Souza, “A Tabú Search with Efficient Problem”. Diversification Strategies for the Class/Teacher Timetabling

Luca Di Gaspero , Andrea Schaerf, “Multi-Neighbourhood Local Search for Course Timetabling”.

3. Web • • • • • http://www.oracle.com/technology/documentation/forms.html http://www.zonaOracle.com/foros-Oracle http://www.foros.emagister.com http://www.orasite.com/errores/ORA-00984.html http://www.aaai.org/AITopics/pmwiki/pmwiki.php/AITopics/Searc h

-57-