Modelo costos horarios

Universidad de Carabobo
Facultad de Ciencias y Tecnolog´ıa
Departamento de Computación
Modelo general de costos para el
problema de asignación de horarios.
Autor:
Br. José Rosendo
C.I. V - 22.213.692
Tutor Académico:
Dr. Amad´ıs Mart´ınez
Valencia, septiembre de 2016.
1

Resumen
El problema de asignación de horarios consiste en la colocación de tareas a realizar en
determinados momentos a un sujeto. Tal asignación se ve restringida previamente por un
conjunto de limitaciones asociadas al contexto. Este problema es combinatorio y de orden
no polinomial, lo cual lo coloca como imposible de ser resuelto en tiempo polinomial por
un algoritmo determin´ıstico. A la fecha la solución del mismo se ve abordada por técnicas
heur´ısticas y metaheur´ısticas, las cuales brindan soluciones cercanas a la óptima.
Tomando en cuenta el inconveniente antes mencionado, se hace necesario el planteamiento
de un modelo de costos lo suficientemente flexible en cuanto a uso y que sirva de base para la
optimización de los cálculos relacionados a la asignación de horarios. En este trabajo se plan-
tea la realización de tal tarea, desarrollando el correspondiente entramado teórico-práctico,
a fin de conseguir un avance positivo en las investigaciones del campo.
Siguiendo las directrices establecidas por el Protocolo de Modelado matemático - lógico,
se desarrolló un conjunto de premisas que estructuraban las entidades, relaciones y restric-
ciones del modelo general a construir, definiendo el objetivo del modelado, formulando el
respectivo modelo conceptual, estableciendo bajo que categor´ıa(s) cae el modelo a construir,
seleccionando las herramientas de software para las simulaciones y validaciones del mismo,
realizando previamente las respectivas parametrizaciones, para as´ı presentar bajo el formato
requerido el compendio de resultados en donde se demuestra la validez de las hipótesis plan-
teadas, esto es, la posibilidad de construir un sistema genérico de procesos, o en su defecto
que abarque los principales casos del timetabling problem, que optimice el modelo de restric-
ciones del problema a solucionar, para luego proceder con la solución en concreto.
Palabras claves: modelado de restricciones, algoritmos de propagación de restricciones,
optimización.
2

Índice
1. Introducción 7
2. Marco Teórico 9
2.1. Antecedentes de la investigación . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2. Bases teóricas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.1. Investigación de operaciones . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.2. Problema de asignación de horarios [38] [36] [58] . . . . . . . . . . . . 16
2.2.3. Complejidad algor´ıtmica . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.4. Programación con restricciones . . . . . . . . . . . . . . . . . . . . . 20
2.2.5. Propagación de restricciones [25] [28] [41] [53] . . . . . . . . . . . . . 20
2.2.6. Modelado cient´ıfico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3. Planteamiento del Problema y Justificación 24
3.1. Contexto del Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2. Definición del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3. Objetivos de la investigación . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.1. Objetivos Generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.2. Objetivos Espec´ıficos . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4. Justificación e importancia del tema tratado . . . . . . . . . . . . . . . . . . 28
4. Marco Metodológico 29
4.1. Descripción de la metodolog´ıa . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1.1. Protocolo de Modelado . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2. Aplicación de la metodolog´ıa . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.1. Definición del objetivo del modelado . . . . . . . . . . . . . . . . . . 34
4.2.2. Formulación del modelo conceptual . . . . . . . . . . . . . . . . . . . 37
4.2.3. Tipo de modelo a usar . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.4. Selección del código a aplicar . . . . . . . . . . . . . . . . . . . . . . 43
4.2.5. Parametrización del modelo . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.6. Validación del modelo . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3

4.2.7. Simulación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.8. Presentación y análisis de resultados . . . . . . . . . . . . . . . . . . 47
5. Diseño de la solución 49
5.1. Descripción de la solución . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.2. Alcance y limitaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6. Resultados experimentales 52
6.1. Configuración de los experimentos . . . . . . . . . . . . . . . . . . . . . . . . 53
6.1.1. Plataforma computacional . . . . . . . . . . . . . . . . . . . . . . . . 53
6.1.2. Casos de prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.1.3. Métricas de evaluación . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.2. Análisis de resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.2.1. Hipótesis iniciales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.2.2. Resultados obtenidos . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
7. Conclusiones y recomendaciones 120
7.1. Conclusiones de la investigación . . . . . . . . . . . . . . . . . . . . . . . . . 120
7.2. Trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
4

Índice de figuras
1. Clases de complejidad [88] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2. Trilog´ıa Modelo - Algoritmo - Programa [32] . . . . . . . . . . . . . . . . . . 30
3. Esquema general del modelo matemático. [32] . . . . . . . . . . . . . . . . . 31
4. Primera etapa del protocolo de modelado [32] . . . . . . . . . . . . . . . . . 32
5. Segunda etapa del protocolo de modelado [32] . . . . . . . . . . . . . . . . . 33
6. Tercera etapa del protocolo de modelado [32] . . . . . . . . . . . . . . . . . . 34
7. Clase Individuo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
8. Clase Actividad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
9. Relacion Individuo-Realiza-Actividad. . . . . . . . . . . . . . . . . . . . . . . 42
10. Entrada del caso de prueba PE-CTT: matriz de asistencia de estudiantes a
clases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
11. Entrada del caso de prueba PE-CTT: matriz correlación de aulas con propie-
dades. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
12. Entrada del caso de prueba PE-CTT: matriz correlación de eventos con pro-
piedades requeridas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
13. Entrada del caso de prueba PE-CTT: matriz de restricción de precedencia
entre eventos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
14. Ejemplo de formato original de entrada de caso de prueba CB-CTT. . . . . . 71
15. CB-CTT: Proporción de casos exitosos . . . . . . . . . . . . . . . . . . . . . 108
16. CB-CTT: Menor tiempo de solución por caso . . . . . . . . . . . . . . . . . 109
17. CB-CTT: Mayor tiempo de solución por caso . . . . . . . . . . . . . . . . . . 109
18. CB-CTT: Tiempo promedio de solución por caso . . . . . . . . . . . . . . . 110
19. PE-CTT: Proporción de casos exitosos . . . . . . . . . . . . . . . . . . . . . 110
20. PE-CTT: Menor tiempo de solución por caso . . . . . . . . . . . . . . . . . . 111
21. PE-CTT: Mayor tiempo de solución por caso . . . . . . . . . . . . . . . . . . 111
22. PE-CTT: Tiempo promedio de solución por caso . . . . . . . . . . . . . . . . 112
5

´Indice de tablas
1. Valores de Caso de Prueba PE-CTT . . . . . . . . . . . . . . . . . . . . . . 69
2. Valores de Caso de Prueba CB-CTT . . . . . . . . . . . . . . . . . . . . . . 75
3. Resultados de Caso de Prueba CB-CTT . . . . . . . . . . . . . . . . . . . . 106
4. Resultados de Caso de Prueba PE-CTT . . . . . . . . . . . . . . . . . . . . 107
6

1. Introducción
El problema de asignación de horarios consiste en la asignación de un conjunto de tareas
a ser realizada por un sujeto en determinados bloques horarios. Tal asignación se ve influida
por un conjunto de restricciones que var´ıan de acuerdo al contexto. As´ı, por ejemplo, en
un horario universitario tales restricciones van asociadas a la cantidad de aulas disponibles,
los profesores asignados a una determinada asignatura, entre otros factores. En términos
conceptuales, el timetabling problem es un problema combinatorio de orden no polinomial.
Los problemas algor´ıtmicos que entran en esta categor´ıa no son resolubles en tiempos cortos
utilizando técnicas tradicionales. Tomando en cuenta lo anterior, se han planteado múltiples
soluciones que van desde optimizar el modelado de las restricciones, pasando por el uso de
heur´ısticas y metaheur´ısticas en el cálculo del horario óptimo para un sujeto dado, hasta la
aplicación de cómputos en paralelo en hardware dedicado para tal fin. [38] [36] [58]
Partiendo de la base anterior, en la cual se perfila la naturaleza del problema de asigna-
ción de horarios, se hace enfático el planteamiento de un modelo de costos y de restricciones
que por un lado sea lo suficientemente flexible para ser usado en los más diversos contex-
tos y por el otro proporcione la base para optimizar los cálculos posteriores relacionados a
la asignación del horario requerido. Es as´ı que en este trabajo se plantea la posibilidad de
realizar tal cometido, partiendo de investigaciones previas que han planteado perspectivas
similares pero para contextos más limitados. Se recalca que por un lado es imprescindible
la creación de un modelo robusto que soporte cualquier restricción a modelar, as´ı como los
mecanismos necesarios para que tal modelo se reformule en base a mecanismos algor´ıtmicos
ya establecidos. Tal reformulación va orientada a la búsqueda de mejores soluciones en el
marco del conjunto de datos dado. [84] [52] [51]
Este documento está estructurado en siete cap´ıtulos, incluyendo la introducción. El cap´ıtu-
lo 2 cubre el marco teórico en base a dos puntos principales que son los antecedentes de la
investigación y las bases teóricas del presente trabajo. El cap´ıtulo 3 define el contexto del
problema presentado as´ı como una definición detallada del mismo, para luego mostrar los
7

objetivos generales y espec´ıficos a lograr, todo esto con su debida justificación y explicación
de la importancia de cumplirlos. El cap´ıtulo 4 describe la metodolog´ıa a usar para resolver
el problema ya descrito, as´ı como el plan de trabajo a cumplir acorde a la misma. El cap´ıtulo
5 da un paso más allá, partiendo de la sección anterior, y esquematizando el proceso emp´ırico
que de vida a la solución buscada, especificando también las limitaciones de la misma. El
cap´ıtulo 6 muestra los datos recolectados consecuencia de ejecutar los pasos de la sección
anterior, esto con sus respectivas métricas formales. El cap´ıtulo 7 presenta un breve com-
pendio acerca de todo el trabajado desarrollando, el análisis que se pueda realizar acerca del
contraste entre los objetivos esperados y los obtenidos, as´ı como los respectivos consejos di-
rigidos a la realización de trabajos del mismo tópico o de alguno ´ıntimamente relacionado. Y
de último, en la sección 7.2 se muestra el listado de recursos teóricos y prácticos consultados
para la realización de este TEG.
8

2. Marco Teórico
Este cap´ıtulo se compone de dos secciones. En los Antecedentes (2.1) se describe el con-
junto de trabajos más resaltantes relacionados a la solución del problema de asignación de
horarios, el enfoque y/o búsqueda de un modelo de costos general para expresar las enti-
dades y restricciones del mismo, as´ı como las herramientas de software más significativas
desarrolladas al respecto. En las Bases Teóricas (2.2) se cubren los conceptos más importan-
tes del problema que permitan un entendimiento completo del marco general a tratar, as´ı
como una base lo suficientemente robusta para generar el conjunto de nuevos razonamientos
y planteamientos plasmados en las posteriores secciones.
9

