PIA FINAL Zelito Atumane Saide

UNIVERSIDADE EDUARDO MONDLANE
FACULDADE DE ENGENHARIA
Curso de Licenciatura em Engenharia Informática
Projecto Integrado de Aplicativos
PROPOSTA DE DESENVOLVIMENTO DE SISTEMA DE GESTÃO DE HORÁRIOS
ACADÊMICOS
Caso de estudo: Geração de horários acadêmicos do DEEL
Autor
Zelito Atumane Saide
Supervisor
Eng.º Ruben Manhiça
Maputo, Novembro de 2019

UNIVERSIDADE EDUARDO MONDLANE
FACULDADE DE ENGENHARIA
Curso de Licenciatura em Engenharia Informática
Projecto Integrado de Aplicativos
PROPOSTA DE DESENVOLVIMENTO DE SISTEMA DE GESTÃO DE HORÁRIOS
ACADÊMICOS
Caso de estudo: Geração de horários acadêmicos do DEEL
Autor
Zelito Atumane Saide
Supervisor
Eng.º Ruben Manhiça
Maputo, Novembro de 2019

Dedicatória
Dedico este trabalho a minha família, amigos, colegas e professores que sempre me
apoiaram e deram me força sempre que precisa-se.
1
Epígrafe
“O Homem realizado é aquele que reconhece o maior problema de sua vida e consegue
encontrar a fonte viável da solução desse problema” (Zelito Atumane Saide)
2
Agradecimentos
A Deus por ter me dado vida, saúde e força para superar as dificuldades enfrentados na
elaboração deste trabalho.
Aos meus pais, pelo amor, incentivo e apoio, que apesar de todas dificuldades que eles
enfrentaram durante todo este percurso, nunca desistiram de apostar em mim.
A esta universidade, seu corpo docente, direção e administração que abriram a janela que
hoje vislumbro um horizonte superior, eivado pela acendrada confiança no mérito e ética
aqui presentes.
Ao meu supervisor Eng.º Ruben Manhiça, pelo suporte no pouco tempo que lhe coube,
pelas suas correções e incentivos.
Ao grupo decente da cadeira PIA que me deu a oportunidade de terminar o trabalho mesmo
depois do limite de entrega.
A todos que directas ou indirectamente fizeram parte da na materialização deste trabalho,

o meu muito obrigado.
3
Resumo
Diante dos factos que esta pesquisa revela acerca da elaboração manual de horários,
este tem sido um processo demorado, exaustivo e muito complexo enfrentado em várias
instituições, e quanto maior for a instituição em questão, maior ainda será o problema. A
despeito dos problemas comuns que as instituições acadêmicas enfrentam na gestão de
horários, existem problemas particulares que são muito próprios da instituição. Face ao
disposto no período anterior, a Faculdade de Engenharia da Universidade Eduardo
Mondlane (UEM) tem enfrentado problemas referentes a modificações do horário nas
primeiras semanas de aulas depois de este ter sido publicado, mediante negociações
entre os docentes ou entre docentes e a turma em causa. Face a este problema, propôs-
se estudar e desenvolver um sistema de geração de horários acadêmicos para a
Faculdade de Engenharia da UEM, onde descreveu-se primeiro a situação actual do
processo de elaboração de horários, identificou-se e descreveu-se os problemas que
esta enfrenta, de seguida analisou-se e comparou-se algumas aplicações existentes
para a gestão de horários, e por último desenvolveu-se uma proposta de solução, com
recurso a inteligência artificial (Algoritmos Genéticos) e modelos matemáticos para
garantir a qualidade dos horários gerados. Com esta solução, espera-se diminuir o tempo
gasto e o nível de intervenção e concentração do utilizador que é exigido no processo de
elaboração manual de horários, gerar horários sem nenhum tipo de choque
(sobreposição) tanto de professores assim como de salas e por último diminuir o nível
de modificações feitas sobre o horário após este ser publicado.
Palavras-chave: Algoritmos Genéticos, Gestão de salas, alunos, gestão de horários

acadêmicos.
4
Abstract
Given the facts that this research reveals about the manual elaboration of schedules, this
has been a time consuming, exhausting and very complex process faced in several
institutions, and the bigger the institution in question, the bigger the problem will be.
Despite the common problems academic institutions face in schedule management, there
are particular problems that are very much of the institution. In view of the previous period,
the Faculty of Engineering of UEM has been facing problems regarding schedule changes
in the first weeks of classes after it was published, through negotiations between the
teachers or between teachers and the class in question. Faced with this problem, it was
proposed to study and develop a system of academic schedule management for the
Faculty of Engineering of UEM, where we first described the current situation of the
process of elaboration of schedules at the Faculty of Engineering of UEM, the problems
it faces were identified and described, then some existing applications for schedule
management were analyzed and compared, and a solution proposal was developed,
using artificial intelligence (Genetic Algorithms) and mathematical models to guarantee
the quality of the generated schedules. With this solution, it is expected to decrease the
time spent and the level of user intervention and concentration that is required in the
manual scheduling process, to generate schedules without any kind of clash (overlap) of
both teachers as well as classrooms and by the latter decreases the level of changes
made to the schedule after it is published.
Key words: Genetic Algorithms, management of classrooms, students, management of

schedules.
5
Índice
Capítulo I – Introdução ............................................................................................... 12
1.1. Contextualização.............................................................................................. 13
1.2. Justificativa....................................................................................................... 14
1.3. Objectivos ........................................................................................................ 15
1.3.1. Objectivo geral ........................................................................................... 15
1.3.2. Objectivos específicos ............................................................................... 15
1.4. Metodologia...................................................................................................... 15
1.4.1. Questão de Pesquisa ................................................................................ 15
1.4.2. Classificação da metodologia .................................................................... 16
1.4.3. Técnicas de coleta de dados ..................................................................... 17
1.4.4. Técnicas de análise de dados ................................................................... 17
1.4.5. Metodologia do desenvolvimento do protótipo .......................................... 18
1.5. Organização do trabalho .................................................................................. 19
Capítulo II - Revisão de literatura............................................................................... 21
2.1. Problema de Horário ou Timetabling problem .................................................. 22
2.1.1. Descrição do Problema de Horário ............................................................ 22
2.1.1.1. Tempos ............................................................................................... 22
2.1.1.2. Recursos ............................................................................................. 22
2.1.1.3. Reuniões ............................................................................................. 23
2.1.1.4. Restrições ........................................................................................... 23
2.1.2. Classificação dos problemas de horários .................................................. 25
2.2. Algoritmo genético ........................................................................................... 26
6
2.3. Avaliação de alguns sistemas existentes de gestão de horários ..................... 28
2.3.1. Cronos ....................................................................................................... 29
2.3.2. GridClass ................................................................................................... 30
2.3.3. Sistema proposto pela engenheira Kida .................................................... 30
Capítulo III – Caso de Estudo ..................................................................................... 32
3.1. Descrição da situação actual do processo de elaboração de horários do DEEL

33
3.2. Constrangimentos da situação actual .............................................................. 35
Capitulo IV – Desenvolvimento do trabalho ............................................................. 36
4.1. Descrição da solução ....................................................................................... 37
4.1.1. Utilizadores ................................................................................................... 37
4.1.2. Fluxo de funcionamento ................................................................................ 38
4.1.3. Requisitos ..................................................................................................... 39
4.1.3.1. Requisitos Funcionais ......................................................................... 39
4.1.3.2. Requisitos não funcionais ................................................................... 41
4.1.4. Casos de uso ................................................................................................ 42
4.1.4.1. Descrição dos casos de uso ............................................................... 43
4.1.5. Modelagem do problema pelo algoritmo genético ........................................ 50
4.1.5.1. Diagrama de classes que será usado pelo AG ................................... 50
4.1.5.2. Representação do cromossoma ......................................................... 51
4.1.5.3. Inicialização da população .................................................................. 53
4.1.5.4. Função de Avaliação........................................................................... 55
4.1.5.5. Operadores genéticos ......................................................................... 58
4.1.6. Proposta de Arquitectura para o sistema ...................................................... 58
7
4.1.7. Tecnologias Utilizadas .................................................................................. 60
4.2. Apresentação do protótipo ............................................................................... 61
Capitulo V – Discussão de resultados ...................................................................... 67
Capítulo VI - Conclusões e recomendações ............................................................. 70
6.1. Conclusões ...................................................................................................... 71
6.2. Recomendações .............................................................................................. 71
Referências bibliográficas .......................................................................................... 73
Anexos ......................................................................................................................... 75
8
Índice de Figuras
Figure 1: Fluxograma de um algoritmo genético ........................................................... 28
Figure 2: Fluxo do processo de elaboração de horários da Faculdade de Engenharia 34
Figure 3: Diagrama de casos de uso............................................................................. 43
Figure 4: Diagrama de classes ...................................................................................... 51
Figure 5: Estrutura do cromossoma .............................................................................. 52
Figure 6: Quadro de Horários ........................................................................................ 52
Figure 7: Objecto Aula e sua relação com cromossoma ............................................... 53
Figure 8: População de cromossomas .......................................................................... 54
Figure 9: Cruzamento entre cromossomas iguais ......................................................... 54
Figure 10: Choque entre professores ............................................................................ 56
Figure 11: Disponibilidade do professor ........................................................................ 57
Figure 12: Arquitectura de três camadas ...................................................................... 59
Figure 13: Criação de uma nova geração de horários .................................................. 61
Figure 14: Director do curso informa as aulas ao sistema ............................................ 62
Figure 15: Edição do horário por parte dos professores ............................................... 63
Figure 16: Negociação de troca de aula entre professores ........................................... 64
Figure 17: Resposta do pedido de trocas de aulas ....................................................... 65
Figure 18: Validação das alterações do horário pelo director ....................................... 66
Figure 19: Descrição do diagrama de sequência DS01 ................................................ 76
9
Índice de Tabelas
Table 1: Descrição do caso de uso CU01 ..................................................................... 44
Table 10: Descrição do caso de uso CU10 ................................................................... 48
10
Lista de abreviaturas e acrónimos
UEM Universidade Eduardo Mondlane
FENG Faculdade de Engenharia
DEEL Departamento de electrotecnia
DEQUI Departamento de engenharia Química
DCG Departamento de cadeiras gerais
DEMA Departamento de engenharia mecânica
DEMA Departamento de engenharia mecânica
DECI Departamento de engenharia civil
AG Algoritmo Genético
RF Requisito functional
RNF Requisito não functional
UML Linguagem unificada para Modelação
HTML HyperText Markup Language
CSS Cascading Style Sheets
DS Diagrama de Sequencia
MVC Model – View – Controller
11
Capítulo I – Introdução
12
1.1. Contextualização
Antes de adentrar-se no estudo minucioso do tema proposto, vale numa primeira

