Instituto Politécnico Nacionalsappi.ipn.mx/cgpi/archivos_anexo/20070030_4995.pdf · UPIICSA,...

Instituto Politécnico

Nacional

Unidad Profesional Interdisciplinaria de Ingeniería, Ciencias Sociales y Administrativas

REPORTE FINAL Generación Automática de Horarios para las Academias de Informática Proyecto de Investigación No 20070030

Dr. Eric Manuel Rosales Peña Alfaro

Enero, 2008

Tabla de Contenidos INTRODUCCIÓN........................................................................................................ 1 I. El plan de trabajo....................................................................................................... 2 II. Resultados de las Fases Importantes ......................................................................... 2

2.1 El Problema de Horarios...................................................................................... 2 2.1.1 Características del problema de los horarios.................................................. 3 2.1.2 Los Horarios en la UPIICSA ........................................................................ 4

2.2 El Problema de Restricción de Satisfacciones......................................................7 2.2.1 Definición .................................................................................................... 7 2.2.2 Clasificación de la Programación de Restricciones ....................................... 8 2.2.3 Resolución del CSPs..................................................................................... 8 2.2.4 Conceptos CSP............................................................................................. 9 2.2.5 Notación CSP............................................................................................. 10 2.2.6 Restricciones .............................................................................................. 11 2.2.7 Aplicaciones............................................................................................... 12

2.3 Diseño de las Bases de Conocimientos ..............................................................13 2.3.1 Generación de Horarios .............................................................................. 13 2.3.2 Asignación de Profesores a Horarios........................................................... 16

2.4 Resultados de los experimentos ......................................................................... 19 2.4.1 Generación de horarios ............................................................................... 19 2.4.2 Separación de horarios por academia .......................................................... 20 2.4.3 Asignación de Profesores............................................................................ 21

2.5 Integración ........................................................................................................ 24 Conclusiones............................................................................................................... 26 REFERENCIAS ......................................................................................................... 27 Descripción del Contenido del CD incluido ................................................................ 29

EL PROBLEMA DE HORARIOS Dr. Eric Manuel Rosales Peña Alfaro

1

INTRODUCCIÓN Los horarios pueden ser definidos como un conjunto de reuniones programadas, en un lugar determinado a una hora especificada con la atención de un número determinado de personas. En este sentido existen horarios de conferencias, de seminarios, de juntas, de clases, de exámenes entre otros. El tema de horarios presenta el problema de diseño o construcción dado que pertenece a la clase de problemas denominados NP-completos; es decir que hasta el momento, no existe algún método que solucione el problema en un tiempo razonable (polinomial). Bloomfiel y McSharry establecieron: “dependiendo del tamaño del departamento y la diversidad de cursos ofertados, el tiempo requerido para producir la programación de horarios puede variar desde una tarde de trabajo hasta más de un mes de esfuerzo intensivo” [3]. En este sentido, entre más cursos deban ser programados el tiempo de programación de los mismos se incrementa considerablemente. El caso UPIICSA no es la excepción, aunque si presenta singularidades. El proceso de programación de horarios suele estar sujeto al cumplimiento de ciertas restricciones, las cuales pueden ser aplicadas durante el proceso de creación de los horarios o pueden ser utilizadas como punto de evaluación de los mismos para determinar su factibilidad operativa. En este sentido, la construcción de una solución es frecuentemente categorizada mediante la búsqueda de un horario que satisfaga todas las restricciones. Las restricciones son diversas y pueden variar. Además, las restricciones pueden ser agrupadas en duras y suaves. Un horario que viola una restricción dura no es una solución factible y debe ser reparada o rechazada por el algoritmo de creación de horarios. Por un lado, las restricciones duras suelen incluir “conflictos de primer orden” como por ejemplo que una persona no pueda ser requerida a atender más de una junta al mismo tiempo. Por el otro, las restricciones suaves son menos importantes que las duras, y usualmente es imposible evitar violar alguna de ellas. Aunado a lo anterior e independiente del algoritmo de programación de horarios que se utilice, éstos son usualmente graduados por una función de penalización, que calcula en que nivel un horario ha violado las restricciones suaves. Algunas de las restricciones suaves son más importantes que otras y por lo tanto el valor de prioridad es más alto que las otras. La producción central y coordinación de un horario de cursos es esencial dado que más módulos y eventos asociados tienen que ser programadas de tal manera que: i) Primeramente, se ofrezca máxima flexibilidad de selección a los estudiantes; ii) en segundo lugar, provea flexibilidad para la planta docente y iii) finalmente, garantice que los espacios de enseñanza son usados efectivamente. Dado lo anterior y las singularidades del proceso de planeación de horarios en la UPIICSA se propuso el desarrollo de un sistema que lo realizará de manera automática, atendiendo tanto a los aspectos de flexibilidad como respetando las restricciones políticas y operativas impuestas por la misma escuela. Es así como en este reporte se pretende dar a conocer los resultados de la investigación 20070030 auspiciada por la SIP del IPN. El reporte se integra, en este sentido, por las siguientes partes: i) se describe brevemente el plan de trabajo que sirvió de guía al desarrollo del proyecto, ii) se describen los resultados de cada fase, iii) se describe en detalle el sistema propuesto así como resultados de las pruebas individuales. Al final se presentan conclusiones y acciones a seguir para poner a punto el sistema en toda la UPIICSA


2

I. El plan de trabajo El plan de trabajo para buscar una solución adecuado al problema de horarios inicio con la suposición de que el problema se podía resolver utilizando técnicas de Satisfacción de Restricciones. Con este planteamiento se inicio la investigación documental concluyendo con el resumen de Técnicas de Satisfacción de Restricciones. El segundo paso realizado, fue caracterizar el problema de horarios en la UPIICSA como un problema de satisfacción de restricciones y como un problema que requería una solución basada en un sistema basada en conocimientos. En este sentido y siguiendo la metodología planteada en el proceso de ingeniería del conocimiento se concluyo con el documento “El problema de Horarios en la UPIICSA”. Encontrando que el problema se podía segmentar en tres fases:

a. La generación de horarios, b. La asignación de profesores a los horarios, y c. La asignación de salones a los horarios con profesor.

Cabe mencionar que la presente investigación se limitó a los dos primeros puntos, siendo las Academias de Informática el lugar para poder explotar la información y probar el sistema propuesto. Como tercera actividad y con el objetivo de comprender lo que sucede en la UPIICSA, se procedió a describir paso a paso el procedimiento de planeación de horarios en la UPIICSA, realizando entrevistas en la Subdirección Académica y varias jefaturas de Academias. El resultado de las entrevistas arrojo que el proceso suele tardarse hasta tres meses, existiendo aún al final errores que se corrigen ya entrado el semestre para el cual se planeo. La cuarta parte del proyecto consistió en el diseño y formulación de las bases de conocimientos para los dos procesos; así como de su validación por parte de los jefes de Academias. A continuación se formula el algoritmo de solución de cada una de las fases a realizar, terminándose el desarrollo de los algoritmos en Septiembre. La implementación de dichos algoritmos se terminó en el mes de Noviembre. El análisis de sensibilidad e instalación para sus pruebas onsite se está realizando actualmente, aunque el avance del proyecto puede considerarse de un 100%. A continuación se resumen los resultados de las fases importantes del proyecto.

II. Resultados de las Fases Importantes De las actividades descritas con anterioridad resaltan, por su importancia al proyecto la concerniente a la caracterización del problema de horarios, lo relativo al técnicas de Constraint Satisfaction Problems, así como lo relativo al diseño de las bases de conocimientos y los algoritmos de solución. Lo anterior es descrito a continuación.

2.1 El Problema de Horarios El problema de horarios tiene dos particularidades, se describe en términos formales y posteriormente se sitúa el marco referencial en la UPIICSA.


3

2.1.1 Características del problema de los horarios Desde el punto de vista de la Inteligencia Artificial, específicamente desde la perspectiva del método de Ingeniería del Conocimiento, todo problema debe ser caracterizado para definir qué método de solución podría ser el más viable ú óptimo. Una vez caracterizado el problema se podrá definir el problema formalmente. Dicho lo anterior, el problema de horarios puede ser caracterizado como sigue:

1. El problema de horarios puede ser descompuesto en tres etapas: a. Una primera etapa en la cual solo se generan los horarios,

independientemente de los profesores que impartan qué clases y los salones en los cuales se impartan esas clases.

b. En la segunda etapa, a cada horario se le asigna un profesor titular, un profesor asistente –en caso de que lo necesite- y si es necesario el profesor asistente del laboratorio –en caso de que la asignatura se asocie también a un laboratorio y éste dependa de las horas de cátedra.

c. En la última fase, los salones son asignados a los ya aceptados horarios-profesor.

2. En cada uno de los sub-problemas, nuevas asignaciones por ejemplo de asignatura a horario, pueden ser deshechas para buscar una nueva asignación y así evitar violaciones a las restricciones impuestas.

3. En el sub-problema de horarios no es tan visible el hecho de poder saber que va a pasar si se hace una asignación de un horario a una asignatura; este hecho es más previsible cuando se está asignando un profesor a un horario en particular ya que después se puede inferir si la próxima asignación –asignatura.horario-profesor – puede ser éxitosa o no. Lo mismo puede decirse de la asignación de salones aunque nuevamente es más compleja la previsión del éxito o del fracaso.

4. Este es un problema en el cual se requieren soluciones relativas, las cuales además de existir son muchas, como se verá más adelante

5. Además la solución requerida es un estado en el cual no se violan las restricciones del caso particular.

6. El conocimiento existente es mínimo dado que solo se conoce la disponibilidad de horarios, profesores (con sus limitaciones) y salones, y estos no cambian drásticamente semestre con semestre.

7. En términos de interacción con el usuario es importante señalar que si debe de existir, dado que es la persona que define si un estado es aceptable o no.

El problema de horarios puede definirse formalmente en términos de un problema de Satisfacción de Restricciones (CSP – Constraint Satisfaction Problem). Para poder entender esto, definiremos primeramente un problema de CSP en términos formales como sigue: Sea V el conjunto de variables a tener un valor asignado; D el dominio de valores posibles a ser asignado a V; la relación Rel:V�D, el mapeo de V hacia D sujeto a un conjunto de restricciones definidas en Res. Tomando en consideración la característica de poder descomponer el problema, podría ser más conveniente definir, formalmente, cada una de las partes que componen el problema, de la siguiente manera:

1. Horarios puros. Sea V el conjunto de variables Secuencia.Asignatura –SM(i)-, sea D el conjunto de horarios iniciales a asignar a las variables SM(i), y las restricciones podrían ser:


4

a. En la misma secuencia, dos asignaturas no pueden iniciar a la misma hora,

b. En la misma secuencia, dos asignaturas no se pueden traslapar 2. Asignación de profesores. El conjunto de variables, V, está formado por los

profesores y su disponibilidad de horarios y preferencias; el conjunto de valores disponibles a ser asignados, D. formado por las triadas Secuencia.Asignatura.Horario y las restricciones pueden ser:

