Modelando o caso do IFRN como datasets XHSTT

Para a validação do algoritmo e a promoção de um estudo comparativo, foram produzidas instâncias tomando como base grades de horários reais utilizadas nos semestres letivos 2018.1 e 2018.2 em quatro diferentes campi do IFRN, compreendendo cursos de Nível Médio e Superior. Todos os datasets foram modelados utilizando o padrão XHSTT. O Quadro 4 apresenta os dados gerais de cada uma das instâncias, com destaque ao identificador (Id) adotado para cada uma das instâncias e os quantitativos de horários,

Quadro 3 – Restrições XHSTT agrupadas por objeto de aplicação. Restrições adotadas neste trabalho estão destacadas em negrito.

Event Constraints

Split Events Particiona um evento em um número limitado de encontros Distributed Split Events Particiona um evento em encontros de duração limitada Assign Time Associa um tempo a um evento

Prefer Times Associa a preferência de um conjunto de tempos a um evento

Spread Events Espalha os eventos uniformemente entre os dias letivos

Link Events Associa um mesmo tempo a diferentes eventos

Order Events Associa tempos assegurando ordem cronológica

Event Resources constraints

Assign Resource Associa um recurso a um evento

Prefer Resources Associa a preferência de um conjunto de recursos a um evento

Avoid Split Assignments Associa um mesmo recurso a diferentes eventos

Resource constraints

Avoid Clashes Evita conflitos envolvendo recursos

Avoid Unavailable Times Torna o recurso livre em determinados tempos

Limit Idle Times Limita o número de tempos ociosos de um dado recurso

Cluster Busy Times Limita o número de dias ociosos de um dado recurso

Limit Busy Times Limita o número de alocações de recursos em um mesmo dia

Limit Workload Limita a carga de trabalho total dos recursos

Fonte:Kingston(2014)

Quadro 4 – Dados gerais das instâncias

Id Campus Horários Turmas Disciplinas Professores Dias Indisp.

CA182M Caicó 2018.2 30 11 109 41 71 CA182MT Caicó 2018.2 60 22 209 58 105 JC181M João Câmara 2018.1 30 9 87 39 77 JC181MT João Câmara 2018.1 60 15 147 52 98 JC182M João Câmara 2018.2 30 9 86 44 91 JC182MT João Câmara 2018.2 60 14 144 52 107 IP181M Ipanguaçu 2018.1 30 10 84 56 112

PF181M Pau dos Ferros 2018.1 30 12 122 51 102

PF182M Pau dos Ferros 2018.2 30 12 124 55 110

PF182T Pau dos Ferros 2018.2 30 13 98 55 109

turmas, disciplinas, professores e, por fim, a soma dos dias de indisponibilidade registrado para o conjunto de professores.

As instâncias descritas com 30 horários foram produzidas apenas com dados pertencentes ao turno matutino de cada campus. Cada turno possui 6 períodos de aula, distribuídos em 5 dias da semana, perfazendo um total de 30 horários de aula. As instâncias de 60 horários possuem dados relativos aos turnos matutino e vespertino. Embora o IFRN disponibilize cursos em turno noturno, para a produção dos datasets, eles foram desconsiderados. A verbosidade do formato XHSTT impôs uma média superior a três mil linhas de código para a produção de uma instância para um único turno de aula. A produção dos datasets não pôde ser automatizada motivada pela ausência de padrão na

Quadro 5 – Modelagem no formato XHSTT de aulas geminadas usando grupos e splits.

Distribuição Grupo Split Descrição

2 aulas geminadas Double DistributeSplit1 Assegura a existência de 1 bloco com 2 aulas

2 aulas geminadas e

1 isolada DoubleSingle SplitEvents1 Particiona as aulas em blocos com no máximo 2 aulascada

DistributeSplit1 Assegura a existência de 1 bloco com 2 aulas

2 blocos de 2 aulas

geminadas cada TwoDouble SplitEvents2 Particiona as aulas em blocos com 2 aulas cada 3 blocos de 2 aulas

geminadas cada ThreeDouble SplitEvents2 Particiona as aulas em blocos com 2 aulas cada 3 aulas geminadas Triple DistributeSplit2 Assegura a existência de 1 bloco com 3 aulas gemina-

das

4 aulas geminadas Quatruple DistributeSplit3 Assegura a existência de 1 bloco com 4 aulas gemina-

das 2 blocos de 3 aulas

geminadas cada TwoTriple DistributeSplit4 Assegura a existência de 2 blocos com 3 aulas gemi-nadas cada

fonte dos dados. Dessa forma, a ampliação do número de turnos poderia comprometer a capacidade de produção de uma quantidade maior de instâncias.