instância, situá-lo dentro do contexto, isto é, espaço e tempo, e designar as
circunstâncias que estão em volta deste tema.
A Universidade Eduardo Mondlane (UEM) é uma instituição pública de âmbito nacional,

a mais antiga instituição de ensino superior em Moçambique. Foi fundada no dia 21 de
Agosto de 1962 (UEM, 2019). Esta universidade possui a maioria das suas faculdades
na capital do país, sendo a faculdade de engenharia uma delas.
A Faculdade de Engenharia foi fundada no mesmo ano que a UEM, e possuía uma
estrutura de chefia centralizada, com cada curso associado a um Departamento
específico. Logo após a Independência, os departamentos assumiram o estatuto de
Faculdade com estrutura não centralizado. Esta estrutura permaneceu até 1980, quando
foi de novo mudada para a situação de 1962 (FEUEM, 2019).
Esta mudança de estrutura organizacional verificada ao longo dos tempos, deveu-se ao

fato de esta ser uma unidade orgânica de grande e de difícil gestão. Relacionados a
estes desafios administrativos, a faculdade de engenharia actualmente possui um
grande problema de gestão de horários e salas, problema este que se vai agravando
com o crescimento da faculdade. Paradoxalmente, embora tenham sido empreendidos
esforços mediante pesquisas com objectivo de abordar este problema, este ainda tem
sido um problema real na faculdade.
Na elaboração de horários académicos, várias restrições devem ser tomadas em conta,

e tais restrições de um modo geral incluem restrições pedagógicas, restrições
operacionais e restrições com relação às preferências do professor (Góes, Costa, &
Steiner, 2010). Ademais, tem sido um facto na faculdade de engenharia, durante as
primeiras semanas de aula, professores proporem modificações no horário, mediante
negociações entre professores ou entre professores e a turma após este ter sido
13
publicado. Assim, a tarefa de gestão de horário na faculdade de engenharia torna-se
ainda muito complexa e difícil, pior ainda quando é realizada manualmente.
Face aos factos acima apresentados, constata-se que são muitos os elementos
envolvidos na elaboração de horários e alocação de salas na faculdade de Engenharia,
e portanto, fica muito difícil gerir todos eles ao mesmo tempo sem a ajuda de algum
recurso informático. Desta feita, o presente trabalho irá focar-se essencialmente no
estudo de soluções à problemática apresentada.
1.2. Justificativa
A necessidade de um sistema que faz a gestão de horários acadêmicos de forma flexível

e eficiente, é de extrema importância no contexto das actividades de gestão universitária.
Actualmente, apesar de todo o avanço tecnológico, algumas das instituições

académicas, como é o caso da faculdade de engenharia da UEM, ainda elabora os
horários académicos de forma manual, tornando esta tarefa bastante demorada e
ineficiente. Além disso, esta tarefa é tida como um factor crítico e de enorme
complexidade, pois são necessárias combinações de vários recursos, tais como
disciplinas, salas, professores, directores e alunos.
Ademais, a escolha da temática deve-se também a preocupação do autor pelos impactos

negativos que gestão manual dos horários tem causado aos estudantes. Quando os
horários são elaborados manualmente, erros graves, como por exemplo docentes
alocados à várias aulas ou então salas alocadas a diferentes aulas ao mesmo tempo,
podem ocorrer. E como consequência desse problema, os estudantes podem correr o
risco de perder aulas por um longo período de tempo.
Diante dos factos apresentados, propõe-se, através desta pesquisa, optimizar e

automatizar este processo, com um sistema capaz de gerir todos os elementos presentes
na elaboração de horários na Faculdade de Engenharia da Universidade Eduardo
Mondlane.
14
1.3. Objectivos
1.3.1. Objectivo geral
Desenvolver um sistema de gestão de horários académicos para Faculdade de

Engenharia da UEM.
1.3.2. Objectivos específicos
 Descrever os aspectos principais relacionados com a elaboração de horários

académicos.
 Descrever a situação actual do processo de elaboração de horários na Faculdade
de Engenharia da UEM;
 Identificar os constrangimentos enfrentados na elaboração manual de horários
académicos na faculdade de engenharia.
 Desenvolver a proposta do protótipo funcional à problemática apresentada.
1.4. Metodologia
No presente trabalho foram utilizadas as seguintes metodologias de investigação a fim

de alcançar os objectivos traçados:
1.4.1. Questão de Pesquisa
Segundo (Lakatos & Marconi, 1992), o problema deve ser levantado e formulado, de
preferência em forma interrogativa. O presente trabalho teve como fundamento a
necessidade de responder a seguinte questão: Até que ponto a falta de um sistema de
gestão de horários académicos pode, de certo ponto, afectar negativamente a
administração pedagógica da faculdade de engenharia da UEM e os seus intervenientes,
como estudantes, professores e directores?
15
1.4.2. Classificação da metodologia
Para além da apresentação da questão que deve ser respondida ao se realizar a

pesquisa, importa referenciar a classificação das restantes metodologias de acordo com
determinados critérios:
 Quanto aos objectivos
Segundo (Prodanov & Freitas, 2013), a investigação pode ser classificada em descritiva,
exploratória ou explicativa. A pesquisa exploratória visa proporcionar maior familiaridade
com o problema, tornando-o explícito ou construindo hipóteses sobre ele. Foi possível,
através da pesquisa exploratória, apresentar quais os problemas existentes no processo
de elaboração manual de horários académicos da FEUEM, determinando as suas
limitações e lacunas a serem resolvidas.
 Quanto à abordagem
Segundo (Prodanov & Freitas, 2013), quanto à abordagem a pesquisa pode ser
qualitativa e quantitativa. Na pesquisa qualitativa o ambiente natural é a fonte directa
para coleta de dados, interpretação de fenômenos e atribuição de significados. Sendo
assim, inicialmente fez-se um levantamento histórico do caso de estudo, de modo a aferir
se mediante a informação obtida poderia se realizar a pesquisa e quais elementos
poderiam ser analisados, por forma a resolver a problemática existente. De seguida, fez-
se uma análise para se poder obter informações sobre quais os critérios que se teriam
em conta e que elementos analisar.
 Quanto ao método científico
Segundo (Prodanov & Freitas, 2013), a pesquisa quanto ao método científico pode ser
indutiva, dedutiva, hipotético-dedutiva, dialético ou fenomenológica. No método
hipotético-dedutivo formula-se hipóteses para expressar as dificuldades do problema, de
onde deduz-se consequências que deverão ser testadas ou falseadas. Sendo que,
16
através das observações do processo de gestão de horários da FEUEM, foi possível
aferir as hipóteses, inicialmente, impostas.
1.4.3. Técnicas de coleta de dados
Para (Lakatos & Marconi, 1992), a técnica de colecta de dados corresponde, portanto, à
parte prática de colecta de dados, por via de preceitos e processos pré-estabelecidos.
Face ao disposto no período anterior, na presente pesquisa utilizou-se as seguintes
técnicas: Colecta documental, observação e entrevista.
A colecta documental, conforme (Lakatos & Marconi, 1992), é o método de busca de

informação que pode ser feita de duas formas, documentação directa e documentação
indirecta. Assim, através da internet, foi possível ter acesso a documentos como livros,
trabalhos investigativos, revistas, entre outros, relacionados com a temática do presente
trabalho.
As observações feitas, consistiram nas experiencias pessoais do autor durante o tempo

em que frequentou o curso de licenciatura na faculdade de engenharia.
Também fez-se entrevista face a face com a directora do curso de licenciatura à

engenharia informática a fim de obter informações sobre como tem sido a elaboração
dos horários na faculdade de engenharia, especificamente no departamento de
electrotecnia.
1.4.4. Técnicas de análise de dados
A elaboração da análise, segundo (Lakatos & Marconi, 1992) citado por (Mahanjane,
2019) é realizada em três níveis, sendo a interpretação, a explicação e a especificação.
Assim, foram os últimos dois níveis utilizados para analisar os dados resultantes da
pesquisa realizada.
17
A explicação constituiu a fase em que se buscou os conceitos obtidos dos dados, de
modo a formular um raciocínio lógico e organizar o documento da pesquisa. Por fim, a
especificação permitiu determinar até que ponto o sistema podia responder as
necessidades do processo de gestão de horários, e se seria possível, através da solução
proposta, se ultrapassar grande ou todos os problemas constatados na pesquisa.
1.4.5. Metodologia do desenvolvimento do protótipo
A fim de desenvolver a proposta da solução da problemática do presente trabalho, usou-

se a metodologia de desenvolvimento de software waterfall, isto é, o desenvolvimento
clássico em cascata. Segundo (Sommerville, 2011) esta metodologia é designada
cascata por causa do encadeamento entre uma fase e a outra. Assim, as fases que
compreendem a metodologia de desenvolvimento em cascata encontram-se descritas a
seguir:
 Levantamento de requisitos: onde foram definidos os objectivos, traçadas as

metas e delimitados os funcionalidades do sistema. Nesta fase, para além da
entrevista feita à directora do curso de engenharia informática, foi usado
maioritariamente o trabalho desenvolvido pela engenheira Kida, visto que este
contempla maior parte das especificações do sistema e da descrição do caso de
estudo.
 Descrição da solução: onde foram apresentadas as especificações do sistema,
