Carlos Eduardo Correia de Passos
Nº 44574Elaboração de Horários Académicos
Dissertação de Mestrado Integrado em Engenharia Informática
2º Semestre, 2015/2016
Orientador: Pedro Barahona, Professor Doutor, UNL
© Copyright
Carlos Eduardo Correia de Passos
ii
Agradecimentos
Todo o trabalho desenvolvido não seria possível sem a orientação, apoio e ajuda de várias pessoas. Desde já expresso toda a minha gratidão.
Gostaria de começar por enaltecer, reconhecer e agradecer toda a sábia orientação e ajuda que o Professor Doutor Pedro Barahora nunca deixou de humildemente me proporcionar. Terá para sempre o meu reconhecimento.
Não podia deixar de citar os meus verdadeiros pilares em todo o desenrolar do trabalho. A minha esposa, Vera, que sempre me apoiou e nos momentos cruciais se sacrificou ao acarretar todas as responsabilidades familiares, à minha filha, Joana, que soube sempre mostrar um sorriso quando eu precisava, aos meus pais e ao meu irmão que mesmo longe estiveram sempre perto de mim.
iv
Resumo
A geração de horários é uma tarefa de dificuldade elevada e requer trabalho árduo devido à necessidade de gerir os diversos conflitos de restrições impostos aos recursos a ser usados, mais concretamente alunos, professores e salas.
A grande variedade de restrições associada às diferentes necessidades de diferentes sistemas de ensino e até mesmo entre escolas do mesmo nível, tem dificultado a elaboração de formatos standard que permitam não só caracterizar as próprias restrições/regras mas também os recursos de grandes variedades de sistemas de ensino, possibilitando a comparação de práticas e avaliação de desempenho assim como proporcionar uma estrutura capaz de ser manipulada por sistemas com capacidade de gerar horários.
Esta dissertação aborda o problema da elaboração de horários académicos, focando-se no caso da Academia da Força Aérea (AFA). São apresentados vários exemplos de sistemas de ensino e um formato de especificação em XML para benchmarking de horários académicos, no qual são especificadas as restrições impostas aos horários da Academia da Força Aérea. Várias técnicas de pesquisa local restringida que são tradicionalmente usadas para resolver este tipo de problemas, nomeadamente as técnicas de Hill-Climbing (HC), Simulated Annealing (SA) e Tabu Search (TS), são discutidas e são exploradas para resolver o problema da geração de horários na AFA.
Este trabalho avalia esta abordagem e foi elaborada uma ferramenta para resolução de horários académicos, que para além de validar a completude de informação fornecida na representação XML (e estendê-la), permite obter soluções que satisfazem um conjunto de restrições obrigatórias (como a não sobreposição de recursos) e otimizam um conjunto de preferências adicionais (boas práticas pedagógicas, como a não existência de furos). A eficiência da ferramenta é estudada por comparação com ferramentas que já utilizam a representação XML referida.
vi
Abstract
Timetabling generation is a task of high difficulty requiring hard work given the need to manage several conflicting constraints on resources to be used, namely students, teachers and classrooms.
The wide variety of restrictions associated with the different needs of different educational systems and even between schools of the same level, has hindered the development of standard formats that not only fully characterize restrictions/rules but also the resources of different education systems, enabling the comparison of practices and performance evaluation as well as providing a structure capable of being manipulated by systems capable of generating schedules.
This dissertation addresses the problem of academic timetabling generation, focusing on the case of the Air Force Academy (AFA). It presents several examples of school systems and an XML specification format for benchmarking of academic schedules, in which the schedules restrictions in Air Force Academy are specified. Several constrained local search techniques that have been traditionally used to solve this type of problems, namely Hill-climbing (HC), Simulated Annealing (SA) and Tabu search (TS), are discussed and are explored to solve the timetabling problem in AFA.
This work evaluate this approach and a tool was elaborated for implementing academic schedules, which in addition to validating the completeness of information provided in the XML representation (and extending it), allows for seeking solutions that satisfy a set of mandatory restrictions (such as no overlap of resources) and optimize a set of additional preferences (good teaching practices, such as the lack of idle times). The efficiency of the tool is studied by comparison with tools that already use the referred XML representation.
vii
Índice
1 Introdução ... 1
1.1 Contexto e Motivação ... 1
1.2 Descrição do Problema... 1
1.3 Solução do Problema e Contribuições ... 2
1.3.1 Solução do Problema ... 2
1.3.2 Contribuições ... 2
2 Trabalho Relacionado ... 3
2.1 Problema de Horários Académicos ... 3
2.1.1 Austrália ... 4
2.1.2 Reino Unido ... 5
2.1.3 Finlândia ... 5
2.1.4 Grécia ... 6
2.1.5 Holanda ... 7
2.1.6 Horários na AFA/FAP ... 7
2.2 Formato para benchmarking... 8
2.2.1 Tempos letivos e recursos ... 9
2.2.2 Eventos ... 9
2.2.3 Regras ... 10
2.2.4 Formato XML ... 12
2.3 Pesquisa Local ... 14
2.3.1 Hill-Climbing ... 17
2.3.1.1 Late Acceptance Hill-Climbing ... 18
viii
2.3.2 Simulated Annealing ... 19
2.3.3 Tabu Search ... 20
2.3.4 Outros ... 21
3 TimeTabling ... 22
3.1 Implementação MVC ... 23
3.1.1 Controller... 24
3.1.2 Model... 25
3.1.3 View ... 27
3.2 Plano do trabalho ... 34
3.3 Implementação da Pesquisa Local ... 34
3.3.1 Random-restart hill-climbing ... 34
3.3.2 Late Acceptance Hill-Climbing... 35
3.3.3 Step Counting Hill-Climbing ... 36
3.3.4 Simulated Annealing ... 36
3.3.5 Tabu Search ... 37
3.4 Material utilizado ... 37
4 Resultados Experimentais ... 38
4.1 Baseadas em horários existentes ... 39
4.1.1 Alteração da tarde livre para outro dia ... 40
4.1.2 Indisponibilidade de dois professores para um dia ... 41
4.1.3 Indisponibilidade de uma sala toda a semana ... 41
4.2 Através de geração aleatória de horários ... 42
4.2.1 Horários para a AFA ... 42
4.2.2 Horários para benchmark de escola da Grécia ... 43
5 Conclusões ... 45
ix
Webliografia ... 49
A. Apêndice ... 51
Exemplo de um formato XML para horários académicos da AFA... 52
Exemplo num formato XML de restrições aos horários académicos da AFA ... 56
Resultados experimentais baseados no horário da AFA com a alteração da tarde livre para outro dia ... 61
Resultados experimentais baseados no horário da AFA com a indisponibilidade de dois professores ... 63
x
Ilustrações
Ilustração 1: Algoritmo de Pesquisa Local ... 15
Ilustração 2: Exemplo de Plateaus em Pesquisa Local ... 16
Ilustração 3: Modelo MVC ... 23
Ilustração 4: Código do TimeTabling ... 24
Ilustração 5: Entrada no sistema ... 28
Ilustração 6: Ecrã inicial do sistema ... 28
Ilustração 7: Upload de ficheiros ... 29
Ilustração 8: Seleção de ficheiros ... 29
Ilustração 9: Criação de ficheiros ... 29
Ilustração 10: Detalhe da instância ... 30
Ilustração 11: Continuação do detalhe da instância ... 31
Ilustração 12: Detalhe da solução ... 31
Ilustração 13: Horário ... 32
Ilustração 14: Gráficos ... 33
Ilustração 15: Geração automática ... 33
Ilustração 16: Resultados experimentais com a técnica Random-restart hill-climbing ... 39
Ilustração 17: Média dos resultados experimentais da alteração da tarde livre ... 40
Ilustração 18: Média dos resultados experimentais com a indisponibilidade de dois professores ... 41
Ilustração 19: Média dos resultados experimentais com a indisponibilidade de uma sala . 41 Ilustração 20: Média dos resultados experimentais da geração aleatória de horários para a AFA ... 42
xi
Tabelas
1
1
Introdução
Todos os estabelecimentos de ensino se deparam no início de cada momento académico com a necessidade de criar horários académicos.
A criação de um horário académico é uma tarefa de difícil execução, implica a gestão de restrições entre alunos, professores e salas em determinados tempos letivos, e que deve ser suportada por sistemas de informação evoluídos.
A conjugação de sistemas capazes de gerir informação académica e técnicas de pesquisa e otimização eficientes, pode permitir a geração semiautomática de horários académicos com um desempenho que na grande maioria das vezes não seria capaz de ser atingido com um tratamento tradicional, essencialmente manual.
1.1
Contexto e Motivação
A Força Aérea Portuguesa (FAP) tem na Direção de Comunicações e Sistemas de Informação (DCSI), entre várias outras, a missão de desenvolver sistemas de informação. Um dos sistemas desenvolvidos é o sistema de gestão escolar (SGE) da Academia da Força Aérea (AFA). O SGE engloba tarefas inerentes à formação académica e gestão dos seus recursos.
Embora se tenha atingido um grau de maturidade elevado do sistema, este ainda tem capacidade para evoluir, e a motivação desta dissertação prendeu-se com uma necessidade sentida na FAP de geração automática dos horários académicos. Com o colmatar desta necessidade vai ser possível de uma maneira célere e eficiente a criação de variados horários académicos, evitando-se perdas de tempo nesta tarefa e assim poder disponibilizar recursos humanos a outro tipo de tarefas.
1.2
Descrição do Problema
2
O objetivo é portanto colmatar a geração manual de horários académicos com a geração automática dos mesmos. A este problema acresce a necessidade de na geração automática saber gerir as restrições/regras impostas aos próprios recursos e tempos letivos e satisfazer variadas preferências de diferentes graus.
A automatização de procedimentos é concretizada utilizando técnicas eficientes, a resolução do atual problema passa por técnicas que proporcionam resultados eficientes e céleres, mas também otimizados.
1.3
Solução do Problema e Contribuições
1.3.1 Solução do Problema
A solução do problema passou pela implementação de um sistema para geração de horários académicos. Nesta implementação foi utilizada informação num formato em XML para benchmarking de horários académicos. A informação referente às turmas, aulas e tempos letivos é proveniente da estrutura de dados do sistema da Força Aérea, a restante informação foi gerada de modo a salvaguardar informação sensível. Esta informação caracteriza todos os recursos e foram adicionadas um conjunto de restrições obrigatórias e outras preferências.
1.3.2 Contribuições
3
2
Trabalho Relacionado
Neste capítulo resume-se alguma bibliografia pesquisada no contexto da preparação da dissertação, focada em 3 áreas distintas para o desenvolvimento da dissertação:
1. Especificidade de horários em vários contextos, 2. Benchmarking em horários académicos,
3. Pesquisa local.
Nem toda a bibliografia pesquisada está diretamente relacionada com o desenvolvimento do trabalho em si, mas pretende dar um contributo para a compreensão e estruturação das ideias sobre o mesmo.
No subcapítulo 2.1 é abordado o problema dos horários académicos. Esta abordagem é iniciada através da explicação do conceito de benchmarking assim como a sua importância no desenvolvimento da dissertação. Mais concretamente através da análise de um documento sobre a formatação/definição de horários académicos, focando-se essencialmente nas diferentes restrições à geração de horários em diferentes países e também as utilizadas na especificação de horários na Academia da Força Aérea Portuguesa (AFA/FAP). Seguidamente no subcapítulo 2.2 é introduzido o formato XML para benchmarking referindo os tempos letivos, alunos, professores, salas, eventos e regras, sendo este demonstrado com um exemplo concreto. Finalmente no subcapítulo 2.3 são revistos os conceitos de pesquisa local restringida assim como algumas técnicas específicas, (por exemplo Hill-Climbing, Simulated Annealing e Tabu Search), sendo abordados alguns trabalhos sobre geração automática de horários que as utilizam.
2.1
Problema de Horários Académicos
Com alguma frequência se fala no meio académico e também empresarial no conceito de benchmarking. Este termo é definido em (da Silva, 2010) como a comparação de práticas e avaliação de desempenho de uma empresa em relação às outras. Visa também identificar padrões de boas práticas para aplicar nas avaliações e melhorar os desempenhos.
4
combatendo a falta de estudos de benchmarks e formatos de dados sobre a temática dos horários académicos. A razão desta falta de informação advém da variedade de restrições e preferências dos ensinos, quer entre países diferentes ou até dentro do mesmo, quer entre diferentes sistemas de ensino, o que constitui um problema central na generalização de soluções para a elaboração de horários académicos.
A publicação referida em (Post, et al., 2012) foi desenvolvida no âmbito desse projeto e demonstra a necessidade de definição de um formato standard para benchmarking em horários académicos.
Este formato foi definido em eXtensible Markup Language (XML). O XML foi criado pela World Wide Web Consortium (W3C) e é um formato que permite organizar a informação hierarquicamente, delimitada por meta-informação e que pode ser entendida por utilizadores e por sistemas de informação (World Wide Web Consortium (W3C), 2013).
A geração de horários tem como principais orientações a organização da escola e a gestão de alunos, professores e salas. A natureza cultural, social e até mesmo a orientação política e económica de diferentes países influencia as regras e os objetivos na geração de horários. O projeto anteriormente mencionado, e que serve de guia de orientação desta dissertação, descreve essas mesmas regras e objetivos em diferentes países com a finalidade de alcançar requisitos comuns, e que tornem possível a criação do formato para benchmarking em horários académicos.
Para atingir os objetivos desta dissertação são descritos vários problemas na geração de horários por diferentes países, contemplando os seus requisitos e as diferenças entre eles, fornecendo assim informações credíveis para a compreensão e apoio na resolução do objetivo proposto. O enfoque do trabalho antes referido é relativo a escolas secundárias, mas as condicionantes gerais são semelhantes em instituições de ensino superior.
2.1.1 Austrália
5 As escolas privadas têm menos alunos e uma vasta escolha de unidades curriculares, tendo os professores mais tempo livre de aulas e as escolas mais salas especiais.
Objectivos e dificuldades na geração de horários académicos:
Objectivo das escolas publicas é minimizar a partilha de alguns cursos por dois professores;
Objectivo das escolas privadas é minimizar as aulas conjuntas com alunos de anos lectivos diferentes mas com o mesmo professor;
Outra dificuldade tem a ver com a distribuição das aulas das unidades curriculares pelos cinco dias, devido a unidades curriculares escolhidas por alunos com número de aulas diferentes.
2.1.2 Reino Unido
A referência bibliográfica (University of Twente, 2009d) refere que se nos primeiros anos letivos das escolas do Reino Unido não há unidades curriculares optativas, (são todas obrigatórias), já nos restantes anos letivos são poucas as unidades curriculares obrigatórias.
As escolas dividem os alunos por grupos. Em algumas escolas, e devido à política escolar das mesmas, a cada grupo é atribuído um tutor, um professor com responsabilidades organizacionais e de encaminhamento. Em outras escolas é efetuado um agrupamento de outros grupos de alunos tutorados e as unidades curriculares são agrupadas em blocos de uma ou mais unidades curriculares de diferentes grupos de alunos e são organizadas num horário ao mesmo tempo.
Dificuldades na geração de horários académicos:
Os alunos têm os horários sem tempos livres, exceto nos últimos anos escolares;
Grande variedade de diferentes tempos de aulas;
Um ou dois ciclos semanais de horários;
Diferentes tempos letivos diários, e correspondente número de unidades curriculares, em diferentes escolas.
2.1.3 Finlândia
6
determinado grupo de alunos (turma) e pode pertencer a outros grupos adicionais apenas relacionados com unidades curriculares opcionais.
Dificuldades na geração de horários académicos:
Os horários académicos finlandeses têm a particularidade de serem formados não por um conjunto de unidades curriculares, mas por um conjunto de aulas das unidades curriculares (lições);
As lições são dadas a apenas um grupo de alunos, quer a unidade curricular seja obrigatória ou opcional;
Só nos últimos anos letivos é que os professores são atribuídos a lições e a maioria das salas são reservadas consoante as decisões dos respetivos professores;
Normalmente os anos letivos têm 10 unidades curriculares com uma carga horária entre duas a seis horas semanais, e as aulas podem durar entre uma e três horas;
Os alunos têm os horários sem tempos livres. 2.1.4 Grécia
É descrito em (University of Twente, 2009f) que as aulas nas escolas gregas funcionam nos cinco dias da semana, têm entre 6 a 7 horas de aulas por dia, são pré-atribuídas aos professores, as aulas das unidades curriculares essenciais são distribuídas uniformemente pelos dias da semana e os alunos têm os horários sem tempos livres.
As dificuldades na geração de horários académicos derivam essêncialmente das diferenças entre os primeiros e os últimos anos letivos, isto é:
Primeiros anos letivos
Os grupos base de alunos mantêm-se por um determinado período do dia, para assim terem as aulas transversais aos cursos. Nos restantes momentos do dia os grupos de alunos são reorganizados de modo a frequentarem as aulas mais específicas, relativas às especializações escolhidas pelos alunos;
É muito difícil organizar as unidades curriculares essenciais nas primeiras horas do dia;
Também é muito difícil minimizar os tempos livres dos professores. Últimos anos letivos
7
Num período de tempo de aulas os grupos de alunos são divididos ou organizados com outros grupos de alunos para terem aulas de determinadas unidades curriculares. Nestas situações é normal haver dois professores, (ou em simultâneo ou para cada grupo de alunos divididos);
As unidades curriculares essenciais devem ser nas primeiras horas do dia;
Deve-se minimizar os tempos livres de aulas dos professores. 2.1.5 Holanda
Segundo (University of Twente, 2009g) nas escolas holandesas os professores são distribuídos por anos letivos. Nos primeiros anos os grupos de alunos têm as mesmas unidades curriculares, mas nos últimos os alunos têm unidades curriculares obrigatórias e opcionais consoante as especializações escolhidas.
Dificuldades na geração de horários académicos:
Os horários são construídos para uma semana e são repetidos por seis semanas, um trimestre, semestre ou por todo o ano;
Os alunos têm os horários sem tempos livres, exceto nos últimos anos escolares;
Deve-se minimizar os tempos livres de aulas dos professores;
Os professores são atribuídos a lições, por exemplo um professor para dar aulas teóricas e outro para aulas práticas.
O projeto referido em (University of Twente, 2009b) também teve o contributo dos problemas na geração de horários de países como Brasil, Dinamarca, Espanha, Itália, Kosovo e África do Sul, mas a grande diversidade dos problemas já está suficientemente ilustrada nos exemplos anteriores.
2.1.6 Horários na AFA/FAP
8
Em função de informação informal obtida através do Gabinete de Estudos e Planeamento (GEP) da AFA foi possivel identificar as principais dificuldades na geração de horários académicos, comparando-as com os exemplos anteriores:
Os alunos têm os horários sem tempos livres entre aulas. Esta restrição é verificada em quase todos os primeiros anos letivos dos exemplos referidos anteriormente;
Grande variedade de diferentes tempos de aulas, como acontece nas escolas do Reino Unido;
Uma tarde por semana sem aulas, dedicada apenas a estudo e investigação, mais precisamente às quartas-feiras à tarde, ponto este que tem alguma semelhança com o ensino público australiano;
Não há aulas às sextas-feiras à tarde. Como o anterior, este ponto tem alguma semelhança com o ensino publico australiano.
As aulas de treino físico devem ser dadas nas últimas horas das manhãs ou tardes e devem ser distribuídas uniformemente pelos dias da semana, semelhante ao ensino na Grécia;
As aulas de carácter militar devem ser dadas numa manhã específica da semana;
Num período de tempo de aulas os grupos de alunos são divididos ou organizados com outros grupos de alunos para terem aulas de determinadas unidades curriculares. No caso de divisão, tem de haver mais que um professor para essas unidades curriculares, mas em caso de junção um professor dará a aula a mais que um grupo de alunos ao mesmo tempo;
Os professores são atribuídos a lições.
Em termos gerais pode-se afirmar que o tipo de restrições entre os horários académicos da AFA é bastante semelhante ao das escolas gregas.
2.2
Formato para benchmarking
A análise da informação obtida sobre as várias dificuldades e requisitos dos horários académicos dos diferentes países permitiu a criação do formato em XML para benchmarking em horários académicos.
9 2.2.1 Tempos letivos e recursos
Segundo (University of Twente, 2009b) os tempos letivos são aulas. Os grupos de tempos podem referir-se a tempos letivos por dia ou por semana e são frequentemente referidos nas validações das regras para a definição de um horário académico.
A criação de um horário académico útil não é possível só com tempos letivos, mas a associação de recursos a esses tempos já possibilita essa criação. Os recursos são as entidades aos quais são impostas regras. Neste contexto, são definidos como recursos os alunos, os professores e as salas de aulas.
Os alunos ou grupos de alunos (ou até mesmo turmas) estão sujeitos as regras como ter ou não tempos livres entre aulas, número de aulas por dia e outras;
Os professores podem estar afetos a unidades curriculares ou ser apenas especificado que as suas qualificações possibilitam lecionar aulas de algumas unidades curriculares. Esta informação é relevante para a implementação de regras como número de tempos livres, aulas por dia e até mesmo dias sem aulas;
As salas de aulas têm especial relevância nos casos das salas especiais, por exemplo os laboratórios, ginásios, etc.
2.2.2 Eventos
A mesma referência bibliográfica especifica que os eventos são as aulas ou lições e atribuição de recursos a tempos letivos, tendo em conta as situações em que os professores não são pré-atribuídos às unidades curriculares. Neste caso após a escolha de um professor para a primeira aula de uma unidade curricular a um grupo de alunos, este deve manter-se nas restantes aulas da mesma unidade curricular e do mesmo grupo de alunos.
No formato XML, estão definidos eventos com as seguintes propriedades:
A duração do evento;
A unidade curricular relativa ao evento;
O tempo letivo (hora de inicio) em que o evento está agendado;
A carga horária do evento;
O grupo de alunos do evento;
O professor associado ao evento;
10
2.2.3 Regras
As regras são definidas em (University of Twente, 2013h) como as condições existentes que podem ser utilizadas para restringir os horários académicos e no fim têm de estar satisfeitas no resultado obtido, isto é, no próprio horário.
As regras existentes são:
AssignResourceConstraint – associa recursos a eventos;
AssignTimeConstraint – associa tempos letivos a eventos;
SplitEventsConstraint – limita o número de eventos de uma unidade curricular e as suas durações;
DistributeSplitEventsConstraint – limita o número de eventos de uma certa duração de uma unidade curricular;
PreferResourcesConstraint – especifica quais os recursos preferenciais de eventos;
PreferTimesConstraint – especifica que alguns tempos letivos têm preferência na associação a eventos;
AvoidSplitAssignmentsConstraint – obriga que os recursos estejam afetos a todos os eventos de uma unidade curricular, é o exemplo típico de um professor que dá todas as aulas de uma unidade curricular de um curso;
SpreadEventsConstraint – especifica quais os eventos que devem ser distribuídos nos tempos letivos;
LinkEventsConstraint – especifica que determinados eventos devem ser agendados ao mesmo tempo;
OrderEventsConstraint – especifica que um evento só começa após um outro determinado evento terminar;
AvoidClashesConstraint – esta é uma das regras com mais importância, evita conflitos de recursos;
AvoidUnavailableTimesConstraint – especifica que alguns recursos estão indisponíveis para eventos a determinados tempos letivos;
LimitIdleTimesConstraint – limita o número de tempos letivos que um recurso está livre;
11
LimitBusyTimesConstraint – limita o número de tempos letivos que um recurso está associado;
LimitWorkloadConstraint – limita a carga horária total de certos recursos.
Todas as regras têm uma característica que influência o cálculo do custo da violação da mesma, nomeadamente o desvio (deviation). Nem todas as regras calculam o desvio segundo a mesma premissa. Normalmente é considerado como desvio a duração da aula.
Existem propriedades comuns a todas as regras, que têm como objetivo identificar inequivocamente a regra e catalogar o peso da mesma para permitir que seja calculado o custo inerente.
As propriedades comuns existentes são:
Id – serve para identificar inequivocamente a regra, permitindo assim que a mesma seja referenciada;
Name – serve para identificar a regra em modo visual, isto é, serve para os utilizadores poderem identificar a regra num modo legível;
Required – propriedade booleana que determina se a regra é uma restrição obrigatória ou não;
Weight – peso dado à regra, inteiro de 1 a 1000 inclusive;
CostFunction – função para o custo da regra que é aplicada ao respetivo valor do desvio. Há 3 funções possíveis para a propriedade CostFunction:
o Linear – o valor da função é o valor do desvio;
o Quadratic – o valor da função é o quadrado do desvio;
o Step – o valor da função é 0 ou 1 se o desvio for diferente de 0;
AppliesTo – limita os eventos e/ou recursos sobre os quais a regra é aplicada. Caso a regra seja definida como uma restrição obrigatória, isto é Required = True, é atribuído ao respetivo custo um valor muito elevado, caso contrário o custo da regra é calculado através da fórmula:
Cost = Weight * CostFunction(deviation)
12
departamentos académicos que reúnem unidades curriculares assim como professores pode dar origem a novas regras.
Estão exemplificadas algumas regras (restrições) no A.2.
2.2.4 Formato XML
A Universidade de Twente divulgou em (University of Twente, 2013h) o formato XML, que tal como referido anteriormente este formato contem toda a informação necessária para a interpretação de horários académicos, mais precisamente informação relativa a tempos letivos, alunos, professores, salas, eventos e regras.
A informação está organizada segundo a hierarquia da informação, e para criar tal organização foi definida uma estrutura da qual o formato tem de obedecer.
O formato está definido do seguinte modo:
Archives – coleção de instâncias de horários académicos, mais concretamente um archive é o aglutinador de todos os horários académicos definidos num mesmo ficheiro XML;
Instances – é uma ocorrência de um horário académico num determinado tempo escolar, isto é, um horário académico dum ano/semestre/trimestre. As instances estão contidas num archive;
Times – definem os dias de semana aplicáveis aos horários, as semanas que incluem os respetivos dias, e outros tipos de tempos que podem, por exemplo, conter TimeGroups para uma melhor organização. Um caso concreto é a definição de manhãs ou tardes como TimeGroups. Os Times estão contidos nas Instances;
Resources – declaram as entidades aos quais são impostas regras, mais concretamente os alunos, os professores e as salas de aulas, e estão contidos nas Instances;
Resources Groups – são coleções de recursos, (dentro de Resources), que referenciem tipos de recursos com regras específicas;
Events – como referido anteriormente são as aulas ou lições às quais é necessário atribuir Resouces em determinados Times e também estão contidos nas Instances;
13
Solution Groups – são coleções de soluções, isto é, são concretamente o aglutinador de todas as soluções geradas para os horários académicos definidas num mesmo ficheiro XML, as Solution Groups estão contidas num archive;
Solutions – são as soluções para um respetivo horário, as Solutions estão contidas no Solution Groups;
Reports – é toda a informação obtida após a geração do horário, estão contidas em Solution e entre outras informações retêm o custo da geração do horário assim como as regras violadas.
De seguida é apresentado um breve extrato XML retirado do apêndice A.1: <HighSchoolTimetableArchive> <Instances> <Instance Id="3"> <Times> <TimeGroups> <Day Id="2"> <Name>Segunda</Name> <TimeGroup Id="Mornings"> <Name>Manhãs</Name> <Resources> <ResourceTypes> <ResourceType Id="Teacher"> <ResourceGroups>
<ResourceGroup Id=" AllTeachers"> <Resource Id="1T0016866">
<Name>MANUEL M. DE</Name> <ResourceType Reference="Teacher"/> <ResourceGroups> <ResourceGroup Reference="AllTeachers"/> <Events> <EventGroups> <Course Id="11101">
<Name>Mestrado em Aeronáutica Militar, Especialidade de Piloto Aviador</Name> <Event Id="19">
<Name>OTOPCM</Name> <Duration>1</Duration>
14
<Resources>
<Resource Reference="PILAV_1"> <Role>Class</Role>
<ResourceType Reference="Class"/> <SolutionGroups>
<SolutionGroup Id="AFA_2014-01-24"> <Solution Reference="3"> <Events>
<Event Reference="TEACH_1_PILAV_1_1"> <Duration>1</Duration>
<Time Reference="21" /> </Event>
<Time Reference="Monday_1" />
A informação existente no formato XML é passível de ser usada para geração de novos horários académicos, mais concretamente através de técnicas de pesquisa local.
2.3
Pesquisa Local
Em (Gaspero, 2003), a pesquisa local é referida como pertencente à família de técnicas usadas em problemas de pesquisa e otimização (Brailsford, Potts, & Smith, 1999), isto é, dado um conjunto de variáveis, um conjunto finito de valores possíveis para essas variáveis e uma lista de restrições, descobrir valores para as variáveis que satisfaçam as restrições.
A pesquisa local é um método para encontrar soluções para problemas de otimização sujeita a restrições, que se baseia na melhoria iterativa dos valores atribuídos às variáveis até todas as regras (restrições) estarem salvaguardadas (ou pelo menos as regras obrigatórias) e a função objetivo esteja (quase) otimizada, com o custo zero ou pelo menos reduzido. A pesquisa local pode assim ser considerada como um método de pesquisa que começa num estado inicial, obtido através de uma escolha de dados aleatória (ou heuristicamente por semelhança com casos anteriores) e que em cada iteração é melhorado através de pequenas modificações (Rossi, Beek, & Walsh, 2006).
15 function Local Search (Search Space S, Neighborhood N, Cost Function F) begin
s0 := InitialSolution(S);
i := 0;
while (¬StopCriterion(si,i)) do begin
m := SelectMove(si,F,N); if (AcceptableMove(m,si,F)) then swap(m,si );
i := i + 1 end
end return si;
Ilustração 1: Algoritmo de Pesquisa Local
A Ilustração 1, baseada no algoritmo de pesquisa local existente em (Gaspero, 2003), apresenta um algoritmo abstrato de pesquisa local. Nesta função estão referidos os parâmetros de entrada “Search Space”, “Neighborhood” e “Cost Function”.
Search Space – refere o espaço de estados que podem ser gerados ou melhorados durante a pesquisa. A solução final, (no caso dos horários, os tempos letivos atribuídos às aulas), retornada pela função é o estado final obtido na pesquisa;
Neighborhood (Vizinhança) – é o conjunto de estados para o qual um determinado estado pode transitar, (normalmente por alteração do valor de uma ou mais variáveis). No caso dos horários pode representar alterações aos recursos atribuídos às aulas (alunos, professores, salas) e os tempos letivos em que as aulas são lecionadas;
Cost Function – é a função que calcula os custos de cada estado, baseado nas restrições violadas e no objetivo a atingir.
O algoritmo tende a melhorar ao longo do processamento a qualidade das soluções exploradas, obtidas por avaliação do grau de satisfação das restrições e no final do processamento devolve o último estado obtido.
16
satisfaz o critério de paragem. A escolha dos valores que irão alterar as variáveis é baseada nos custos das alterações induzidas nos estados obtidos.
As funções abstratas utilizadas no processamento descrito anteriormente são materializadas dependendo das técnicas e algoritmos utilizados.
Várias são as técnicas que implementam a pesquisa local e que têm como objetivo atingir uma solução que salvaguarda as regras impostas mas com o menor custo possível.
Há dois tipos extremos de técnicas para alcançar este objetivo durante o ciclo iterativo. No primeiro, as alterações dos valores das variáveis tentam sempre diminuir ou pelo menos não aumentar o custo dos estados seguintes (técnicas Greedy). O segundo, utiliza métodos aleatórios para alteração das variáveis (técnicas Random), (Rossi, Beek, & Walsh, 2006). A razão destes dois tipos prende-se com uma lacuna das técnicas Greedy, que não conseguem obter melhores vizinhos quando o estado atingido é um mínimo local ou uma superfície plana (Plateau). As técnicas Random permitem ultrapassar este problema efetuando movimentos aleatórios.
Ilustração 2: Exemplo de Plateaus em Pesquisa Local
A Ilustração 2 exemplifica um problema de minimização em que no espaço de estados existe um Plateau que inclui o estado A e em que o processo não consegue prosseguir até ao estado B apenas com técnicas Greedy.
Os algoritmos de pesquisa local utilizam geralmente heurísticas a curto prazo para melhorar (ou não piorar) o estado corrente, (técnicas Greedy), e mais raramente aceitam piores estados, (técnicas Random). Tipicamente são utilizadas meta-heurísticas que permitem aceitar estados piores para melhorar a longo prazo as soluções obtidas.
17 dissertação por se tratarem de técnicas baseadas em populações e que utilizam métodos bastantes distintos.
2.3.1 Hill-Climbing
Hill-Climbing é uma das técnicas mais simples de pesquisa local que tenta otimizar a função objetivo, (em geral, nesta dissertação a técnica Hill-Climbing foi adaptada para minimizar a função objetivo). Como a generalidade de algoritmos de pesquisa local, este algoritmo não mantém em memória uma árvore de pesquisa, guardando apenas o estado (ou nó) corrente, (Russell & Norvig, 1995).
O Hill-Climbing é uma técnica que devolve em cada iteração um estado com melhor valor (menor custo) na vizinhança do estado corrente.
Durante a pesquisa local com a técnica de Hill-Climbing há duas situações que devem ser referidas:
Local minima (Mínimo local) – um mínimo local é um estado com custo mais baixo que os seus vizinhos, mas possivelmente mais alto que outros estados, nomeadamente a um mínimo global. Sempre que o algoritmo atinja um tal estado ele já não atingirá o mínimo global, mesmo que o algoritmo ainda não tenha atingido um resultado satisfatório;
Plateaux (Planaltos) – tal como referido anteriormente, esta situação acontece quando os vizinhos do estado corrente têm um valor semelhante.
Caso alguma destas situações seja atingida, então a melhor solução adaptada é geralmente reiniciar o processamento a partir de outro estado inicial. Random-restart hill-climbing (RRHC) é uma variante de Hill-Climbing que adota exatamente esta solução, podendo-se definir o número de iterações a utilizar. Random-restart hill-climbing implementa uma meta-heurística aleatória.
18
modo a solução inicial não ser sempre a mesma e no caso dos planaltos o critério de paragem utilizar uma constante com o número máximo de iterações.
É conhecida a utilização de outras variantes do Hill-Climbing em trabalhos sobre geração automática de horários, mais concretamente as variantes Late Acceptance Hill-Climbing (LAHC) e Step Counting Hill-Climbing (SCHC). Estas variantes previnem os mínimos locais e os planaltos.
2.3.1.1 Late Acceptance Hill-Climbing
Esta variante de Hill-Climbing é explicada em (Bykov & Burke, A Late Acceptance Strategy in Hill-Climbing for Exam Timetabling Problems, 2008) como tendo a particularidade de implementar uma heurística quase Greedy, com a diferença de aceitar um vizinho melhor que um dos estados (ou nós) visitados em K ciclos anteriores.
Na mesma referência bibliográfica, os criadores de Late Acceptance Hill-Climbing, (Yuri Bykov e Edmund K. Burke), demonstram a eficiência do algoritmo aplicando-o na geração automática de horários para exames e comparam os resultados obtidos entre esta técnica e o tradicional Hill-Climbing.
Para implementar Late Acceptance Hill-Climbing no exemplo presente na Ilustração 1, a função AcceptableMove aceita um estado cujo custo fosse menor que o estado anterior ou menor que estados tratados em determinados ciclos anteriores.
2.3.1.2 Step Counting Hill-Climbing
A variante Steps Counting Hill-Climbing é introduzida em (Bykov & Petrovic, A Step Counting Hill Climbing algorithm, 2013) como uma evolução de Late Acceptance Hill-Climbing. Esta evolução surge depois de constatado o sucesso da variante anterior e a tentativa de a tornar mais eficiente mas mantendo as suas vantagens. A diferença está na não existência de uma lista com algumas soluções anteriores, mas a continuação da necessidade de aceitar um vizinho melhor, ou pelo menos melhor que um estado (ou nó) anterior, considerado com o valor limite (“cost bound”).
19 Counting Hill Climbing algorithm, 2013) a eficiência do algoritmo aplicando-o na geração automática de horários para exames e comparam os resultados obtidos entre esta técnica, Late Acceptance Hill-Climbing e Simulated Annealing.
Tendo novamente como base o exemplo demonstrado na Ilustração 1, a implementação de Steps Counting Hill-Climbing obriga a função AcceptableMove a aceitar um estado cujo custo seja preferencialmente menor que o estado anterior ou pelo menos menor que um determinado estado anterior (estado com o valor limite).
2.3.2 Simulated Annealing
Simulated Annealing é uma técnica de pesquisa local probabilística sendo o seu nome justificado por analogia com a termodinâmica (Gaspero, 2003). Em (Russell & Norvig, 1995) esta técnica é referida como um meio alternativo ao reinício de um processamento devido a um mínimo local. Basicamente em vez de escolher um estado cujo custo é menor ou igual ao estado anterior, esta técnica gera e avalia movimentos aleatórios.
No processamento da técnica Simulated Annealing é usado um parâmetro que representa a temperatura (T). T começa com um valor elevado que vai sendo diminuído ao longo das iterações. Esta variável é manipulada por uma função que determina a velocidade à qual ela é reduzida em consideração ao número de ciclos ocorridos.
A implementação desta técnica no exemplo demonstrado na Ilustração 1 impõe que as funções InitialSolution e SelectMove façam sempre uma escolha aleatória, que a função StopCriterion seja verdade quando T atinge o valor 0, (ou um valor suficientemente baixo), e a função AcceptableMove aceite incondicionalmente estados cujo custo seja inferior ao anterior, ou, no caso contrário, essa aceitação é condicional (com probabilidade e^-ΔE/T, em que ΔE representa a alteração dos custos do estado corrente e vizinho).
A heurística Random é basicamente aplicada em Simulated Annealing por gerar um qualquer vizinho, sendo a meta-heurística aplicada para aceitar probabilísticamente (com menor probabilidade no final do processo pois T desce ao longo da pesquisa) piores valores para o estado vizinho que é gerado.
20
e na segunda fase é alcançada uma solução boa. A segunda fase é alcançada utilizando trocas de tempos letivos. Este trabalho refere que este algoritmo teve uma performance melhor que o algoritmo tradicional (com uma só fase).
Em (Ceschia, Gaspero, & Schaerf, 2012) e (Bellio, Ceschia, Gaspero, Schaerf, & Urli, 2013) estão referidos dois trabalhos que também utilizam a técnica Simulated Annealing. A diferença destes dois trabalhos está relacionada com a origem das restrições e o objetivo dos mesmos, isto é, o trabalho referido em (Ceschia, Gaspero, & Schaerf, 2012) está relacionado com a aplicação de restrições sobre os alunos e respetivos cursos, enquanto no trabalho referido em (Bellio, Ceschia, Gaspero, Schaerf, & Urli, 2013) todas as restrições e objetivos estão relacionados com a configuração inicial de um curso sem a aplicação de restrições sobre alunos.
2.3.3 Tabu Search
A técnica Tabu Search, como referida em (Gaspero, 2003), tem a particularidade de manter informação sobre soluções visitadas mais recentemente. Para implementar esta ideia é utilizada uma lista Tabu, lista essa referida em (Thamilselvan & Balasubramanie, 2009) como uma memória de curto prazo que contém informação das soluções que foram visitadas (menos de k iterações atrás onde k, o número de soluções a armazenar, é chamado de tabu tenure).
A técnica Tabu Search pode ser implementada como o exemplo presente na Ilustração 1. A função SelectMove seleciona estados vizinhos e a função AcceptableMove aceita o estado obtido se este não pertencer à lista Tabu. Este estado é armazenado na lista Tabu e caso a lista esteja cheia o estado com mais tempo na lista Tabu é retirado.
Em certas exceções é utilizada uma função de aspiração que permite selecionar estados presentes na lista Tabu. Esta situação só é possível se o custo seja inferior ao custo do estado corrente.
O Tabu Search implementa a heurística ao selecionar bons vizinhos e implementa meta-heurística ao impedir que alguns bons vizinhos Tabu sejam aceites e explorados repetidamente. Mais concretamente, seleciona bons vizinhos através de trocas com a vizinhança, mas considera apenas os bons vizinhos que não estejam referidos na lista Tabu.
21 Formiga, & Souza, 2011) com objetivo semelhante ao desta dissertação. Estes trabalhos têm a particularidade de a solução inicial ser gerada através de algoritmos que não pretendem alcançar soluções ótimas. O trabalho referido em (Dorneles, 2010) tem também como premissa a informação guardada num ficheiro com um formato padrão em XML, o que realça ainda mais a aproximação com esta dissertação.
2.3.4 Outros
22
3
TimeTabling
TimeTabling foi o nome dado ao sistema por exemplificar o verdadeiro objetivo do mesmo, gerar horários académicos. É um sistema acedido através de interface Web, utiliza um servidor aplicacional (Barry & Associates, Inc., 2000) como fornecedor dos seus serviços e foi desenvolvido com uma metodologia que possibilita o uso do seu código no desenvolvimento de sistemas acedidos de outras maneiras. Este sistema tem também como valências, a possibilidade de criar ficheiros com formato em XML para benchmarking em horários académicos a partir de informação existente em repositórios de dados, fazer upload de ficheiros que obedeçam às mesmas regras e posterior seleção dos mesmos, visualizar detalhadamente a informação e obter indicadores da performance das técnicas utilizadas nas gerações dos horários.
No contexto da dissertação foi necessário considerar linguagens que fossem eficientes na resolução de problemas com restrições e que implementassem pesquisa local. COMET (Dynadec, 2010) é uma linguagem especializada nestas resoluções que foi considerada, mas para além de ser uma linguagem proprietária não é uma linguagem utilizada pela FAP.
O sistema foi desenvolvido na linguagem JAVA (Oracle, 2007). É uma linguagem de código aberto, orientada a objetos, é executada através de uma máquina virtual o que a torna portável, sendo a sua sintaxe similar a C/C++. Esta linguagem é utilizada pela FAP no desenvolvimento de meros aplicativos mas também de sistemas de informação complexos. A FAP é dotada de sistemas próprios em JAVA que funcionam de forma autónoma mas também de sistemas acedidos através de interface WEB. A interface WEB foi desenvolvida em JSP (Oracle, 2013) e javascript (W3Schools, 1999).
No seu funcionamento, o trabalho tem um ficheiro com formato em XML para benchmarking em horários académicos a funcionar como repositório de dados e um sistema com interface WEB que implementa as técnicas de pesquisa local abordadas, (Simulated Annealing, Tabu Search e as variantes de Hill-Climbing), para gerar automaticamente horários académicos.
23 caso de inexistência de uma solução é sempre gerada uma solução inicial, onde são gerados horários preenchidos com tempos letivos e recursos selecionados aleatoriamente. As classes que interpretam as regras/restrições do problema devolvem o custo do estado vizinho aos respetivos algoritmos.
As variáveis tratadas são referentes aos tempos letivos, unidades curriculares, salas, professores e turmas. Estas variáveis estão todas definidas no ficheiro XML e são utilizadas pelo sistema WEB.
Relativamente ao universo de dados tratados, foram manipuladas 5 turmas, cada turma com cerca de 35 aulas por semana, (7 horas vezes 5 dias), que envolveu a atribuição de estados com mais de 500 variáveis.
O desenvolvimento seguiu o modelo Model–view–controller (MVC) (Cunningham & Cunningham, Inc., 2013). Modelo este que isola o ambiente gráfico do controlador das regras do sistema e da base de dados, o que juntamente com uma linguagem de programação adequada, possibilita a criação de sistemas modernos eficientes para interfaces WEB, aplicativos locais e até aplicações para dispositivos móveis, este modelo está ilustrado na Ilustração 3.
Ilustração 3: Modelo MVC
3.1
Implementação MVC
24
Ilustração 4: Código do TimeTabling
3.1.1 Controller
Controller, está definido no sistema como um pacote que engloba as classes responsáveis por fazer a ligação entre a camada de visualização e a lógica do sistema. Estas classes funcionam como servlet, processando requisições (request), respostas (response) e gerando ou invocando páginas HTML ou JSP. As classes criadas são as seguintes:
AuthenticationServlet.java: Permite gerir a autenticação de utilizadores;
CreateFileServlet.java: Classe responsável por receber parâmetros com a descrição de consultas a base de dados e assim criar ficheiros com formato em XML para benchmarking em horários académicos;
CreateSolutionServlet.java: Esta é a classe invocada quando é solicitada a geração de horários académicos;
SelectFileServlet.java: Permite selecionar ficheiros armazenados no sistema;
UploadDownloadFileServlet.java: Permite armazenar ficheiros;
25
WB_GetSolutionEventsServlet.java: Devolve os eventos da solução;
WB_GetSolutionGroupServlet.java: Devolve grupos de soluções;
WB_GetTimeTablesServlet.java: Devolve os horários.
3.1.2 Model
Model, ou mais concretamente, a lógica do sistema, é onde estão definidas todas as classes responsáveis pela estratégia utilizada para entre outras coisas ser possível gerar horários. As classes Model estão organizadas estruturalmente de modo a permitir uma gestão mais prudente, uma codificação mais eficiente e uma ligação entre as classes também muito eficiente.
Organização das classes:
database - pacote com o intuito de armazenar a classe responsável por aceder a base de dados:
o JDBCParser.java: classe onde utiliza uma estrutura enumerada (Enum) para implementar configurações estandardizadas para aceder a base de dados;
localSearch - pacote crucial para a geração automática de horários académicos: o LocalSearch.java: classe onde as técnicas de pesquisa local estão
desenvolvidas, são acedidas através de uma função básica de pesquisa local utilizando mecanismos de rescrita e organizadas segundo uma estrutura enumerada;
o LocalSearchInterface.java: interface Java onde estão definidas os métodos reescritos pela classe LocalSearch.java;
o Neighborhood.java: classe responsável por fornecer a vizinhança de cada estado;
utils - pacote que guarda as classes utilitárias do sistema:
o Authentication.java: classe responsável pela informação necessária para a autenticação dos utilizadores;
o Pair.java: classe que permite criar pares de objetos;
o XmlDomDocument.java: classe utilizada para interagir com ficheiros XML;
26
o XHSTT.java: classe que permite gerir a informação existente no ficheiro com o formato em XML para benchmarking;
o XHSTT_DB.java: classe que entende a classe XHSTT.java, possibilitando a criação do ficheiro com informação existente numa base de dados;
o constraint - pacote com as classes responsáveis pela implementação das restrições impostas aos horários:
Constraint.java: classe que implementa a estrutura base das restrições, e os métodos generalistas relativos às restrições;
ConstraintInterface.java: interface com as definições dos métodos de “Deviation” reescritos pela classe ConstraintTypes.java;
ConstraintTypes.java: classe onde estão caraterizados os vários tipos de restrições, utiliza métodos de reescrita e devolvem o custo inerente a cada restrição violada para cada aula instanciada;
CostFunctionInterface.java: interface com as definições dos métodos de “CostFunction” reescritos pela classe CostFunctionTypes.java; CostFunctionTypes.java: classe que através de métodos de reescrita
implementa as funções de custo associadas a cada restrição definida no ficheiro;
EventPair.java: classe que permite gerir informação referente a certos tipos de restrições;
o instance - pacote onde estão definidas todas as classes que instanciam os objetos existentes nas instâncias definidas no ficheiro:
Course.java: curso;
Event.java: unidade curricular;
Event_EventGroup.java: grupos de eventos a que pertence o evento; Event_Resource.java: recursos afetos ao evento;
Event_ResourceGroup.java: grupos de recursos afetos ao evento; EventGroup.java: grupo de eventos;
Instance.java: instância; Resource.java: recurso;
Resource_ResourceGroup.java: grupos de recursos a que pertence o recurso;
27 ResourceType.java: tipo de recursos;
Time.java: tempo letivo;
Time_TimeGroup.java: grupos de tempos letivos a que pertence o tempo letivo;
TimeGroup.java: grupos de tempos letivos;
o solution - pacote onde estão definidas todas as classes que instanciam os objetos existentes nas soluções definidas no ficheiro:
Solution.java: solução; SolutionEvent.java: aula;
SolutionEvent_Constraint.java: restrição da aula; SolutionEvent_Resource.java: recurso da aula; SolutionGroup.java: grupo de soluções; SolutionReport.java: relatório da solução;
SolutionReport_Statistic.java: estatística da solução;
o timetable - pacote com as classes pertinentes para a demonstração de horários:
TimeTable.java: classe que implementa os métodos para interagir com um horário;
TimeTableSlot.java: aula existente num horário.
Estas classes podem ser utilizadas em outros sistemas que implementem o método MVC, mesmo que os sistemas utilizem outro tipo de interface.
3.1.3 View
View, é a componente do método MVC onde estão definidas as propriedades visuais do sistema, materializadas na interface gráfica.
28
Ilustração 5: Entrada no sistema
A Ilustração 5 demonstra o acesso ao sistema, onde é possível identificar o objetivo do sistema e inserir as credenciais que permitem aceder às funcionalidades do mesmo.
Ilustração 6: Ecrã inicial do sistema
29
Ilustração 7: Upload de ficheiros
Ilustração 8: Seleção de ficheiros
30
Depois de selecionar qualquer uma das três funcionalidades antes referidas, o utilizador acede ao detalhe da instância. O detalhe da instância é a informação da origem da instância assim como a informação dos cursos, eventos, recursos e restrições da mesma.
Ilustração 10: Detalhe da instância
Na Ilustração 10 esta evidenciado o menu lateral que permite um acesso rápido a determinada informação:
Dashboard: informação dos cursos, eventos, recursos e restrições definidos na instância;
Soluções: detalhe das soluções existentes no ficheiro assim como as possíveis violações das restrições, tem a possibilidade de navegar entre soluções;
Horários: horários por solução;
Gráficos: gráficos por número de restrições, estados verificados, segundos e custos;
31 Continuando o detalhe da instância também estão visíveis os recursos e as restrições, como está exemplificado na Ilustração 11.
Ilustração 11: Continuação do detalhe da instância
Para cada instância pode haver várias soluções, na Ilustração 12 está demonstrado o detalhe de uma solução.
Ilustração 12: Detalhe da solução
32
detalhe da solução é possível visualizar todos os eventos da mesma assim como as restrições violadas.
Nas Ilustração 13 está demostrado um horário de um curso, dividido por dias da semana e tempos letivos. Em cada aula está visivel qual a unidade curricular, o professor e a sala.
O horario visivel é o produto final da geração automática usando um algoritmo de pesquisa local com restrições às aulas.
Ilustração 13: Horário
Após a geração de um horário é possível ver gráficos que informam sobre os detalhes na execução da técnica que o gerou, assim como das gerações anteriores. Os gráficos existentes são referentes ao número de restrições violadas por estados verificados e por segundos e aos custos por número de restrições violadas e por segundos. Em cada gráfico existe uma legenda no canto superior direito com a abreviatura da técnica responsável pela geração do horário.
33
Ilustração 14: Gráficos
A Ilustração 15 exemplifica o pedido da geração automática. O utilizador seleciona a técnica responsável pela geração e depois edita o detalhe da solução. Nesta edição está disponível a opção de ser gerada uma nova solução aleatória ou uma geração baseada numa solução existente.
34
3.2
Plano do trabalho
O plano de trabalho para a elaboração da dissertação seguiu a seguinte sequência de tarefas:
1. Criação de classes que instanciam os objetos existentes no ficheiro; 2. Criação das classes que implementam as restrições;
3. Criação das classes que implementam a pesquisa local; 4. Criação da interface web;
5. Implementação das estatísticas. 6. Análise dos resultados obtidos.
7. Conclusão da escrita do relatório da dissertação.
3.3
Implementação da Pesquisa Local
Foram implementadas as cinco técnicas de pesquisa local abordadas. A codificação está presente na “LocalSearch.java”, e é através desta classe que a solicitação para a geração de horários assim como a própria geração está desenvolvida.
A função exemplificada na Ilustração 1 está presente na classe “LocalSearch.java”, a sua implementação é básica e é a função base das técnicas de pesquisa local. Os métodos “InitialSolution”, “StopCriterion”, “SelectMove” e “AcceptableMove” são reescritos consoante a técnica de geração desejada.
Para uma melhor performance, foram utilizadas no desenvolvimento do sistema, estruturas existentes na linguagem de programação JAVA, que melhoram a pesquisa e o armazenamento da informação. Mais concretamente estrutura hash, set, list, array, etc...
3.3.1 Random-restart hill-climbing
35 inicialização de variáveis que auxiliam a sua execução, mais concretamente sobre o a possibilidade de reiniciar a função;
StopCriterion: o critério de paragem da técnica é atingir um número máximo de iterações ou atingir a solução ideal, a solução com custo zero, a solução sem violação de restrições;
SelectMove: o estado desejado é alcançado através de procura na vizinhança de um estado não pior que o estado atual, esta procura só é executada caso o custo do estado atual seja maior que 0, esta procura passa primeiro por validar a troca do estado tendo em consideração apenas os tempos letivos sem aulas atribuídas, (o que beneficia o alcance de uma solução sem furos entre aulas), caso não encontre um estado aceitável considera a troca de tempos letivos entre o estado atual e os estados na vizinhança e caso ainda seja necessário poderá validar a troca de recursos, (salas, professores, etc…);
AcceptableMove: são aceites as trocas que não piorem o custo, mas caso a procura de estados melhores seja continuamente não alcançada, então aceita um estado com custo pior.
3.3.2 Late Acceptance Hill-Climbing
InitialSolution: uma solução antes gerada ou então uma solução gerada aleatoriamente;
StopCriterion: o critério de paragem da técnica é atingir um número máximo de iterações ou atingir uma solução ideal;
SelectMove: o estado desejado é alcançado do mesmo modo que a técnica Random-restart hill-climbing mas com a particularidade de procurar na vizinhança de um estado não pior que o estado atual ou que K estados visitados anteriormente;
36
3.3.3 Step Counting Hill-Climbing
InitialSolution: uma solução antes gerada ou então uma solução gerada aleatoriamente;
StopCriterion: o critério de paragem da técnica é atingir um número máximo de iterações ou atingir uma solução ideal;
SelectMove: o estado desejado é alcançado do mesmo modo que a técnica Random-restart hill-climbing mas com a particularidade de procurar na vizinhança de um estado não pior que o estado atual ou que um determinado estado visitado anteriormente;
AcceptableMove: são aceites as trocas que não piorem o custo.
3.3.4 Simulated Annealing
InitialSolution: uma solução antes gerada ou então uma solução gerada aleatoriamente, devido às características desta técnica, foi introduzida a inicialização de variáveis que auxiliam a sua execução, mais concretamente sobre a variável T, (temperatura);
StopCriterion: o critério de paragem da técnica é atingir uma temperatura muito reduzida;
SelectMove: o estado desejado é alcançado através de troca de variáveis existentes na vizinhança;
AcceptableMove: são aceites as trocas que não piorem o custo ou então que o custo não seja superior à função:
Math.exp((NewState.getCost() - ActualState.getCost()) / T);
O método “AcceptableMove” termina com a função responsável por fazes decrescer a temperatura:
37 3.3.5 Tabu Search
InitialSolution: uma solução antes gerada ou então uma solução gerada aleatoriamente;
StopCriterion: o critério de paragem da técnica é atingir um número máximo de iterações ou atingir uma solução ideal, a solução com custo zero, a solução sem violação de restrições;
SelectMove: o estado desejado é alcançado através de troca de variáveis existentes na vizinhança que não estejam presentes na lista Tabu, na lista Tabu estão referenciados os índices dos estados visitados em trocas anteriores;
AcceptableMove: as trocas são aceites e a lista Tabu é atualizada com o índice do estado melhorado.
3.4
Material utilizado
O TimeTabling foi desenvolvido na linguagem de programação JAVA, com o JDK na versão 8.0_92.
Foi utilizado JSP e javascript para a programação da interface, com jQuery na versão v1.11.3 e a inclusão da biblioteca bootstrap na versão v3.3.6. Foram também utilizados os plugins de jQuery: bootpag va versão 1.0.7 no componente que permite a navegação entre soluções e javascript plotting library na versão 0.8.3 para a implementação dos gráficos.
As ferramentas utilizadas foram os editores Eclipse (Eclipse Foundation, s.d.) e Notepad++ (Notepad++, s.d.) assim como o servidor aplicacional (Barry & Associates, Inc., 2000) Wildfly (Red Hat, Inc., 2013). O editor Eclipse na versão Mars.2 Release (4.5.2) para a programação do sistema, assim como para configuração do servidor aplicacional utilizado, Wildfly na versão 9.0.2.
38
4
Resultados Experimentais
Foram efetuados cinco tipos de experiências, em cada tipo de experiência foram executadas as cinco técnicas de pesquisa local.
Devido à particularidade de cada técnica, foram usados parâmetros específicos para as referidas técnicas, como está demonstrado na Tabela 1.
Nome Valor Descrição Técnica que usa
iRequiredCost 1000000 Custo das validações
obrigatórias Todas
iMaxCicle Nº de aulas Nº máximo de ciclos Random-restart hill-climbing; Late Acceptance Hill-Climbing; Step Counting Hill-Climbing
iMaxSameIterator 2 Nº máximo de ciclos sem alterações de custo total
Random-restart hill-climbing
iKStates 2 Nº de estados tratados
anteriormente ao estado corrente, que validam o custo do vizinho
Late Acceptance Hill-Climbing
iCostBoundIndex i Variável com o índice do outro estado a validar o custo
Step Counting Hill-Climbing
iCostBoundStates 10 Nº de iterações até alterar a variável iCostBoundIndex
Step Counting Hill-Climbing
iInitialTemp 1000 Temperatura inicial Simulated Annealing
dCoolingRate 0.003 Nº que influência a frequência em que a temperatura baixa
Simulated Annealing
iTemperature iTemperature * 1
- dCoolingRate Variável temperatura, com inicia a com a variável iInitialTemp
Simulated Annealing
iTabuSize 10 Tamanho da lista tabu Tabu Search
39 Os resultados experimentais só são possíveis através de uma evolução ao formato benchmark, mais concretamente com a criação da estrutura “Statistics”. Nesta estrutura é possível guardar em qualquer momento específico da geração da solução, o número de restrições violadas, o custo da solução e o tempo de execução.
4.1
Baseadas em horários existentes
Foram gerados horários baseados no horário do 1ºsemestre do ano letivo de 2011/2012 da AFA, onde foram utilizadas 5 turmas, cada turma com cerca de 35 aulas por semana, (7 horas vezes 5 dias).
No caso dos horários da AFA foram consideradas para as restrições base os seguintes tipo de regras:
AssignTimeConstraint: Para obrigar a que cada aula tenha um tempo letivo atribuído;
AvoidClashesConstraint: Para evitar conflitos de recursos;
AvoidUnavailableTimesConstraint: Para evitar que sejam atribuídas aulas em determinados tempos letivos;
PreferTimesConstraint: Para indicar que determinadas unidades curriculares sejam lecionadas em determinados tempos letivos;
LimitIdleTimesConstraint: Para limitar o número de tempos letivos livres entre aulas.
Os testes experimentais ocorreram com todas as técnicas implementadas. Para cada técnica o sistema executou cinco vezes como está exemplificado na Ilustração 16.
Ilustração 16: Resultados experimentais com a técnica Random-restart hill-climbing
RRHC
Testes Custo Violações Milisegundos mm:ss,SSS Milisegundos mm:ss,SSS Custo Violações 1 30000000 30 5621 00:05,621 -1422,4 00:01,422 0 0 2 30000000 30 5721 00:05,721 -1322,4 00:01,322 0 0 3 30000000 30 8081 00:08,081 1037,6 00:01,038 0 0 4 30000000 30 7904 00:07,904 860,6 00:00,861 0 0 5 30000000 30 7890 00:07,890 846,6 00:00,847 0 0
7043,4 00:07,043 0 0
1255,58 00:01,256 0,00 0,00
Média Desvio Padrão
Tempo de Execução