a. A un profesor no se le puede asignar mas de una Secuencia.Asignatura.Horario que inicie a la misma hora,

b. A un profesor no se le puede asignar una Secuencia.Asignatura.Horario que produzca un traslape,

c. Las horas frente a grupo asignadas a un profesor deben ser menor o igual al tiempo disponible del mismo,

d. Las horas frente a grupo asignadas a un profesor deben de cumplir con la disponibilidad del mismo

3. Asignación de salones. En este caso, el conjunto de variables es formado por las cuádruplas Secuencia.Asignatura.Horario.Profesor y el conjunto de valores a serles asignados, D, los identificadores de los salones; mientras que el conjunto de restricciones puede ser:

a. La capacidad de los salones, b. Requerimientos especiales de ciertos profesores, como por ejemplo no

poder subir escaleras por enfermedad.

2.1.2 Los Horarios en la UPIICSA La Unidad Profesional Interdisciplinaria de Ingeniería, Ciencias Sociales y Administrativas (UPIICSA) es una escuela de nivel superior del Instituto Politécnico Nacional (IPN). Surgió en el año de 1972 como solución a la problemática industrial y de servicios de aquella época, impartiendo las carreras de Licenciaturas en Ingeniería Industrial y Administración Industrial con un enfoque interdisciplinario; en el año de 1974 surge la Licenciatura en Ciencias de la Informática y en el año de 1976 se implanta la Licenciatura en Ingeniería del Transporte. Para el año 1998, la Licenciatura en Ingeniería en Informática inicia actividades. Siendo éstas cinco carreras las que se siguen impartiendo hoy en día. En promedio se puede hablar de que cada semestre se atiende a aproximadamente 9000 alumnos distribuidos en los cerca de 180 grupos entre todas las carreras. La UPIICSA, para poder atender a los alumnos de las cinco carreras está organizada en 4 departamentos: Ciencias Básicas, Ciencias Sociales y Administrativas, Ciencias de la Ingeniería y Ciencias Aplicadas; junto con un laboratorio: Laboratorios Ligeros que depende del departamento de Ciencias Básicas. Cada departamento, a su vez, se divide en Academias. Las academias son las directamente asociadas a la impartición de clases a las cinco carreras. Cada carrera tiene estructurado un plan de estudios, en el cual se tienen las asignaturas que los alumnos deben tomar por cada semestre. Las asignaturas están distribuidas a lo largo y ancho de la UPIICSA, correspondiendo a las Academias mantener los programas de estudio. Es así como dentro de cada área de Academias, existen una o varias Academias que agrupan a una ó más asignaturas, de acuerdo al conjunto y relación de conocimientos que en éstas se imparten.


5

Históricamente, se puede hablar que en la UPIICSA, los horarios son construidos en tres niveles: en la subdirección académica, a través de su departamento de control de horarios, hoy absorbido por el departamento de control y apoyo a las actividades docentes; los departamentos y laboratorios; y las diversas academias involucradas en los respectivos planes de estudio. Esta construcción tendía a ser lo más flexible posible con el objetivo de que los alumnos tuvieran la oportunidad de generar sus propios calendarios de horarios, en base a sus necesidades y preferencias. Esto hace que en la UPIICSA, se tenga un sistema de oferta de horarios, denominados secuencias, único en todo el IPN. Desde hace 3 años se han incrementado las dificultades para la generación de las secuencias, debido a las siguientes razones:

1. Cambios de los puestos por seguimiento de la reglamentación correspondiente y falta de capacitación o de transmisión de los conocimientos de manera apropiada. Esto trae consigo que los nuevos jefes de academias que no conocen el procedimiento de generación de horarios, reflejen cierta inexperiencia; efectuando decisiones no óptimas de distribución de horarios y de asignación de profesores a esos horarios.

2. El incremento en la población estudiantil expresada en los siguientes términos: i) incremento de alumnos aceptados al primer semestre de las carreras que la UPIICSA imparte, el cuál seguirá aumentando; ii) incremento en el número de alumnos, que pasado un semestre de estudios ya sea en la misma UPIICSA o en otras escuelas del IPN, deciden cambiar de carrera. El incremento de reprobación de alguna generación en alguno de los semestres, provocando una mayor demanda de secuencias para alumnos defasados1.

3. El incremento de alumnos que por dictamen de comisión de honor se re-incorporan a las clases.

4. La alta dinámica de movilidad docente de algunas academias que provocan cancelaciones inesperadas de secuencia.asignaturas.

Lo anterior, ha provocado que al inicio de cada semestre se tengan los siguientes problemas:

1. La oferta de horarios no está 100% actualizada en el sistema SIGUE2 al momento del periodo de reinscripciones.

2. Retraso en las inscripciones o re-inscripciones por parte de los alumnos a las secuencia.asignaturas.

3. Retraso en el procesamiento de cambios, que afectan la oferta de horarios y por ende los periodos de re-inscripción.

Estos problemas, se han incrementado en el último año académico. Los horarios son generados de manera integral por los departamentos y las jefaturas de academias, todos ellos coordinados por la subdirección académica, a través de la coordinación de horarios, actualmente extinta. Desde hace tres semestres, ésta actividad ha sido coordinada por el departamento de control y apoyo a las actividades docentes. Históricamente, la generación de horarios se desarrollaba de la siguiente manera. La coordinación de horarios enviaba a las jefaturas de academias el número de secuencias 1 Sobre todos los que reprueban y tienen que cursar más asignaturas de un semestre inmediato bajo 2 Sistema de Gestiín y Unificación Escolar


6

que se ofertarían para un siguiente semestre, existiendo un orden y un tiempo límite para que las academias propusieran los horarios de las materias que les corresponden. Desgraciadamente, éste conocimiento está perdido y solo es posible hacer conjeturas al respecto. Por ejemplo, para el caso de las carreras de Ciencias de la Informática e Ingeniería Informática, el orden era: Informática, Computación, etc. Como se menciona éste conocimiento está perdido y solo es posible realizar conjeturas al respecto: La prioridad está marcada por las academias esenciales básicas de cada carrera, siguiendo posteriormente las complementarias. El proceso de construcción de horarios iniciaba con la decisión de cuántas secuencias por semestre por carrera se tendrían que ofertar. Ésta decisión se basaba en una estimación del número de aprobados del nivel inmediato anterior y el número de re-probados del nivel en consideración. Ejemplo, para determinar el número de secuencias para el tercer semestre de la carrera de Ingeniería Informática, asumiendo que el estimado de aprobados del 2do semestre fuera de 170 y qué el número de reprobados del mismo tercer semestre fuera de 20, entonces se tendría una demanda esperada de 190, considerando una tolerancia de 10 alumnos más, se podría planear abrir una oferta par 200 alumnos. Ahora bien asumiendo, una capacidad uniforme de 40 alumnos por grupo ( 540200 =÷ ), se podrían abrir cinco secuencias. El proceso de creación de horarios continuaba al pasar las matrices de los horarios a las diversas academias involucradas en una carrera de manera secuencial; es decir, que existían ciertas prioridades para la asignación de tiempos (horas de inicio-fin) a las asignaturas pertenecientes a aquellas academias que se consideraban esenciales a la carrera. En el ejemplo de los horarios de tercer semestre de Ingeniería Informática, las academias esenciales son Informática y Computación, por lo que basado en preferencias del número de profesores de tiempo completo de base se procedía asignar mayor prioridad a aquella academia que tuviera menos profesores de tiempo completo. En este sentido, para el caso ejemplo, las matrices pasaban primero a las Academias de Computación, dado que las Academias de Informática no tienen asignaturas asignadas a esta carrera en este semestre, donde se escribían las asignaturas en los horarios correspondientes. Luego, de haber sido llenadas por Computación, ya con espacios ocupados, las matrices se entregaban a las demás academias (Administración, Química y Matemáticas) de la misma manera. Ajustes, correcciones y modificaciones se desarrollaban de manera iterativa hasta que, en este caso, las cinco secuencias tenían asignadas todas las materias a horarios respectivos; respetando la inexistencia de traslapes. Una vez obtenido el horario del semestre, las matrices eran reproducidas en el número de academias involucradas, en nuestro ejemplo de las cinco matrices se generaban cuatro juegos, los cuales eran entregados a las academias (Computación, Administración, Química y Matemáticas) para que fueran asignados profesores. De esta manera, la asignación de profesores ocurría de manera paralela en cada jefatura de Academias. El área central, verificaba que no existieran errores y entonces se integraba con los demás horarios de las demás carreras, para poder ser desplegados en oferta a los alumnos.


7

Es importante notar, que aunque el ejemplo solo lo dimos para el tercer semestre de la carrera de Ingeniería Informática, el proceso ocurre de manera concurrente y paralela a todas las carreras en todos los semestres. Ya el último año académico, se empezó a manejar no el mismo procedimiento: la repetición de secuencias del semestre correspondiente al año académico anterior con “ligeras” modificaciones, que en lugar de provocar mayores opciones de horario, produjeron secuencias.materias saturadas, traslapadas y con pocas posibilidades de ser asignadas a algún profesor. Más aún, a este problema se le sumo, los cambios en disponibilidades que los profesores de las academias esenciales de cada carrera realizaron por motivos tales como: permisos de ausencia autorizados, descargas académicas solicitadas o cambios en las disponibilidades de los profesores de tiempo parcial. Se estima que el proceso de creación de horarios se estabilice aunque de manera paulatina y lenta en función de que los participantes obtengan mayor experiencia y mejores políticas de evaluación y generación de horarios se vayan generando. Por ello, se ha estado realizando este esfuerzo para generar un sistema que genere los horarios de la UPIICSA de manera automática con mínima intervención humana.

2.2 El Problema de Restricción de Satisfacciones

2.2.1 Definición La programación de restricciones es una tecnología software utilizada para la descripción y posterior resolución efectiva de grandes y complejos problemas, particularmente combinatorios, de muchas áreas de la vida real. Muchos de estos problemas pueden modelarse como problemas de satisfacción de restricciones (CSPs) y resolverse usando técnicas de programación de restricciones. Esto incluye problemas de áreas tales como inteligencia artificial, investigación operativa, bases de datos, sistemas expertos, etc. Algunos ejemplos son scheduling, planificación, razonamiento temporal, diseño en la ingeniería a, problemas de empaquetamiento, criptografía, diagnosis, toma de decisiones, entre otros. Durante los últimos años la programación de restricciones ha generado una gran expectación entre expertos de muchas áreas debido a su potencial para la resolución de grandes problemas reales. Por ello, no es de sorprender, que la ACM (Association for Computer Machinery) ha identificado a la programación de restricciones como una de las direcciones estratégicas en la investigación informática. Sin embargo, al mismo tiempo, se considera la programación de restricciones como una de las tecnológicas menos conocida y comprendida. La programación de restricciones se define como el estudio de sistemas computacionales basados en restricciones. La idea de la programación de restricciones es resolver problemas mediante la declaración de restricciones sobre el área del problema y consecuentemente encontrar soluciones que satisfagan todas las restricciones, y en su caso optimicen unos criterios determinados.