o processo de modelação e determinação da forma de interacção entre os
autores. Assim, resultando na especificação completa documentada do
comportamento do software.
 Projecto: onde foi apresentada a maneira como deve ser implementado o sistema
através da representação de sua arquitectura de funcionamento.
 Codificação: onde se fez a selecção da língua de programação e ferramentas
auxiliadoras, sendo apresentadas detalhadamente na secção 4.1.7. Devido a
questões de tempo, esta fase ainda está em processo.
 Validação: onde será apresentado o protótipo para ser validado para utilização.
18
1.5. Organização do trabalho
O presente trabalho é composto por seis (6) capítulos e por mais duas (2) secções
referentes a referências bibliográficas e anexos:
Capitulo I – Introdução
Contém uma breve descrição do que será apresentado ao longo do trabalho. Aqui é feita
uma contextualização sendo igualmente apresentados os objectivos e as justificativas
que levaram a escolha do tema.
Capitulo II – Revisão de Literatura
Neste capítulo, faz-se uma síntese referente aos conceitos relacionados com a
elaboração de horários, dentro de uma sequência lógica voltada directamente a
aplicação das TICs em prol da superação das dificuldades que a faculdade de
engenharia enfrenta.
Capitulo III – Caso de Estudo
Neste capítulo, é feita uma descrição da situação actual do processo de elaboração de

horários na Faculdade de Engenharia da UEM, onde são apresentados os problemas
que se pretende resolver.
Capitulo IV – Desenvolvimento do Trabalho
Neste Capítulo, após a apresentação clara e precisa do problema, dá-se a solução

proposta para que se possa resolver os constrangimentos anteriormente identificados.
Capitulo V – Discussão de resultados
Neste capítulo apresenta-se os resultados dos estudos realizados e são comparados

com os esperados.
Capitulo VI – Conclusões e recomendações
19
Este capítulo apresenta as principais conclusões obtidas na realização do trabalho. Por
fim, são feitas recomendações sobre o que se pode fazer no futuro para melhorar a
solução aqui apresentada.
Referencias Bibliográficas
Neste capítulo são apresentadas as referências bibliográficas utilizadas para a

elaboração do presente trabalho.
Anexos
Apresenta o questionário feito aos directores do curso, os diagramas UML e outros

documentos importantes para discutir o problema da gestão de horários da faculdade.
20
Capítulo II - Revisão de literatura
21
2.1. Problema de Horário ou Timetabling problem
O desenvolvimento de programas e sistemas de computador para solucionar problemas

de horários tem sido tratado pela comunidade científica há mais de 40 anos. Em 1995
mais de 60 artigos foram publicados, e em 1996, foi lançado o Grupo de Trabalho da
Associação Europeia de Sociedades Operacionais de Pesquisa em Horário Automático,
e hoje possui mais de 300 membros de mais de 60 países (Gross, Yellen, & Zang, 2014).
2.1.1. Descrição do Problema de Horário
Segundo (Gross, Yellen, & Zang, 2014), o problema de horário é um problema com
quatro parâmetros: T, um conjunto finito de Tempos (times); R, um conjunto finito de
recursos (resources); M, um conjunto finito de Reunião (meeting); e C, um conjunto finito
de restrições (constraints). O problema consiste em associar o tempo e recursos aos
eventos, buscando satisfazer as restrições da melhor forma possível.
2.1.1.1. Tempos
O tempo é geralmente discreto, dividindo em um conjunto finito e fixo de intervalos de

igual duração. Um tempo t é um elemento do conjunto de Tempos T em uma instância
do problema de horários. Um time slot é uma variável restrita que conte um tempo e
estes slots são previamente fixados em um valor específico (Gross, Yellen, & Zang,
2014).
O autor ainda continua dizendo que as restrições envolvendo tempo são, por exemplo,
dois times slots devem conter horas cujos intervalos de tempo subjacentes são
diretamente adjacentes ou que um conjunto de times slots deve conter horas que são
distribuídos de maneira uniforme durante a semana.
2.1.1.2. Recursos
Os recursos de acordo com (Gross, Yellen, & Zang, 2014), são os elementos que
compõem a reunião, podendo ser professore, salas, estudantes (ou grupos de
22
estudantes) e assim por diante. Um recurso r é um elemento do conjunto de recursos R
de uma instância do problema de horários. Um resource slot é uma variável restrita que
conte um recurso, e estes slots são previamente fixados em um valor específico, como
é o caso de slots de grupo de estudante.
A restrição de que nenhum recurso deve aparecer em duas reuniões que compartilham
um tempo, aplica-se igualmente a professores, alunos e salas e, portanto, esses itens
geralmente são tratados juntos como parte de uma reunião (Gross, Yellen, & Zang,
2014).
2.1.1.3. Reuniões
Uma reunião m é uma coleção nomeada de time slots e de resource slots. Atribuir valores
a esses slots significa que todos os recursos atribuídos participam dessa reunião no
tempo atribuído (Gross, Yellen, & Zang, 2014).
Face ao disposto no parágrafo anterior, no horário escolar, uma reunião geralmente

representa uma disciplina ministrada durante uma semana em um tempo predefinido, um
slot de grupo de estudantes predefinido, um slot de professor predefinido e um slot de
sala.
2.1.1.4. Restrições
Os investigadores da área de criação de horários desenvolveram várias restrições nas

instituições na qual investigaram, entretanto, não é possível fornecer uma lista
abrangente de restrições em um cenário geral. Ao avaliar restrições em relação às
soluções, é conveniente atribuir um valor 0 a resultados perfeitamente aceitáveis e
atribuir valores progressivamente mais altos a resultados menos aceitáveis (Gross,
Yellen, & Zang, 2014).
2.1.1.4.1. Tipos de restrições
De acordo com (Gross, Yellen, & Zang, 2014), no problema de horários existem cinco
tipos de restrições que devem ser tomadas em conta na elaboração de horários:
23
hard constraint: é uma restrição que deve ser satisfeita. Associada a cada hard
constraint está uma função de valor binário ℎ: 𝑆 ⇒ {0, 1}.
a) Definida para cada solução 𝑤 ∈ 𝑆 (onde S é o conjunto de todas soluções do

problema de horários).
1, 𝑠𝑒 𝑤 𝑛ã𝑜 𝑠𝑎𝑡𝑖𝑠𝑓𝑎𝑧 𝑎 𝑐𝑜𝑛𝑑𝑖çã𝑜

ℎ (𝑤 ) = {
0, 𝑛𝑜𝑠 𝑜𝑢𝑡𝑟𝑜𝑠 𝑐𝑎𝑠𝑜𝑠
Uma solução viável é qualquer solução que satisfaça todas as hard constraints,
isto e, ℎ(𝑤 ) = 0 para todo h.
b) Soft constraint: é uma restrição que é desejável, mas não é necessária

satisfazer. Associada a cada soft constraint está uma função 𝑠: 𝑆 ⇒ 𝑍 + . A
interpretação é que uma solução 𝑤 ∈ S para a qual 𝑠(𝑤) é pequena é preferida.
c) Completeness constraint: esta restrição exige que cada time slot receba um
valor.
d) No-conflicts constraint: esta restrição exige que cada recurso não participe de
duas reuniões no mesmo tempo.
e) Availability constraint: esta restrição indica que um recurso específico está
disponível apenas para um determinado subconjunto de Tempos T. Por exemplo,
um professor de tempo parcial pode estar disponível apenas às quintas e sextas-
feiras.
2.1.1.4.2. Função badness
Seja S o conjunto de todas as soluções para um determinado problema de cronograma.

A função de badness desse problema é uma função 𝑏: 𝑆 ⇒ 𝑍 + que encapsula em um
único número 𝑏(𝑤) uma classificação geral de uma solução 𝑤 ∈ 𝑆.
24
Sejam as hard constraints para um determinado problema serem ℎ1 , ℎ2 , ..., ℎ𝑛 e sejam
soft constraints 𝑆1 , 𝑆2 , ..., 𝑆𝑚 Uma abordagem comum é escolher uma função badness
que seja uma soma ponderada desses valores:
𝑛 𝑚
𝑏(𝑆) = ∑ 𝑣𝑖 ℎ𝑖 (𝑆) + ∑ 𝑤𝑗 𝑠𝑗 (𝑆)

𝑖=1 𝑗=1
onde os pesos 𝑣𝑖 e 𝑤𝑗 são números inteiros não negativos escolhidos para refletir a
importância das restrições correspondentes, com o 𝑣𝑖 muito maior que o 𝑤𝑗 .
2.1.2. Classificação dos problemas de horários
De acordo com Schaerf (1995) citado por (Vieira & Macedo, 2011) classifica o problema
de horários escolares em três diferentes grupos: school timetabling, course timetabling,
examination timetabling. Os dois primeiros se caracterizam pelo agendamento de um
conjunto de aulas (ensino médio e cursos universitários, respectivamente), e o
examination timetabling, para a marcação de avaliações.
A diferença entre estas formas está na quantidade do conjunto finito de determinados parâmetros.
O school timetabling possui uma quantidade de recursos menor, pois uma turma já possui uma
sala especificada e seu grupo de alunos, em sua maioria, é predeterminado, o que faz com que a
complexidade seja reduzida. Em problemas de course timetabling existe um grande conjunto de
restrições: disciplinas de uma mesma turma podem ser alocadas em salas diferentes, cada
disciplina é constituída por alunos de diversos cursos, cada disciplina possui conjuntos de pré-
requisitos que devem ser respeitados, entre outras. Já no caso do examination timetabling, as
restrições são mínimas. Para cada disciplina existe uma avaliação, as mesmas não devem ocorrer
em um mesmo dia e horário e a marcação de provas em dias consecutivos deve ser evitada (Vieira
& Macedo, 2011).
O presente trabalho enquadra-se na categoria course timetabling, por se tratar de uma

instituição de ensino superior.
25
2.2. Algoritmo genético
Existem várias abordagens para modelagem do problema de horários e as que mais se