A engenharia reversa aplicada às grades de horários reais, embora tenham viabilizado a produção dos datasets, não foi capaz de prover o detalhamento das indisponibilidades de cada um dos professores a nível de horário de aula, bem como, as suas respectivas preferências por aulas geminadas. Dessa forma, as indisponibilidades foram sempre tratadas a nível de dia, ou seja, ao identificar uma aula sendo lecionada em um dia da semana por um professor, o referido dia passa a contar como dia disponível para aula. Em relação às aulas geminadas, por não ser possível determinar se o agrupamento de aulas era proposital ou não, foi convencionado que os grupos deveriam ser respeitados. Com isso, foram adicionadas constraints para assegurar que as mesmas composições seriam replicadas nas grades de horários produzidas pela solução. Para as demais informações necessárias para a confecção das instâncias, as grades de horários reais se mostraram suficientes.

A modelagem das restrições foi feita usando os recursos do padrão XHSTT. Será discutida inicialmente a modelagem da restrição H6 (atendimento de distribuição de aulas) que, como discutido anteriormente, é assegurada pelo pré-processamento das disciplinas de acordo com as preferências de distribuição informadas pelos professores. Foram usados dois tipos de recursos para modelar esta restrição: grupos e splits, como listado no Quadro 5. Especificamente, um split promove a divisão de um evento, neste caso aulas de uma disciplina modeladas como um grupo. As demais modelagens são descritas a seguir:

H1 - Atendimento à grade curricular: para indicar ao otimizador a necessidade de

associação de todos os eventos aos tempos disponíveis para alocação, foi criada uma constraint do tipo AssignTime aplicada ao grupo gr_AllEvents, que engloba todas as aulas.

Figura 18 – Exemplo de restrição de disponibilidade de professor em XHSTT

.

H2 & H3 - Exclusividade dos recursos professor e turma: a constraint Avoid-

Clashes foi aplicada em dois grupos de recursos: (i) gr_Teachers e (ii) gr_Classes, que representam, respectivamente, todos os professores e turmas do dataset.

H4 - Aulas contíguas: para evitar a concentração de aulas de uma mesma disciplina

em um único dia letivo, foi adicionada uma constraint do tipo SpreadEvents aplicada a todas as disciplinas que possuem mais de um encontro previsto. A restrição indica que para uma mesma disciplina, por dia, deve existir uma ocorrência máxima de um encontro, o que não exclui a possibilidade de existência de aulas geminadas.

H5 - Atendimento de distribuição semanal justificada: a fim de refletir as indis-

ponibilidades ou preferências dos professores por dias específicos para o lecionamento de aulas, foram criadas restrições do tipo AvoidUnavailableTimes. Cada restrição desse tipo indica os recursos do tipo professor a ela associada, bem como os dias da semana específicos que devem ser evitados para a locação dos recursos referenciados. Na Figura 18, é exemplificada a restrição da atuação dos professores T2, T3 e T10 a três dias da semana. Mais especificamente, aulas nas quintas-feira (gr_Th) e sextas-feira (gr_Fr) devem ser evitadas. Por estar identificada com o valor true no atributo Required, esta restrição deve ser obrigatoriamente atendida pelo otimizador, como preconiza a restrição H5 do problema.

H7 - Número máximo de aulas diárias de um professor: para a modelagem do ce-

nário da restrição H7 foi utilizada a constraint do tipo LimitBusyTimes. A restrição foi aplicada sobre o grupo de professores (gr_Teachers) e aos TimeGroups que representam os horários de cada um dos dias da semana, limitando os recursos do tipo professor a uma alocação máxima de 10 aulas por dia letivo.

S1 & S2 - Redução de janelas de alunos e professores: para a modelagem das

que se aplicam aos grupos gr_Classes e gr_Teachers. Além disso, englobam os TimeGroups de cada um dos dias da semana.

Neste capítulo, foi proposta uma formulação para o problema de alocação de horários escolares no contexto do IFRN. Inicialmente, foram identificadas as restrições fortes e fracas do problema, seguindo para a proposição de uma formulação matemática. O capítulo foi concluído com a construção de um dataset contendo instâncias modeladas no formato XHSTT, o padrão que tem sido adotado pela comunidade internacional que pesquisa o HST. No próximo capítulo, é proposto um algoritmo baseado na metaheurística GRASP e sua validação a partir da comparação com os algoritmos de maior relevância identificados na literatura.

5 Algoritmo proposto e validação

Como discutido no Capítulo 3, a observação dos trabalhos dedicados ao estudo e à solução dos problemas de HST destaca a proposição de algoritmos que atuam sobre o problema em duas fases distintas. Geralmente, a primeira fase se dedica à produção de uma solução inicial viável e a segunda empreende esforços para o melhoramento da qualidade das grades de horários inicialmente produzidas. Dessa forma, a partir da reconhecida eficiência dos métodos heurísticos sobre os problemas de HST, que foi evidenciada na revisão bibliográfica, foi produzida uma solução para o problema de horários do IFRN embasada na metaheurística GRASP. A fase de construção utiliza um algoritmo guloso aleatorizado, enquanto a fase de melhoramento recorre a uma busca local simples, auxiliada por três movimentos para a exploração da estrutura de vizinhança em busca de melhores soluções.

Nesta seção, é detalhado inicialmente o algoritmo proposto. Em seguida, o setup experimental utilizado para validação do algoritmo é apresentado, comparando-o com outras soluções existentes para o HST.