2.1. Antecedentes de la investigación
En paralelo a la naturaleza combinatoria y altamente compleja del problema de asigna-
ción de horarios, la mayor´ıa de las soluciones propuestas se ven restringidas por el contexto
en el que se aplican, y si bien contribuyen al aumento de la bibliograf´ıa relacionada a tal
campo de investigación, brindando más herramientas para el abordaje de tal problema, aún
se dista de tener un modelo cercano a lo general para el tratamiento del asunto. Sin em-
bargo, eso no quita que existan propuestas que hayan jugado con la posibilidad de brindar
un enfoque general para el timetabling problem, as´ı como tratamientos del mismo usando
herramientas de cómputos heur´ısticos. Existen también obras, desde papers hasta libros y
disertaciones, orientadas exclusivamente al análisis abstracto de los elementos que forman
parte del problema de asignación de horarios, esto es, desde crear formatos generales para
los datos de entrada, crear representaciones estándar para las relaciones entre los individuos
y las actividades y las restricciones asociadas a las mismas. Se pueden listar los siguientes
trabajos:
Muhammad Rozi Malim, Ahamad Tajudin Khadery Adli Mustafa (2005), “University
Course Timetabling: A General Model”: [84] es un art´ıculo de investigación redactado
por integrantes de la Universidad de la Ciencia en Malasia. Mostrado en la 2da Con-
ferencia Internacional de Investigación y Educación Matemática el 2005, toma como
objeto de estudio el contexto universitario al ser un entorno rico en complejidad y
restricciones en comparación a otros entornos de estudios. Construye el modelo clasi-
ficando cada una de las restricciones como obligatoria (hard) y opcional (soft). Cada
restricción es representada como una variable matemática entera acompañada por una
constante c = 0 o c = 1, proponiendo entonces el llamado modelo general como un
problema de programación [lineal] entera.
Matthias Gröbner, Peter Wilke, y Stefan Büttcher (2003), “A Standard Framework
for Timetabling Problems”: [52] es el t´ıtulo de un trabajo realizado por integrantes
de la Universität Erlangen-Nürnberg, en Alemania, y The University of Western, en
Australia. En el trabajo construyen en paralelo una propuesta de modelo general para el
problema de asignación de horarios relacionada ´ıntimamente con el funcionamiento del
10

framework que proponen como solución al problema. Argumentan que las propuestas
existentes poseen un nivel de degradación al grado de especificidad de los algoritmos
de acuerdo al contexto en los cuales son implementados, y que poco sirve para avanzar
en las investigaciones en el campo. Generalizan los elementos asociados al timetabling
problem llamándolos entidades, y diviéndolos en distintas clases: recursos, eventos y
restricciones. Realizan el debido proceso de documentación mediante UML y en base a
ella crean una implementación de lo que llaman GTL: General Timetabling Language,
realizada sobre Java. En resumen, se crea el código de formulación del problema sobre
GTL, representando las mencionadas entidades mediante clases, y la carga de los datos
asociados a un contexto se realiza mediante ficheros XML.
Edmun Burke, Jeffrey Kingston (1997), “A standard data format por timetabling pro-
blem instances”: [31] es una revisión teórica de los aspectos obligatorios que debe cubrir
una propuesta de modelo estándar para la formulación del problema de asignación de
horarios, resumidos en los siguientes puntos: (1) generalidad, el modelo debe brindar el
soporte suficiente para que cualquier restricción e instancia de un problema cualquie-
ra sea expresable en términos de las herramientas prove´ıdas por el modelo; (2) cada
instancia de problema debe poder ser representada completamente por el modelo, esto
incluye contemplar los recursos, los participantes, las restricciones as´ı como las pro-
puestas de soluciones; (3) debe ser posible la conversión bidireccional de un problema
expresado con el modelo estándar con los distintos formatos de modelos existentes en
este campo de investigación. El trabajo identifica que el problema central reside en la
dificultad atada invariablemente a la tarea de reducir expresiones complejas genéricas
que incluyen elementos de teor´ıa de conjuntos, lógica formal y de predicados a una
serie de directivas incluidas en librer´ıas, as´ı como la imposibilidad de cubrir todas las
conversiones posibles a los otros modelos existentes en un momento dado, aunque el
trabajo busque minimizar tal falla inherente al contexto. Al final, el modelo de lenguaje
que presentan incluyen combinados entre si elementos que van desde la programación
imperativa hasta la programación lógica.
Michael Marte (2002), “Models and Algorithms for School Timetabling - A Constraint-
11

Programming Approach”: [51] es una tesis acerca del problema de asignación de horarios
en relación con el sistema de educación media en Alemania, que asemeja más no iguala,
en cuanto a complejidad de situaciones, al sistema universitario. Parte de la premisa
de la necesidad de establecer un sistema robusto de restricciones que emule de la mejor
manera posible el problema de asignación de horarios asociado al Gymnasium alemán.
Lu´ıs Paulo Reis y Eugénio Oliveira (2001), “A Language for Specifying Complete Ti-
metabling Problems”: [81] se identifican en este trabajo ocho versiones principales del
timetabling problem, y basados en ellos se presenta un nuevo lenguaje descriptivo lla-
mado Unilang, para la representación de los problemas de asignación de horarios. Este
va enfocado a servir como lenguaje adaptable para cualquier versión del problema,
ofreciendo una representación clara y concisa de los datos, las restricciones, medidas
de calidad as´ı como soluciones para cada una de las version del problema como la
asignación de horarios para universitarios o para exámenes.
Jeffrey Kingston (1999), “Modelling Timetabling Problems with STTL”: [62] art´ıculo
que explora las ventajas e inconvenientes presentados al intentar modelar problemas
del mundo real usando el Standard Timetabling Language.
David Ranson y Samad Ahmadi (2007), “An Extensible Modelling Framework for the
Examination Timetabling”: [80] en este trabajo los autores plantean que si bien el abor-
daje del timetabling problem con el objetivo de lograr una generalización del problema
ha sido ya realizado varias veces, argumentan que hasta el momento las opciones ofreci-
das no simplifican el proceso de modelado, carecen de caracter´ısticas claves para lograr
una mayor optimización en los resultados finales, y en ultima instancia ofrecen pocos
avances en comparación a soluciones análogas ya existentes en lenguajes de programa-
ción ya establecidos en la comunidad. Para solucionar tal problema, proponen crear un
framework de modelado independiente del lenguaje a usar a posteriori, usando STTL.
Si bien al final del documento queda como trabajo en progreso, los planteamientos rea-
lizados a lo largo del documento son de utilidad para cualquiera que desea abordar la
misma temática, a fin de generar nuevos resultados.
12

Jeffrey Kingston (2006), “Data Formats for Exchange of Real-World Timetabling Pro-
blem Instances and Solutions”: [60] realizado por el mismo autor del STTL, realiza los
siguientes planteamientos:
◦ La dificultad del modelado va intr´ınsecamente asociada a la larga cantidad de
requerimientos asociados al contexto. Esto se ha tratado de solucionar desde dis-
tintos enfoques, como lo son usando tecnolog´ıas de la web semántica, modelado
orientado a objetos, usando programación con restricciones, entre otros.
◦ A fin de no incurrir en la sobrecarga de información, deben establecerse cotas
asociadas a cuales variaciones del timetabling problem se pretende abarcar con la
propuesta de modelo general que se quiera realizar. Esto es, una vez definida la
cota y desarrollado una solución basada en la misma, se propone a futuro volver
a redefinir la solución extendiendo la cota superior en la que se basa la solución
previa.
Ender Özcan (2013), “Towards and XML base standard for Timetabling Problems:
TTML”: [70] busca solucionar el problema asociado a las dificultades de reusar los
datos de entrada y salida de otras propuestas de solución al timetabling problem, crean-
do un nuevo formato de data en XML que se basa a su vez en MathML [90].
Moritz Mühlenthaler(2014), “Fairness in Academic Course Timetabling”: [75] luego de
realizar un análisis exhaustivo del Problema de Asignación de Horarios en entornos uni-
versitarios, el autor se enfoca en como se puede formalizar y medir la equidad asociada
a la asignación de individuos y actividades, terminando con un caso de estudio a fin de
probar la efectividad de sus planteamientos.
Simon Kristianse, Thomas Jacob Riss (2013), “A Comprehensive Study of Educational
Timetabling - a Survey”: [63] se encarga de realizar una descripción extensiva del estado
del arte de un problema en cuestión, en este caso el problema de asignación de horarios,
evalúa las principales formalizaciones para cuatro principales versiones del problema,
usando datos de la vida real a fin de ofrecer medidas de calidad de las soluciones plan-
teadas.
13

De igual manera se puede encontrar en la red multitud de software que trata el timetabling
problem (no confundir con el software de agenda). En otros términos se les conoce como
software para la creación automática de horarios una vez que se carga la información aso-
ciada a las entidades y restricciones de la instancia a trabajar. Entre los más resaltantes se
encuentran:
FET [43]: es un software de código abierto creado en C++ para la generación au-
tomática de horarios de escuelas, liceos y universidades una vez cargada la información
asociada principalmente a profesores, asignaturas, aulas, estudiantes, entre otras. Sus
siglas se pueden interpretar como Free Evolutionary Timetabling, dado que de acuerdo
a los autores el conjunto de las restricciones var´ıa continuamente. Según la descripción
oficial, trata con un algoritmo “rápido y eficiente”, en contraste con el hecho de que en
el peor de los casos, cuando las restricciones cargadas son muy elaboradas, en el peor
de los casos el tiempo varia de cinco minutos a horas.
UniTime: University Timetabling [89] es un software distribuido bajo licencia de código
abierto, creado en Java para manejar con el mayor nivel de granularidad posible el pro-
blema de asignación de horarios, a fin de minimizar en la medida posible la coincidencia
de horarios para las actividades de un estudiante u otro participante en la organización.
Su elemento más distinguido es la Librer´ıa de Resolución de Restricciones (Constraints
Solver Library), basado en una combinación de “búsqueda hacia adelante” iterativo
con conjunto con búsqueda local, extendiendo sus capacidades a considerar todas las
soluciones consideradas como óptimas, pero que no sean necesariamente completas. En
el proceso, los candidatos a soluciones deben ir cumpliendo cada una de las restric-
ciones contempladas en el sistema, sin excepción. Para colaborar en la investigación
asociada al problema de asignación de horarios, el personal humano asociado a la crea-
ción y mantenimiento de este software ha liberado todo el trabajo relacionado bajo
licencias GNU, además de brindar en su web un listado de todas las publicaciones y
presentaciones en las cuales han colaborado.
14

En otro contexto, desde 1995 se celebra cada dos años una serie de conferencias interna-
cionales acerca de la teor´ıa y práctica del timetabling automatizado (PATAT, Practice and
Theory of Automated Timetabling) [76], en la que participa un cúmulo de investigadores,
practicantes y relacionados de alguna manera a todo lo que tenga ver con el abordaje del
problema de asignación de horarios. Entre los tópicos tratados se encuentran los diferentes
tipos de horarios, manejo de restricciones, inteligencia artificial, metaheur´ısticas, grafos, entre
muchos otros, que van desde los aspectos formales del problema hasta sus representaciones
practicas.
Patrocinado por PATAT existe también existe la ITC – International Timetabling Compe-
tition [57], donde se ponen a prueba a los participantes para usar sus propuestas de soluciones
con problemas compuestos de restricciones tomada del mundo real, as´ı como otras creadas
espec´ıficamente para la competencia. Es de notar que el software mencionado anteriormente,
UniTime, fue uno de los ganadores de tal competencia en su edición del 2007, obteniendo
dos de los tres principales premios posibles.
2.2. Bases teóricas
2.2.1. Investigación de operaciones
Campo multidisciplinario (posee componentes de matemáticas, lógica, ingenier´ıa, compu-
tación, entre otros) encargado de la optimización del uso de recursos para la ejecución de
distintas tareas [87]. Enfatiza en el uso de modelados matemáticos, espacios de soluciones
factibles y no factibles as´ı como los subconjuntos asociados a tales espacios, y la repetición
intensiva de cálculos para optimizar las soluciones temporales encontradas. Tales elementos,
combinados entre s´ı, dan pie para que en la investigación de operaciones se establezca que el
elemento de mayor importancia en la resolución de un problema es la definición del mismo,
y que el modelo general de solución se defina en base al predicado maximizar o minimizar
una o más funciones objetivos sujeto a un conjunto de restricciones [55].
15