destacam são as de algoritmos genéticos (AGs), satisfação de restrições, arrefecimento
simulado, busca tabu, e algoritmos de colónias de formigas (Vieira & Macedo, 2011).
O desenvolvimento dos algoritmos genéticos partiu dos conhecimentos da biologia,

através da teoria evolutiva de Darwin e dos princípios básicos da genética moderna
desenvolvida por Mendel (Vieira & Macedo, 2011). Algoritmos genéticos são buscas
heurísticas e técnicas de optimização que imitam o processo de evolução natural
(Bhattacharjya, 2013). Nessa técnica, diversos indivíduos diferentes são gerados
aleatoriamente e somente os mais adaptados sobrevivem. O fundamento básico é criar
indivíduos (população), avaliar, seleccionar os mais aptos, realizar o cruzamento de seus
“códigos genéticos”, e gerar novos indivíduos, que possivelmente são mais adaptados
ao ambiente (Vieira & Macedo, 2011). Neste trabalho, os indivíduos são as possíveis
soluções de horários que serão designados de cromossomas.
Os operadores genéticos são responsáveis pela evolução da população. Quando são

criados os indivíduos, estes ainda não estão aptos a ser uma solução. Para isso, são
utilizados os operadores de selecção, cruzamento e mutação, que farão com que os
indivíduos evoluam e cheguem a ser uma solução (Lenzi, 2004).
A operação de selecção é responsável pela escolha dos indivíduos. A possibilidade de

um individuo permanecer ou ser copiado para uma nova geração é feita na operação de
selecção e é determinada pelo seu valor de adaptação. O valor de adaptação (fitness) é
calculado pela função de avaliação (Lenzi, 2004).
Segundo (Lenzi, 2004), existem vários métodos de selecção como o método da Roleta
Giratória, a selecção por Classificação, a Selecção de Estado Seguro e a selecção por
Torneio ou Elitismo. Neste trabalho, cerca de 20% dos indivíduos serão sorteados por
elitismo e o restante pela roleta giratória.
26
A etapa de mutação consiste na alteração dos genes dos indivíduos gerados para evitar
a estagnação da população após o cruzamento dos mesmos. Isto ocorre porque
indivíduos com grande grau de adaptação se diferenciam muito do restante da
população, sendo eles seleccionados repetidamente (Lenzi, 2004).
Na figura 1 está ilustrado o ciclo de execução de um AG. Primeiramente, é gerada uma

população inicial. De seguida os indivíduos são avaliados através de uma função de
avaliação (fitness). Na etapa seguinte, uma condição de parada é testada, que pode ser
uma quantidade fixa de gerações ou um valor médio de fitness para a população. Através
do fitness de cada indivíduo é realizada a selecção para participar da etapa de
reprodução. Depois é realizada a mutação nos indivíduos criados, o que possibilita o
surgimento de novas soluções. Por fim, uma nova população é composta e o processo
se repete (Vieira & Macedo, 2011).
27
Figure 1: Fluxograma de um algoritmo genético
Fonte: Adaptado de (Vieira & Macedo, 2011)
2.3. Avaliação de alguns sistemas existentes de gestão de horários
Existem muitas aplicações para a gestão de horários na Internet. Estas são de diferentes
tipos, algumas com licenças gratuitas e outras não, implementadas com diferentes
tecnologias, sendo algumas Web e outras desktop. Assim, antes de ser apresentada a
28
proposta de solução, entendeu-se ser de extrema importância, investigar e analisar cada
uma dessas opções de software e tentar avaliar como é que estas se encaixariam no
domínio em estudo. A seguir, apresenta-se 2 aplicações e uma proposta de solução
desenvolvida na FENG pela engenheira (Aly, 2016), de forma a serem avaliadas como
potenciais soluções para resolver o problema de gestão de horários da Faculdade de
Engenharia da UEM.
2.3.1. Cronos
É um sistema baseado na tecnologia web e pago, que gera automaticamente os horários

com base nas necessidades e restrições do utilizador. Segundo (Cronos, 2019), este
sistema possui as seguintes características:
 Sistema WEB com acesso restrito e seguro: O Cronos não precisa ser
instalado no seu computador pois sua utilização é pela Internet a partir do cadastro
feito pela instituição de ensino.
 Garantia de horários sem Choques: Utilizando inteligência artificial e modelos
matemáticos o Cronos é capaz de garantir a geração de horários com qualidade,
ou seja, sem nenhum choque de professores.
 Obedecendo a todas as restrições dos professores: Os horários gerados pelo
Cronos atendem a todas as restrições dos professores. E quando isso não é
possível, o sistema sugere modificações simples aos usuários.
 Parâmetros configurados pelo usuário: O Sistema possui ainda outros
parâmetros que podem ser configurados pelo usuário, como por exemplo a
eliminação de aulas triplas, aulas geminadas e aulas isoladas.
 Permite modificações em um horário já gerado: Após a elaboração do horário,
o usuário poderá utilizar o módulo de Trocas Automáticas do Cronos para
melhorar ainda mais seu horário.
Esta solução resolve muitos problemas gerais enfrentados pelas instituições na gestão
de horários, entretanto, alguns problemas específicos da FEUEM, como por exemplo a
29
impossibilidade de negociação entre professores e a impossibilidade de modificações
dos horários pelos professores, não são abordadas. A despeito destas desvantagens,
este sistema não é gratuito. Por essas razoes, não constitui uma solução ideal deste
problema.
2.3.2. GridClass
É um sistema de gestão de horários online que gera horário desde os mais simples aos
meus complexos, e que é acedido através da criação de uma conta. Este sistema não
impõe nenhum requisito de armazenamento aos seus utilizadores, sendo que os dados
são armazenados na nuvem (WPensar, 2019). Os diferenciais desse sistema em relação
aos outros são descritos por (WPensar, 2019), dos quais incluem:
 Gestão de Multiunidades: permite cadastrar o nome da (s) unidade (s) com

endereço completo. Permite especificar quanto tempo corresponde ao
deslocamento dos professores entre suas unidades.
 Professores e disponibilidades: assim como o cronos, este sistema permite
Cadastrar professores e solicitar sua disponibilidade de horário, economizando
muito tempo dos coordenadores de professores.
 Parceiros e Chancelas: Conta com o apoio de empresas de tecnologia
reconhecidas mundialmente: Microsoft e IBM.
 Permite Inserir valor de hora/aula dos professores e saiba qual é o seu custo
operacional
A despeito dos benefícios que este sistema oferece, este possui como principais
desvantagens o facto de não atender os problemas específicos da FEUEM como por
exemplo não permitir negociações e de ser um sistema pago.
2.3.3. Sistema proposto pela engenheira Kida
Este sistema aborda vários requisitos impostos pela faculdade, entretanto, a elaboração
de horários usando este sistema ainda requer esforços por parte do utilizador. O
30
utilizador deve se preocupar se a carga horaria foi completa, o utilizador ainda deve
preocupar-se em como deve alocar as aulas de modo a não provocar choques. Esta
abordagem apesar de garantir sempre uma solução aceitável, esta pode não ser a
óptima. Outra desvantagem diz respeito ao tempo gasto, sendo que quem elabora o
horário ainda são pessoas, o sistema apenas dá sinal quando uma certa restrição for
violada. A funcionalidade de negociações de aulas não foi implementada e os
professores não podem editar o horário. Diante destes factos conclui-se que esta não
seria uma solução viável para este problema.
31
Capítulo III – Caso de Estudo
32
3.1. Descrição da situação actual do processo de elaboração de horários do
DEEL
A Faculdade de Engenharia foi fundada em 1962, e actualmente possui cinco

departamentos académicos, nomeadamente: departamento de engenharia civil (DECI),
engenharia electrotécnica (DEEL), engenharia mecânica (DEMA), engenharia química
(DEQUI) e cadeiras gerais (DCG) (FEUEM, 2019). O DEEL oferece três cursos de
licenciatura dos quais incluem, engenharia eléctrica, electónica e informática.
Actualmente, o processo de elaboração dos horários do DEEL se dá da seguinte forma.

Inicialmente, o chefe do Departamento de Cadeiras Gerais elabora a parte dos horários
relativos às disciplinas de tronco comum, tendo em vista a disponibilidade e capacidades
das salas. As disciplinas de tronco comum, ou seja, as cadeiras gerais são aquelas que,
em princípio, influenciam os horários de todos os cursos (Aly, 2016).
O autor (Aly, 2016) ainda continua dizendo que em princípio as aulas das cadeiras gerais
devem decorrer nas salas de aula do Departamento de Cadeiras Gerais e só, quando
existir falta de salas, é que se requisita as de outros departamentos. Existem cadeiras
gerais que são comuns em determinados cursos, sendo por vezes necessário juntar as
turmas, facto que acontece com as aulas teóricas.
No Departamento de Cadeiras Gerais, a disponibilidade dos docentes não é tida em

conta, apesar de ser prática em alguns cursos pedir-se que os docentes preencham uma
ficha relativa à sua disponibilidade. Portanto, os docentes das Cadeiras Gerais devem
adaptar-se ao horário, e só em casos muito raros é que estes conseguem negociar uma
alteração do mesmo (Aly, 2016).
O autor ainda continua dizendo que depois da alocação feita pelo Departamento de
Cadeiras Gerais, os horários dos cursos são enviados aos respectivos departamentos,
cujos Diretores do Curso são responsáveis por fazer a alocação das cadeiras que
33
pertencem ao departamento em causa. A direcção começa por enviar um documento
para os docentes, onde estes podem especificar a sua disponibilidade. Com base na
disponibilidade dos docentes, nas cadeiras do semestre, na capacidade das salas, o
horário é elaborado.
As aulas das cadeiras do departamento normalmente decorrem nas salas do