8

2.2.2 Clasificación de la Programación de Restricci ones La programación de restricciones puede dividirse en dos ramas claramente diferenciadas: la satisfacción de restricciones y la resolución de restricciones. Ambas comparten la misma terminología pero sus orígenes y técnicas de resolución son diferentes. La satisfacción de restricciones trata con problemas con dominios finitos, mientras que la resolución de restricciones está orientada principalmente a problemas sobre dominios infinitos o dominios más complejos. Este resumen se enfocará a la Satisfacción de Restricciones, que básicamente consiste en un conjunto finito de variables, un dominio de valores para cada variable y un conjunto de restricciones que acotan la combinación de valores que las variables pueden tomar. Asi el objetivo es encontrar un valor para cada variable de manera que se satisfagan todas las restricciones del problema.

2.2.3 Resolución del CSPs La resolución de un problema de satisfacción de restricciones (CSP) consta de dos fases diferentes:

1. Modelar el problema como un problema de satisfacción de restricciones. La modelización expresa el problema mediante una sintaxis de CSPs, es decir, mediante un conjunto de variables, dominios y restricciones del CSP.

2. Procesar el problema de satisfacción de restricciones resultante. Una vez formulado el problema como un CSP, hay dos maneras de procesar las restricciones:

a. Técnicas de consistencia. Se trata de técnicas para la resolución de CSPs basadas en la eliminación de valores inconsistentes de los dominios de las variables.

b. Algoritmos de búsqueda. Estos algoritmos se basan en la exploración sistemática del espacio de soluciones hasta encontrar una solución o probar que no existe tal solución.

Las técnicas de consistencia o inferenciales permiten deducir información del problema, (niveles de consistencia, valores posibles de variables, dominios mínimos, etc.), aunque en general se combinan con las técnicas de búsqueda, ya que reducen el espacio de soluciones y los algoritmos de búsqueda exploran dicho espacio resultante. 2.2.3.1 Modelización del CSP Generalmente la declaración de un problema se suele expresar de muchas maneras diferentes, e incluso en lenguaje natural. Una parte muy importante para la resolución de problemas de la vida real es el modelado del problema en términos de CSPs, es decir, variables, dominios y restricciones. A continuación se considerarás un ejemplo en el cual veremos distintas modelizaciones de un mismo problema y las ventajas de una modelización adecuada para resolverlo. Consideremos el conocido problema criptográfico 'send+more=money'. El problema puede ser declarado como: asignar a cada letra {s, e, n, d, m, o, r, y} un digito diferente del conjunto {0,...,9} de forma que se satisfaga send+more=money. La manera mas fácil de modelar este problema es asignando una variable a cada una de las letras, todas ellas con un dominio {0,...,9} y con las restricciones de que todas las


9

variables toman valores distintos y con la correspondiente restricción para que se satisfaga 'send+more=money'. De esta forma las restricciones (no binarias) son:

� 103(s+m)+102(e+o)+10(n+r)+d+e = 104m + 103o + 102n + 10e + y; � restricción de todas diferentes (s, e, n, d, m, o, r, y);

Para el algoritmo mas general como es Backtracking (BT) este modelo no es muy eficiente porque con BT, todas las variables necesitan ser instanciadas antes de comprobar estas dos restricciones. De esta manera no se puede podar el espacio de búsqueda para agilizar la búsqueda de soluciones. Además, la primera restricción es una igualdad en la que forman parte todas las variables del problema (restricción global) por lo que dificulta el proceso de consistencia. Un modelo más eficiente para resolver el problema es el que utiliza los bits de acarreo para descomponer la ecuación anterior en una colección de pequeñas restricciones. Tal y como está planteado el problema, M debe de tomar el valor 1 y por lo tanto S solamente puede tomar valores de {1,…,9}. Además de las variables del modelo anterior, el nuevo modelo incluye tres variables adicionales, c1, c2, c3 que llamaremos 'portadoras'. Los dominios de las variables e, n, d, o, r e y son {0,…,9}, el dominio de s es {1,…,9}, el dominio de m es {1}, y los dominios de las variables portadores c1, c2, c3 son {0,1}. Con la ayuda de las variables portadores, la restricción de la ecuación anterior puede descomponerse en varias restricciones más pequeñas:

� e + d = y + 10c1; � c1 + n + r = e + 10c2; � c2 + e + o = n + 10c3; � c3 + s + m = 10m + o. � restricción de todas diferentes (s, e, n, d, m, o, r; y);

La ventaja de este modelo es que estas restricciones más pequeñas pueden comprobarse antes en la búsqueda de backtracking, y así podarse muchas inconsistencias. En las dos formulaciones anteriores, la restricción de todas diferentes puede reemplazarse por un conjunto de pequeñas restricciones, es decir s; r 6= y, obteniendo así un modelo alternativo. Como hemos visto en las formulaciones anteriores, dependiendo de la transformación que se haga del problema planteado en lenguaje natural a la modelización en forma de CSP, el problema se resolverá con más o menos eficiencia. Concretamente, en el contexto de los problemas de satisfacción de restricciones no binarias, cuando tratamos de resolver un CSP no binario ya modelado, nos volvemos a encontrar con un nuevo problema crucial de modelización. ¿Debemos convertir el problema no binario en uno binario, o debemos dejarlo en su formulación original?

2.2.4 Conceptos CSP En esta sección presentamos los conceptos y objetivos básicos que son necesarios en los problemas de satisfacción de restricciones.


10

CSP. Un problema de satisfacción de restricciones (CSP) es una terna (X, D, C) donde:

1. X es un conjunto de n variables {x1,…, xn}. 2. D =< D1,…,Dn > es un vector de dominios. La i-ésima componente Di es el

dominio que contiene todos los posibles valores que se le pueden asignar a la variable Xi.

3. C es un conjunto finito de restricciones. Cada restricción n-aria (Cn) esta definida sobre un conjunto de variables {x1,…,xn} restringiendo los valores que las variables pueden simultáneamente tomar.

Asignación. Una asignación de variables, también llamado instanciación, (x, a) es un par variable-valor que representa la asignación del valor a, a la variable x. Una instanciación de un conjunto de variables es una tupla de pares ordenados, donde cada par ordenado (x; a) asigna el valor a a la variable x. Una tupla ((x1, a1),…, (xi, ai)) es localmente consistente si satisface todas las restricciones formadas por variables de la tupla. Para simplificar la notación, sustituiremos la tupla ((x1, a1),…,(xi, ai)) por (a1,…, ai). Solución. Una solución a un CSP es una asignación de valores a todas las variables de forma que se satisfagan todas las restricciones. Es decir, una solución es una tupla consistente que contiene todas las variables del problema. Una solución parcial es una tupla consistente que contiene algunas de las variables del problema. Por lo tanto diremos que un problema es consistente, si existe al menos una solución, es decir una tupla consistente (a1, a2,…, an). Básicamente los objetivos que se desean obtener de un CSP se centran en encontrar:

1. Una solución, sin preferencia alguna, 2. Todas las soluciones, 3. Una optima, o al menos una buena solución, dando alguna función objetivo

definida en términos de algunas o todas las variables.

2.2.5 Notación CSP La notación utilizada en la Satisfacción de Restricciones es la siguiente: General: El número de variables de un CSP se denotará por n. La longitud del dominio una variable xi se denotara por di = |Di|. El número de restricciones totales se denotará por c. La aridad máxima de una restricción se denotará por k. En el caso de problemas disyuntivos, al número máximo de disyunciones que tiene una restricción disyuntiva se denotará por l. Variables: Para representar las variables se utilizará las ultimas letras del alfabeto en cursiva, por ejemplo x, y, z, así como esas mismas letras con un subíndice, por ejemplo x1, xi, xj. Estos subíndices son letras seleccionada por mitad del alfabeto o números enteros. Al conjunto de variables xi,…, xj se denota por Xi,…,j . Dominios/Valores: El dominio de una variable xi lo denotamos por Di. A los valores individuales de un dominio los representaremos mediante las primeras letras del alfabeto, por ejemplo, a; b; c, y al igual que en las variables también pueden ir seguidas


11

de subíndices. La asignación de un valor a a una variable x la denotaremos mediante el par (x; a). Como ya en la definición una tupla de asignación de variables ((x1, a1),…, (xi; ai)) se denota por (a1,…, ai). Restricciones: Una restricción k-aria entre las variables {x1,…,xk} se denotará por C1..k. De esta manera, una restricción binaria entre las variables xi y xj se denota por Cij. Cuando los índices de las variables en una restricción no son relevantes, se denotará simplemente por C. El conjunto de variables involucrados en una restricción Ci...k se representara por XCi..k .

2.2.6 Restricciones En esta sección veremos algunas definiciones sobre restricciones y explicaremos algunas de las propiedades básicas. La aridad de una restricción es el número de variables que componen dicha restricción. Una restricción unaría es una restricción que consta de una sola variable. Una restricción binaria es una restricción que consta de dos variables. Una restricción ternaria consta de tres variables. Una restricción no binaria (o n-aria) es una restricción que involucra a un número arbitrario de variables. 2.2.6.1 Consistencia en un CSP Los algoritmos de búsqueda sistemática para la resolución de CSPs tienen como base la búsqueda basada en backtracking. Sin embargo, esta búsqueda sufre con frecuencia una explosión combinatoria en el espacio de búsqueda, y por lo tanto no es por sí solo un método suficientemente eficiente para resolver CSPs. Una de las principales dificultades con las que nos encontramos en los algoritmos de búsqueda es la aparición de inconsistencias locales que van apareciendo continuamente. Las inconsistencias locales son valores individuales o combinación de valores de las variables que no pueden participar en la solución porque no satisfacen alguna propiedad de consistencia. Las restricciones explicitas en un CSP, que generalmente coinciden con las que se conocen explícitamente del problema a resolver, generan cuando se combinan restricciones implícitas que pueden causar inconsistencias locales. Si un algoritmo de búsqueda no almacena las restricciones implícitas, repetidamente redescubrirla la inconsistencia local causada por ellas y malgastarla esfuerzo de búsqueda tratando repetidamente de intentar instanciaciones que ya han sido probadas. 2.2.6.1.1 Backtracking Cronológico El algoritmo de búsqueda sistemática para resolver CSPs es el Algoritmo de Backtracking Cronológico (BT). Si asumimos un orden estático de las variables y de los valores en las variables, este algoritmo trabaja de la siguiente manera. El algoritmo selecciona la siguiente variable de acuerdo al orden de las variables y le asigna su próximo valor. Esta asignación de la variable se comprueba en todas las restricciones en las que forma parte la variable actual y las anteriores. Si todas las restricciones se han satisfecho, el backtracking cronológico selecciona la siguiente variable y trata de encontrar un valor para ella de la misma manera. Si alguna restricción no se satisface entonces la asignación actual se deshace y se prueba con el próximo valor de la variable actual. Si no se encuentra ningún valor consistente entonces tenemos una situación sin salida (dead-end) y el algoritmo retrocede a la variable anteriormente asignada y prueba asignándole un nuevo valor. Si asumimos que