2.2.2. Problema de asignación de horarios [38] [36] [58]
Término con el cual se denota el problema que envuelve asignar un conjunto de recursos
finitos en espacio y tiempo a una serie de actividades (comúnmente académicas) que van a
ser realizadas por distintos componentes (máquinas, humanos), los cuales también poseen
limitaciones en cuanto a cantidad de tareas que pueden realizar, por cuánto tiempo pueden
hacerla, as´ı como cuáles pueden ejecutar y cuáles no (dependencia condicional). El problema
se formula inicialmente teniendo un conjunto de restricciones (análogo al enfoque de inves-
tigación de operaciones), donde cada restricción puede ser obligatoria (hard constraint), es
decir, para solucionar una instancia dada debe cumplirse esa restricción obligatoriamente;
u opcional (soft constraint), es decir, la restricción no es obligatoria pero en caso de que se
pueda incluir como parte de la solución de una instancia dada, mejorar´ıa la calidad de la
misma.
El término timetabling problem engloba distintas variantes que comparten la misma lógica
de fondo. Entre las principales, en sus versiones más básicas se tienen:
STP (School Timetabling Problem): la versión más básica del problema, y por lo
general resoluble fácilmente de manera manual, busca asignar a los distintos estudiantes
de un sistema de primaria, a sus respectivos salones de clases.
BACP (Balanced Academic Curriculum Problem): dado los siguientes elemen-
tos:
◦ Un conjunto de asignaturas.
◦ Una carga asociada a cada asignatura.
◦ Sistema de prelaciones entre las asignaturas.
◦ Un conjunto de per´ıodos académicos.
◦ Un carga académica máxima permitida por cada per´ıodo.
En esta variante se busca distribuir el conjunto de asignaturas entre todos los per´ıodos
académicos, respetando las restricciones planteadas y minimizando la diferencia entre
las cargas académicas por cada per´ıodo.
16

ETP (Employee Timetabling Problem): dados los siguientes elementos:
◦ Un conjunto de actividades, cada una con una dificultad asociada.
◦ Un conjunto de individuos, cada una con una carga máxima de actividades a afron-
tar. Este formato de problema es el que más se aborda en los problemas iniciales
de programación lineal, se busca cubrir la realización de todas las actividades,
respetando las restricciones planteadas. Dependiendo del contexto, se suele contar
con un criterio de desgaste por cada individuo, as´ı como por ejemplo la dificultad
de una actividad var´ıe dependiendo del individuo.
ETP (Examination Timetabling Problem): dados los siguientes elementos:
◦ Un conjunto de pruebas
◦ Un conjunto de estudiantes, cada uno a la espera de presentar una de las pruebas.
◦ Una lista de bloques horarios.
◦ Salones de clase, cada uno con una capacidad máxima de estudiantes.
Se busca cubrir de manera eficiente la asignación estudiantes - prueba - salón de clases,
sin incumplir las restricciones impuestas. Al ser una triple asignación, las soluciones
creadas para este tipo de problemas suelen dividir el problema principal en subproble-
mas.
SSP (Student Sectioning Problem): por lo general, cuando se habla de que un
conjunto de estudiantes cursa o cursará una asignatura, esta asignación se encuentra
con el inconveniente en que los salones de clases disponibles no presentan la capacidad
suficiente para acoger a todos los inscritos. Es aqu´ı en donde entra el proceso de seccio-
namiento, en donde se realizan las divisiones óptimas para luego distribuir cada sección
de estudiantes en los salones de clases, y conceptualmente cada uno estar´ıa viendo una
asignatura distinta.
UCTP (University Course Timetabling Problem): una de las versiones más
abordadas en el campo de investigación del timetabling problem, es el que suele poseer
la mayor cantidad de individuos, actividades, relaciones entre esos dos componentes
17

as´ı como restricciones sobre tales restricciones. Tal sobrecarga de componentes en un
solo problema conlleva a asumir enfoques que dividan el problema principal en sub-
problemas, y mecanismos ya probados que interrelaciones los resultados de unos con la
entrada de otros, buscando soluciones factibles en tiempos cortos.
2.2.3. Complejidad algor´ıtmica
Un algoritmo es una secuencia de pasos ordenados para resolver un problema. Cada uno
de los pasos, o el conjunto de los mismos es expresable mediante operaciones matemáticas
y lógicas, las cuales var´ıan de forma de acuerdo al paradigma de programación que se esté
usando al momento. [37]
Comúnmente se asocia a un algoritmo un tamaño n el cuál es un valor natural asocia-
do al tamaño de los datos de entrada que serán evaluados por el programa. En base a ese
tamaño n, se determina un orden de complejidad, que es un valor real obtenido mediante
técnicas de análisis de complejidad de algoritmos [45]. Este valor es determinado en base al
análisis del algoritmo ante el peor de los casos que se puedan presentar. Este peor caso es
planteado mediante el modelo de análisis que se esté usando [49]. As´ı, si el estudio se hace
mediante un análisis asintótico, se realizan entonces los cálculos de complejidad asociados
con una cantidad l´ımite de data de entrada, la máxima cantidad iteraciones a ser ejecutada
para cada bucle del algoritmo en el caso de la programación imperativa as´ı como en una
decisión condicional, hacer los cálculos en base a la mayor complejidad de cada una de las
posibles condiciones a ejecutarse. [88] [26]
La notación más usada para realizar análisis de complejidad de algoritmos es la notación
O-grande, que trabaja con el ya nombrado análisis asintótico [88], donde se define una función
g(n) que viene a ser peor valor en tiempos de ejecución para el algoritmo dada una entrada
de tamaño n.
En base a lo anterior se define brevemente que [88]:
Un algoritmo de tiempo polinomial es aquel que posee un orden de complejidad O(p(n)),
18

donde p(n) es una función polinomial (complejidad P).
Los algoritmos que no entran en la categor´ıa anterior son algoritmos de complejidad
no polinomial (complejidad NP).
Un algoritmo es de tiempo exponencial si la complejidad asociada es O(cn
), donde
c ≥ 1.
Si un algoritmo es la solución a un problema, y cada algoritmo posee una complejidad
asociada, se define la complejidad de un problema como la complejidad asociada al mejor
algoritmo creado para resolver tal problema. [54]
Conocer el orden de un complejidad de un problema es un problema de decisión porque en
la teor´ıa de algoritmos los problemas se encuadran en dos clases principales de complejidad:
polinomial y no polinomial, ya mencionados anteriormente. Estas clases de complejidad se
dividen en subclases de manera recursiva. [64]
Figura 1: Clases de complejidad [88]
Un problema de clase de complejidad P (de ahora en adelante clase P) son problemas
resolubles en tiempos polinomiales en el peor de los casos [61]. La clase de interés para el pro-
yecto actual es la clase de complejidad NP (de aqu´ı en adelante clase NP). Son problemas que
en promedio para el caso estándar o el peor de los casos son resolubles en tiempo polinomial
por algoritmos no determin´ısticos, dado que si se abordan con estrategias determin´ısticas
su tiempo de solución puede llegar al orden de años o siglos [35]. Uno de los problemas del
19

milenio plantea la interrogante: ¿P=NP? [34]
Está demostrado que el Problema de Asignación de Horarios es un problema NP-completo.
[42]
2.2.4. Programación con restricciones
Es un paradigma de modelado y búsqueda orientado a satisfacer un conjunto de restriccio-
nes [27]. Es una de las principales estrategias a aplicar en problemas que dada su naturaleza
poseen una alta cantidad de restricciones, cada una con una cantidad importante de condi-
ciones a satisfacer. [56]
Dado un problema X, una solución al problema se puede plantear como un vector de
valores V = (v1, v2, . . . vn). Un algoritmo inicial buscar´ıa la solución óptima al problema
analizando todas las combinaciones de valores para el vector V , lo cual teóricamente es
válido, pero ineficiente cuando la cantidad de combinaciones es alta (en este caso, es n!) [59].
La programación con restricciones aprovecha la posibilidad de definir un problema como un
conjunto de condiciones que la solución debe cumplir para ser válida, reduciendo as´ı el espacio
de búsqueda inicial as´ı como los subsecuentes caminos a seguir para hallar una solución válida
y óptima.
2.2.5. Propagación de restricciones [25] [28] [41] [53]
Dado un modelo de restricciones, definido en base a un conjunto de variables y restriccio-
nes de valor aplicadas sobre las mismas, se entiende a la propagación de restricciones como
el proceso de determinar como las restricciones y los posibles valores de una variable pueden
afectar los posibles valores de otras variables. Tal proceso desemboca en la re-formulación
del modelo original, todo esto encaminado a reducir el número de decisiones a tomar a la
hora de hallar la solución (haciendo con esto analog´ıa al proceso de resolver un modelo de
restricciones como una búsqueda).
Tal proceso de refinación del modelo se logra ya sea reduciendo el dominio de las variables
20

involucradas, creando y/o eliminando variables y/o restricciones. Un algoritmo de propaga-
ción de restricciones se conoce comúnmente como ”propagador”. Un esquema resumido de
cómo se comporta ser´ıa el siguiente:
Cuando una variable X cambia de valor, el sistema evalúa el dominio de cada variable
Yi dependiente de X. Esto genera nuevos dominios para cada una de ellas.
Por lo general, cada nuevo dominio de una variable Yi es subconjunto del dominio de
esa misma variable Yi previo al cambio de valor de X.
Ahora, cada variable Yi se convierte en una variable X, y se repite el proceso de ma-
nera recursiva, hasta llegar a un punto de parada, que var´ıa dependiendo del tipo de
propagador que se esté usando.
Entre los principales tipos de propagadores, se tienen:
Node consistency.
Arc consistency.
Hyper-arc consistency.
Directional arc consistency.
Path consistency.
Directional path consistency.
2.2.6. Modelado cient´ıfico
Es una actividad cient´ıfica orientada a convertir un componente del mundo real en al-
go más fácil de entender, definir, cuantificar, visualizar y/o simular, usando mecanismos,
conceptos y herramientas aceptados por la comunidad cient´ıfica. Si bien la totalidad de los
modelos existentes no dejan de ser sólo aproximaciones a aquello que desean representar, su
utilidad está exenta de prueba en lo que concierne a entender los fenómenos que comúnmente
acontecen. Entre los principales tipos de modelos se tienen:
21

Modelos cualitativos vs cuantitativos: los primeros basan su esencia en la descrip-
ción más que todo verbal del objeto a modelar, mientras que los segundos se construyen
mediante unidades de medida, interrelaciones de entidades y formulación de procesos
mediante basamentos lógico-matemáticos.
Modelos deductivos vs inductivos: un modelo deductivo trabaja con un enfoque
top-down, esto es, va desde lo más general hasta lo más especifico. En otras palabras,
parte desde una teor´ıa general (dentro del marco de abstracción en el cual esté tra-
bajando), y va descomponiendo la misma en un conjunto de ”sub-postulados”también
válidos, repitiendo el proceso de manera c´ıclica, hasta que un elemento desconocido es
tomado como cierto, ya que está respaldado por el proceso previo realizado. Mientras
que un modulo inductivo usa el enfoque bottom-up, el cual empieza con observacio-
nes espec´ıficas, y mediante la identificación de patrones y elementos regulares, termina
formulando una o más hipótesis que al ser probadas y resultan ser ciertas, derivan en
conclusiones o teor´ıas generales.
Modelos deterministas vs estocásticos: un modelo determinista describe el com-
portamiento de un objeto o fenómeno como algo completamente condicionado por su
estado inicial. Esto es, para los mismos datos de entrada, siempre se tendrán los mismos
valores de salida. Mientras que en un modelo estocástico o probabilista el resultado no
es tan directo, ya que los valores de entrada se ven influenciados en los procesos internos
del modelo por mecanismos de aleatoriedad.
Modelos universales vs espec´ıficos: los primeros buscan simular procesos que sean
convertibles a través de distintos dominios e instancias del mismo problema, mientras
que los segundos solo trabajan en un dominio único, as´ı como en conjuntos de datos
adaptados a ese único dominio del problema.
Entre los puntos más importantes a recalcar acerca de un modelo cient´ıfico se tiene:
Estos son construidos cuando el nivel de factibilidad asociado a reproducir emp´ırica-
mente las condiciones y/o el fenómeno a estudiar es bajo o nulo.
22