departamento. No entanto, quando existe necessidade, podem ser requisitadas salas de
outros departamentos. É possível ainda alocar e reservar várias salas para a mesma
aula. Como pode ser visto nos parágrafos anteriores, este processo é bastante complexo
e demorado, e no entanto, muitas vezes, os horários propostos são conflitantes. A seguir
é mostrado na figura abaixo um esquema que mostra os órgãos envolvidos neste
processo e sua interdependência.
Figure 2: Fluxo do processo de elaboração de horários da Faculdade de Engenharia
Fonte: adaptado de (Aly, 2016)
34
No final das contas, os responsáveis pela elaboração de horários devem ter elaborado 3
tipos de horários: Horários dos cursos por ano; Horários das salas de aulas e Horários
dos docentes.
3.2. Constrangimentos da situação actual
Os horários da faculdade são elaborados de forma manual, facto que requer muito tempo
de trabalho. Conforme foi discutido anteriormente, são muitas as restrições a ter em
conta no processo de elaboração de horários, portanto, é exigido um nível elevado de
concentração e atenção.
Após a elaboração dos horários, estes podem conter erros graves, por exemplo,
docentes alocados às várias aulas ou então salas alocadas a diferentes aulas ao mesmo
tempo. Este problema, se não for descoberto a tempo, os alunos podem correr o risco
de perder aulas por um longo período de tempo.
A despeito dos problemas apresentados nos parágrafos anteriores, tem sido um facto na
Faculdade de Engenharia da Universidade Eduardo Mondlane (UEM) existência de
problemas referentes a modificações do horário nas primeiras semanas de aulas depois
de este ter sido publicado, mediante negociações entre os professores ou entre
professores e a turma em causa. Esta situação pode prejudicar a organização dos
próprios estudantes e ate mesmo incorrer-se a outros problemas relacionados com o uso
dos recursos que compõem o problema de horários apresentados no capítulo II.
Diante desses factos, surge a necessidade de desenvolver uma proposta de solução

para gestão dos horários da faculdade de engenharia.
35
Capitulo IV – Desenvolvimento do trabalho
36
4.1. Descrição da solução
O sistema proposto, é Web e tem como objectivo facilitar o processo de elaboração de

horários e alocação de salas e professores. Este sistema é baseado em AGs e trabalha
com dois módulos principais: Cadastro de informações (como por exemplo dados de
professores, de disciplinas, de salas, disponibilidades dos professores, cursos) e o
módulo onde é feita a busca pela solução mediante o Algoritmo Genético.
No sistema, considera-se que os cursos de laboral são diferentes dos cursos de pós-
laboral. Isto, porque as cadeiras previstas para decorrer em determinado semestre de
laboral são por vezes diferentes das previstas para decorrerem em pós-laboral. Outra
questão, é o facto de, normalmente, os cursos de laboral decorrerem em 4 anos e os de
pós-laboral em 5 anos. Assim, fica mais fácil considerá-los como cursos diferentes, e por
isso, no sistema existe a Engenharia Informática Laboral e Engenharia Informática Pós-
Laboral como cursos diferentes.
Os horários da Faculdade são elaborados em duas fases: primeira fase é da

responsabilidade do Departamento de Cadeiras Gerais e a outra do Departamento do
respectivo curso (Aly, 2016). Este facto, em particular, foi tido em consideração na
definição dos requisitos do sistema. O sistema prevê 4 tipos de utilizadores: os
Professores, os Directores dos Cursos, o Chefe do Departamento de Cadeiras Gerais e
o Administrador. As responsabilidades e privilégios destes serão discutidos a seguir.
O sistema disponibiliza três tipos de horários: os horários das turmas, os horários das
salas e os horários dos docentes.
4.1.1. Utilizadores
Como fora referenciado na secção anterior, o sistema prevê 4 tipos de utilizadores, que
estes são diferenciados pelo sistema através do inteiro nível de acesso. O administrador
tem nível de acesso igual a 1, os directores dos cursos nível 2, o chefe do Departamento
de Cadeiras Gerais nível 3 e os Professores nível 4.
37
As principais responsabilidades dos professores são: especificar a sua disponibilidade
antes de serem elaborados os horários, Editar horários caso estes não contemplem sua
disponibilidade, Negociar troca de horários com outros professores e podem visualizar
os horários das turmas em que estão alocados.
O chefe do Departamento de Cadeiras Gerais é responsável por informar a parte de

disciplinas relativas às cadeiras gerais, visualizar os horários gerados, imprimir os
horários gerados e modificar seu perfil.
Os directores dos cursos são responsáveis por informar a parte das disciplinas relativas
aos cursos a que se encontram associados, validar as modificações de horários feitas
pelos professores, visualizar e imprimir os horários e modificar seu perfil.
O administrador tem acesso a maior parte da informação do sistema, sendo este

responsável por cadastrar utilizadores, cursos, salas, professores, disciplinas e atribuir
níveis de acesso. Também é responsável em criar uma nova geração de horários,
visualizar e imprimir os horários e modificar seu perfil.
4.1.2. Fluxo de funcionamento
Inicialmente o administrador dá a conhecer ao sistema o início de uma nova geração de

horários. O administrador especifica o semestre, para que o sistema mostre aos
utilizadores as cadeiras disponíveis para fazer a selecção. A seguir, o sistema envia
notificações a todos utilizadores (professores, directores dos cursos e chefe do
departamento de cadeiras gerais) que participam da elaboração dos horários a fim de
fornecerem as informações que sistema precisa. Os professores devem especificar a
sua disponibilidade para aquele semestre. O chefe do Departamento de Cadeiras Gerais
informa, para cada curso, as disciplinas relativas às cadeiras gerais. Os Directores dos
Cursos informam as disciplinas relativas aos seus respectivos cursos.
Após os utilizadores informarem os dados que o sistema necessita, estes são enviados
ao algoritmo genético que fara a busca da melhor solução, considerando no máximo,
38
todas as restrições impostas. Após encontrada a solução, o sistema disponibiliza o
horário aos utilizadores.
Se o horário não satisfazer as preferências dos professores, estes podem modificá-lo

caso hajam possibilidades para tal. Se não houver possibilidades de modificações no
horário, os professores podem efectuar negociações com outros professores. Não
haverá possibilidades de modificar os horários se todas as propostas de modificações
não atenderem as restrições do tipo hard constraints, pós estas inviabilizam o horário.
Após os horários sofrerem modificações, estas precisam ser validadas pelo respectivo
responsável (directores dos cursos). Só depois da validação os horários podem ser
publicados aos utilizadores e disponibilizados nas vitrinas dos departamentos.
4.1.3. Requisitos
Segundo (Sommerville, 2001), os requisitos de um sistema são as descrições do que o

sistema deve fazer, os serviços que oferece e as restrições do seu funcionamento. Esses
requisitos devem reflectir as reias necessidades dos utilizadores do sistema. Em
engenharia de software, o processo de elaboração dos requisitos é conhecido como
engenharia de requisitos.
4.1.3.1. Requisitos Funcionais
Os requisitos funcionais descrevem aquilo que o sistema deve fazer e estes dependem
do tipo de software a ser desenvolvido, de quem são os seus possíveis utilizadores e da
abordagem geral adoptada pela organização (Sommerville, 2001).
Olhando para a descrição da problemática do presente trabalho, foram identificados os

seguintes requisitos funcionais:
RF01: O Sistema deve permitir criar uma nova geração de horários.
39
RF02: O Sistema deve permitir aos docentes especificar a sua disponibilidade para o
semestre;
RF03: O Sistema deve permitir aos utilizadores visualizarem os 3 tipos de horários:

horário de determinado curso, horário de ocupações das salas e horário dos docentes.
RF04: O Sistema deve permitir aos utilizadores imprimirem os 3 tipos de horários: horário
de determinado curso, horário de ocupações das salas e horário dos docentes.
RF05: O Sistema deve permitir que os professores editem seus horários caso sua
preferência não esteja satisfeita;
RF06: O Sistema deve permitir que os professores façam negociações entre eles nos
horários em que estão alocados;
RF07: O Sistema deve permitir ao chefe do departamento das cadeiras informar as

disciplinas relativas as cadeiras gerais;
RF08: O Sistema deve permitir aos directores dos cursos informarem as disciplinas
relativas ao respectivo curso;
RF09: O Sistema deve permitir aos directores validarem as alterações feitas pelos
professores nos horários.
RF10: O Sistema deve permitir aos professores responderem aos pedidos de troca de
horários enviados pelos outros professores.
RF11: O Sistema deve permitir ao administrador alterar as definições do sistema como

por exemplo a carga horária diária máxima e mínima de cadeiras.
RF12: O Sistema deve permitir ao administrador registar utilizadores, cursos, salas e

disciplinas.
RF13: O Sistema deve permitir aos utilizadores modificarem seus perfis.
40
4.1.3.2. Requisitos não funcionais
Requisitos não funcionais são definidos por (Sommerville, 2001) como aqueles que não
estão directamente relacionados com os serviços oferecidos pelo sistema a seus
utilizadores. Estes podem estar relacionados com confiabilidade, desempenho ou
disponibilidade.
Olhando para a descrição da problemática do presente trabalho, foram encontrados os

seguintes requisitos não funcionais do sistema:
RNF01: Usabilidade
A interface do utilizador do sistema deve ser agradável, objectiva e trivial ao utilizador,

Suas funcionalidades e informações deverão estar bem visíveis e disponíveis, a
comunicação do sistema com o utilizador deverá ser simples e intuitiva.
RNF02: Desempenho
O sistema deve apresentar tempos de resposta pequenos aos pedidos do utilizador

assim como na execução do AG.
RNF03: Escalabilidade
Esta é uma característica desejável de todo o sistema, é uma propriedade que lhe
confere a capacidade de ajustar seu desempenho em função da carga, quando mais
recursos forem acrescentados a ele devido as necessidades externas tanto em Hardware
como em Software.
RNF04: Interoperatividade
O sistema deve se comunicar com os já existentes e permitir que outros sistemas