12

estamos buscando una sola solución, el backtracking cronológico terminará cuando a todas las variables se les ha asignado un valor, en cuyo caso devuelve una solución, o cuando todas las combinaciones de variable-valor se han probado sin éxito, en cuyo caso no existe solución. Es fácil ver como el backtracking cronológico puede ser generalizado a restricciones no binarias. Cuando se prueba un valor de la variable actual, el algoritmo comprobarla todas las restricciones en las que solo forman parte la variable actual y las anteriores. Si una restricción involucra a la variable actual y al menos una variable futura, entonces esta restricción no se comprobaría hasta que se hayan comprobado todas las variables futuras de la restricción. Por ejemplo, si nosotros tenemos las restricciones x1 + x2 + x3 > 5 y x1 + x3 + x4 > 0 y x3 es la variable actual entonces el backtracking cronológico comprobaría la primera restricción, pero debería esperar hasta que tratemos de instanciar x4 antes de comprobar la segunda restricción. El backtracking cronológico es un algoritmo muy simple pero es muy ineficiente. El problema es que tiene una visión local del problema. Solo comprueba restricciones que están formadas por la variable actual y las pasadas, e ignora la relación entre la variable actual y las futuras. Además, este algoritmo es ingenuo en el sentido de que no 'recuerda' las acciones previas, y como resultado, puede repetir la misma acción varias veces innecesariamente.

2.2.7 Aplicaciones La programación de restricciones se ha aplicado con mucho éxito a muchos problemas de áreas tan diversas como planificación, scheduling, generación de horarios, empaquetamiento, diseño y configuración, diagnosis, modelado, recuperación de información, CAD/CAM, criptografía, etc. Los problemas de asignación fueron quizás el primer tipo de aplicación industrial que fue resuelta con herramientas de restricciones. Otra área de aplicación de restricciones típica es la asignación de personal donde las reglas de trabajo y unas regulaciones imponen una serie de restricciones difíciles de satisfacer. El principal objetivo en este tipo de problemas es balancear el trabajo entre las personas contratadas de manera que todos tengas las mismas ventajas. Existen sistemas como Gymnaste que se desarrollo para la generación de turnos de enfermeras en los hospitales, para la asignación de tripulación a los vuelos (British Airways, Swissair), la asignación de plantillas en compañías ferroviarias (SNCF, Compañía de Ferrocarril Italiana) o sistemas para la obtención de mallas ferroviarias optimas. Sin embargo, una de las áreas de aplicación mas exitosa de los CSPs con dominios finitos es en los problemas de secuenciación o Scheduling, donde de nuevo las restricciones expresan las limitaciones existentes en la vida real. El software basado en restricciones se utiliza para la secuenciación de actividades industriales, forestales, militares, etc. En general, el uso de las restricciones en sistemas complejos de planificación y scheduling se esta incrementando cada vez mas debido a las tendencias de las empresas de trabajar bajo demanda.


13

2.3 Diseño de las Bases de Conocimientos Partiendo de las necesidades del modelar el problema de horarios en términos de un CSP, se logró lo siguiente

2.3.1 Generación de Horarios El modelo CSP para la generación de horarios puede ser visto como sigue:

1. Sea V el conjunto de variables a ser asignadas cuyo contenido es { },....12,.12 ccincmccercmV =