La puesta en marcha del modelo se conoce como simulación, y genera resultados a ser
evaluados para verificar principalmente si el modelo cumple el objetivo para el cual fue
creado.
Un modelo estructurado adecuadamente debe cubrir los pasos de observación y reco-
nocimiento de todos los patrones y relaciones existentes en el objeto real.
Generar/construir el modelo implica asumir un adecuado nivel de abstracción, que var´ıa
de acuerdo al problema.
La evaluación de un modelo conlleva a tener en cuenta los siguientes factores:
◦ Habilidad para describir las observaciones previas.
◦ Habilidad para predecir, con margenes de error m´ınimos, futuras observaciones.
◦ Costo de usar el modelo en comparación a otros con los mismos objetivos.
◦ Simplicidad.
23

3. Planteamiento del Problema y Justificación
Este cap´ıtulo se compone de cuatro secciones. En el Contexto del Problema (3.1) se des-
cribe brevemente dos puntos: los contextos en donde suele ubicarse el problema de asignación
de horarios, y el contexto escogido para desarrollar el presente TEG, que dará pie para en-
tonces escoger, cap´ıtulos más adelante, determinados casos de prueba. En la Definición del
Problema (3.2 se presenta lo que se entiende en este trabajo por el timetabling problem, y
será este el concepto a usar en el posterior desarrollo. En los Objetivos de la Investigación
(3.3) se detallan los objetivos generales y espec´ıficos a alcanzar por este trabajo. Mientras
que en la Justificación e Importancia del tema a tratar (3.4) se presentan el conjunto de
razones que sustentan la realización de este trabajo, amparadas en conjunto por la necesidad
ya descrita de aumentar la sistematización en cuanto a recolección de esquemas y modelos
de restricciones del problema de asignación de horarios.
24

3.1. Contexto del Problema
El problema de asignación de horarios se encuentra en todos aquellos ámbitos en los
que la planificación de actividades con relación a los recursos disponibles, tanto en tiempo
como en mano de obra o similares, es un asunto cr´ıtico. El caso a desarrollar tanto en
términos teóricos, como a la hora de estructurar los casos de pruebas y las simulaciones,
corresponde al timetabling problem asociado a entornos académicos, esto es, escuelas, liceos
y universidades [30]. La complejidad de cada formulación es proporcional al nivel académico
el cual se esté trabajando, as´ı, el problema de asignación de horarios en una escuela suele
ser un problema no pocas veces resoluble con algoritmos deterministas, mientras que en una
universidad la regla es que se usen metaheur´ısticas, que no es más que la combinación de
varias heur´ısticas, con el fin de aproximarse a soluciones óptimas o en su defecto aceptables.
3.2. Definición del problema
Tómese en cuenta que en un entorno de trabajo la realización de una serie de tareas
es la actividad central del mismo. Una medida de optimalidad en el llevado a cabo de las
mismas está basada en el orden en que son realizadas unas con respecto a las otras, as´ı como
la ubicación en el tiempo de cada una de ellas. Todos estos elementos teóricos entran en el
marco de la investigación de operaciones [91], donde se busca dado un conjunto de recursos
para la realización de tareas, optimizar el uso de los mismos.
El problema de asignación de horarios (interpretación del término anglosajón timetabling
problem) busca en su versión más básica distribuir la realización de un conjunto de tareas
atados a dos restricciones obligatorias:
Cantidad de espacio limitada.
Cantidad limitada de bloques horarios.
Al ser un problema combinatorio NP-completo [42] la búsqueda de soluciones óptimas
suele estar muy influida por el contexto en el cual se evalúa el problema, as´ı, las alternativas
25

algor´ıtmicas planteadas se ven altamente atadas en cuanto a modelado de acuerdo al pro-
blema espec´ıfico tratado (un departamento universitario o un ente del gobierno). Es decir,
mientras se busca elevar la cota de optimalidad de las soluciones generadas, el algoritmo de-
genera hasta convertirse solo útil para un número reducido de contextos, con particularidades
espec´ıficas.
Ahora bien, hay dos segmentos bien delimitados, pero para nada independientes, en la
resolución del timetabling problem. Esto es:
El modelo de restricciones que representa el problema a resolver.
El conjunto de algoritmos a usar para solucionar el modelo. Entiéndase por solución la
asignación de individuos a actividades redundando en la superación de una cota m´ınima
de optimalidad.
El presente trabajo se encarga de optimizar los procesos asociados al primer elemento,
mientras que el segundo, asociado a la búsqueda, de la solución queda excluido.
Los principales problemas asociados a la construcción de un modelo de restricciones para
una instancia del timetabling problem son los siguientes:
La rigidez en su estructura. Un diseño demasiado atado al problema para el cual fue
creado resulta inútil cuando la instancia origen cambia, haciendo incluso necesario
volver a re-formular todo el sistema.
La optimalidad asociada al modelo de restricciones (existen métricas que calculan la
misma) incide directamente en la factibilidad a la hora de construir una solución factible
al problema.
En relación al problema de la rigidez, un modelo flexible entonces va orientado a que
la mayor cantidad de instancias del timetabling problem puedan ser representadas bajo
el modelo, sin que en el proceso de transformación se pierda información alguna.
26

El lenguaje usado para el modelo suele causar limitantes a la hora de usarlo. Esto es,
al construirlo en un lenguaje de uso especifico, genera una carga adicional de trabajo
en caso de que sea necesario usarlo bajo otras tecnolog´ıas.
3.3. Objetivos de la investigación
3.3.1. Objetivos Generales
1. Crear un modelo de costos que contemple la naturaleza dinámica de las restricciones de
una instancia cualquiera del problema de asignación de horarios, usando herramientas
de modelado y tomando en cuenta las debilidades de los planteamientos previos con el
fin de superar la rigidez de modelos de restricciones ya existentes.
2. Usar un recurso algor´ıtmico que trabaje sobre el modelo construido y, en conjunto
con datos provenientes de la instancia a resolver, realice un proceso de reformulación
del mismo, optimizando su estructura y con miras a optimizar los cálculos futuros de
resolución del sistema.
3.3.2. Objetivos Espec´ıficos
1.1 Realizar un estudio intensivo del estado del arte del problema de asignación de horarios,
en espec´ıfico el manejo de las restricciones, con el fin de asegurar la mayor cantidad de
herramientas disponibles para el modelado del proyecto actual.
1.2 Crear un modelo de costos usando basamentos formales lógicos y matemáticos para un
conjunto dinámico de restricciones.
2.1 Construir el esquema algor´ıtmico de alto nivel que trabajará sobre el modelo de costos
y restricciones construido en el paso anterior para la reformulación del mismo.
2.2 Implementar el esquema algor´ıtmico en lenguaje de programación, y probar el com-
portamiento del mismo usando conjuntos de entrenamiento pertenecientes a diversos
contextos.
27

3.4. Justificación e importancia del tema tratado
Se piensa que el planteamiento de una solución para el timetabling problem que contem-
ple un modelado robusto para un conjunto dinámico de restricciones que además supere la
tradicional dicotom´ıa de restricciones obligatorias y opcionales, asignando una medida de
importancia espec´ıfica a cada una conllevar´ıa a un avance positivo en las investigaciones de
dicho campo.
La realización de actividades es, sin necesidad de extenderse demasiado al respecto, el eje
central de la existencia de cualquier organismo. Y en la sociedad industrializada, en donde
la planificación toma más importancia conforme aumenta la complejidad de las relaciones de
trabajo, la necesidad de automatizar procesos que solucionados de otra manera (manualmen-
te por ejemplo) tomar´ıan más tiempo del necesario cobra mayor importancia. El desarrollo
de un tópico desde una perspectiva global, y que busque abarcar en términos solventes al
menos las principales versiones de un problema, siempre ofrecerá la oportunidad de revisar
nuevos aspectos del problema consecuencia de las conclusiones a las que se logre llegar.
De esta manera, los resultados que se obtengan de este trabajo no deber´ıan limitarse a su
aplicación al contexto indicado más arriba, sino que pueden servir también como medidores
en contextos de la misma naturaleza.
28

4. Marco Metodológico
Este cap´ıtulo se compone de dos secciones. En la Descripción de la Metodolog´ıa (3.1) se
presenta el Protocolo de Modelado, el cual no es más que una serie de pasos a seguir para la
construcción de un modelo matemático y/o lógico, mientras que en la sección de Aplicación de
la Metodolog´ıa (4.2) los pasos anteriores toman vida para comenzar con el diseño del modelo
general que es el objetivo general del presente trabajo, yendo desde el esclarecimiento final
sobre el objetivo del modelado, pasando por el modelado conceptual, la parametrización del
modelo, la escogencia del código y recursos de software para la ejecución de las simulaciones
y pruebas, y la creación del esquema con el cual se presentarán los resultados finales.
29

4.1. Descripción de la metodolog´ıa
Se perfila que el trabajo genere como producto principal el modelo general de restricciones
para el timetabling problem.
El modelado cient´ıfico toma un ente de la realidad y lo convierte en un conjunto de pos-
tulados formales basados principalmente en elementos lógicos y matemáticos que describen
el comportamiento de tal ente conforme a las caracter´ısticas que se desean estudiar [32] [47].
Se define la siguiente trilog´ıa:
Figura 2: Trilog´ıa Modelo - Algoritmo - Programa [32]
Existen otros dos elementos que brindan robustez a la metodolog´ıa de modelado ma-
temático, como lo son el esquema general del modelo y el protocolo de modelado.
El esquema general gira alrededor del postulado de la validez universal del principio causa-
efecto. Los elementos que conforman este principio son adaptados al contexto en el cual se
aplica. En un escenario se transfiere energ´ıa, en otros información.
El modelo se clasifica de acuerdo a sus caracter´ısticas [48]. Existen muchos tipos de
modelos, as´ı como subtipos, y de la misma manera tal clasificación no necesariamente se
establece al terminar de construirlo. También se puede inferir sobre qué clase de modelo es,
respondiendo preguntas durante el proceso de creación que esclarezca que decisiones tomar
30

Figura 3: Esquema general del modelo matemático. [32]
de acuerdo a qué herramientas usar y cuáles no.
4.1.1. Protocolo de Modelado
1. Definición del objetivo del modelado: debe responder a las preguntas ”¿para qué
modelar un proceso?”, ”¿para qué modelar los procesos relacionados a las restricciones
del problema de asignación de horarios?”. Siendo la sección inicial del protocolo, si
bien no todas las ideas que puedan generar los investigadores serán plasmadas aqu´ı,
es importante que se planteen aqu´ı todos los puntos cr´ıticos asociados al objetivo del
modelado: las hipótesis, establecer el tipo del modelo, alcances y limitaciones entre otros
elementos. No posee una estructura definida, y dependerá de la esencia del modelo que
se esté construyendo.
2. Formulación del modelo conceptual: teniendo un marco establecido en cuanto a
nivel de factibilidad del trabajo a realizar, el modelo conceptual establece la complejidad
de los procesos y elementos a tomar en cuenta para el modelado. Al mismo tiempo, se
identifican también los elementos pertenecientes al modelo, y cómo se relacionan entre
s´ı, el alcance del modelo o, en otras palabras, sus limitantes.
3. Tipo de modelo a usar: consecuencia del paso anterior, se puntualiza qué tipo de
modelo es más adecuado usar. Puede ser puro o compuesto, esto de acuerdo a las
31

necesidades. Conforme al tipo de modelo escogido, se explica el porqué de la elección,
y esto más que todo está condicionado a las caracter´ısticas lo cual lo ubican dentro de
determinada categor´ıa.
Figura 4: Primera etapa del protocolo de modelado [32]
4. Selección del código a aplicar: basado en el tipo de modelo a usar, se investiga la
disponibilidad de código, librer´ıas y cualquier otro soporte de software relacionado al
mismo y que sirva de apoyo para el desarrollo de la aplicación que trabajará sobre la
construcción, testing y validación del modelo, as´ı como de los resultados que se generen
de los procesos ya mencionados. Es aplicable la creación de código propio, y este último
es obviamente imprescindible para cuando la existencia de herramientas que den soporte
al producto a construir sea casi nula.
5. Parametrización del modelo: se establecen las magnitudes de los parámetros que
forman parte de la estructura matemática. Los elementos identificados y plasmados
en el modelo conceptual son traducidos a definiciones formales en términos lógicos y
matemáticos, principalmente. Esto incluye variables, relaciones, restricciones, as´ı como
alcances y limitaciones del modelo en su generalidad.
32

Figura 5: Segunda etapa del protocolo de modelado [32]
6. Validación del modelo: mientras que el paso anterior establece el rango de valores
a trabajar para cada uno de los parámetros del modelo, este último se prueba ahora
con un conjunto de valores de prueba que estén fuera de tales rangos, recolectando
los resultados obtenidos. A tal conjunto de resultados se les asocia una medida de
error de acuerdo al criterio de validación que se esté usando. El modelo construido será
considerado válido a efectos de uso cuando tal medida de error se encuentre dentro de
un l´ımite considerado permisible.
7. Simulación: el modelo construido entra en fase de uso con casos de prueba definidos
sistemáticamente, con el fin de obtener la información suficiente para el paso final.
Si bien ya es una práctica general, vale recalcar que queda como impl´ıcito que estas
simulaciones son computacionales, as´ı que también es importante especificar las espe-
cificaciones de las plataformas en donde se realicen tales simulaciones.
La construcción y/o recolección de casos de prueba debe ser realizada de manera sis-
temática y ordenada, para as´ı tener un control preciso sobre el contraste que se realice
entre los resultados obtenidos y los esperados (en las hipótesis previas).
8. Análisis y presentación de resultados: se verifica la coherencia de los resultados
33

Figura 6: Tercera etapa del protocolo de modelado [32]
obtenidos en el paso anterior, soportado también por el momento en que se superó la
validación del modelo, para as´ı construir el documento formal que dé soporte a la toma
de decisiones, as´ı como la construcción de las conclusiones y recomendaciones.
4.2. Aplicación de la metodolog´ıa
4.2.1. Definición del objetivo del modelado
El problema de asignación de horarios es un problema combinatorio NP-completo [66]. No
existe una sola versión del mismo, sino que esta var´ıa dependiendo del contexto del proble-
ma. Esta variación se define mediante cambios en la naturaleza y estructura de sus variables,
relaciones entre las mismas, restricciones sobre los dominios de las variables y sobre tales
relaciones. Si bien persiste un patrón común en cuanto el núcleo del problema, independiente
de las versiones que tenga el mismo, el común de las soluciones existentes se basa en el alto
grado de diferencia que hay entre cada una de ellas consecuencia de crearlas condicionadas
en su totalidad a la instancia espec´ıfica que se desea resolver.
34

El proceso general de solución al problema se divide en la fase de modelado y la fase al-
gor´ıtmica. La segunda trabaja sobre lo construido en la primera. Esto trae como consecuencia
que la efectividad asociada a la estructura del modelo influya directamente en la calidad de
la solución algor´ıtmica.
En cuanto a la bibliograf´ıa que trata acerca de las soluciones al problema de asignación de
horarios (en sus distintas variantes), la mayor´ıa se concentra más en los procesos algor´ıtmicos
que en la fase de modelado, siendo esta última ubicada como un elemento trivial en compa-
ración a los algoritmos desarrollados para tratar el problema.
Entonces, durante el desarrollo del modelo se busca responder las siguientes interrogantes,
con el fin de tener un producto consistente:
¿Qué se busca?
◦ Aportar al fortalecimiento de la bibliograf´ıa relacionada a la construcción de mo-
delos.
◦ Desarrollar un esquema base orientado en principio a unificar una lista definida
tomada de las principales variantes del timetabling problem en un sistema que per-
mita luego reformular el modelo usando como datos la información de la instancia
a resolver, todo esto orientado a la optimización de los cálculos algor´ıtmicos que
resuelvan el problema.
◦ El modelo creado (entendiéndose por modelo tanto los esquemas conceptuales aso-
ciado al mismo como los mecanismos de reformulacion y optimización basado en
los casos de prueba) va orientado a ser independiente de plataformas y lenguajes de
programación. En otras palabras, debe ofrecer los mecanismos (teóricos y emp´ıri-
cos) m´ınimos necesarios para que su interfaz de entrada-salida sea re-usable en la
mayor cantidad de contextos asociados al problema de asignación de horarios.
¿Qué se sabe?: Esto es cubierto en la sección del modelado conceptual (4.2.2). Se
expresa verbalmente y mediante gráficos las entidades que se han identificado del pro-
35

blema, las relaciones entre las mismas, y los resultados (propiedades emergentes del
sistema) de operar ambos elementos.
¿Qué se puede asumir?: descrito también la sección del modelado conceptual (4.2.2),
las suposiciones que se realizan con respecto al problema a modelar son concentradas
en términos conceptuales en lo que será tratado como las entradas del modelo general
del problema de asignación de horarios.
¿Cómo deber´ıa ser visto este modelo?: cada una de las caracter´ısticas del modelo
a construir lo condicionan a formar parte de ciertos conjuntos de modelos cient´ıficos
(cubiertos en la sección (4.2.3)), los cuales definen la respuesta a tal interrogante. As´ı
mismo, y en términos generales, el trabajo presente se orienta principalmente a pre-
sentar el modelo como una especie de plantilla base en la cual deber´ıan confluir, si no
todos, un segmento significativo tanto en cantidad como en relevancia de las instancias
del timetabling problem.
¿Los resultados obtenidos coinciden con las hipótesis planteadas?: esta pre-
gunta es respondida convenientemente en la sección de Hipótesis Iniciales (6.2.1) y
en la sección de Resultados Obtenidos (6.2.2). Los elementos a analizar en las simu-
laciones del modelo son expuestos en la sección de Métricas de Evaluación (6.1.3).
¿Cómo será usado este modelo?: respuesta cubierta más extensamente en la sección
de (7.1), básicamente dependiendo de los resultados obtenidos, si son alcanzadas las
hipótesis planteadas, el modelo entonces deber´ıa servir para avanzar en la creación de
un marco de trabajo para el problema investigado que gire alrededor del modelo general
planteado, y en su si defecto si no son cubiertas en su mayor´ıa las hipótesis predecidas,
entonces deber´ıa servir como indicador de distintos elementos tales como el evitar el
código escogido para futuras soluciones al mismo problema, el desarrollo del mismo
modelo conceptual pero bajo otro paradigma de programación, la reformulación del
mismo modelo bajo otro enfoque de modelado, entre otras alternativas.
¿Cómo se puede mejorar este modelo? descrito con mayor profundidad en la sec-
ción de Trabajos Futuros (7.2), la mejora del modelo construido deber´ıa ir orientada
36

principalmente a mejorar los resultados contemplados en las métricas de evaluación, y
ampliar su capacidad de aceptar nuevas instancias del problema de asignación de ho-
rarios, as´ı mismo tal proceso de transformación deber´ıa ser lo menos engorroso posible.
4.2.2. Formulación del modelo conceptual
El modelo conceptual se divide en tres secciones:
Entrada: es la instancia original del problema a resolver. Está compuesta de :
◦ Modelo original: es el conjunto de variables, relaciones y restriciones existentes
en el modelo original. Pueden estar formuladas sólo de manera conceptual o ya
estar parametrizadas adecuadamente en términos lógicos y matemáticos.
◦ Datos de entrada: es la instancia del mundo real que necesita ser resuelta. Por
ejemplo, pueden ser el conjunto de estudiantes que necesitan ser distribuidos entre
las distintas asignaturas, o el conjunto de operarios a distribuir entre las distintas
máquinas de una planta.
37

Modelo general: incluye el esquema general al cual debe ser mapeado el modelo
original, as´ı como los procesos encargados de optimizar el modelo. Más detalladamente:
◦ Mapeo: es el proceso de conversión del modelo original al modelo general.
Transforma los elementos del modelo original a elementos que encuadren den-
tro de la lógica de Clases Individuo-Clases Actividad-Relaciones-Restricciones.
38

Es realizado de manera manual por aquel que desee hacer uso de los mecanis-
mos de optimización del sistema. Este proceso de transformación también debe
aplicarse sobre el conjunto de datos, generando entonces mapeo(dataOriginal) =
dataTransformada.
◦ Clases Individuo: en la semántica del problema de asignación de horarios son
aquellos elementos del sistema avocados a realizar alguna actividad.
Figura 7: Clase Individuo.
Para los distintos tipos de clase individuo se tienen los mismos tipos de campo, a
continuación:
◦ Id: identificador único para el individuo.
◦ Lista de atributos: tupla de valores, en donde cada valor es de un tipo primiti-
vo o tupla. Su estructura var´ıa dependiendo del modelo origen. Este atributo
compuesto sirve para modelar los atributos de los Individuos del modelo ori-
ginal que no tienen representación directa en el resto de los atributos de la
clase Individuo.
◦ Clases Actividad: en la semántica del problema de asignación de horarios son
aquellos elementos del sistema disponibles para ser ejecutados por los individuos.
Para los distintos tipos de clase actividad se tienen los mismos tipos de campo, a
continuación:
◦ Id: identificador único para la actividad.
◦ Lista de atributos: tupla de valores, en donde cada valor es de un tipo primitivo
o tupla. Su estructura var´ıa dependiendo del modelo origen. Este atributo
39

Figura 8: Clase Actividad.
compuesto sirve para modelar los atributos de las actividades del modelo
original que no tienen representación directa en el resto de los atributos de la
clase Actividad.
Posterior al concepto de Clase Actividad, se tiene el concepto de seccionamiento. Para
la definición del mismo, y con el fin de generalizar el concepto de Actividad aplicado
a las principales instancias existentes de problema de asignación de horarios, se deben
en tener en cuenta los siguientes factores:
◦ Una actividad puede tener una cantidad o estimada o determinada de o aspirantes
o participantes.
◦ Diferencias contextuales entre participantes y aspirantes: se habla de participantes
cuando ya está establecida la relación de ejecución de un individuo con respecto
a una actividad. Se habla de aspirante cuando tal relación es deseable (ya sea por
condiciones del sistema o por voluntad del individuo) pero aún no se ha establecido.
◦ En la generalización del problema de asignación de horarios, se tiene que el con-
junto de actividades son ejecutadas en un determinado plazo. Tal plazo es repetido
por lo menos una vez, es decir, su ejecución es c´ıclica.
◦ La ejecución de cada actividad en el marco de un plazo c´ıclico se ve condicionada,
directa o indirectamente, por tres elementos:
◦ Tiempo: la ejecución total de una actividad, en algunos casos (depende del
problema original), debe distribuirse en segmentos a través del tiempo. A cada
uno de estos segmentos se le conocerá como sub-actividad.
40

◦ Ubicación: una actividad es ejecutada en alguna instancia del espacio. Tal
ubicación poseerá diversos atributos relacionados, pero a efectos del análisis
presente relacionado al seccionamiento, se considerará únicamente aquel atri-
buto relacionado a la máxima carga de individuos que tal ubicación puede
admitir.
◦ Ejecutores: cantidad estimada o determinada de participantes o aspirantes.
Comprendiendo entonces la limitante asociada a la cantidad de individuo que puede
albergar una ubicación f´ısica para la prosecución de una actividad, se tiene que:
Se entiende por seccionamiento [71] el proceso por el cual una actividad es replicada
de tal manera que cada réplica se toma como una actividad independiente con respecto
a las otras, con el fin de que su ejecución sea manejable con respecto a la correlación
carga máxima de individuos por ubicación y cantidad total estimada o
determinada de participantes o aspirantes
Establecido el concepto de seccionamiento, entra en juego el de eventos. Un evento
no es más que la asignación de una sub-actividad a un par (instancia temporal,
instancia posicional). En otras palabras, un evento es la representación indivisible (a
efectos del presente modelo) de la ejecución de una actividad en términos de sub-
actividades, ubicando cada una en una determinada instancia del espacio y del tiempo
(cada una de estas caracter´ısticas dependerán del contexto del trabajo, pero se toman
como referencias principales no excluibles por ser parte de los principales sistemas de
medición existentes).
◦ Relaciones: son las representaciones necesarias para indicar que la Clase In-
dividuo X agrupa los individuos del modelo original que se plantean realizar las
actividades del modelo original pertenecientes ahora a la Clase Individuo Y. Las
siguientes son las relaciones planteadas en el modelo a construir:
◦ Individuo-realiza-Actividad:
41

Figura 9: Relacion Individuo-Realiza-Actividad.
◦ Incompatiblidad: se habla de ausencia de compatibilidad cuando, prestos dos
o más elementos a ser comparados entre si, existe disonancia entre los valores
esperados para ser evaluados dentro de un conjunto de funciones matemáticas y
condiciones lógicas y los valores reales de tales elementos aplicados a tales funciones
y condiciones. Este esquema general es donde van encuadradas las tradicionales
restricciones “fuertes” y opcionales del timetabling problem.
◦ Propagadores: [29] es el conjunto de algoritmos de optimización de modelos
que trabaja sobre el modelo general (que contiene, posterior al proceso de mapeo,
una representación manejable del modelo original), produciendo una versión me-
jorada del mismo. En términos formales, puede describirse de la siguiente manera:
propagadores(modeloGeneral, dataTransformada) = modeloOptimizado.
Salida: es consecuencia de la actividad de los propagadores, el modeloOptimizado.
4.2.3. Tipo de modelo a usar
Es un modelo h´ıbrido, dado que su estructura engrana conceptos y mecanismos de dis-
tintos tipos de modelos homógeneos, los cuales están listados a continuación:
Modelo matemático [40]: dado que la mayor´ıa de sus componentes son expresa-
dos en base a conceptos matemáticos. Principalmente las restricciones asociadas a las
relaciones entre las clases existentes en el sistema.
Modelo lógico [85]: debido a que tanto las relaciones como las restricciones son
expresadas, en última instancia, como el cumplimiento o no (verdadero o falso) de
determinadas condiciones construidas con postulados matemáticos.
42

Modelo emp´ırico: como consecuencia de incluir en uno de los procesos del modelo el
uso de datos reales.
Modelo estocástico: por el uso de componentes aleatorios y heur´ısticos a la hora de
hallar una version optimizada del modelo general basado en los datos de la instancia
del problema a resolver.
Modelo conceptual/cualitativo: porque en su concepción inicial, a fines de una me-
jor comprensión, es presentado como un engranaje de conceptos que permitan realizar
el proceso de mapeo más fácilmente.
Modelo descriptivo: dado que el enfoque asumido para la construcción del modelo
general es comprender la esencia del problema de asignación de horarios desde una
perspectiva tanto global como intr´ınseca, haciendo necesario la descripción detallada
de los procesos involucrados no sólo en términos formales sino también en lenguaje
natural, y definiendo la estructura final del mismo usando un marco recursos-procesos-
resultados.
Modelo de optimización: debido a que una de las principales caracter´ısticas del
timetabling problem es que las soluciones propuestas van orientadas desde un principio
a optimizar las asignaciones de individuos a actividades a realizar.
Modelo universal (vs Modelo de dominio espec´ıfico): porque se busca englo-
bar el problema de asignación de horarios, colocando como cota m´ınima abarcar sin
inconvenientes las versiones más representativas del problema, para luego en trabajos
futuros basados en el actual, corregir las deficiencias del modelo construido y añadir
nuevas caracter´ısticas que permitan cubrir versiones más sofisticadas del timetabling
problem que no sean cubiertas con el esquema construido en el presente trabajo.
4.2.4. Selección del código a aplicar
Esto es descrito con más detalle en la sección de Plataforma Computacional (6.1.1),
espec´ıficamente en el segmento dedicado a la especificación de los recursos de software a usar
para ejecutar las simulaciones.
43

4.2.5. Parametrización del modelo
Actividades:
A = {Ai/Ai es una actividad} , 1 ≤ i ≤ nA, nA = |A|
Ai =< id, < attr1, attr2, ..., attrm >>, m ≥ 0
Donde attri es un valor primitivo o una tupla, que contiene a su vez valores primitivos
o una tupla, y as´ı sucesivamente...
Sea F = {fi/fi es la cantidad de individuos asignados a realizar la actividad Ai}
Sea P = {p1, p2, ..., pn}
Donde pi es la cantidad promedio estimada de ejecutores que tendr´ıa cada sub-actividad
de Ai.
|A| = |F| = |P|
Aplicando criterio de seccionamiento (replicación de actividad):
R = {Ri/Ri es el conjunto de réplicas de la actividad Ai ∧ |Ri| = roof(fi/pi)}
Donde roof(...) arroja el valor redondeado al tope del parámetro.
Se tiene entonces:
A =
n
i=1
(Ri ∈ R) = {Aj/Aj es un seccionamiento de una de las actividades originales}
Aj =< id, id actividad original, < attr1, attr2, ..., attrm >>
Lapso:
L = {Lk/Lk es una instancia temporal } , 1 ≤ k ≤ nL, nL = |L|
Lk =< id, < attr1, attr2, ..., attrp >>, p ≥ 0
Ubicación:
U = {Ul/Ul es una instancia locacional } , 1 ≤ l ≤ nU , nU = |U|
Ul =< id, < attr1, attr2, ..., attrq >>, q ≥ 0
Eventos:
44

E = {Ed/Ed es un evento } , 1 ≤ d ≤ nE, nE = |E|
Ed =< id, id actividad, id lapso, id ubicacion, < attr1, attr2, ..., attrr >>, r ≥ 0
Donde compatibles AEd[id actividad] ∈ A , LEd[id lapso] ∈ L, UEd[id ubicacion] ∈ U . Está res-
tricción de compatibilidad será etiquetada como RT0.
Individuos:
I = {Is/Is es una individuo } , 1 ≤ s ≤ nI, nI = |I|
Us =< id, < attr1, attr2, ..., attrw >>, w ≥ 0
Restricciones:
◦ Minimización de incompatibilidades entre eventos (RT1):
Dado un valor min1 ∈ R:
RT2 ≡ (
nE
i=1
incompatibilidad(AEi[id actividad] ∈ A ,
LEi[id lapso] ∈ L, UEi[id ubicacion] ∈ U)) ≤ min1
◦ Minimización de incompatibilidades en asignaciones Individuo-Actividad
(RT2):
Sea G = {(Iy, Ac)/Iy ∈ I ∧ Ac ∈ A }
G es el conjunto de asignaciones de individuos a actividades que se desean solu-
cionar. Tomando como elementos de cálculo los pertenecientes a G, minimizar lo
siguiente:
Dado (Ix, Ai), (Ix, Aj) ∈ G. Ocurre que:
RT2 ≡ (Ai[id] = Aj[id] ∧ Ai[id actividad] = Aj[id actividad]) ∨
(Ai[id] = Aj[id] ∧ Ai[id actividad] = Aj[id actividad]∧
(∃x, y ∈ E[x[id actividad] = Ai[id actividad]∧
y[id actividad] = Aj[id actividad]∧
(solapamiento(Lx[id lapso] ∈ L, Ly[id lapso] ∈ L)∨
solapamiento(Ux[id ubicacion] ∈ U, Uy[id ubicacion] ∈ U))]))
45

4.2.6. Validación del modelo
Verificación del modelo:
¿El modelo está programado correctamente?, ¿Los algoritmos han sido im-
plementados apropiadamente?, ¿El modelo no contiene errores de ningún
tipo? [86]
El diseño del modelo, realizado con cierto subconjunto de tecnolog´ıas y descrito con más
profundidad en la sección de Configuración de los experimentos (6.1.2), se basó en
la construcción de un conjunto de condiciones en lógica de primer orden, que incluye
lógica de predicados y postulados matemáticos básicos, que pueden ser verificados para
comprobar su correctitud semántica y por supuesto sintáctica.
As´ı mismo la fiabilidad funcional de las herramientas de software a usar están garantiza-
das dado que se tratan de creaciones validadas por los procesos estándar de evaluación
de las investigaciones cient´ıficas.
La existencia o ausencia de errores en el modelo de restricciones creado para el presente
trabajo puede ser verificado, como ya se dijo, estudiando las condiciones desarrolladas
en la sección de descripción de los casos de prueba.
Validación del modelo: La validación de un modelo va orientada principalmente a
establecer la correctitud que existe entre lo que hace el modelo y el comportamiento
del fenómeno del mundo real que desea reproducir. Este modelo no busca esquematizar
un fenómeno del mundo real sino brindar un marco común de parámetros (entidades,
relaciones y restricciones) para el problema de asignación de horarios. En consecuencia,
no son aplicables los mecanismos de validación de modelos existentes para el actual.
4.2.7. Simulación
El proceso de simulación consta de las siguientes fases:
Definición de casos de prueba.
Mapeo de casos de prueba, en conjunto con la data complementaria, al modelo general
construido en el presente trabajo.
46

Formulación de hipótesis iniciales.
Escogencia de código, software y/o librer´ıas que desarrollen los algoritmos de propaga-
ción.
Implementación de resultados de mapeo de los casos de prueba en los códigos seleccio-
nados.
Establecimiento de plataformas de hardware en donde se ejecutarán las simulaciones
(equipos computadores).
Ejecución de los códigos en conjunto con los casos de prueba.
Análisis de los resultados obtenidos, constrastación con hipótesis iniciales. Reformula-
ción de hipótesis o de otro punto previo en caso de considerarse necesario.
Presentación de resultados finales.
4.2.8. Presentación y análisis de resultados
Presentación de resultados:
Cubierto en la sección de Resultados obtenidos (6.2.2).
Se realiza con las herramientas de presentación más convenientes (tablas, gráficos),
adaptando los valores generados a partir de las simulaciones contenidos por determina-
das variables. Se trabajan las distintas combinaciones que puedan generarse entre los
segmentos de datos generados para as´ı producir la información que será cubierta en el
análisis final de resultados.
Análisis de resultados:
Desarrollado en la sección de Conclusiones y Recomendaciones.
Aqu´ı se expone el análisis final que contrasta las hipótesis iniciales planteadas y los
resultados obtenidos de las simulaciones. A partir de aqu´ı también se generará las
recomendaciones para futuros trabajos que basen su temática en la desarrollada en la
47

presente investigación, en la continuación de la misma, o en su defecto de uno intr´ınseca-
mente relacionado tanto al problema de generar un esquema general de las restricciones,
o en la optimización de las mismas mediante técnicas de propagadores o alternativas.
48

5. Diseño de la solución
Este cap´ıtulo se compone de dos secciones. En la Descripción de la Solución (5.1) se
presentan una serie de puntos que describen el proceso a seguir ahora que se tiene establecido
por completo el marco de trabajo definido por el Protocolo de Modelado. Esta serie de pasos
incluyen el proceso de escogencia de los casos de prueba a desarrollar y la selección del
software para las simulaciones. En la sección de Alcances y Limitaciones (5.2) se describen
los contras en relación al proceso a seguir para la consecución de los resultados que convaliden
los objetivos a lograr.
49

5.1. Descripción de la solución
El siguiente es un listado que resume la serie de pasos a seguir para lograr el objetivo final
propuesto, as´ı como las caracter´ısticas que rodean al proceso. Cada paso posee la respectiva
referencia a la sección o secciones del presente trabajo en donde se describe con mayor detalle:
Se ha realizado una investigación a fondo de los tópicos más activos con respecto al
problema de asignación de horarios. Esto ha permitido identificar las principales ins-
tancias existentes del problema, y para cada una de ellas extraer un patrón alrededor
de la tr´ıada entidades-relaciones-restricciones, y construir un modelo conceptual debi-
damente parametrizado que permita dar soporte en su totalidad a los aspectos más
esenciales de las instancias seleccionadas.
Se escogen de manera detallada los casos de prueba más representativos a efectos de
poner a prueba la validez de los planteamientos del presente trabajo. Estos casos de
prueba consisten en modelos de entidades-relaciones-restricciones de instancias del ti-
metabling problem. A cada caso de prueba se le asocian datos de entrada, tanto reales
como artificiales (provenientes de un generador de casos previamente construido), los
cuales servirán para la ejecución de los pasos posteriores.
Habiendo construido las hipótesis iniciales, estableciendo cotas de trabajo, definido las
plataformas en donde se ejecutará la simulación, en conjunto con el código correspon-
diente, se realiza la conversión de los modelos originales en conjunto con la data al
esquema general planteado como solución en este trabajo.
Desarrolladas las conversiones, se ejecutan las simulaciones, que consistirán en (para
cada modelo convertido al esquema general), usando los mecanismos prove´ıdos por el
código seleccionado, la aplicación de los algoritmos de propagación (optimizadores de
modelo) en base a los datos que también fueron transformados.
Posterior a las simulaciones, se recolectarán los datos producidos por las mismas, rea-
lizando los análisis correspondientes orientados principalmente a validar las hipótesis
planteadas. En caso de no existir una correlación válida entre hipótesis y resultados, se
realiza una iteración consistente en identificar algún elemento erróneo existente entre
50

los planteamientos iniciales del trabajo y las hipótesis previas a la simulación. Realizada
la re-formulación, se ejecutan nuevamente las simulaciones (volver al paso anterior).
Para cuando exista una correlación válida entre hipótesis y resultados obtenidos, se
realizan las conclusiones asociadas a la investigación en general, as´ı como las recomen-
daciones para trabajos futuros basados en el actual.
5.2. Alcance y limitaciones
El proceso de mapeo debe realizarse de manera manual. Esto involucra una carga
adicional para el usuario, dado que tiene que realizar un análisis propio que logre
encajar con el esquema general construido. Se evaluó la posibilidad de trabajar con
un proceso de mapeo automático, pero queda fuera de los objetivos propuestos en el
trabajo actual.
El código encontrado para ser usado en el módulo de optimización del modelo (los
propagadores), si bien cumplen su trabajo, no está asegurado que sean la mejor versión
de si mismos, constituyéndose esto en otra limitación, y al mismo tiempo, en un punto
importante a ser tocado en un trabajo futuro, en donde se optimicen los algoritmos de
propagación encargados de optimizar el modelo construido en el trabajo actual.
Queda fuera del trabajo la realización de una interfaz de usuario de alto nivel que
permita un manejo y/o entendimiento simple de los resultados, esto debido a que el
uso de estos componentes está más orientado a desarrolladores de una herramienta
más global como lo ser´ıa un solver para el problema de asignación de horarios, con los
conocimientos necesarios en el campo.
Si bien la bibliograf´ıa revisada está lejos de ser pequeña, el modelo construido está lejos
de abarcar todas las variantes del problema de asignación de horarios, pero si ha sido
diseñado para que de solución, con la respectiva conversión (mapeo), a las principales
versiones del mismo. Dando pie entonces a que, en trabajos futuros, una versión más
refinada del modelo sea construida.
51

6. Resultados experimentales
Este cap´ıtulo se compone de dos secciones. En la Configuración de los Experimentos
(6.1) se describe la plataforma computacional sobre la cual se ejecutarán las pruebas (esto
incluye caracter´ısticas de hardware y códigos escogidos que traten con el problema de la
optimización de modelos mediante algoritmos de propagación de restricciones), los casos de
prueba en su versión inicial, descritos verbalmente, pasando por sus definiciones lógicas hasta
la representación de los mismos en el software escogido para las simulaciones, as´ı como la
definición de las métricas de evaluación para analizar el nivel de validez de los resultados
en relación a los objetivos planteados. Mientras que en el Análisis de los Resultados (6.2) se
describen las hipótesis iniciales en relación a lo que se espera obtener de las simulaciones en
base a todo el entramado teórico y de análisis realizado previamente, para luego mostrar los
resultados obtenidos de las simulaciones.
52

6.1. Configuración de los experimentos
6.1.1. Plataforma computacional
Las pruebas descritas en las siguientes secciones fueron realizadas en un equipo compu-
tador con las siguientes caracter´ısticas de hardware y software:
Sistema Operativo: Windows 10 de 32 Bits.
Disco Duro (HDD):
◦ Capacidad: 320 GB.
◦ Marca: Samsung.
◦ Modelo: HM321HI.
◦ RPM (Revoluciones Por Minuto): 5400 / 8M.
RAM: DDR3 2 GB Single Channel. Frecuencia DRAM (Dynamic RAM) de 399.0
MHz.
CPU: Pentium(R) Dual-Core E5700 @ 3.00 GHz 3.00 GHz.
En cuanto a la selección de código para ejecutar la optimización del modelo, se construyó
una lista de candidatos suficientemente amplia, para que el análisis de escogencia (en base a
una serie de criterios descritos a posteriori) se realizara con la mayor holgura posible. Estos
programas son los mencionados a continuación:
Choco [2]: es una biblioteca para Java de código abierto usada para la programación con
restricciones. Permite al usuario (programador) modelar su problema estableciendo el
conjunto de restricciones que deben ser cumplidas en cada una de las soluciones. Luego,
el problema es resuelto usando mecanismos que alternan entre algoritmos de filtrado
con mecanismos de búsqueda.
EclipseCLP [4]: es un sistema de código abierto para el desarrollo y puesta en marcha
de aplicaciones basadas en programación con restricciones. Contiene varias librer´ıas
para resolver esquemas pre-definidos de restricciones, un lenguaje de alto nivel para el
53

modelado, interfaces para solvers externos, entre otras herramientas. Su uso es mediante
la sintaxis de la programación lógica.
IBM ILOG Cplex Optimization Studio [11]: es un kit de herramientas de soporte a
la toma de decisiones mediante anal´ıtica para acelerar el desarrollo y el despliegue
de modelos de optimización utilizando programación matemática y de restricciones.
Combina un entorno de desarrollo integrado con un potente lenguaje de programación
de optimización y solucionadores de optimizador ILOG CPLEX de alto rendimiento. Es
de uso pago mediante licencia, ofreciendo una versión de prueba y con funcionalidades
limitadas.
Mozart Programming System [16]: combina investigaciones en desarrollo acerca del
diseño e implementación de lenguajes de programación, computación distribuida, e
interfaces humano-computador. Está implementado sobre el lenguaje multiparadigma
Oz y provee poder expresivo y avanzadas funcionalidades por igual. La última versión
(la 2) provee un soporte limitado al manejo de restricciones, que espera ser mejorado
con el lanzamiento de nuevas versiones, siendo esta la principal meta.
Constraint 0.4.1 [3]: es una biblioteca disponible para Python, orientada a resolver
problemas de restricciones usando propagadores. Es un desarrollo aún en fase experi-
mental.
UNITIME [89]: descrito ya previamente en la sección de Antecedentes Teóricos / Tra-
bajos Previos. Además del software principal, ofrece acceso a componentes .jar para ser
usados como librer´ıas externas de algún modulo personalizado relativo al timetabling
problem.
python-constraint [18]: otra biblioteca para Python que ofrece solucionadores para pro-
blemas de programación con restricciones. Los solvers disponibles hasta el momento
son backtracking, recursivo y el de m´ınimo conflicto, en donde se minimizan la cantidad
de veces en la que cierta restricción se incumple en las soluciones halladas o construidas.
Swi-Prolog [22]: es una implementación estable y gratuita del lenguaje Prolog, con
orientación a ser usada principalmente en entornos de investigación y educativos.
54

Lingo [13]: herramienta diseñada para la construcción y solución de modelos lineales y
no lineales (convexos y no convexos), cuadráticas, restringidas cuadráticamente, entre
otros, de manera rápida, fácil y eficiente.
Gecode [7]: es un conjunto de herramientas para el desarrollo de sistemas y aplicacio-
nes basadas en restricciones. Posee caracter´ısticas en su implementación que lo hacen
abordar de manera muy eficiente muchos problemas tanto con enfoques deterministas
como con enfoques heur´ısticos. Permite su ejecución en paralelo, maximizando el uso de
esta caracter´ıstica acorde a la arquitectura de hardware en la que esté siendo ejecutada,
respaldada por sus primeros lugares en diversas competencias del ramo, y distribuida
de manera gratuita y en código abierto.
SavileRow [74]: implementada en Java, es una herramienta orientada a la optimización
de modelos de restricciones, más que a la solución de los mismos.
As´ı mismo, existe un compendio adicional de herramientas, entre ellas LOOM ( [14]),
IBEX ( [10]), Cassowary ( [1]), Jacop ( [12]), Simple Theorem Prover (AKA SMT Solver)
( [20]), Opta Planner ( [17]), SCIP ( [19]), GUROBI ( [8]), Xpress ( [23]), SoPlex ( [21]),
FaCiLe ( [5]), HaifaCSP ( [9]), FPCS ( [6]), Mistral ( [15]). A diferencia de los descritos
más detalladamente en la lista previa a la anterior, estos últimos tienen en común que son
softwares descontinuados, programas pagos sin acceso a versiones de prueba (limitadas en
tiempo de uso o cantidad de caracter´ısticas/funcionalidades), o sin posibilidad de acceder a
su código fuente para revisiones más detalladas. En base a los mismos criterios junto a otros
adicionales se aplicó un filtro entre los principales, para as´ı quedar con un solo candidato a
usar en las simulaciones:
Acceso a código fuente: disponible en todas las principales excepto en UNITIME
y en IBM ILOG Cplex.
Licencias libres Vs Licencias privativas: aplica el mismo resultado del punto
anterior.
Curva de aprendizaje: un aprendizaje más rápido es ofrecido por herramientas
como SavileRow, dado que solo precisan conocimientos en lógica de primer orden, as´ı
55

como definición de predicados, mientras que en Lingo o ILOG Cplex o las bibliotecas
de Python hay que adaptarse a una sintaxis especifica definida por la herramienta, o
en Gecode, Swi-Prolog, Mozart o EclipseCLP se debe tener un background de conoci-
mientos en Programación Lógica.
De igual manera, la capacidad expresiva de la librer´ıa para Java llamada Choco es bastante
reducida, en contraste con la potencia de sus solvers internos as´ı como de sus algoritmos
propagadores.
En base a lo anterior, tenemos entonces que el código escogido para la ejecución de las
simulaciones fue SavileRow 1.6.3, el cual a su vez usa dos herramientas complementarias,
Minion 1.8 y Essence 1.6.3. Se ha escogido SavileRow por su capacidad expresiva a la
hora de construir las restricciones, por sus algoritmos de propagación debidamente validados
en sus publicaciones cient´ıficas y concursos y conferencias del problema de asignación de
horarios, as´ı como la versatilidad inherente a la hora de generar los resultados en distintos
formatos para distintos solvers de restricciones. Se describen las herramientas escogidas a
continuación:
SavileRow [74]: en su versión 1.6.3, es un asistente de modelado para programación
con restricciones. Provee un lenguaje de alto nivel que permite especificar las restriccio-
nes del problema que se quiera solventar, y luego traslada esa definición a un archivo de
entrada para un determinado solver. Durante el proceso de traducción, SavileRow apli-
ca procesos de reformulación al modelo usando técnicas de propagación de restricciones,
en conjunto con los valores asignados a las variables del modelo de restricciones, para
as´ı optimizar el modelo. El lenguaje usado para modelar el problema que luego será
pasado para ser optimizado por el núcleo de SavileRow (implementado en Java [79])
se conoce como Essence.
Minion [69]: en su versión 1.8, es un solucionador de restricciones basado en el modela-
do de las mismas usando modelos matriciales. En otras palabras, restringe la expresión
de las restricciones a ser aplicadas sobre el conjunto de datos a resolver a una estruc-
tura de matriz, ofreciendo poca versatilidad a la hora de modelar, esto con el fin de
optimizar los procesos de solución del problema. Esto contrasta con la mayor´ıa de los
56

restantes solucionadores de restricciones, que en la búsqueda de proporcionar más fle-
xibilidad a la hora del modelado, sacrifican el performance de las soluciones obtenidas,
tanto en calidad como en tiempo. El paper que presentó a Minion fue escogido entre
los 10 primeros de un total de 500 entregas durante la ECAI [50].
Essence [46]: en su versión 1.6.3, es un lenguaje formal (usado por SavileRow en
el presente problema) para la especificación de problemas combinatorios, usando una
mezcla de lenguaje natural y matemáticas discretas (lógica de primer orden, de pre-
dicados, matrices, etc). Provee un sistema de tipos para definir una amplia gama de
estructuras de datos, con el nivel de profundidad que requiera el problema a solucionar.
Está construido con la finalidad de ser accesible en uso a cualquiera que tenga cono-
cimientos básicos en matemáticas discretas, y no necesariamente de programación con
restricciones.
6.1.2. Casos de prueba
De la lista de casos del problema de asignación de horarios estudiados hasta el punto
actual, han sido escogidos dos instancias para la realización de las simulaciones, dado que
ambas engloban las principales caracter´ısticas a ser estudiadas del timetabling problem. Las
dos pertenecientes al contexto universitario, debido a que este brinda la mayor cantidad de
condiciones que aumentan la complejidad del problema, estas son:
Post-Enrolment Course Timetabling (PE-CCT): evalúa la distribución de las asigna-
turas en un conjunto de aulas y per´ıodos (intervalos de horas repartidos en los d´ıas de
la semana) una vez que ya se tiene definido el conjunto de estudiantes que cursará cada
asignatura [67]. Más formalmente, se manejan los siguientes elementos en esta instancia
del problema:
◦ Entidades:
◦ Eventos: cada evento requiere la asistencia de un conjunto de estudiantes as´ı
como de un salón con determinadas caracter´ısticas. Puede existir una pre-
cedencia obligatoria que obligue a que un evento ocurra primero en un d´ıa
57

antes que otro en espec´ıfico. De igual manera, también se define una condi-
ción de disponibilidad que establezca cuales timeslots están disponibles para
el evento.
◦ Salones: un salón posee un conjunto de caracter´ısticas, siendo la principal la
capacidad máxima de estudiantes que puede admitir.
◦ Timeslots: se tienen a disposición cierto conjunto de d´ıas (dentro de una
semana), cada uno dividido en determinados teaching timeslots (“ranuras de
tiempo para enseñanza”) los cuales tienen que ser asignados a los eventos.
◦ Restricciones obligatorias:
◦ Restricción H1 - Conflictos: eventos que posean estudiantes en común no
pueden compartir el mismo timeslot.
◦ Restricción H2 - Compatibilidad: un evento no puede ser alojado en un salón
que no posea las caracter´ısticas necesarias para el desarrollo del mismo, as´ı
como tampoco en un salón que no posea la capacidad m´ınima necesaria.
◦ Restricción H3 - Ocupación: No se permite el desarrollo de más de un evento
por salón al mismo tiempo.
◦ Restricción H4 - Disponibilidad: el timeslot asignado a un evento debe estar
disponible y no restringido para ese evento en espec´ıfico.
◦ Restricción H5 - Precedencias: respetar la precedencia entre eventos.
◦ Restricciones opcionales:
◦ Restricción S1 - Eventos Tard´ıos: evitar la asignación de eventos al final del
d´ıa.
◦ Restricción S2 - Eventos Consecutivos: evitar la asignación de eventos que
obliguen al estudiante a asistir a dos eventos consecutivos.
Curriculum-Based Course Timetabling (CB-CCT): plantea la asignación de horarios
agregando como elemento central del análisis el concepto de curr´ıculum. Este no es más
que la agrupación de un conjunto de asignaturas marcadas por varias caracter´ısticas en
común relacionadas mayoritariamente por la proximidad semestral. Existen distintas
58

variantes de este problema, siendo la presentada aqu´ı un compendio de los elementos
más resaltantes de [39], [72] y [65].
◦ Entidades:
◦ D´ıas, timeslots y per´ıodos: se especifica un conjunto de d´ıas a la semana,
y cada d´ıa es dividido en un conjunto de timeslots. Un per´ıodo viene a ser la
combinación d´ıa-timeslot. La cantidad total de per´ıodos disponibles vendr´ıa a
ser la unión generalizada de todos los productos cardinales entre cada d´ıa y
sus respectivos timeslots.
◦ Cursos y profesores: un curso es divido en clases para ser impartidas cada
una en un timeslot, siendo atendida por un conjunto de estudiantes, y dirigida
por un profesor. Hay timeslots para los cuales está restringido el desarrollo de
determinadas asignaturas.
◦ Salones: poseen una capacidad de carga máxima, y en principio son asigna-
bles a cualquier clase (aplicando luego la restricción de capacidad).
◦ Curr´ıculo: es un grupo de cursos tal que cualquier par de ellos posee es-
tudiantes en común. Es a partir de este elemento de donde se generan las
restricciones de este caso.
◦ Restricciones obligatorias:
◦ Restricción H6 - Ocupación de aula: no pueden haber par de clases compar-
tiendo la misma aula en el mismo per´ıodo.
◦ Restricción H7 - Conflictos: clases que pertenezcan a asignaturas del mismo
curr´ıculo deben tener entonces distintos per´ıodos asignados.
◦ Restricción H8 - Disponibilidad: si el profesor encargado de una asignatura
no está disponible para trabajar un determinado per´ıodo, entonces ninguna
clase de esa asignatura debe ser dictada en ese per´ıodo.
◦ Restricción H9 - Multiplicidad: solo se permite más de una clase de la misma
asignatura para aquellas especificadas en el conjunto de datos de entrada.
◦ Restricción H10: existen per´ıodos en los que no se está permitido dictar clases
de determinados cursos.
59

◦ Restricción H11: existen aulas en las que no está permitido dictar clases de
determinados cursos.
◦ Restricciones opcionales:
◦ Restricción S4 - No exceder la capacidad máxima de cada aula.
◦ Restricción S5 - Las clases de cada asignatura deben ser dictadas por encima
de una cantidad m´ınima de d´ıas, incluyente.
◦ Restricción S6 - Asignar de manera consecutiva las clases de asignaturas per-
tenecientes al mismo curr´ıculo.
◦ Restricción S7 - Todas las clases de una misma asignatura deben ser realizadas
en la misma aula.
En base a lo anterior, se construirán los casos de prueba, cada uno de ellos basados en los
formatos que se acaban de describir respectivamente, excluyendo determinadas restricciones.
As´ı mismo, se hará énfasis en describir los procesos relacionados al seccionamiento, creación
de eventos, y optimización de modelos para posterior asignación de individuos a actividades
y/o eventos. Todo esto descrito a continuación:
Caso de prueba 1: basado en el PE-CTT. Se excluyen la restricción S1 debido que
a la formulación de la misma conlleva el uso de expresiones matemáticas basadas en
sumatorias que no pueden ser desarrolladas de manera directa con el software escogido.
Las entidades y/o variables, relaciones y restricciones a tomar en cuenta son los siguien-
tes:
◦ Entidades:
◦ Eventos: E = {ei/ei es un evento} , |E| > 0
Cada evento posee un identificador único y un conjunto de atributos de valores
booleanos
ai =< id, < attr1, attr2, ..., attrn >>, n > 0
La semántica de cada atributo attrj es la siguiente: si attrj == V erdadero,
significa que es necesario que el aula en donde se quiera llevar a cabo el evento
60

ei debe cumplir con ese requerimiento. Si es Falso, indica que no es necesario
que el aula cumpla con tal requisito.
Cada evento posee la misma cantidad de atributos booleanos, y variará entre
ellos el valor de verdad de cada uno.
◦ Aulas: A = {ai/ai es un aula} , |A| > 0
Cada aula posee un identificador único y un conjunto de atributos de valores
booleanos
ai =< id, < attr1, attr2, ..., attrn >>, n > 0
La semántica de cada atributo attrj es la siguiente: attrj == V erdadero indica
que el aula ai cumple con poseer el atributo mencionado. En caso contrario,
si es Falso, quiere decir que no lo posee.
Cada aula posee la misma cantidad de atributos booleanos, y variará entre
ellas el valor de verdad de cada uno.
◦ Estudiantes: S = {si/si es un estudiante} , |S| > 0
Cada estudiante posee un identificador único asociado, y la lista de eventos
en los que definitivamente va a participar.
si =< id, < e1, e2, ..., em >>, m ≤ |E|
Donde ej es un identificador de uno de los eventos.
◦ per´ıodos: P = {pi/pi es un periodo} , |P| > 0
Un per´ıodo es la combinación de un timeslot con un d´ıa.
pi = (d, t)
d ∈ D = {di/di es un dia de la semana} , 1 ≤ |D| ≤ 7
t ∈ T = {ti/ti es un timeslot} , |T| > 0
ti = (hx, hy), donde hx y hy son horas y hx < hy.
Entonces, P ⊆ D × T.
◦ Restricciones:
◦ H1: Sea E el conjunto de eventos,
E = {(x, y)/x, y ∈ E ∧ x = y ∧ x[periodo] = y[periodo]}, y sea Zv el conjunto
de estudiantes que asisten al evento v ∈ E, para cada (x, y) ∈ E minimizar
61

Modelo costos horarios

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Modelo costos horarios

Similar to Modelo costos horarios (20)

Modelo costos horarios