também se intercomuniquem com este para poder se extrair informação.
RNF05: Segurança
41
O sistema deverá permitir que somente pessoas autenticadas e autorizadas façam uso
das funcionalidades do mesmo.
RNF06: Disponibilidade
O sistema deve estar disponível a seus utilizadores sempre que os mesmos necessitem
dele.
4.1.4. Casos de uso
Segundo (Jacobson et al., 1993) citado por (Sommerville, 2001), os diagramas de casos
uso são uma técnica de descoberta de requisitos, e o conjunto de todos casos de uso
representa todas as possíveis interacções que serão descritas nos requisitos de
sistemas, os requisitos funcionais. O diagrama da figura abaixo, foi desenhado usando
a ferramenta astah UML na sua versão 8.1.0.
42
Figure 3: Diagrama de casos de uso
4.1.4.1. Descrição dos casos de uso
De acordo com (Larman, 2005), existe uma diferença entre modelos de casos de uso e
casos de usos. A modelagem de casos de uso é essencialmente uma acção de redigir
texto e não de desenhar diagramas ao passo que modelos de casos de uso são
diagramas. A seguir é apresentada a descrição dos casos de usos do sistema proposto.
43
Nome CU01: Criar uma nova geração de horários
Actores Administrador
1. Escolher a opção Horário no menu

Fluxo básico 2. Clicar a opção “nova geração de Horário”.
3. Seleccionar o semestre e clicar no botão Criar novo Horário
Tipo Primário, essencial
Referências RF01
Pré-condições
Ter feito login e ter nível de acesso igual a 1
Table 1: Descrição do caso de uso CU01
Nome CU02: Especificar disponibilidade
Actores Professor
1. Escolher a opção Horário no menu.

2. Clicar a opção “disponibilidade”.
Fluxo básico
3. Marcar com X todos os períodos em que estará disponível.
4. Confirmar.
Referências RF02
Pré-condições Ter feito login e ter nível de acesso igual a 4

Nome CU03: Visualizar horários
Actores Todos utilizadores do sistema.
Fluxo básico 1. Escolher a opção Horário no menu.
44
2. Clicar a opção “Horários gerados”.
3. Seleccionar o semestre e clicar em confirmar.
Referências RF03
Pré-condições Ter feito login

Nome CU04: Imprimir horários
Actores Todos utilizadores do sistema.

Fluxo básico
3. Seleccionar o semestre e clicar no botão Confirmar.
4. Imprimir.
Referências RF04

Nome CU05: Editar horários
Actores Professor, director do curso

3. Seleccionar o semestre e clicar no botão confirmar.
Fluxo básico
4. Efectuar as modificações do horário arrastando as aulas para o
local disponível que deseja.
5. Confirmar.
45
Referências RF05
Pré-condições Ter feito login e possuir nível de acesso 4 ou 2

Nome CU06: Negociar a troca no horário
Actores Professor

Fluxo básico 3. Seleccionar o semestre e clicar no botão confirmar.
4. Efectuar a troca da aula arrastando para o local da outra aula.
5. Confirmar.
Referências RF06
Pré-condições Ter feito login e possuir nível de acesso 4

Nome CU07: Informar as disciplinas relativas as cadeiras gerais
Actores Chefe do depart. das cadeiras gerais

2. Clicar a opção “Informar disciplinas”.
Fluxo básico 3. Seleccionar o semestre e clicar no botão confirmar.
4. Marcar todas as disciplinas para todos os cursos.
5. Confirmar.
46
Referências RF07

Nome CU08: Informar as disciplinas relativas ao respectivo curso
Actores Director do curso
Fluxo básico 1. Escolher a opção Horário no menu.

2. Clicar a opção “Informar disciplinas”.
3. Seleccionar o semestre e clicar no botão confirmar.
4. Marcar todas as disciplinas do determinado curso.
5. Confirmar.
Referências RF08

Nome CU09: Validar as alterações feitas pelos professores nos horários
Actores Director do curso

Fluxo básico 3. Seleccionar o semestre e clicar em confirmar.
4. Seleccionar a lista de requisições
5. Confirmar/Recusar
Referências RF09
47
Nome CU10: Responder pedidos de troca de horários
Actores Professor

Fluxo básico 3. Seleccionar o semestre e clicar em confirmar.
4. Seleccionar a lista de pedidos
5. Confirmar/Recusar
Referências RF10

Nome CU11: Alterar as definições do sistema
1. Escolher a opção Definições no menu.

Fluxo básico 2. Informar os parâmetros de configuração do sistema no painel.
3. Clicar em confirmar.
Referências RF11

48
Nome CU12: Registar utilizadores
1. Escolher a opção Utilizadores no menu.

2. Introduzir os dados do utilizador.
Fluxo básico 3. Atribuir nível de acesso. Se for nível de acesso 2, associar a um
determinado curso.
Referências RF12

Nome CU13: Modificar perfil
Actores Todos os utilizadores do sistema
1. Escolher a opção Utilizadores no menu.

2. Selecionar a opção perfil.
Fluxo básico
3. Fazer as alterações desejadas.
Referências RF13
Nome CU13: Registar sala
49
1. Escolher a opção Dados do Horário no menu.
Fluxo básico 2. Introduzir os dados da sala.
Referências RF12
Pré-condições Ter feito login e possuir nível de acesso igual a 1

4.1.5. Modelagem do problema pelo algoritmo genético
4.1.5.1. Diagrama de classes que será usado pelo AG
O diagrama abaixo representa as classes que interagem com o algoritmo genético

fornecendo dados para gerar o horário.
50
Figure 4: Diagrama de classes
4.1.5.2. Representação do cromossoma
Como foi referenciado no capítulo II, cada cromossoma representa uma possível
solução, ou seja, um horário completo. Cada cromossoma será representado por um
vector de tamanho variável de acordo com o número de total de aulas ministradas no
departamento. Supondo que cada turma tem duas aulas por dia (vide tabela 1), logo,
essa turma terá semanalmente dez aulas, ou seja o tamanho do cromossoma será dez.
E, se existir três turmas, multiplicado pelas dez aulas têm-se trinta aulas (o que
51
corresponde ao tamanho do cromossoma), onde de um a dez pertencem a primeira
turma, de onze a vinte a segunda turma e assim sucessivamente.
Figure 5: Estrutura do cromossoma
Fonte: Adaptado de (Lenzi, 2004)
Como cada turma possui dez aulas diferentes, as posições 11 a 20 correspondem as

aulas da segunda turma, onde a posição 11 armazenará o código da aula a ser
ministrada no tempo 1 (segunda, das 11:45 às 13:30), a posição 12 ao tempo 2 e assim
sucessivamente, fechando o ciclo na posição 20 e reiniciando-o na posição 21 para a
turma 3. O índice do vector, diz respeito ao tempo que a aula será ministrada, de acordo
com a figura 4.
Figure 6: Quadro de Horários
52
A informação que será armazenada no vector será o código da aula de acordo com a
posição que ela foi cadastrada no vector de aulas.
A relação entre o objecto aulas e o cromossoma é dada da seguinte maneira: o

cromossoma armazenará o valor do índice do vector aulas e através desse valor podem
se buscar as informações referentes àquela aula, como o professor que irá leccionar, a
turma e a disciplina, como mostra a figura 5.
Figure 7: Objecto Aula e sua relação com cromossoma
4.1.5.3. Inicialização da população
A partir da estrutura criada na secção 1.9.5.2, será criada uma população com vários
cromossomas. A forma de inicialização da população ocorrerá da seguinte maneira: o
primeiro cromossoma será inicializado sequencialmente, mas a partir do segundo
cromossoma, irá acontecer um deslocamento de uma casa a cada doze posições como
mostra a figura 6.
53
Figure 8: População de cromossomas
Com base nesta inicialização, problemas como a ocorrência de choque entre turmas,
turma com disciplina de outra turma, entre outros, serão resolvidos.
O deslocamento serve para não deixar os cromossomas todos iguais e haver mudanças
no cruzamento, porque se os cromossomas fossem iguais, os cromossomas filhos
seriam iguais aos cromossomas pais, como mostra a figura 7.
Figure 9: Cruzamento entre cromossomas iguais
54
4.1.5.4. Função de Avaliação
Para desenvolver a função de avaliação, devem ser levados em conta as seis restrições
do tipo hard constraints, discutidas no capítulo II:
 Choque entre turmas;

 Turma com disciplina de outra turma;
 Turma sem alguma de suas disciplinas;
 Choque entre professores;
 Choque de salas
 Disponibilidade dos professores.
Com o tratamento dessas seis restrições, consegue-se criar uma função de avaliação
que seja capaz de avaliar cada cromossoma e dizer o quão perto ele está da solução.
Abaixo segue a explicação para cada uma das restrições:
Choque entre turmas: de acordo com a estrutura do cromossoma, não há

possibilidades de haver choque entre turmas, pois a forma de inicialização não é
aleatória, e sim sequencialmente com um deslocamento de uma casa (vide figura 7).
Desta forma, as aulas de determinada turma serão distribuídas entre as 10 posições
relacionadas a ela, evitando que sejam alocadas em duas posições que indicam o
mesmo hora, por exemplo 1 e 11.
Turma com disciplina de outra turma: não ocorrerá devido à forma de inicialização.
De acordo com o cadastro das disciplinas, que deverão ser cadastradas na sequência
de turmas, nas posições de 1 a 10 só estarão as disciplinas da primeira turma; da posição
11 a 20 só estarão as disciplinas da segunda turma e assim até o final do cromossoma.
Turma sem alguma de suas disciplinas: pode vir a ocorrer, pois após o cruzamento
dos cromossomas, alguma disciplina pode desaparecer do cromossoma, mas para isso
55
não prejudica o resultado, o sistema irá percorrer cada 10 posições no cromossoma
(turma) e verificar se alguma disciplina está faltando para aquela turma específica.
Choque entre professor (choque ente salas funciona da mesma forma): poderá
ocorrer, mas o sistema irá percorrer o cromossoma de 10 em 10 posições para verificar
se há choque entre professor, por exemplo, o sistema irá verificar as posições 1, 11, 21,
31, 41, 51, 61 e 71 e comparar se há o mesmo professor em turmas distintas na mesma
hora.
A figura 8 mostra um cromossoma com choque de professores cujo código é 10, na