2. Sea el D, el dominio de valores que cada variable puede tener { }..}),...}),.12,11,10{,(}),12,11,10{,{(,(}).,..}),9,8,7{,(}),9,8,7{,{(,( jmccinmlccerD =

3. Sea R el conjunto de restricciones, básicamente a. No existan traslapes b. Que los días asignados a una variable no sean consecutivos

Dado lo anterior se tiene las siguienres variables: Semestre=[1,2,3,4,5,6,7,8] NSecpSempTurno=[(M1,T1),(M2,T2),(M3,T3),(M4,T4),(M5,T5),(M6,T6),(M7,T7),(M8,T8)], donde Mi,Ti son el número de secuencias por semestre que se ofertarán MatxSemxCarr=[(CarrID,[(1,[M1,M2,M3…]),…,(8,[M1,M2,M3…])]),…] donde Mi=(Clavemateria,HrsxSem,NoSes,HrsxSesion) CarrId={a,c,f,i,t}/a=Administración Industrial, c=Ciencias de la Informática, f=Ingeniería Informática, i=Ingeniería Industrial y t=Ingeniería en Transporte Objetivo: Producir 5x8 archivos planes, uno por cada semestre por cada carrera, con el siguiente formato: secuencia(HorariosxCarreraxSemestre) Donde: HorariosxCarreraxSemestre =[(Semestre1,HorxSem1),...,(Semestren,HorxSemn)] Semestrei = numero del semestre (2...8) HorxSem=[(S1,Horsec1),...,(Sn,Horsecn)] Si=Identificador de la Secuencia, ejemplo cm5 HorSeci=[(Mat1,HorMat1),...,(Matn,HorMatn)] Mati=Identificador de la asignatura, ejemplo CCAF HorMati=Horario de la materia= [(Dia1,HoraInicio1,HrsxSesion1),...,(DIAn,HoraInicion,HrsxSesionn)] El problema CSP de generación de horarios se define como Sea V: el conjunto de materias a los cuales se les debe asignar un conjunto de días-horas -(día, Listahorainicio,HrsxSesión)- de D: tal que D puede ser uniforme (el mismo conjunto) para todas las materias o no-uniforme si el conjunto de Listahorainicio es variable entre todas las materias Se tienen las siguientes restricciones locales

1) Evitar traslapes


14

1)( hasta )( desde

}/{

1)(

−+==⇒

−+−−−

onNoHrsxSesivHvH

uearhorasabloqddD

onNoHrsxSesivH

ii

ii

i

2) No asignar días consecutivos (si es que aplica) Si NoSes >1 � Sacar d1∈Du y sacar d2∈Du / d2=d1+2 Si d1=J � d2=L Si d1=V � d2=L Combinaciones en donde se prefieren L a J

d1 d2 L W L J M J L V M V W V

PREMISAS 1. Los horarios de un semestre (1º) son independientes de los horarios de otros semestre (2º-8º). Esto implica que se pueden correr ya sea de manera secuencial o en paralelo sin afectar la asignación de horarios entre semestres. 2. Los horarios son independientes entre carreras. PROCEDIMIENTO GENERAL

Arma Variables (principalmente Claves de Secuencias) a. Semestre � strSem b. Traer LMatSem de

miembro((CarrId,Semestre,LMatSem),MatxSemxCarr) c. De N=1 a NoSecPSem

i. N � strN ii. Concatena strSem+CarrId+Turno+StrN � SEC

Arma Horarios por cada secuencia %Aqui se tiene armado n variables p/horarios de una secuencia Entradas: LMatSem,HorariosDisponibles

iii. Arma Horario para Secuencia N iv. Si N>1

1. Compara horario N contra j=1...N-1. Si iguales entonces modificar Horario N

El armado de Horarios se puede realizar como sigue:

1. Tomar v∈V 2. Asignar (v,d)�VD, de acuerdo a restricción local (2) 3. Propagar VD a D(v’)/v’≠v

a. Traer NoHrsxSesion de BC b. Computar D- según restricción local (1) c. Quitar D- de D/v’≠v

4. Si hay inconsistencias realizar retrocesos y repetir con otra asignación para v


15

Los horarios construidos tienen el formato siguiente: […(Seci,HorSeci)…] Donde Seci =clave de la secuencia (cm5) HorSeci=[..,(Mati,HorMati),…] Mati =clave de la matéria (ccaf) HorMati=[…,(Diai,Hinicioi,HrsSesi),…] Diai =día de la semana (l,m,w,j,v) Hinicioi =Hora de inicio HrsSesi =No de horas de ésta sesión Pero la estructura de horarios a entregar debe ser Estructura horarios HorariosxCarreraxSemestre =[X|RestoHorarios] X=(Secuencia,HorarioSecuencia) Secuencia = 4cm5 HorarioSecuencia=[(l,LMatD),…,(Dia,LMatD),…] LMatD=[(Hinicio1,Mat1,HrsSes),…] Donde: HorariosxCarreraxSemestre =[(Semestre1,HorxSem1),...,(Semestren,HorxSemn)] Semestrei = numero del semestre (2...8) HorxSem=[(S1,Horsec1),...,(Sn,Horsecn)] Si=Identificador de la Secuencia, ejemplo cm5 HorSeci=[(Mat1,HorMat1),...,(Matn,HorMatn)] Mati=Identificador de la asignatura, ejemplo CCAF HorMati=Horario de la materia= [(Dia1,HoraInicio1,HrsxSesion1),...,(DIAn,HoraInicion,HrsxSesionn)] Por lo que debe existir un procedimiento de conversión de un formato a otro Para propósitos de presentación (impresión) Los horarios en la mañana van de 7 a 14 y en la tarde de 14 a 21, como horas de inicio y de Luneas a Viernes. Esto provoca tener un arreglo Horario[8][5]. Los índices son i para los renglones (las horas) y j para las columnas (los días) Cálculo de i -----------------------------(1) Si turno=m � i=Hinicio-7 Si turno=v � i=Hinicio-14 Cálculo de j -----------------------------(2)

Tomar HxD∈HorarioSecuencia: miembro((Dia,HxD),LMatD) j = Dia

Tomar Hinicio∈HxD PROCESO DE TRANSFORMACION PARA PRÓPOSITOS DE IMPRESIÓN

1. Tomar HorSec∈ListaHorarios, (Sec,HorSec) 2. Turno=substr(Sec,3,1) 3. Para c/(D,LMatD)∈HorSec


16

a. j=D b. Para c/(Hinicio,Mat,HrsSes)∈LmatD

i. Calcular i según (1) ii. De i1=i hasta i+HrsSes-1

1. Horário[i][j]=Mat

2.3.2 Asignación de Profesores a Horarios El modelo de CSP para la asignación de profesores a horarios se puede visualizar como sigue:

4. Sea V el conjunto de variables a ser asignadas cuyo contenido es { })}),...2,9,(),2,9,{(,.12()}),2,7,(),2,7,{(,.12( wlccincmwlccercmV =

5. Sea el D, el dominio de valores que cada variable puede tener { })...,_(),...,,_( 11 ii sordatosprofeprofesorRFCsordatosprofeprofesorRFCD =

6. Sea R el conjunto de restricciones, básicamente a. No asignar el mismo profesor a dos asignatura que tengan el mismo día y

hora de inicio b. No asignar más de las horas máximas frente a grupo permitidas para el

profesor Cómo su nombre lo dice, la idea es que a cada materia de cada secuencia se le asigne un único profesor. En este sentido la relación es de 1 a 1. En el sentido inverso, a un profesor se le pueden asignar varias materias en diferentes secuencias. Este es un problema de distribución de recursos con restricciones, es más fácil propagar restricciones sobre la disponibilidad del profesor. De hecho, al asignarle una materia se disminuyen las horas de su disponibilidad. Detalles sobre base de conocimientos y estructuras de datos. Disponibilidad de profesores. disponibilidad(RFC,Hrsnomb,Hrsfrtegpo,sobrecarga,LHrsDisp,LAsigPref) RFC del profesor, Hrsnomb horas de nombramiento en total HrsFrtegpo horas que debe tener frente a grupo: (Min,Max) tomando en consideración

las horas de nombramiento totales. (qué pasa con aquellos que tienen dos o más plazas?, existen profesores que sumen 40 hrs con múltiples plazas?, qué categorías tienen?, qué dice la reglamentación al respecto?).

Sobrecarga. 0 si no, 1 si si. Esta bandera tiene la finalidad de asignar más grupos de los que la reglamentación marca. Sobre todo para profesores de tiempo parcial que desean obtener más horas de base.

LHrsDisp lista de horas disponibles que el profesor tiene para dar clases. Tiene el siguiente formato:

LHrsDisp=[…,(Turno,[…,(Dia,HoraInicio,HoraFinal),…]),…] Turno puede ser M o V. Si um profesor tiene disponibilidad mixta se ponen lãs

horas de la mañana y lãs horas de la tarde por separado: [(M,[]),(V,[])] Día de la semana L,M,W,J,V (W por miércoles) HoraInicio Hora inicial


17

HoraFinal Hora final LAsigPref. Lista de asignaturas ordenadas por preferência mayor a menor, que el

profesor está dispuesto a dar. Tiene el siguiente formato: LAsigPref=[…,(CveMat,Sem,CarrId),…]

CveMat clave de la materia Sem Semestre en el que se da. CarrId Identificador de la carrera.

Si sobrecarga � maxhrsfrentegpo (asignadas) ≥ HrsFrtegpo.Max Si ¬sobrecarga � HrsFrtegpo.Min ≤ maxhrsfrentegpo (asignadas) ≤ HrsFrtegpo.Max En la asignación de profesores a horarios las entradas son: LProfesores=[RFC1,…, RFCn]. Lista de profesores profesordisp ordenada ascendentemente conforme horas de nombramiento (tiempo parcial a tiempo completo) y categoría (asignatura a titular). La asignación de profesores a horarios conlleva la aplicación de los siguientes criterios y/o restricciones:

1. (C) La disponibilidad y preferencias deben ser marcadas con prioridad. 2. (R) No sobrepasar las hrs frente a grupo independientemente de las horas de

nombramiento. Esto se relaja cuando el profesor solicita sobrecarga. En este sentido puede ser un relajamiento débil si es solo hrs frente grupo asignadas > max hrs frente grupo permitidas pero menor o igual a las horas de nombramiento. Se tendrá un relajamiento fuerte cuando las horas frente a grupo asignadas superen las horas de nombramiento. Esto último es solo aplicable a profesores de tiempo parcial en busca de más horas de base.

La solución es construir de 1 a n matrices que tengan combinaciones de las hrs-materias de cada profesor como si fueran horarios personalizados. Luego compararlos/traslaparlos con los horarios construidos marcando las semejanzas. Los horarios están filtrados/separados por academia y ordenados x materia de forma descendente de acuerdo al número de horas a la semana de la materia. secuencia(HorariosxSemestrexAcademia) Donde: HorariosxSemestrexAcademia=[(Sem1,SecxSem)…] Semi = Semestre (1 a 8) SecxSem = [(Si,HorSec1)...] Si=Identificador de la Secuencia, ejemplo cm1 HorSec1=[(Mat1,HorMat1),…,(Matn,HorMatn)] Mati=Identificador de la asignatura, ejemplo CCAF HorMati=Horario de la materia= [(Dia1,HoraInicio1,HrsxSesion1),…,(DIAn,HoraInicion,HrsxSesionn)] materiasxacademia(Academia,[…,(CveMat,Sem,CarrId),…]


18

Algoritmo. 1. Por c/Seci∈ListaHorarios

a. Por c/Mati∈HorarioSecuencia i. Filtrar profesores que tengan en LAsigPref a Mati, ordenarlos en forma

ascendente por horas de nombramiento y prioridad de Mati (los primeros deben ser aquellos que tengan menos horas de nombramiento y que tengan a Mati al principio de la lista)

ii. Tomar a profesor que cumpla con los días y horas (Hinicio1∈[HoraInicio,HoraFinal]

iii. Propagar restricciones para (RFC,Mati) asignada (decrementar la disponibilidad de RFC)

Observación: 1. A un profesor se le puede asignar 3 grupos de la misma materia ⇔ hrsnombramiento permiten y descarga y preferencia (Mati). Salida del proceso de asignación de horarios: secuencia(HorariosxSemestreparaAcademia) Donde: HorariosxSemestreparaAcademia=[(Sem1,SecxSem)…] Semi = Semestre (1 a 8) SecxSem = [(Si,HorSec1)...] Si=Identificador de la Secuencia, ejemplo cm5 HorSec1=[(Mat1,HorMat1,RFCProf),…,(Matn,HorMatn,RFCProf)] Mati=Identificador de la asignatura, ejemplo CCAF HorMati=Horario de la materia= [(Dia1,HoraInicio1,HrsxSesion1),…,(DIAn,HoraInicion,HrsxSesionn)] RFCProf RFC del profesor que tiene asignada la materia 2.3.3 Separación de Horarios por Academia Dado que el algoritmo de generación de horarios produce la lista de horarios de un semestre y para el proceso de asignación de profesores es necesario tener la lista de todas las asignaturas que ésa academia administra, se hace necesario un proceso que extraiga las secuencia.asignatura de cada lista de horarios y las integre en otra lista que contenga los horarios de todas las carreras de 1º a 8º con solo las asignaturas pertenecientes a cada academia. En por eso que se implementará la separación como sigue:

1. Por C/academia a. Extraer sus materias de ListaHorarios b. Salvarlas en un archivo

Filtrado de profesores x Mati y ordenarlos. Lista con RFC, horas de nombreamiento, descarga, LDispHor y LAsigPref. Insertar ordenados Los programas fueron implementados utilizando el lenguaje PROLOG y la herramienta AMZI PROLOG+LOGIC SERVER V7.6.


19

2.4 Resultados de los experimentos En esta sección se presentan los primeros resultados de los programas implementados. Es importante mencionar que la prueba integral no se ha concluido debido a situaciones fuera del control del proyecto.

2.4.1 Generación de horarios Para generar los horarios, desde el ambiente AMZI solo se le da Run as y dentro del listener se teclea main. Otra forma de correrlo es desde el prompt de DOS tecleando arun filename.xpl, donde filename.xpl es el nombre del programa que se desea correr. El programa de generación de horarios requiere los parámetros: Carrera, Semestre, Turno y el número de secuencia que se desea generar. Este programa se corrió varias ocasiones variando las horas disponibles por materia con la finalidad de encontrar el conjunto que pudiera generar los horarios más variables posibles. Algunos resultados para las carreras de Ciencias de la Informática e Ingeniería Informática se muestran a continuación en las figuras 2 a la 4. CLAVE MATERIA LUNES MARTES MIERCOLES JUEVES VIERNES

CCER Estructura y Representación de Datos

7-9 7-9

CJIN Ingeniería de Software

11-13 11-12

CCE2 Lenguajes de Programacion 2

9-11 9-10

CCD2 Sistemas Digitales 2

7-9 7-8

CAA1 Administración 1 11-1 11-1 CMCD Cálculo

Diferencial e Integral

9-11 8-10

CHCP Comunicación Profesional

13-15 12-14

Figura 1 Secuencia 2CM1 de Ciencias de la Informática CLAVE MATERIA LUNES MARTES MIERCOLES JUEVES VIERNES CCER Estructura y

Representación de Datos

11-13 11-13

CJIN Ingeniería de Software

7-9 7-8

CCE2 Lenguajes de Programacion 2

13-15 10-11

CCD2 Sistemas Digitales 2

9-11 8-9

CAA1 Administración 1 7-9 7-9 CMCD Cálculo

Diferencial e Integral

11-13 11-13


9-11 9-11

Figura 2 Secuencia 2CM4 de Ciencias de la Informática


20

CLAVE MATERIA LUNES MARTES MIERCOLES JUEVES VIERNES NLFA Física Aplicada 13-15 13-15 NRA2 Aplicaciones de

Sistemas Digitales 2

7-9 7-9

NCER Estructura y Representación de Datos

9-11 9-11

NCIN Ingeniería de Software

7-9 7-8

NCE2 Lenguajes de Programación 2

11-13 10-11

NCS2 Sistemas Digitales 2

9-11 8-9

NSFF Fundamentos de Física

11-13 11-13

NMCD Cálculo Diferencial e Integral

13-15 11-13


13-15 7-9

Figura 3 Secuencia 2NM1 de Ingeniería Informática CLAVE MATERIA LUNES MARTES MIERCOLES JUEVES VIERNES NLFA Física Aplicada 13-15 13-15

NRA2 Aplicaciones de Sistemas Digitales 2

9-11 9-11

NCER Estructura y Representación de Datos

7-9 7-9

NCIN Ingeniería de Software

7-9 8-9

NCE2 Lenguajes de Programación 2

11-13 10-11

NCS2 Sistemas Digitales 2

9-11 9-10

NSFF Fundamentos de Física

13-15 13-15

NMCD Cálculo Diferencial e Integral

11-13 11-13


11-13 9-11

Figura 4 Secuencia 2NM4 de Ingeniería Informática El archivo generado por la generación de horarios se llama secuenciaCST.pro, donde C es el código de la carrera, S es el número de semestre que se generó y T el turno. En el caso de las figuras 1 y 2 se extrajeron del archivo secuencia2CM y las figuras 3 y 4 fueran extraídas del archivo secuencia2NM.

2.4.2 Separación de horarios por academia Para correr este programa se debe asegurar que los archivos producidos por la generación de horarios se encuentran en el mismo directorio donde se está corriendo


21

éste programa. El archivo que se genera se llama secuencia.pro y un ejemplo se muestra a continuación. :-module(secuencia). :-export secuencia/1. secuencia([(1 , []), (2 , [(2cm1 , [(caa1 , [(martes , 11 , 2), (jueves , 11 , 2)])]), (2cm2 , [(caa1 , [(lunes , 7 , 2), (miercoles , 7 , 2)])]), (2cm3 , [(caa1 , [(lunes , 7 , 2), (miercoles , 7 , 2)])]), (2cm4 , [(caa1 , [(lunes , 7 , 2), (miercoles , 7 , 2)])]), (2cm5 , [(caa1 , [(lunes , 7 , 2), (miercoles , 7 , 2)])]), (2cm6 , [(caa1 , [(lunes , 7 , 2), (miercoles , 7 , 2)])])]), (3 , []), (4 , []), (5 , []), (6 , []), (7 , []), (8 , [])]). :-end_module(secuencia). En este caso en particular, como solo se ha corrido el 2º semestre de Ciencias de la Informática, solo se tiene la información de ese semestre. Los demás semestres tienen su correspondiente lista vacía. :-module(secuencia). :-export secuencia/1. secuencia([(1 , []), (2 , [(2cm1 , [(ccer , [(lunes , 7 , 2), (miercoles , 7 , 2)]), (cjin , [(lunes , 11 , 2), (miercoles , 11 , 1)])]), (2cm2 , [(ccer , [(lunes , 11 , 2), (miercoles , 11 , 2)]), (cjin , [(martes , 7 , 2), (jueves , 7 , 1)])]), (2cm3 , [(ccer , [(lunes , 11 , 2), (miercoles , 11 , 2)]), (cjin , [(martes , 7 , 2), (jueves , 8 , 1)])]), (2cm4 , [(ccer , [(lunes , 11 , 2), (miercoles , 11 , 2)]), (cjin , [(martes , 7 , 2), (jueves , 7 , 1)])]), (2cm5 , [(ccer , [(lunes , 11 , 2), (miercoles , 11 , 2)]), (cjin , [(martes , 7 , 2), (jueves , 8 , 1)])]), (2cm6 , [(ccer , [(lunes , 11 , 2), (miercoles , 11 , 2)]), (cjin , [(martes , 7 , 2), (jueves , 7 , 1)])])]), (3 , []), (4 , []), (5 , []), (6 , []), (7 , []), (8 , [])]). :-end_module(secuencia). En el caso anterior, similarmente existen solo las asignaturas del 2º semestre de la carrera de Ciencias de la Informática.

2.4.3 Asignación de Profesores La prueba de asignación de profesores se hizo tomando como archivo de entrada, secuencia, las secuencias planeadas para el 2º semestre 2007 de Agosto-Diciembre y tomando solo una pequeña muestra de disponibilidades de maestros, tal como se muestra a continuación. /* DISPONIBILIDAD DE PROFESORES ESTE ARCHIVO DEBE SER GENERADO POR UN PROGRAMA INTERFAZ ENTRE LA BASE DE DATOS Y LA BASE DE CONOCIMIENTOS LA BASE DE DATOS FUENTE FUE OBTENIDA DURANTE EL PROCESO DE CAPTURA DE LAS DISPONIBILIDADES DE LOS PROFESORES */ :-module(disponibilidad). :-export disponibilidad/6. %disponibilidad(RFC,HrsNomb,(HrsMinFrteGpo,HrsMaxFrteGpo),sobrecargca,LisDispHoras,LisPrefasig). disponibilidad(hecj750528,4,(4,4),no,[(martes,20,22),(jueves,20,22)], [cjba,njba,cjda,njda,njto,cjin,njin,ccni,cjn2]).


22

disponibilidad(lotj550405,6,(6,6),no,[(miercoles,19,22),(viernes,19,22)],[cjm2,cjep]). disponibilidad(cehj6202242c6,9,(9,9),no,[(lunes,18,22),(martes,18,22),(miercoles,18,22), (jueves,18,22)],[cjuf,cjat]). disponibilidad(cahi650308,10,(10,10),no,[(lunes,20,22),(martes,20,22),(miercoles,20,22), (jueves,20,22),(viernes,20,22)],[cjm2,cjm1,njto,cjsb]). disponibilidad(curj650820,11,(11,11),no,[(lunes,16,22),(miercoles,17,22)], [cjda,njda,cjba,njba,cjm1,cjm2]). disponibilidad(aasf660320386,12,(12,12),no,[(lunes,19,22),(martes,19,22),(miercoles,20,22), (jueves,20,22),(viernes,20,22)],[cjuf,cjat,njsu]). disponibilidad(caur600719cg9,16,(16,16),no,[(lunes,18,22),(martes,18,22),(miercoles,18,22), (jueves,18,22),(viernes,18,22)],[cjep,ccer,ncer,ccni,cjsb,njto,cjuf]). disponibilidad(aaaj530516000,17,(17,17),no,[(lunes,16,22),(martes,19,22),(miercoles,19,22), (viernes,17,22)],[cjaf,njaf,ccni,njad]). disponibilidad(favh800812,17,(17,17),no,[(lunes,17,21),(martes,17,21),(miercoles,17,21), (jueves,17,22)],[cncn,ccni,cjin,njin]). disponibilidad(rope700730,40,(6,12),si,[(lunes,10,14),(lunes,18,22),(martes,10,14),(martes,18,22), (miercoles,10,14),(miercoles,18,22),(jueves,10,14),(jueves,18,22),(viernes,10,14),(viernes,18,22)], [cjge,njaf,ccaf,cjsb,njoo]). disponibilidad(feme,40,(6,12),no,[(lunes,10,14),(lunes,18,22),(martes,10,14),(martes,18,22), (miercoles,10,14),(miercoles,18,22),(jueves,10,14),(jueves,18,22),(viernes,10,14),(viernes,18,22)], [cjsb]). :-end_module(disponibilidad).

El programa asigna a los profesores en dos fases: en la primera asigna las materias que tengan prioridad 1 y en una segunda fase, de manera iterativa, las prioridades 2 hasta la indicada en los parámetros de corrida. Este programa se corrió modificando las disponibilidades de los maestros, produciéndose el siguiente archivo. secuencia([(2 , [(2cv2 , [(ccer , [(lunes , 18 , 2), (miercoles , 18 , 2)] , pendiente), (ccin , [(lunes , 20 , 2), (miercoles , 20 , 1)] , pendiente)]), (2nv1 , [(ncer , [(martes , 18 , 1), (miercoles , 18 , 1), (jueves , 18 , 1), (viernes , 18 , 1)] , pendiente), (ncin , [(martes , 19 , 1), (miercoles , 19 , 1), (jueves , 19 , 1)] , pendiente)])]), (3 , [(2cv1 , [(ccn1 , [(lunes , 16 , 2), (martes , 19 , 1)] , pendiente)]), (2cv2 , [(ccn1 , [(miercoles , 18 , 2), (viernes , 18 , 1)] , pendiente)]), (2cv3 , [(ccn1 , [(lunes , 18 , 1), (miercoles , 20 , 2)] , pendiente)])]), (4 , [(4cv1 , [(ccaf , [(lunes , 20 , 2), (jueves , 20 , 2)] , pendiente), (ccba , [(lunes , 18 , 2), (miercoles , 18 , 2)] , pendiente), (ccn2 , [(lunes , 15 , 2), (miercoles , 16 , 1)] , pendiente)]), (4cv2 , [(ccaf , [(lunes , 17 , 2), (miercoles , 17 , 2)] , pendiente), (ccba , [(martes , 18 , 2), (viernes , 18 , 2)] , pendiente), (ccn2 , [(lunes , 19 , 1), (viernes , 16 , 2)] , pendiente)]), (4nv1 , [(njba , [(martes , 20 , 2), (jueves , 20 , 2)] , pendiente), (njad , [(lunes , 16 , 2), (jueves , 18 , 1)] , pendiente)]), (4nv2 , [(njba , [(miercoles , 18 , 2), (viernes , 18 , 2)] , pendiente), (njad , [(martes , 20 , 2), (viernes , 20 , 1)] , pendiente)])]), (5 , [(5cv1 , [(cjda , [(lunes , 20 , 2), (miercoles , 20 , 2)] , curj650820), (cjge , [(martes , 15 , 2), (jueves , 15 , 2)] , pendiente)]), (5cv2 , [(cjge , [(martes , 18 , 2), (jueves , 18 , 2)] , rope700730)]), (5cv3 , [(cjda , [(lunes , 16 , 2), (miercoles , 16 , 2)] , pendiente), (cjge , [(martes , 15 , 2), (jueves , 18 , 2)] , pendiente)]), (5cv4 , [(cjda , [(lunes , 18 , 2), (miercoles , 17 , 2)] , pendiente), (cjge , [(lunes , 20 , 2), (miercoles , 19 , 2)] , rope700730)]), (5cv5 , [(cjda , [(lunes , 20 , 2), (miercoles , 20 , 2)] , pendiente), (cjge , [(martes , 20 , 2), (jueves , 20 , 2)] ,


23

pendiente)]), (5cv6 , [(cjda , [(martes , 20 , 2), (jueves , 20 , 2)] , pendiente), (cjge , [(martes , 18 , 2), (jueves , 18 , 2)] , pendiente)]), (5cv7 , [(cjda , [(lunes , 18 , 2), (miercoles , 20 , 2)] , pendiente), (cjge , [(martes , 20 , 2), (jueves , 20 , 2)] , pendiente)]), (5nv1 , [(njaf , [(lunes , 20 , 2), (martes , 19 , 1), (viernes , 19 , 1)] , pendiente)]), (5nv2 , [(njaf , [(lunes , 18 , 2), (miercoles , 18 , 2)] , pendiente), (njad , [(lunes , 16 , 2), (miercoles , 16 , 1), (jueves , 21 , 1)] , pendiente)]), (5nv3 , [(njaf , [(martes , 20 , 2), (jueves , 20 , 2)] , pendiente), (njad , [(martes , 18 , 2), (jueves , 18 , 2)] , pendiente)])]), (6 , [(6cv1 , [(cjsb , [(martes , 18 , 2), (jueves , 18 , 2)] , feme)]), (6cv2 , [(cjsb , [(lunes , 18 , 2), (viernes , 19 , 2)] , feme)]), (6cv3 , [(cjsb , [(miercoles , 18 , 2), (viernes , 17 , 2)] , pendiente)]), (6cv4 , [(cjsb , [(martes , 20 , 2), (jueves , 20 , 2)] , feme)]), (6nv2 , [(njoo , [(martes , 17 , 2), (jueves , 17 , 2)] , pendiente)]), (6nv3 , [(njoo , [(lunes , 18 , 2), (martes , 17 , 2)] , pendiente)])]), (7 , [(7cv1 , [(cjuf , [(lunes , 19 , 2), (miercoles , 19 , 2)] , cehj6202242c6), (cjep , [(martes , 21 , 1), (miercoles , 21 , 1), (jueves , 21 , 1)] , caur600719cg9), (cjm1 , [(lunes , 17 , 2), (martes , 20 , 1)] , pendiente)]), (7cv2 , [(cjuf , [(lunes , 20 , 2), (miercoles , 20 , 2)] , aasf660320386), (cjep , [(viernes , 19 , 3)] , pendiente), (cjm1 , [(martes , 20 , 2), (jueves , 21 , 1)] , pendiente)]), (7cv3 , [(cjuf , [(lunes , 20 , 2), (miercoles , 20 , 2)] , pendiente), (cjep , [(martes , 19 , 2), (jueves , 20 , 1)] , pendiente), (cjm1 , [(miercoles , 19 , 1), (viernes , 20 , 2)] , pendiente)]), (7cv4 , [(cjuf , [(lunes , 21 , 1), (martes , 19 , 3)] , pendiente), (cjep , [(miercoles , 16 , 2), (viernes , 17 , 1)] , pendiente), (cjm1 , [(lunes , 20 , 1), (miercoles , 20 , 2)] , pendiente)]), (7cv5 , [(cjuf , [(lunes , 17 , 2), (miercoles , 17 , 2)] , pendiente), (cjep , [(lunes , 20 , 2), (miercoles , 21 , 1)] , pendiente), (cjm1 , [(martes , 19 , 3)] , pendiente)]), (7cv6 , [(cjuf , [(lunes , 19 , 3), (martes , 19 , 1)] , pendiente), (cjep , [(martes , 21 , 1), (jueves , 19 , 2)] , pendiente), (cjm1 , [(martes , 18 , 1), (viernes , 17 , 2)] , pendiente)]), (7cv7 , [(cjep , [(lunes , 18 , 2), (miercoles , 18 , 1)] , pendiente), (cjm1 , [(martes , 20 , 2), (miercoles , 19 , 1)] , pendiente), (cjuf , [(lunes , 20 , 2), (miercoles , 20 , 2)] , pendiente)]), (7cv8 , [(cjuf , [(lunes , 20 , 2), (miercoles , 20 , 2)] , pendiente), (cjep , [(miercoles , 19 , 1), (viernes , 20 , 2)] , pendiente), (cjm1 , [(martes , 18 , 1), (jueves , 18 , 2)] , pendiente)]), (7nv1 , [(njir , [(lunes , 20 , 2), (miercoles , 20 , 2)] , pendiente)]), (7nv2 , [(njir , [(martes , 20 , 2), (jueves , 20 , 2)] , pendiente)]), (7nv3 , [(njir , [(martes , 17 , 2), (miercoles , 20 , 2)] , pendiente)]), (7nv4 , [(njir , [(lunes , 20 , 2), (miercoles , 20 , 2)] , pendiente)])]), (8 , [(8cv1 , [(cjaq , [(martes , 20 , 2), (jueves , 20 , 2)] , pendiente), (cjat , [(martes , 16 , 2), (jueves , 17 , 1)] , pendiente), (cjm2 , [(lunes , 19 , 2), (miercoles , 21 , 1)] , pendiente)]), (8cv2 , [(cjat , [(lunes , 19 , 1), (martes , 20 , 2)] , pendiente)]), (8cv3 , [(cjaq , [(jueves , 18 , 2), (viernes , 20 , 2)] , pendiente), (cjat , [(lunes , 19 , 1), (martes , 21 , 1), (jueves , 20 , 1)] , pendiente), (cjm2 , [(martes , 19 , 2), (jueves , 21 , 1)] , pendiente)]), (8cv4 , [(cjaq , [(martes , 17 , 1), (miercoles , 20 , 2), (jueves , 17 , 1)] , pendiente), (cjat , [(martes , 19 , 1), (miercoles , 19 , 1), (jueves , 19 , 1)] , pendiente), (cjm2 , [(lunes , 16 , 2), (miercoles , 16 , 1)] , pendiente)]), (8cv5 , [(cjat , [(martes , 18 , 1), (jueves , 18 , 2)] , pendiente)]), (8nv1 , [(njso , [(martes , 20 , 2), (jueves , 21 , 1)] , pendiente), (njto , [(viernes , 19 , 3)] , pendiente)]), (8nv2 , [(njtm , [(lunes , 20 , 2), (miercoles , 20 , 2)] , pendiente), (njso , [(lunes , 19 , 1), (miercoles , 18 , 2)] , pendiente), (njto , [(viernes , 19 , 3)] , pendiente)]), (8nv3 , [(njso , [(lunes , 19 , 1), (miercoles , 18 , 2)] , pendiente), (njto , [(viernes , 19 , 3)] , pendiente)]), (8nv4 , [(njtm , [(lunes , 20 , 2), (miercoles , 20 , 2)] , pendiente)]), (8nv5 , [(njtm , [(martes , 18 , 2), (jueves , 18 , 2)] , pendiente)]), (8nv6 , [(njtm , [(martes , 20 , 2), (jueves , 20 , 2)] , pendiente)])])]).

Mientras que la segunda fase logró asignar las siguientes secuencias. horariosasigdespues([(2 , 2nv1 , ncer , [(martes , 18 , 1), (miercoles , 18 , 1), (jueves , 18 , 1), (viernes , 18 , 1)] , caur600719cg9), (5 , 5cv6 , cjda , [(martes , 20 , 2), (jueves , 20 , 2)] , hecj750528), (8 , 8cv5 , cjat , [(martes , 18 , 1), (jueves , 18 , 2)] , cehj6202242c6), (8 , 8cv2 , cjat , [(lunes , 19 , 1), (martes , 20 , 2)] , aasf660320386), (7 , 7cv2 , cjm1 , [(martes , 20 , 2), (jueves , 21 , 1)] , cahi650308), (7 , 7cv2 , cjep , [(viernes , 19 , 3)] , lotj550405), (5 , 5nv3 , njaf , [(martes , 20 , 2), (jueves , 20 , 2)] , rope700730), (5 , 5nv1 , njaf , [(lunes , 20 , 2), (martes , 19 , 1), (viernes , 19 , 1)] , aaaj530516000), (4 , 4nv1 , njba , [(martes , 20 , 2), (jueves , 20 , 2)] , hecj750528), (2 , 2cv2 , ccer , [(lunes , 18 , 2), (miercoles , 18 , 2)] , caur600719cg9)]).

Quedando pendientes las siguientes secuencias horariospendientes([(2 , 2cv2 , ccin , [(lunes , 20 , 2), (miercoles , 20 , 1)]), (2 , 2nv1 , ncin , [(martes , 19 , 1), (miercoles , 19 , 1), (jueves , 19 , 1)]), (3 , 2cv1 , ccn1 , [(lunes , 16 , 2), (martes , 19 , 1)]), (3 , 2cv2 , ccn1 , [(miercoles , 18 , 2), (viernes , 18 , 1)]), (3 , 2cv3 , ccn1 , [(lunes , 18 , 1), (miercoles , 20 , 2)]), (4 ,


24

4cv1 , ccaf , [(lunes , 20 , 2), (jueves , 20 , 2)]), (4 , 4cv1 , ccba , [(lunes , 18 , 2), (miercoles , 18 , 2)]), (4 , 4cv1 , ccn2 , [(lunes , 15 , 2), (miercoles , 16 , 1)]), (4 , 4cv2 , ccaf , [(lunes , 17 , 2), (miercoles , 17 , 2)]), (4 , 4cv2 , ccba , [(martes , 18 , 2), (viernes , 18 , 2)]), (4 , 4cv2 , ccn2 , [(lunes , 19 , 1), (viernes , 16 , 2)]), (4 , 4nv1 , njad , [(lunes , 16 , 2), (jueves , 18 , 1)]), (4 , 4nv2 , njad , [(martes , 20 , 2), (viernes , 20 , 1)]), (4 , 4nv2 , njba , [(miercoles , 18 , 2), (viernes , 18 , 2)]), (5 , 5cv1 , cjge , [(martes , 15 , 2), (jueves , 15 , 2)]), (5 , 5cv3 , cjda , [(lunes , 16 , 2), (miercoles , 16 , 2)]), (5 , 5cv3 , cjge , [(martes , 15 , 2), (jueves , 18 , 2)]), (5 , 5cv4 , cjda , [(lunes , 18 , 2), (miercoles , 17 , 2)]), (5 , 5cv5 , cjda , [(lunes , 20 , 2), (miercoles , 20 , 2)]), (5 , 5cv5 , cjge , [(martes , 20 , 2), (jueves , 20 , 2)]), (5 , 5cv6 , cjge , [(martes , 18 , 2), (jueves , 18 , 2)]), (5 , 5cv7 , cjda , [(lunes , 18 , 2), (miercoles , 20 , 2)]), (5 , 5cv7 , cjge , [(martes , 20 , 2), (jueves , 20 , 2)]), (5 , 5nv2 , njad , [(lunes , 16 , 2), (miercoles , 16 , 1), (jueves , 21 , 1)]), (5 , 5nv2 , njaf , [(lunes , 18 , 2), (miercoles , 18 , 2)]), (5 , 5nv3 , njad , [(martes , 18 , 2), (jueves , 18 , 2)]), (6 , 6cv3 , cjsb , [(miercoles , 18 , 2), (viernes , 17 , 2)]), (6 , 6nv2 , njoo , [(martes , 17 , 2), (jueves , 17 , 2)]), (6 , 6nv3 , njoo , [(lunes , 18 , 2), (martes , 17 , 2)]), (7 , 7cv1 , cjm1 , [(lunes , 17 , 2), (martes , 20 , 1)]), (7 , 7cv3 , cjep , [(martes , 19 , 2), (jueves , 20 , 1)]), (7 , 7cv3 , cjm1 , [(miercoles , 19 , 1), (viernes , 20 , 2)]), (7 , 7cv3 , cjuf , [(lunes , 20 , 2), (miercoles , 20 , 2)]), (7 , 7cv4 , cjep , [(miercoles , 16 , 2), (viernes , 17 , 1)]), (7 , 7cv4 , cjm1 , [(lunes , 20 , 1), (miercoles , 20 , 2)]), (7 , 7cv4 , cjuf , [(lunes , 21 , 1), (martes , 19 , 3)]), (7 , 7cv5 , cjep , [(lunes , 20 , 2), (miercoles , 21 , 1)]), (7 , 7cv5 , cjm1 , [(martes , 19 , 3)]), (7 , 7cv5 , cjuf , [(lunes , 17 , 2), (miercoles , 17 , 2)]), (7 , 7cv6 , cjep , [(martes , 21 , 1), (jueves , 19 , 2)]), (7 , 7cv6 , cjm1 , [(martes , 18 , 1), (viernes , 17 , 2)]), (7 , 7cv6 , cjuf , [(lunes , 19 , 3), (martes , 19 , 1)]), (7 , 7cv7 , cjep , [(lunes , 18 , 2), (miercoles , 18 , 1)]), (7 , 7cv7 , cjm1 , [(martes , 20 , 2), (miercoles , 19 , 1)]), (7 , 7cv7 , cjuf , [(lunes , 20 , 2), (miercoles , 20 , 2)]), (7 , 7cv8 , cjep , [(miercoles , 19 , 1), (viernes , 20 , 2)]), (7 , 7cv8 , cjm1 , [(martes , 18 , 1), (jueves , 18 , 2)]), (7 , 7cv8 , cjuf , [(lunes , 20 , 2), (miercoles , 20 , 2)]), (7 , 7nv1 , njir , [(lunes , 20 , 2), (miercoles , 20 , 2)]), (7 , 7nv2 , njir , [(martes , 20 , 2), (jueves , 20 , 2)]), (7 , 7nv3 , njir , [(martes , 17 , 2), (miercoles , 20 , 2)]), (7 , 7nv4 , njir , [(lunes , 20 , 2), (miercoles , 20 , 2)]), (8 , 8cv1 , cjaq , [(martes , 20 , 2), (jueves , 20 , 2)]), (8 , 8cv1 , cjat , [(martes , 16 , 2), (jueves , 17 , 1)]), (8 , 8cv1 , cjm2 , [(lunes , 19 , 2), (miercoles , 21 , 1)]), (8 , 8cv3 , cjaq , [(jueves , 18 , 2), (viernes , 20 , 2)]), (8 , 8cv3 , cjat , [(lunes , 19 , 1), (martes , 21 , 1), (jueves , 20 , 1)]), (8 , 8cv3 , cjm2 , [(martes , 19 , 2), (jueves , 21 , 1)]), (8 , 8cv4 , cjaq , [(martes , 17 , 1), (miercoles , 20 , 2), (jueves , 17 , 1)]), (8 , 8cv4 , cjat , [(martes , 19 , 1), (miercoles , 19 , 1), (jueves , 19 , 1)]), (8 , 8cv4 , cjm2 , [(lunes , 16 , 2), (miercoles , 16 , 1)]), (8 , 8nv1 , njso , [(martes , 20 , 2), (jueves , 21 , 1)]), (8 , 8nv1 , njto , [(viernes , 19 , 3)]), (8 , 8nv2 , njso , [(lunes , 19 , 1), (miercoles , 18 , 2)]), (8 , 8nv2 , njtm , [(lunes , 20 , 2), (miercoles , 20 , 2)]), (8 , 8nv2 , njto , [(viernes , 19 , 3)]), (8 , 8nv3 , njso , [(lunes , 19 , 1), (miercoles , 18 , 2)]), (8 , 8nv3 , njto , [(viernes , 19 , 3)]), (8 , 8nv4 , njtm , [(lunes , 20 , 2), (miercoles , 20 , 2)]), (8 , 8nv5 , njtm , [(martes , 18 , 2), (jueves , 18 , 2)]), (8 , 8nv6 , njtm , [(martes , 20 , 2), (jueves , 20 , 2)])]).

Debe mencionarse que estos resultados son el producto de contar con una base de conocimientos bastante pequeña. Al momento de escribir el presente reporte todavía estaban en proceso pruebas con más datos y pruebas de carácter integral.

2.5 Integración La integración de los proceso para todas las carreras se logra integrándolos como se muestra en el siguiente organigrama.

SAA-Informática

Captura de Disponibilidades de

Profesores

Generación de Horarios

Asignación Profesores a

Horarios


25

Con cada módulo descrito de la siguiente manera: 1. Captura de Disponibilidad de Profesores

a. Es un subsistema en ambiente web b. Se habilita durante una ventana de tiempo c. Se tiene para analizar las horas disponibles por materias que profesores

quieren dar. El resto puede darse por análisis histórico d. Sirve para generar los archivos de disponibilidades de profesores y las

horas disponibles para cada materia. 2. Generación de Horarios (Objetivos)

a. Formar secuencias con carga completa b. Sin traslapes c. Oportunidad de combinar secuencias generando mas opciones d. Dado que hay cinco carreras y ocho semestres e. Los horarios de un semestre de una carrera son independientes f. Los horarios entre carreras son independientes g. Se corren (5x8x2) 80 procesos independiente para generar los horarios

de las cinco carreras, de los ocho semestres de los dos turnos. 3. Asignación Profesores a Horarios

a. Se realiza en cada academia b. Premisas:

� Considerar condiciones internas de trabajo � Asignar profesores de tiempo parcial a tiempo completo � Balancear carga académica (¿Cuántos grupos de qué materia le

asigno?) � Considerar sobrecarga (¿Quiere la sobrecarga?)

El flujo de proceso del sistema SAA es muestra en la siguiente figura.

Determinar horas

disponibles x materia*

horadisponible.pro

Capturar Disponibilidad

(WEB)

Generar Horarios

(40)

horadisponible.pro

Demanda/Oferta

secuencia1AM

secuencia8TV

Extraer Materias x Academia

secuencia.pro secuencia.

pro

Asigna Profesores

(N)

Profesor

horariosprof.pro


26

Conclusiones Se puede decir que se cumplió con el objetivo de proponer un sistema que genere de manera automática los horarios de las Academias de Informática, desde la generación de horarios hasta la asignación de profesores a los horarios. La idea final es que se permita la realización de ajustes a los horarios y a las asignaciones de profesores de manera manual. Lo cual no fue objeto de análisis de éste proyecto. Se tiene como objetivo principal para el año 2008 lograr expander el sistema al proceso de generación de horarios de la UPIICSA, de tal forma que el 2º semestre/2008 de Agosto-Diciembre se planee usando el sistema propuesto. Los programas podrán ser corridos de manera central por una persona encargada que solo avise que ya termino el proceso. El proyecto involucro el conocimiento de la metodología de ingeniería del conocimiento para el desarrollo de sistemas basados en conocimiento. Además de mayor interacción con usuarios diversos. Los programas se implementaron y se probaron satisfactoriamente, aunque pruebas de carácter integral aún están corriendo. Para expandir el sistema para que cubra en su totalidad el proceso de planeación de secuencias de la UPIICSA se requieren realizar las siguientes acciones, que podrán desarrollarse fuera de un proyecto de investigación. 1. Recopilación de información de disponibilidad de profesores de las demás

academias. 2. Análisis de los horarios históricos de 3 o 4 semestres atrás para determinar la

disponibilidad de horas por cada materia. 3. Correr pruebas integrales de generación de horarios de las carreras de

Administración Industrial, Ingeniería Industrial e Ingeniería en Transporte. 4. Correr pruebas integrales, escalonadas de asignación de profesores para las

academias restantes. 5. Terminar el desarrollo de los módulos:

a. Captura de disponibilidad de profesores b. Consulta y modificación de horarios generados c. Consulta y modificación de horarios asignados d. Captura de horas de descarga de profesores e. Generación de reportes diversos como circular 20, carga académica,

entre otros. 6. Generar interfaces entre módulos diversos incluyendo el interfaz entre el sistema de

generación automática de horarios y SIGUE.


27

REFERENCIAS [1] TB Cooper and JH Kingston, “The Complexity of Timetable Construction Problems,” in the Practice and Theory of Automated Timetabling, ed. EK Burke and P Ross, pp. 283-295, Springer-Verlag (Lecture Notes in Computer Science), 1996. Basser Department of Computer Science, University of Sydney, Australia [2] MW Carter*, G Laporte†, and JW Chinneck‡, “A General Examination Scheduling System,” Interfaces, vol. 24, no. 3, pp. 109-120, The Institute of Management Sciences, May-June 1994. *Department of Industrial Engineering, University of Toronto, Ontario, Canada; ††Ecole des Hautes Etudes Commerciales de Montr´eal, Quebec, Canada; and ‡Department of Systems and Computer Engineering, Carleton University, Ottawa, Ontario, Canada [3] SD Bloomfield and MM McSharry, “Preferential Course Scheduling,” Interfaces, vol. 9, no. 4, pp. 24-31, The Institute of Management Sciences, August 1979. School of Business, Oregon State University, Corvallis, USA. [4] BP Romero, “Examination Scheduling in a Large Engineering School: A Computer-Assisted Participative Procedure,” Interfaces, vol. 12, no. 2, pp. 17-23, The Institute of Management Sciences, April 1982. Industrial Organization Department, Industrial Engineering Technical School, Madrid, Spain [5] EK Burke, DG Elliman, PH Ford, and RF Weare, “Exam Timetabling in British Universities – A Survey,” in the Practice and Theory of Automated Timetabling, ed. EK Burke and P Ross, pp. 76-90, Springer-Verlag (Lecture Notes in Computer Science), 1996. Department of Computer Science, University of Nottingham, UK [6] VA Bardadym, “Computer-Aided School and University Timetabling: The New Wave,” in the Practice and Theory of Automated Timetabling, ed. EK Burke and P Ross, pp. 22-45, Springer-Verlag (Lecture Notes in Computer Science), 1996. International Soros Science Education Program, International Renaissance Foundation, Kiev, Ukraine [7] MW Carter, “A Survey of Practical Applications of Examination Timetabling Algorithms,” Operations Research, vol. 34, no. 2, pp. 193-201, Operations Research Society of America, March-April 1986. University of Toronto, Ontario, Canada [8] MW Carter* and G Laporte†, “Recent Developments in Practical Examination Timetabling,” in the Practice and Theory of Automated Timetabling, ed. EK Burke and P Ross, pp. 3-21, Springer-Verlag (Lecture Notes in Computer Science), 1996. *Department of Industrial Engineering, University of Toronto, Ontario, Canada; and ††Ecole des Hautes Etudes Commerciales de Montr´eal, Quebec, Canada [9] JH Kingston*, VA Bardadym, and MW Carter, “Bibliography on the Practice and Theory of Automated Timetabling,” in ftp://ftp.cs.usyd.edu.au/jeff/- timetabling/timetabling.bib.gz. *Basser Department of Computer Science, University of Sydney, Australia [10] D Abramson and J Abela, T Arani*, and V Lotfi†, “A Three Phased Approach to Final Exam Scheduling,” IIE Transactions, vol. 21, no. 1, pp. 86-96, IIE, Australia, March 1989. (technical report)


28

[11] D Corne, P Ross, and HL Fang, “Fast Practical Evolutionary Timetabling,” Lecture Notes in Computer Science, vol. 865 (Artificial Intelligence and Simulation of Behaviour (AISB) Workshop on Evolutionary Computing, University of Leeds, UK, 11th-13th April 1994), pp. 251-263, Springer-Verlag, 1994. Department of Artificial Intelligence, University of Edinburgh, UK [12] García García, Ernesto; Rodríguez Mercado, Sara; Delgadillo González, Ma de los Angeles y Páramo López,, Domingo. Memoria Histórica de la UPIICSA 1972-2002. UPIICSA, IPN. México, 2004. [13] Burke, Edmund; Jackson, Kirk; Kingston, Jeff and Weare, Rupert. Automated University Timetabling: The State of the Art. The Computer Journal, Vol 40, No 9, pp 565-571. 1997


29

Descripción del Contenido del CD incluido Junto con éste reporte se anexa un CD que contiene lo siguiente:

1. Reporte Final del Proyecto 2. Listados de Programas de cada módulo

i. Separación de Horarios por Academia ii. Generación de Horarios iii. Asignación de Profesores

3. Bases de Conocimientos i. Horas Disponibles por Materia ii. Materias por Carrera iii. Disponibilidad de Profesores

4. Reporte Técnico sobre el problema de horarios 5. Resumen de la teoría de Constraint Satisfaction 6. Presentación Motivaciones del Proyecto 7. Presentación Avances y resultados 8. Folder con archivos de comprobación de gastos

Así mismo, en la carpeta que se entrega se anexan:

1. Resultados Parciales de corridas diversas a. Creación de Horarios b. Asignación de Profesores

Instituto Politécnico Nacionalsappi.ipn.mx/cgpi/archivos_anexo/20070030_4995.pdf · UPIICSA,...

Documents

Transcript of Instituto Politécnico Nacionalsappi.ipn.mx/cgpi/archivos_anexo/20070030_4995.pdf · UPIICSA,...