segunda-feira às 07:00 horas. Este processo é repetido, sendo iniciado da posição 2, 3,
4 e assim por diante.
Figure 10: Choque entre professores
56
Disponibilidade dos professores: o sistema irá percorrer posição por posição do
cromossoma para verificar se o horário em que o professor está alocado confere com o
horário de disponibilidade do mesmo, como mostra a figura 12.
Figure 11: Disponibilidade do professor
Neste caso a aula 5 foi alocada na segunda-feira às 08:50 hora. O professor responsável
por esta aula é o 8 (como mostra o Objecto Aulas), que está disponível neste horário,
como mostra o Objecto Disponibilidades.
Todo cromossoma iniciará com um valor de função de avaliação, que será decrementado
a cada restrição violada. O valor inicial e a quantia decrementada para cada tipo de
restrição só serão definidos após a implementação e os testes do sistema.
57
4.1.5.5. Operadores genéticos
4.1.5.5.1. Selecção
Como foi referenciado no capítulo II, existem vários métodos de selecção como o método
da Roleta Giratória, a selecção por Classificação, a Selecção de Estado Seguro e a
selecção por Torneio ou Elitismo. Neste trabalho, cerca de 20% dos cromossomas serão
sorteados por elitismo e o restante pela roleta giratória.
4.1.5.5.2. Cruzamento
Existem algumas técnicas de cruzamento como a de um ponto de quebra, a de dois ou

mais pontos de quebra e o cruzamento uniforme. Neste trabalho será utilizada a técnica
do cruzamento uniforme.
4.1.5.5.3. Mutação
Uma probabilidade de mutação será atribuída. Como exemplo considerar-se-á que os

cromossomas têm 90% de chance de não serem submetidos à mutação. Então o sistema
verifica se o cromossoma será mudado ou não, sorteando um número de 1 a 100. Se
esse valor estiver entre 1 e 90, o cromossoma não será mudado, mas se estiver entre
91 e 100, o cromossoma será mudado. Sabendo que o cromossoma será mudado, o
sistema sorteia um ponto no cromossoma onde será feita a mutação, por exemplo,
sorteia-se o número 4, então na posição 4 do cromossoma será feita a alteração do seu
valor, que também um número será sorteado. Porém esse valor será sorteado dentro
dos valores possíveis para aquela turma.
4.1.6. Proposta de Arquitectura para o sistema
O desenho da arquitectura do sistema proposto baseia-se no modelo de três camadas,

que segundo (Sommerville, 2011) citado por (Manhiça, 2013) se resume no seguinte:
58
Figure 12: Arquitectura de três camadas
Fonte: Adaptado de (Manhiça, 2013)
Este padrão provê maior independência para cada camada, facilitando o

desenvolvimento, uma vez que alterações em uma camada não refletem nas demais
(Vieira & Macedo, 2011).
Desta maneira, a primeira camada fornece a interface aos utilizadores, que lhes
permitem relacionar e utilizar os recursos dedicados ao sistema. Na camada seguinte, a
camada de negócio, é onde se vai apresentar todas as regras que o sistema deve conter,
de acordo com o propósito e as normas para as quais devem ser aplicadas no contexto
do processo de geração de horários na faculdade de engenharia. E por fim, a camada
de dados representa o modo de conservação e alocação dos dados no sistema, isto é,
as informações necessárias para a operabilidade do sistema devem ser enviadas e
tratadas nessa camada com interacção com a base de dados.
59
4.1.7. Tecnologias Utilizadas
Para o desenho das interfaces utilizou-se o angular na sua versão 8.2.14, que segundo
(Afonso, 2019) é uma plataforma e framework construção de interface de aplicações
usando HTML, CSS e, principalmente JavaScript, criada pelos desenvolvedores do
Google. Este framework oferece algumas vantagens como suporte a arquitectura MVC,
produtividade e usa ECMAScript para especificação dos seus scripts.
Também foi usado Google Material Design que segundo (Devmedia, 2019) é uma
linguagem de design criada para o novo sistema operativo do Google Android 5.0 –
Lollipop. Embora esta linguagem seja inicialmente criada para uso em aplicativos mobile,
também pode ser estendida para web. A outra vantagem é ser compatível com angular,
visto que ambos são da Tecnologias desenvolvidas pela mesma empresa, a Google.
Na camada de negócio do modelo MVC foi usado o framework laravel, que segundo
(Roberto, 2019) é um framework de desenvolvimento rápido para PHP, livre e de código
aberto, cujo principal objectivo é permitir que se trabalhe de forma estruturada e rápida.
A razão da escolha deste framework foi por ser livre com uma comunidade de
desenvolvedores maduros, e também pelo interesse que o autor tem em aprender esta
tecnologia.
Quase todos os servidores Web podem ser utilizados com o PHP, no entanto, foi
seleccionado o servidor Apache pelo facto de ser livre e de código aberto.
Na camada de dados, foi usada MySQL que é o sistema de Gestão de Base de Dados.
Os factos que levaram a sua escolha são: A alta compatibilidade com o PHP, Facilidade
no manuseio adquirida pelo auto.
As ferramentas usadas durante o desenvolvimento são: Figma (que é uma ferramenta

de prototipagem), astah UML (que é uma ferramenta para modelar diagramas UML), e
Netbeans (que é uma IDE). A principal razão da escolha dessas ferramentas é por serem
gratuitas.
60
4.2. Apresentação do protótipo
Em primeiro lugar, o Administrador deve dar a conhecer ao sistema o início de uma nova
geração de horários. Para isso, O administrador deve especificar o semestre e clicar no
botão confirmar.
Figure 13: Criação de uma nova geração de horários
A seguir, o sistema envia notificações para os utilizadores a fim de dar continuidade com
o processo de geração de horários. Os directores dos cursos e o chefe do departamento
das cadeiras gerais devem informar ao sistema as cadeiras previstas para decorrer no
respectivo semestre e os professores devem especificar sua disponibilidade.
61
Figure 14: Director do curso informa as aulas ao sistema
Os utilizadores com nível de acesso 2 (directores dos cursos) podem informar ao sistema
as aulas prevista para semestre, bastando apenas clicar em Horários > Informar
Disciplinas. Depois deve informar o semestre e logo depois a tabelas de disciplinas será
apresentada, dai basta apenas marcar as disciplinas e confirmar.
O mesmo procedimento é valido para o utilizado de nível de acesso 3 (chefe do

departamento das cadeiras gerais).
62
Figure 15: Edição do horário por parte dos professores
Os utilizadores do nível de acesso 4 (professores) tem o privilegio de fazer alterações no

horário depois deste ter sido criado, bastando apenas navegar em Horários > Horários
Gerados, selecionar o semestre e arrastar a aula para o local que deseja. Essa alteração
será possível se não violar nenhuma restrição do tipo hard constraints discutida no
capítulo II. Depois da alteração, uma notificação será enviada para o director do
respectivo curso para sua validação.
63
Figure 16: Negociação de troca de aula entre professores
Quando o professor arrasta uma aula para um local ocupado por outra aula significa que
está enviando um pedido de troca de aulas para o outro professor. O sistema enviará
uma notificação de pedido de troca para o outro professor e este, pode aceitar a troca ou
recusar.
64
Figure 17: Resposta do pedido de trocas de aulas
O professor pelo qual foi enviado o pedido de troca de aula pode visualizar todas os
pedidos na lista de Requisições. Para confirmar ou recusar basta selecionar o pedido e
clicar em confirmar / recusar. Ao selecionar a requisição, as aulas envolvidas serão
destacadas com uma cor azul no horário.
65
Figure 18: Validação das alterações do horário pelo director
Depois de ter sido feita as alterações nos horários, estas precisam ser confirmadas pelo
director do curso em causa. O processo de validação é semelhante com o processo de
resposta ao pedido de troca de aulas descrito anteriormente.
66
Capitulo V – Discussão de resultados
67
No presente trabalho fez se um estudo sobre o desenvolvimento de um sistema de
gestão de horários para faculdade de engenharia, concretamente para o DEEL.
O trabalho foi baseado, por um lado, na revisão de literatura (Capítulo II, que aborda
temáticas de interesse no assunto) e, por outro, em conhecimentos adquiridos na área
de desenvolvimento de software.
Através da revisão de literatura, foi possível demonstrar que O desenvolvimento de

programas e sistemas de computador para solucionar problemas de horários tem sido
tratado pela comunidade científica há mais de 40 anos, facto este que comprova a grande
importância que este sistema oferece às instituições académicas na gestão de seus
horários. Foi igualmente possível, através da revisão de literatura, obter, analisar e
elucidar sobre os aspectos técnicos relacionados ao desenvolvimento de aplicações com
as características discutidas.
Com os resultados da revisão de literatura, desenhou-se (no capítulo IV) o projecto de

sistema de gestão de horários académicos. O modelo desenvolvido não incluiu a gestão
de requisições de pedidos de alterações de horários, que é um problema abordado na
teoria de filas, a inclusão de tal requisito demandaria muito tempo de desenvolvimento e
pesquisa. Igualmente, aspectos ligados a implementação do sistema no ambienta de
produção, como por exemplo em que servidor será hospedado o sistema e qual é o custo
de implementação, não foram contemplados neste trabalho. E também como foi
mencionado no capítulo I, a parte da codificação ainda esta em processo sendo que a
previsão de término é de duas semanas e alguns dias.
O sistema proposto, apesar de não completamente implementado, apresenta vantagens

em relação aos sistemas estudados na revisão bibliográfica. Com efeito, fazendo se uma
comparação do sistema proposto no presente trabalho com os sistemas já existentes,
pode se dizer que estes sistemas, embora funcionais e tenham provado ajudarem nas
regiões em que eles são implementados, não se encaixam na realidade do domínio do
caso de estudo do presente trabalho, e daí serem incapazes de satisfazer os requisitos
que o presente trabalho propõe. Como parte dos sistemas estudados, está o sistema
68
desenvolvido na faculdade de engenharia pela engenheira Kida, este sistema embora
contemple maior parte dos requisitos funcionais do sistema, a solução ainda requer uma
grande intervenção humana, facto este que pode comprometer a performance desta
tarefa e não garantir gerar a melhor solução dentre as possíveis soluções existentes.
Para resolver estes problemas foram usados métodos da inteligência artificial,
especificamente os algoritmos genéticos, que garantirão gerar horários optimizados.
Os resultados obtidos tanto os do estudo quanto os da criação e implementação parcial

do modelo corresponderam parcialmente ao esperado dentro dos limites definidos no
trabalho.
69
Capítulo VI - Conclusões e recomendações
70
6.1. Conclusões
Conforme os objectivos estabelecidos no capítulo I, conclui-se que o trabalho possibilitou

o desenvolvimento de uma proposta de um modelo de sistema para gestão de horários
académicos do DEEL.
Actualmente na FEUEM, os horários são elaborados manualmente. Assim sendo,

requer-se um nível de concentração e atenção elevados e corre-se o risco de alunos
perderem aulas se os horários tiverem erros do tipo: vários docentes alocados à várias
aulas ao mesmo tempo. Paradoxalmente, embora tenham sido empreendidos esforços
mediante pesquisas com objectivo de abordar este problema, como é o caso da pesquisa
realizada pela engenheira Kida, estes problemas ainda têm sido real na faculdade.
Com este sistema de gestão de horários desenvolvido, espera-se diminuir o tempo gasto,
o nível de intervenção e concentração do utilizador exigido no processo de elaboração
de horários, permitir que os professores modifiquem e façam negociações no horário
antes de ser disponibilizado nas vitrinas e propõe também reduzir os erros cometidos
aquando da elaboração dos horários.
Neste sentido, nos limites de domínio e de tempo definidos e prolongados pelos docentes
para a realização do trabalho, foram alcançados de forma integral os objectivos inicias
colocados no capítulo I.
6.2. Recomendações
Como o sistema de geração de horários trabalha com informações do Sistema do

Registo Académico, como por exemplo números de estudantes inscritos, para trabalhos
futuros, sugere-se que se integre o Sistema de Gestão de Horários com o Sistema do
Registo Académico.
71
Recomenda-se também que nos trabalhos futuros se implemente a gestão das
modificações de horários feitos pelos professores através de técnicas abordadas na
teoria de filas. Isso possibilitara que haja a gestão de concorrência de requisições.
Por último, com o intuito de fornecer maior mobilidade, recomenda-se a implementação

deste sistema para a plataforma mobile.
72
Referências bibliográficas
Afonso, A. (25 de Novembro de 2019). algoworks. Obtido de

https://blog,algoworks.com/o-que-e-angular
Aly, K. d. (2016). Estudo e desenvolvimento de um sistema para gestão de horários na

faculdade de Engenharia da UEM. Maputo.
Bhattacharjya, R. K. (2013). Introduction To Genetic Algorithms.
Cronos. (25 de Novembro de 2019). Solução em Horários Escolares. Obtido de 4cis

Sistemas Ltda: https://www.cronostimetable.com/#about
Devmedia. (25 de 11 de 2019). Conheça o google Material Design. Obtido de

DEVMEDIA: https://devmedia.com.br/conheca-o-google-material-design/32364
FEUEM. (9 de Novembro de 2019). Historial da FEUEM. Obtido de Portal da Faculdade

de Engenharia: http://www.engenharia.uem.mz/index.php/sobrenos/historial
Góes, A. R., Costa, D. M., & Steiner, M. T. (2010). Otimização na programação de

horarios de professores/turmas: Modelo Matemático,Abordagem Heurística e
Método Misto. Brasil.
Gross, J. L., Yellen, J., & Zang, P. (2014). HANDBOOK OF Graph Theory (2nd ed.).
New York.
Lakatos, E. M., & Marconi, M. d. (1992). Metodologia do trabalho científico. São Paulo:
Editora Atlas S.A.
Mahanjane, E. P. (2019). Desenvolvimento de um sistema de apoio ao processo

educativo de pessoas com deficiência auditiva. Maputo.
Manhiça, R. (2013). ESTUDO E DESENVOLVIMENTO DE UMA PLATAFORMA DE

INFORMAÇÃO DE PREÇOS E MERCADOS AGRÍCOLAS EM MOÇAMBIQUE
BASEADA NAS TECNOLOGIAS DE INFORMAÇÃO E COMUNICAÇÃO.
Maputo.
Prodanov, C. C., & Freitas, E. C. (2013). Metodologia do trabalho científico: Métodos e

Técnicas da Pesquisa e do Trabalho Acadêmico. Rio grande do Sul, Brasil.
73
Roberto, J. (25 de Novembro de 2019). O que é Laravel? Porque usa-lo. Obtido de
Medium: https://medium.com/joaorobertopb/o-que-é-laravel-porque-usá-lo-
955c95d2453d
Sommerville, I. (2011). Engenharia de Software. São Paulo: Pearson Prentice Hall.
UEM. (7 de Novembro de 2019). Nota Historica. Obtido de Portal UEM:

https://www.uem.mz/index.php/sobre-a-uem/historial
Vieira, F., & Macedo, H. (2011). Sistema de Alocação de Horários de Cursos

Universitários: Um Estudo de Caso no Departamento de Computação da
Universidade Federal de Sergipe. São Cristovão, Brasil.
WPensar, G. (25 de Novembro de 2019). Compare o GridClass com os concorrentes.

Obtido de GridClass.com: http://gridclass.com.br/diferenciais.php
74
Anexos
75
DS01: Permite criar uma nova geração de horários
Figure 19: Descrição do diagrama de sequência DS01
DS02: Permite informar as disciplinas que farão parte do horário
76
DS03: Permite ao professor informar sua disponibilidade
77
DS04: Permite ao professor editar o Horária já elaborado
78
DS05: Permite ao utilizador editar seu perfil
79
DS06: Permite negociações de troca de aulas entre os professores
80
DS07: Permite ao professor responder os pedidos de troca de horário
81
DS08: Permite ao director do curso validar as modificações feitas no
horário
82
DS09: Permite ao utilizador visualizar os Horários gerados
83

PIA FINAL Zelito Atumane Saide

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

PIA FINAL Zelito Atumane Saide

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE EDUARDO MONDLANE

Curso de Licenciatura em Engenharia Informática

Projecto Integrado de Aplicativos

PROPOSTA DE DESENVOLVIMENTO DE SISTEMA DE GESTÃO DE HORÁRIOS

Caso de estudo: Geração de horários acadêmicos do DEEL

Maputo, Novembro de 2019

Curso de Licenciatura em Engenharia Informática

Projecto Integrado de Aplicativos

PROPOSTA DE DESENVOLVIMENTO DE SISTEMA DE GESTÃO DE HORÁRIOS

Caso de estudo: Geração de horários acadêmicos do DEEL

Maputo, Novembro de 2019

A todos que directas ou indirectamente fizeram parte da na materialização deste trabalho,

Palavras-chave: Algoritmos Genéticos, Gestão de salas, alunos, gestão de horários

Key words: Genetic Algorithms, management of classrooms, students, management of

Capítulo I – Introdução ............................................................................................... 12

1.3. Objectivos ........................................................................................................ 15

1.3.1. Objectivo geral ........................................................................................... 15

1.3.2. Objectivos específicos ............................................................................... 15

1.4.1. Questão de Pesquisa ................................................................................ 15

1.4.2. Classificação da metodologia .................................................................... 16

1.4.3. Técnicas de coleta de dados ..................................................................... 17

1.4.4. Técnicas de análise de dados ................................................................... 17

1.4.5. Metodologia do desenvolvimento do protótipo .......................................... 18

1.5. Organização do trabalho .................................................................................. 19

Capítulo II - Revisão de literatura............................................................................... 21

2.1. Problema de Horário ou Timetabling problem .................................................. 22

2.1.1. Descrição do Problema de Horário ............................................................ 22

2.1.1.1. Tempos ............................................................................................... 22

2.1.1.2. Recursos ............................................................................................. 22

2.1.1.3. Reuniões ............................................................................................. 23

2.1.1.4. Restrições ........................................................................................... 23

2.1.2. Classificação dos problemas de horários .................................................. 25

2.2. Algoritmo genético ........................................................................................... 26

2.3.1. Cronos ....................................................................................................... 29

2.3.2. GridClass ................................................................................................... 30

2.3.3. Sistema proposto pela engenheira Kida .................................................... 30

Capítulo III – Caso de Estudo ..................................................................................... 32

3.1. Descrição da situação actual do processo de elaboração de horários do DEEL

3.2. Constrangimentos da situação actual .............................................................. 35

Capitulo IV – Desenvolvimento do trabalho ............................................................. 36

4.1. Descrição da solução ....................................................................................... 37

4.1.1. Utilizadores ................................................................................................... 37

4.1.2. Fluxo de funcionamento ................................................................................ 38

4.1.3. Requisitos ..................................................................................................... 39

4.1.3.1. Requisitos Funcionais ......................................................................... 39

4.1.3.2. Requisitos não funcionais ................................................................... 41

4.1.4. Casos de uso ................................................................................................ 42

4.1.4.1. Descrição dos casos de uso ............................................................... 43

4.1.5. Modelagem do problema pelo algoritmo genético ........................................ 50

4.1.5.1. Diagrama de classes que será usado pelo AG ................................... 50

4.1.5.2. Representação do cromossoma ......................................................... 51

4.1.5.3. Inicialização da população .................................................................. 53

4.1.5.4. Função de Avaliação........................................................................... 55

4.1.5.5. Operadores genéticos ......................................................................... 58

4.1.6. Proposta de Arquitectura para o sistema ...................................................... 58

4.2. Apresentação do protótipo ............................................................................... 61

Capitulo V – Discussão de resultados ...................................................................... 67

Capítulo VI - Conclusões e recomendações ............................................................. 70

6.1. Conclusões ...................................................................................................... 71

6.2. Recomendações .............................................................................................. 71

Referências bibliográficas .......................................................................................... 73

Figure 1: Fluxograma de um algoritmo genético ........................................................... 28

Figure 2: Fluxo do processo de elaboração de horários da Faculdade de Engenharia 34

Figure 3: Diagrama de casos de uso............................................................................. 43