Área de inteligência artificial por naikow krueger rudimar luis …siaibib01.univali.br/pdf/naikow...
TRANSCRIPT
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SISTEMA PARA GERENCIAMENTO AUTOMATIZADO DAS RESERVAS DE LABORATÓRIO
Área de Inteligência Artificial
por
Naikow Krueger
Rudimar Luis Scaranto Dazzi, M. Sc Orientador
Itajaí (SC), dezembro de 2004
UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SISTEMA PARA GERENCIAMENTO AUTOMATIZADO DAS RESERVAS DE LABORATÓRIO
Área de Inteligência Artificial
por
Naikow Krueger Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Rudimar L. S. Dazzi, M.Sc
Itajaí (SC), dezembro de 2004
SUMÁRIO
LISTA DE ABREVIATURAS.................................................................iii LISTA DE FIGURAS ..............................................................................iv
LISTA DE TABELAS...............................................................................v
RESUMO ..................................................................................................vi ABSTRACT .............................................................................................vii 1. INTRODUÇÃO.....................................................................................1 1.1. OBJETIVOS ........................................................................................................ 2 1.1.1. Objetivo Geral ................................................................................................... 2 1.1.2. Objetivos Específicos ........................................................................................ 3 1.2. METODOLOGIA................................................................................................ 3 1.2.1. Pesquisar Sistemas Similares ........................................................................... 3 1.2.2. Pesquisar e Analisar as Técnicas de IA .......................................................... 3 1.2.3. Pesquisar a Linguagem de Programação PHP .............................................. 4 1.2.4. Identificar Padrões de Página do CTTMar.................................................... 4 1.2.5. Realizar a Análise da Distribuição da Carga Horária .................................. 4 1.2.6. Realizar o Projeto do Sistema.......................................................................... 5 1.2.7. Criação de Tabelas............................................................................................ 5 1.2.8. Ajustes na Modelagem do Sistema .................................................................. 5 1.2.9. Criar Interface de Interação com o Usuário .................................................. 6 1.2.10. Implementar Rotinas de Cadastro, Alteração e Exclusão........................... 6 1.2.11. Implementação do Algoritmo Genético ........................................................ 6 1.2.12. Testes ................................................................................................................ 7 1.3. ESTRUTURA DO TRABALHO ....................................................................... 7
2. FUNDAMENTAÇÃO TEÓRICA .......................................................9 2.1. GERAÇÃO ATUAL DA GRADE DE HORÁRIOS (RESERVAS) DOS LABORATÓRIOS DE INFORMÁTICA................................................................. 9 2.1.1. Dados Necessários para Reservar um Laboratório..................................... 10 2.1.2. Campos Necessários da Planilha de Reservas.............................................. 10 2.1.3. Preenchimento das Planilhas de Reservas.................................................... 11 2.1.4. Análise das Planilhas ...................................................................................... 12 2.1.5. Publicação das Reservas................................................................................. 12 2.2. SOLUÇÕES ALTERNATIVAS EXISTENTES ............................................ 14 2.3. ALGORITMOS GENÉTICOS ........................................................................ 21 2.3.1. Vantagens de se Utilizar Algoritmos Genéticos ........................................... 26 2.3.2. Características Primárias............................................................................... 26 2.4. RECURSOS COMPUTACIONAIS NECESSÁRIOS ................................... 34 2.4.1. PHP................................................................................................................... 35
i
2.4.2. MYSQL ............................................................................................................ 39 2.4.3. UML ................................................................................................................. 41
3. DESENVOLVIMENTO .....................................................................43 3.1. MODELAGEM DO SISTEMA........................................................................ 43 3.1.1. Diagrama de Use-Cases .................................................................................. 43 3.1.2. Diagrama de Seqüência .................................................................................. 46 3.1.3. Diagrama ER................................................................................................... 47 3.1.4. Dicionário de Dados Atual ............................................................................. 50 3.1.5. Dicionário de Dados com as Alterações Necessárias ................................... 52 3.2. IMPLEMENTAÇÃO ........................................................................................ 53 3.2.1. Automatização................................................................................................. 55 3.2.2. Otimização ....................................................................................................... 58 3.2.3. Relatórios ......................................................................................................... 65
4. CONCLUSÕES...................................................................................67
REFERÊNCIAS BIBLIOGRÁFICAS ..................................................69
APÊNDICE 1 – DIAGRAMA ER DO BANCO DE DADOS COM AS ALTERAÇÕES NECESSÁRIAS...........................................................71
ANEXO 1 – DIAGRAMA ER ATUAL DO BANCO DE DADOS......72
ANEXO 2 – ARTIGO CIENTÍFICO ....................................................73
ii
LISTA DE ABREVIATURAS
AGs Algoritmos Genéticos ASCII Arquivo Texto CGI Common Gateway Interface CTTMar Centro de Ciências Tecnológicas da Terra e do Mar GPL General Public License HTML HyperText Markup Language HTTP HyperText Transfer Protocol IMAP Internet Message Access Protocol LAMP Linux Animation and Movie Player NNTP Net News Transfer Protocol PHP Hypertext Processor POP3 Post Office Protocol version 3 SECADI Secretaria Acadêmica Integrada SMTP SiMple Transfer Protocol SNMP Simple Network Managment Protocol SISLAB Sistema de Controle dos Laboratórios TCC Trabalho de Conclusão de Curso UML Unified Modeling Language UNIX Sistema Operacional URL Uniform Resource Locator UNIVALI Universidade do Vale do Itajaí VRP Válvula Redutora de Pressão WWW World Wide Web
iii
LISTA DE FIGURAS
Figura 1. Exemplo da planilha de reservas de laboratório .................................................................12 Figura 2. Exemplo de como as reservas são listadas ao usuário após publicadas..............................13 Figura 3. Esquema da arquitetura da evolução cooperativa...............................................................17 Figura 4. Matriz de valores inicial .....................................................................................................19 Figura 5. Diminui-se o menor valor de cada linha.............................................................................20 Figura 6. Diminui-se o menor valor de cada coluna ..........................................................................20 Figura 7. Traça-se retas que cubram todos os zeros...........................................................................20 Figura 8. Matriz atualizada.................................................................................................................21 Figura 9. Exemplo do funcionamento de um algoritmo genético ......................................................27 Figura 10. Exemplo do processo de Seleção......................................................................................30 Figura 11. Esquema da reprodução sexuada (cruzamento)................................................................31 Figura 12. Operador de Cruzamento de um ponto .............................................................................32 Figura 13. Operador de Cruzamento de dois pontos..........................................................................32 Figura 14. Esquema de funcionamento do PHP.................................................................................36 Figura 15. Esquema de funcionamento entre requisições do cliente e servidor ................................38 Figura 16. Use Case do Sistema Proposto..........................................................................................43 Figura 17. Use-Case do Processo Gerar Relatório. ............................................................................44 Figura 18. Diagrama de Sequência do processo Gerar Reservas. ......................................................47 Figura 19. Diagrama ER atual da estrutura do banco de dados do SISLAB......................................48 Figura 20. Diagrama ER com as alterações necessárias ....................................................................49 Figura 21. Nova tela de entrada de dados para Pré-Reserva..............................................................54 Figura 22. Tabela HTML contendo um agrupamento por data das Pré-Reservas .............................55 Figura 23. Estrutura das matrizes utilizadas na implementação do sistema ......................................57 Figura 24. Exemplo de grade que serve de base para o AG...............................................................59 Figura 25. Exemplo da matriz restrições com suas respectivas colunas e valores.............................60 Figura 26. Grades a serem cruzadas, penalidades e grade resultante.................................................62 Figura 27. Outro exemplo de cruzamento entre as grades. ................................................................63 Figura 28. Tela de saída do sistema, já com as pré-reservas agendadas. ...........................................65
iv
LISTA DE TABELAS
Tabela 1. Tabela com a relação de tabelas do banco de dados dos laboratórios................................50 Tabela 2. Tabela com a relação de tabelas, colunas e tipos de dados ................................................51 Tabela 3. Tabela com a relação de tabelas a serem acrescentadas ao Banco de dados......................53 Tabela 4. Relação de tabelas a serem criadas e suas respectivas colunas e tipos de dados ...............53
v
RESUMO
KRUEGER, Naikow. Sistema para Gerenciamento Automatizado das Reservas de Laboratório. Itajaí, 2004. 83f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) – Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2004. A otimização do processo de reservas de laboratório é uma necessidade emergencial para agilizar e dar mais segurança ao processo de distribuição das reservas por laboratório. Por ser um processo desgastante e delicado, corre-se o risco de cometer muitos erros fazendo-o manualmente, além da necessidade de várias horas de dedicação dos responsáveis. O principal fator que aumenta a complexidade da geração da distribuição das reservas é a alocação dos recursos aos docentes. Existem várias solicitações de reservas para o mesmo dia e hora, fazendo com que muitas vezes não haja laboratórios suficientes para suprir essa demanda. O sistema proposto apresenta uma solução para otimização do processo de geração das reservas com o auxílio dos algoritmos genéticos. Basicamente, os algoritmos genéticos (AGs) irão gerar grades de horários que serão avaliadas e combinadas entre si, gerando novas grades de horários até que uma solução considerada ótima (com uma excelente avaliação, por exemplo) seja alcançada. Este sistema será integrado ao sistema de gerenciamento dos laboratórios de informática do CTTMar, de forma que deverá seguir os padrões de página e utilizar a mesma plataforma de banco de dados e programação web, MySQL e PHP, respectivamente. O sistema proposto também será capaz de gerar relatórios gerenciais referentes à utilização dos laboratórios. Palavras-chave: Algoritmos Genéticos. Otimização. Gerenciamento de Reservas.
vi
ABSTRACT
The optimization of the process of laboratory reserves is an emergencial necessity to speed and to give more security to the process of distribution of the reserves for each laboratory. For being a wearing off and delicate process, there are some risks in performing some errors making it Manually, beyond the necessity of some hours of devotion of the responsible people. The main factor that increases the complexity of the generation of the reserve distribution is the allocation of the resources to the users. There are some reserve requests for the same day and time,which makes that many times there are not enough laboratories to supply this demand. These system presents a solution in the optimization for the reserve generation process with the aid of the genetic algorithms. Basically, the genetic algorithms (AGs) will generate schedules that will be evaluated and combined between itself, generating new schedules until an excellent solution be considered (with an excellent evaluation, for example). This system will be integrated to the CTTMar laboratory management system, in a way that it will follow the page standards and use the same database platform and programming web, MySQL and PHP, respectively. The main advantage of using AGs for such necessity an excellent potential of optimization is the fact that AGs have an excellent optimization potential and also the capacity of expantion for other applications. Moreover, the proposed system will be able to generate referring managemental reports to the use of the laboratories. Keywords: Genetic Algorithms. Optimization. Management of Reserves.
vii
1. INTRODUÇÃO
Na atualidade, têm-se vários sistemas e novas tecnologias capazes de facilitar e automatizar
as mais diversas necessidades, porém, ainda existem muitas áreas a serem exploradas e
automatizadas.
Um trabalho que vem sendo feito há anos nas mais diversas instituições de ensino, sendo
estas particulares ou públicas e que sempre exige um grande esforço e “jogo de cintura” por parte
de seu responsável, é a construção da grade horária de aulas de cada turma. Organizar as aulas de
forma que não ocorram choques de horário é tarefa que exige muita paciência e competência por
parte da (s) pessoa (s) que detêm esta tarefa.
Da mesma forma, quando se têm espaços a serem utilizados por vários docentes, tais como
laboratórios de informática, por exemplo, os choques de horário também são comuns, exigindo um
grande trabalho por parte do responsável pela agenda de aulas do mesmo. Porém, se não bastassem
os choques de horário, há também a questão dos programas instalados, o que limita certas aulas a
laboratórios específicos, pois cada software possui uma licença de uso. E a quantidade de licenças,
em alguns casos, não abrange o total de computadores de todos os laboratórios, limitando desta
forma algumas aulas a laboratórios específicos. Estes e outros fatores fazem com que o responsável
pela distribuição das aulas tenha uma série de cuidados na hora de reservar os laboratórios.
O CTTMar possui sete laboratórios de informática destinados ao ensino, pesquisa e
extensão, o que soma um total de 162 micro-computadores disponíveis para estas atividades. Até o
dia 20/06/2004 haviam 1.641 alunos matriculados nos cursos de graduação, sendo 355 o total de
alunos matriculados no curso de Ciência da Computação, e estes alunos são os que mais utilizam os
laboratórios. Os laboratórios contam com uma série de programas instalados, sendo que alguns
destes programas ficam restritos à alguns laboratórios, como é o caso do software da Autodesk, o
Autocad. Devido a fatores como licenças, capacidade de armazenamento dos micro-computadores
entre outros, acaba existindo esta diferenciação de programas instalados entre os laboratórios.
Existe um sistema para gerenciamento dos laboratórios, o SISLAB, no qual são gerenciadas contas
de usuários e reservas de laboratório. As reservas de laboratório são feitas semestralmente, sempre
alguns dias antes do início das aulas, solicitadas via e-mail pelos docentes ao coordenador dos
laboratórios (exceto os docentes do curso de Ciência da Computação, que fazem suas reservas
diretamente no SISLAB). O coordenador dos laboratórios é o principal responsável pela elaboração
da grade de reservas. Após elaborada uma planilha contendo as solicitações dos docentes, elas são
conferidas e inseridas em um banco de dados pelos estagiários, através do SISLAB, que possibilita
também consultar as reservas. Docentes do curso de Ciência da Computação, podem fazer suas
reservas diretamente no SISLAB, sem a necessidade de repassar um e-mail ao coordenador dos
laboratórios solicitando alguma reserva.
A elaboração da grade de reservas gera alguns problemas, pois geralmente nem todas as
reservas podem ser agendadas. Existe uma demanda muito grande pelos laboratórios, neste
semestre, principalmente nas quartas-feiras, considerado dia de pico quanto a utilização dos
laboratórios. Existe ainda a necessidade de se obter informações gerenciais e operacionais
referentes à utilização dos laboratórios.
1.1. OBJETIVOS
A proposta deste trabalho de conclusão de curso (TCC) é desenvolver um módulo para o
sistema atual de gerenciamento dos laboratórios, capaz de criar a grade de horários referente à
utilização dos laboratórios de informática do CTTMar - UNIVALI, de forma simples, automatizada
e otimizada. Este módulo deve ser desenvolvido em PHP para seguir o padrão de páginas do
servidor do laboratório, bem como tornar o sistema disponível on-line para que docentes possam
efetuar suas reservas de suas casas ou de qualquer lugar que tenha um computador ligado à internet.
Será utilizada uma técnica de Inteligência Artificial, mais precisamente “Algoritmos Genéticos”
para otimização do processo de geração, por apresentarem um ótimo grau de otimização, conforme
pesquisa realizada durante a etapa de pesquisa.
O sistema também deverá ser capaz de gerar relatórios operacionais e gerenciais referentes à
utilização dos laboratórios por software, disciplina, curso e até mesmo por laboratório. Este sistema
deve servir como ferramenta para administração e fonte de informação referente à utilização dos
laboratórios.
1.1.1. Objetivo Geral
Desenvolver um módulo para o sistema de gerenciamento dos laboratórios, cujo objetivo é a
distribuição das reservas de laboratório, considerando os laboratórios disponíveis, software
instalado e quantidade de micro-computadores por laboratório. Este módulo será incorporado ao
Sistema de Gerenciamento dos Laboratórios (SISLAB) utilizando os padrões pré-estabelecidos.
2
1.1.2. Objetivos Específicos
Os objetivos específicos deste TCC são:
• Pesquisar sistemas similares, para analisar as demais formas de solução propostas;
• Pesquisar e analisar algoritmos genéticos;
• Adquirir domínio sobre a linguagem de programação PHP e nos padrões de
programação utilizados pelo CTTMar;
• Implementar sistema (cadastro, alteração, exclusão, AG e geração de relatórios);
• Testar a implementação do sistema, principalmente referente à otimização (AG); e
• Documentar o desenvolvimento e os resultados do sistema.
1.2. METODOLOGIA
A metodologia usada para o desenvolvimento do projeto aqui proposto envolveu algumas
etapas fundamentais, das quais algumas foram realizadas na primeira etapa deste TCC, enquanto
outras foram realizadas na segunda etapa deste TCC. Todas as etapas a seguir tiveram grande
importância para implementação e conclusão deste TCC.
1.2.1. Pesquisar Sistemas Similares
Esta etapa consistiu em pesquisar sistemas similares que apresentem a mesma finalidade ou
que utilizam as mesmas técnicas que serão utilizadas para o desenvolvimento do sistema proposto.
A pesquisa foi feita em bibliotecas e principalmente pela internet, utilizando páginas de
busca para obtenção de trabalhos (monografias, dissertações de mestrado e doutorado) semelhantes.
Os resultados obtidos foram analisados e alguns utilizados neste TCC. Os resultados inclusos neste
TCC, são utilizados também como referência bibliográfica.
1.2.2. Pesquisar e Analisar as Técnicas de IA
Esta etapa consistiu em fazer um apanhado geral sobre as técnicas de IA mais adequadas e
mais utilizadas para o desenvolvimento do sistema proposto.
3
Foram realizadas pesquisas via internet sobre Algoritmos Genéticos e outras técnicas a fim
de descobrir quais suas formas de funcionamento, aplicações existentes e suas limitações. O auxílio
dos docentes do curso de Ciência da Computação teve fundamental importância para eventuais
dúvidas que não puderam ser esclarecidas durante a atividade de pesquisa.
1.2.3. Pesquisar a Linguagem de Programação PHP
Esta etapa consistiu na pesquisa e no aprendizado de PHP, linguagem de programação que é
utilizada para implementação do sistema. Esta etapa está vinculada também à utilização do banco
de dados MySQL, pois este é o banco utilizado atualmente pelo SISLAB.
Esta pesquisa visa adquirir apostilas e manuais gratuitos, disponíveis na internet que possam
auxiliar no aprendizado da ferramenta, bem como utilizar livros disponíveis para consulta a alguns
tópicos mais complexos, com objetivo de entender melhor o funcionamento desta linguagem. Como
é uma etapa de aprendizado, está em evolução constante quanto à utilização da linguagem de
programação.
1.2.4. Identificar Padrões de Página do CTTMar
Esta etapa consistiu em adquirir conhecimento sobre os padrões de páginas web utilizados
pelo CTTMar, identificando rotinas e classes comuns utilizadas na programação e elaboração das
páginas. Durante esta etapa, foram realizadas reuniões com os desenvolvedores web do CTTMar,
nas quais foram expostos os modelos de página utilizados atualmente bem como a estrutura atual
do banco de dados.
O padrão de desenvolvimento é organizado em classes, bibliotecas e funções com rotinas
para criação de menus e acesso ao banco de dados. Porém, foram encontradas algumas dificuldades
como a falta de documentação e comentários referentes aos parâmetros e utilização das funções
existentes, problema este sempre resolvido via e-mail ou verbalmente com os desenvolvedores.
1.2.5. Realizar a Análise da Distribuição da Carga Horária
Esta análise esteve vinculada a realização da modelagem conceitual do sistema através de
uma ferramenta de modelagem UML, onde será modelada a solução proposta para o sistema em
questão.
4
Nesta etapa, foi elaborada a estrutura do sistema, modelada através de diagramas de use-case
e de sequência, bem como foram apresentadas as alterações necessárias no banco de dados para que
o sistema proposto possa ser implementado. Foi de fundamental importância nesta etapa o
conhecimento sobre o funcionamento dos AGs e a forma de interação entre usuários e a página da
web, bem como as atribuições que caberão ao coordenador dos laboratórios.
1.2.6. Realizar o Projeto do Sistema
Esta etapa consistiu em especificar os algoritmos dos processos a serem implementados,
sendo estes extraídos da análise realizada. O projeto incluiu também uma pré-modelagem. Esta
atividade foi revista na etapa de desenvolvimento do sistema, pois várias alterações sed fizeram
necessárias no decorrer deste TCC.
Esta etapa foi muito importante pois foi responsável pelo sistema propriamente dito. Neste
ponto, foi necessário conhecimento pleno e suficiente sobre padrões e formas de implementação do
CTTMar e da linguagem PHP.
1.2.7. Criação de Tabelas
Esta etapa compreendeu a criação das tabelas na base de dados atualmente utilizada, no
caso, MySQL. Em concordância com os desenvolvedores, foi utilizada uma base de dados MySQL
local, de modo que o desenvolvimento e os testes referentes a este TCC não interfiram na base atual
durante o processo de desenvolvimento.
Foi instalado o servidor APACHE com o banco de dados MySQL em um computador local
para desenvolvimento do sistema e para eventuais testes. Isso foi adotado por uma questão de
segurança e para manter a integridade dos dados no banco de dados dos laboratórios.
1.2.8. Ajustes na Modelagem do Sistema
Esta etapa foi executada algumas vezes e foi de grande importância. Tratou de ajustes na
modelagem do sistema que foi elaborada em etapa anterior. Sua finalidade foi melhorar a
modelagem atual para que se aplique melhor ao sistema proposto.
Tendências atuais de utilização de banco de dados, por exemplo, apontam para utilização do
SQL SERVER da Microsoft devido um contrato estabelecido entre a Univali e a Microsoft.
5
1.2.9. Criar Interface de Interação com o Usuário
Esta etapa consistiu na criação da página com a qual o usuário interage para cadastrar a sua
pré-reserva. Foi criada também a interface de gerenciamento do AG, que é destinada ao
coordenador dos laboratórios.
Foram necessárias duas interfaces, uma para os docentes, e outra para o coordenador. O
objetivo foi que pelo menos a interface dos docentes estivesse pronta para meados de julho de 2004
(o segundo semestre letivo teve início no dia 26/07/2004), de modo que os docentes pudessem fazer
suas solicitações de pré-reserva diretamente no SISLAB, no módulo de pré-reservas, para que já
fossem se habituando a fazê-las diretamente no sistema e por dar uma maior praticidade ao
coordenador dos laboratórios na hora de reunir todas as solicitações e gerar a grade de reservas. Isso
foi concluído conforme havia sido planejado.
1.2.10. Implementar Rotinas de Cadastro, Alteração e Exclusão
A implementação das rotinas foi feita em PHP utilizando-se uma base de dados MySQL,
adequando o sistema à interface criada na etapa anterior.
A principal rotina implementada nesta etapa foi a de cadastro, pois é através desta rotina que
os docentes farão sua solicitação de pré-reserva. As demais rotinas foram implementas
posteriormente.
1.2.11. Implementação do Algoritmo Genético
Esta foi uma das etapas mais importantes deste TCC, pois é nesta etapa que implementou-se
o algoritmo genético (AG), responsável pela geração e otimização das reservas do laboratório. Ele
teve como base os dados contidos na tabela de pré-reservas, na qual se faz a otimização necessária
para que um maior número de reservas possam ser encaixadas da melhor maneira possível.
Com pesquisas realizadas em etapas anteriores, pôde-se concluir que o processo de
otimização exige grande capacidade de processamento e memória (BRAZ JR, 2000). Porém, os
testes realizados em computador com processador AthlonXP 2700+ e 512 MB de memória ram
foram satisfatórios, o que não fez necessária a implementação de rotinas adjacentes para
agendamento da geração da grade de reservas.
6
1.2.12. Testes
Esta etapa consistiu em testar o sistema, principalmente o funcionamento da automatização.
Foram utilizados para os testes e primeira validação do processo de geração da distribuição das
reservas, os dados informados pelos docentes para as reservas do segundo semestre de 2004, no
módulo de solicitação de reservas que foi desenvolvido e disponibilizado no mês de julho de 2004.
Os testes referentes a otimização foram realizados com os dados gerados no processo de
automatização, os quais foram submetidos ao AG para que o mesmo fizesse a melhor distribuição
porssível sobre as solicitações de pré-reservas, respeitando as restrições existentes. Esperava-se
fazer um comparativo entre as reservas geradas pelo AG com as reservas existentes no sistema, de
maneira que alguns dias seriam sorteados para fazer tal comparação. Porém, como os docentes do
curso de Ciência da Computação realizam suas reservas diretamente no SISLAB, muitos
laboratórios já haviam sido alocados ao gosto dos docentes, o que impossibilitou a realização de tal
comparativo uma vez que o AG parte do princípio que todos os laboratórios estejam disponíveis.
O sistema também faz a geração de um relatório contendo os choques de horário, bem como
a relação das solicitações de pré-reserva que não puderam ser atendidas. Esta etapa serviu também
para testar esta parte do sistema, de modo que se tenha certeza da eficiência e credibilidade que se
pode ter no sistema.
1.3. ESTRUTURA DO TRABALHO
Este trabalho foi organizado de modo que o leitor possa compreender passo a passo as
técnicas que serão utilizadas para o desenvolvimento deste projeto de conclusão de curso, bem
como entender o motivo do emprego de cada uma das técnicas que se fizeram necessárias. Desta
forma, o trabalho é organizado em capítulos, para que possa haver uma melhor estruturação do
conteúdo aqui apresentado.
O segundo capítulo refere-se à fundamentação teórica, onde serão feitos os levantamentos
bibliográficos para transcrever tanto o modo de funcionamento atual das reservas de laboratório
quanto o funcionamento de técnicas que poderão ser utilizadas para melhorar e otimizar este
processo. Ainda na fundamentação teórica, será feita uma descrição sobre a linguagem de
programação a ser utilizada para implementar o sistema.
7
O terceiro capítulo é a implementação, ou seja, a descrição de como foi implementado o
sistema. Nesta parte do projeto, entra a modelagem do sistema, utilizando-se de técnicas da
engenharia de software para realizar a modelagem e técnicas de inteligência artificial para
implementação dos algoritmos que compõe o sistema.
O apêndice 1 tem como objetivo ilustrar as alterações que foram feitas no banco de dados
atual dos laboratórios para ressaltar a necessidade de adaptações no mesmo.
O anexo 1 contém o diagrama ER atual do banco de dados utilizado pelos laboratórios.
O anexo 2 contém um artigo científico referente a este TCC.
[FIM DE SEÇÃO. Não remova esta quebra de seção]
8
2. FUNDAMENTAÇÃO TEÓRICA
Esta fundamentação teórica tem como objetivo expôr ao leitor alguns trabalhos encontrados,
bem como uma revisão bibliográfica sobre as definições de algoritmos genéticos, tabu search,
simulated anneling, entre outros. Os trabalhos encontrados são referentes a otimização do processo
de geração da grade horária contendo as reservas de salas de aula. Estes trabalhos são válidos pois
utilizam-se de mecanismos distintos para otimização e o contexto dos trabalhos é semelhante ao
contexto deste TCC.
O sistema proposto visa automatizar a geração da grade de horários referentes às reservas
dos laboratórios de informática do CTTMar. Contudo, é necessário entender como funciona o
método de solicitação de reservas atualmente, para que possa haver uma melhor compreensão dos
módulos do sistema proposto.
É de fundamental importância observar que atualmente, as grades de reservas de laboratório
são elaboradas pelo coordenador dos laboratórios ou por funcionários por ele designados. Tal tarefa
exige muito tempo e choques de horários são frequentes. De tal forma, um sistema bem projetado e
implementado pode chegar a uma solução considerada ótima1, mas não garante que todas as
reservas serão agendadas, não dispensando assim, a supervisão do coordenador dos laboratórios
sobre o resultado final de otimização.
Atualmente, o processo de geração da grade de horários coomprende alguns passos e etapas,
como descrito à seguir.
2.1. GERAÇÃO ATUAL DA GRADE DE HORÁRIOS (RESERVAS) DOS LABORATÓRIOS DE INFORMÁTICA
Segundo o coordenador dos laboratórios, atualmente, no início de cada semestre, é enviado
um e-mail aos docentes solicitando que enviem a ele um e-mail com os dados das reservas até uma
data previamente definida.
Docentes do curso de Ciência da Computação possuem o privilégio de cadastrarem
diretamente no sistema suas reservas, sem passar necessariamente pelo coordenador dos
laboratórios, pois como o curso é noturno e os laboratórios são do curso de Ciência da Computação, 1 Solução ótima para este TCC é considerada como sendo uma grade horária que atenda o maior número de solicitações de reservas bem como a melhor otimização possível para a mesma.
cabe a eles tal privilégio. Em caso de conflito, esse eventual choque de horário também é mais
facilmente contornado, pois trata-se de um grupo menor de docentes envolvidos.
2.1.1. Dados Necessários para Reservar um Laboratório
O e-mail enviado pelo coordenador dos laboratórios deve conter os seguintes dados para que
possam ser agendadas as reservas:
• Programas a serem utilizados;
• Horários de início e fim das aulas;
• Quantidade de alunos;
• Dias das reservas; e
• Curso.
Com esses dados, o coordenador dos laboratórios parte para a elaboração da planilha de
reservas.
2.1.2. Campos Necessários da Planilha de Reservas
A planilha de reservas deve conter alguns campos, tais como:
• Nome do laboratório;
• Quantidade de computadores;
• Meses;
• Dias da semana;
• Dias;
• Hora inicial; e
• Hora final.
Após elaborar a planilha com esses campos, parte-se para o preenchimento da mesma com
as requisições de reservas enviadas pelos docentes, via e-mail ao coordenador dos laboratórios. São
montadas então as planilhas para alocar as reservas solicitadas, sendo montada uma planilha para
10
cada laboratório. A Figura 1 (pág. 12) ilustra um exemplo de planilha preenchida contendo algumas
reservas de laboratórios.
2.1.3. Preenchimento das Planilhas de Reservas
Uma vez elaboradas as planilhas, o coordenador dos laboratórios imprime os e-mails que lhe
foram enviados contendo as solicitações de reservas e começa a distribuí-las. Existem algumas
regras a serem respeitadas ao efetuar o preenchimento das planilhas, conforme listadas a seguir:
1. Software Específico - a pessoa responsável pelo preenchimento das planilhas deve observar
todas as requisições de reserva que contenham algum software específico de algum
laboratório, como por exemplo, uma solicitação que contenha como software necessário o
AutoCad. Esta reserva deve ser agendada exclusivamente a algum laboratório que tenha esse
software instalado. O coordenador dos laboratórios sabe quais software estão instalados bem
como os laboratórios onde estão instalados. Os funcionários também sabem, pois geralmente
trabalham nestes laboratórios;
2. Horário de término da aula - a maioria dos laboratórios de informática do CTTMar,
pertencem ao curso de Ciência da Computação. Com isso, alunos do curso possuem
privilégio de acesso exclusivo a estes laboratórios após as 18:00 horas. A partir das 19:00 hs
são permitidas apenas aulas do curso de Ciência da Computação nesses laboratórios. Com
isso, uma reserva prevista com término além das 19:00 não poderá ser agendada a um
laboratório pertencente ao curso de Ciência da Computação caso a aula não esteja vinculada
a este curso;
3. Quantidade de alunos - esta regra refere-se a quantidade de alunos que o solicitante da
reserva possui. Esse dado deve então ser comparado com a quantidade de micro-
computadores que o laboratório disponibiliza. Turmas grandes não poderão ser alocadas em
laboratórios pequenos, bem como turmas pequenas não podem ser alocadas em laboratórios
com grande número de computadores, exceto, quando não houverem mais laboratórios
disponíveis; e
4. Localização dos laboratórios - alocar aulas de docentes em laboratórios o mais próximo
possível de seus locais de trabalho, sempre que possível (em função da distribuição física
dos diversos cursos do centro).
11
2.1.4. Análise das Planilhas
Respeitando-se as regras descritas anteriormente, as planilhas vão sendo preenchidas.
Depois de prontas, são analisadas. Caso haja necessidade de alguma alteração, esta é feita e
novamente as planilhas são verificadas.
Nesta análise, são verificados os ítens referentes as reservas e ao preenchimento das
planilhas. Qualquer não conformidade ou uma possível “melhora” na distribuição das reservas é
analisada e se necessário, é feita a alteração correspondente. A Figura 1 mostra um exemplo de
planilha preenchida para um laboratório, do mês de março de 2004.
Figura 1. Exemplo da planilha de reservas de laboratório Fonte: Laboratório de Informática CTTMar (2004)
2.1.5. Publicação das Reservas
Após serem analisadas e não havendo mais nenhuma alteração a ser feita, as planilhas são
encaminhadas aos estagiários dos laboratórios para que estes digitem as reservas no sistema de
consulta pública via web, o atual SISLAB, como ilustrado na Figura 2.
12
Figura 2. Exemplo de como as reservas são listadas ao usuário após publicadas Fonte: SISLAB (2004)
Os docentes do curso de ciência da computação, já fazem suas reservas diretamente na
internet, no mesmo sistema que disponibiliza a grade de aulas online. Após as pré-reservas terem
sido cadastradas no SISLAB, pretende-se expandir essa opção aos docentes dos outros cursos de
graduação do CTTMar.
É possível perceber a necessidade da automatização e otimização do processo de geração da
grade de horários referentes às reservas de laboratório. Contudo, é importante ressaltar a
necessidade da supervisão do coordenador dos laboratórios em relação as reservas, para que
eventuais choques de horários e falta de laboratórios possam ser contornados da melhor maneira
possível.
13
2.2. SOLUÇÕES ALTERNATIVAS EXISTENTES
Esta seção tem como objetivo descrever alguns trabalhos encontrados cujo contexto é
semelhante ao contexto deste TCC, ressaltando a solução encontrada por cada autor para solucionar
o problema.
Segundo Velloso (1995 apud BRAZ JR., 2000), “o planejamento e a alocação de recursos
são problemas de solução difícil com um histórico longo e variado nas áreas da Pesquisa
Operacional e Inteligência Artificial”. Tais problemas precisam, em geral, ser atacados através de
uma combinação de técnicas de busca e heurísticas, o que torna as soluções específicas para os
problemas em questão. No seu trabalho, ele descreve a aplicação de algoritmos genéticos na busca
de uma solução ótima para o problema, ou seja, a solução que melhor atende a demanda de salas de
aula. Nesta solução o tratamento das especificidades do problema é realizado separadamente,
através de um módulo denominado “construtor de horários”. Desta forma, há uma maior
flexibilidade para adaptar as técnicas de algoritmos genéticos às restrições específicas do problema.
Para Davis (1991 apud LOPES e SCHOEFEL, 2002), problemas de alocação apresentam
grande dificuldade em seu tratamento em função, principalmente, da complexidade computacional e
do conhecimento de domínio. Para diminuir essas dificuldades, podem ser utilizadas técnicas de
alocação provenientes da matemática, mais precisamente da pesquisa operacional, onde através de
valores numéricos e algoritmos, é possível chegar a uma solução otimizada.
Alguns autores utilizam técnicas como a programação linear (AKKOYULU, 1973;
TREVELIN, 1983 apud BRAZ JR, 2000). “A programação linear apresenta desvantagens pois trata
de um problema específico, é feita para uma realidade e não possui nenhuma forma de aprendizado
ou de adequação a uma nova realidade”.
Segundo Braz Jr (2000), após analisar os modelos de otimização existentes, este optou por
desenvolver um modelo com base nos algoritmos genéticos pelas seguintes razões:
• Podem resolver problemas complexos rápida e confiavelmente;
• A construção de algoritmos genéticos e modelos existentes é geralmente simples;
• São extensíveis e
• São fáceis de combinar com outros métodos.
14
Algoritmos genéticos são versáteis e requerem pouco conhecimento sobre a função a ser
otimizada. Em geral, algoritmos genéticos rapidamente descobrem sub-regiões de alta qualidade em
vastos espaços de busca, mas depois demoram a convergir. Para funções desconhecidas,
descontínuas e não diferenciáveis, algoritmos genéticos estão entre os mais indicados (ibidem).
Costa e Della Bruna (2003) propõe uma solução ao problema baseado em uma abordagem
chamada Evolução Cooperativa, que pode ser considerada como uma extensão ao modelo
tradicional de AGs, onde é possível representar e solucionar problemas complexos através da
modelagem da coevolução de espécies. Esta arquitetura modela um ecossistema constituído de duas
ou mais espécies. As espécies são geneticamente isoladas, ou seja, possuem suas próprias
características e seus indivíduos somente cruzam com outros membros de sua espécie. Restrições de
cruzamento são forçadas simplesmente por evoluir as espécies em populações separadas. As
espécies interagem entre si dentro de um modelo de domínio compartilhado e têm um
relacionamento cooperativo. Assim, um indivíduo de uma espécie qualquer terá maiores chances de
criar descendentes e participar de gerações futuras a medida que possua uma boa capacidade de
cooperação com indivíduos de outras espécies. Neste modelo, cada espécie é evoluída dentro de
sua própria população.
Para avaliação de um indivíduo, é formado um grupo com representantes de cada espécie.
Esse grupo é denominado “modelo do domínio”. O indivíduo a ser avaliado é combinado nesse
modelo, onde é verificado o quanto o mesmo colabora e compatibiliza para a obtenção da solução
do problema. Há muitos métodos possíveis para escolher os representantes com os quais cooperar.
Em alguns casos é apropriado permitir que o melhor indivíduo corrente de cada população seja o
representante. Em outros casos, estratégias alternativas são preferidas. O Algoritmo de Evolução
Cooperativa é inicializado com a criação das populações de cada espécie e através do Algoritmo
Genético, é calculado o valor de fitness de cada membro das espécies. Se uma solução satisfatória
não for encontrada na criação da população inicial, todas as espécies são evoluídas. Nesta etapa, são
efetuadas as operações do Algoritmo Genético (seleção, cruzamento e mutação), em cada espécie
separadamente. As populações antigas são substituídas pelas populações geradas após a aplicação
dos operadores. Após isso, são selecionados os representantes de cada espécie, formando assim o
modelo do domínio. (ibidem)
Com o modelo criado, cada indivíduo de cada espécie será avaliado, verificando o grau de
colaboração em relação aos indivíduos do modelo. Este grau é calculado com base nas restrições
15
que tem influência direta com a colaboração das espécies. Potter e De Jong (apud COSTA e Della
Bruna, 2003) se referem a este processo como “uma colaboração porque os indivíduos serão
julgados de acordo a quão bem eles trabalham juntos para resolver o problema”. Outro problema
que pode ocorrer no processo de evolução é a estagnação. Pode ser que existam poucos indivíduos
no ecossistema com o qual construir uma boa solução. Caso isto ocorra, a população da espécie que
estiver estagnada terá sua população novamente inicializada aleatóriamente. A estagnação da
evolução pode ser descoberta monitorando-se a qualidade das cooperações, de acordo com a
inequação: (ibidem)
f(t) - f(t - K) < C Equação 1.
Onde,
• f(t) é o valor de fitness da melhor cooperação na geração t;
• C é uma constante especificando o aumento do valor de fitness, considerando-se ter uma
melhoria significante (ou esperada); e
• K é uma constante especificando o tamanho da janela evolutiva na qual uma melhoria
significante deve existir.
A Figura 3 representa o modelo da arquitetura da evolução cooperativa.
16
Figura 3. Esquema da arquitetura da evolução cooperativa Fonte: Costa e Della Bruna (2003)
Barreto (1997), faz uma comparação entre programação evolucionária e algoritmos
genéticos, onde ele aponta três diferenças fundamentais entre a programação evolucionária e
algoritmos genéticos, conforme listado:
• A representação no caso da programação evolucionária é livre, dependendo do problema
a ser resolvido. No caso dos AGs, a representação envolve a codificação do problema
usando uma lista de símbolos, o “genoma”;
• A operação de mutação altera aspectos da solução seguindo uma distribuição estatística
de modo a que grandes mudanças são pouco prováveis; e
• O operador de cruzamento não é geralmente usado na programação evolucionária.
Uma outra forma de solução encontrada refere-se a Simulated anneling, que trata de uma
estratégia de busca local. É um método que consegue boas soluções sobre problemas com muitas
17
restrições. O método mantém um rastro de possíveis soluções. A cada iteração, um indivíduo é
gerado, no caso, outra possível grade horária, ligeiramente alterada aleatoriamente e em seguida é
avaliada. Este indivíduo será aceito como grade horária corrente se tiver uma boa avaliação. Se o
novo indivíduo tiver uma avaliação ruim (uma nota baixa, por exemplo), ele pode ser aceito de
acordo com uma probabilidade, que é relacionada a um parâmetro de controle chamado
temperatura. A temperatura, que é a probabilidade de que indivíduos inferiores sejam aceitos, é
diminuída a cada iteração, ou depois de um número particular de iterações. O número de iterações
pode ser constante ou pode ser incrementado com a temperatura baixa. Simulated anneling tem sido
aplicado satisfatoriamente no problema de horários em Swansea’s Tissue (THOMPSON. 1996 apud
BRAZ JR, 2000). Os autores Thompson e Dowsland usam um modelo de grafos. Para simplificar a
grande quantidade de restrições do problema de horário, eles o dividiram em duas fases. Em
primeiro lugar são encontradas possíveis soluções, e então são otimizadas as restrições secundárias.
Porém, esta abordagem resulta num espaço de busca consideravelmente reduzido e possivelmente
desconexo. Ao invés de um resfriamento geométrico simples, é feito um aumento da temperatura
quando um indivíduo é rejeitado. Além disso, a taxa de rejeição de indivíduos aumenta
geometricamente com o progresso da procura (BRAZ JR, 2000).
Outro método utilizado é o tabu search, que mantém um rastro de possíveis soluções para o
horário corrente. A diferença está no método pelo qual ele move novos horários para a lista de
aceitos. Um tabu search mantém uma lista de tabelas movidas, representando horários que foram
visitados recentemente, fazendo com que a tabela gerada anteriormente não seja gerada novamente
e otimizando o espaço de busca. A lista de tabelas é usualmente de tamanho fixo, e novos
movimentos são adicionados ao mesmo tempo em que os velhos são removidos, ocorrendo o
mesmo com as tabelas (já que o número de tabelas é fixo). Esse processo vai se repetindo até que
um nível de aspiração (soluções ótimas) seja encontrado. Quando um horário atinge o nível de
aspiração, pode ser removido da lista de tabelas. Tabu search foi aplicado com sucesso por Boufflet
e Negre para gerar os horários na Universidade de Tecnologia de Compiègne (BRAZ JR, 2000).
Suas listas de tabelas contém os sete movimentos mais recentes. Se a vizinhança corrente não
contiver uma solução melhorada, a função de aspiração pode selecionar uma solução da lista de
tabelas. Hertz (1992 apud BRAZ JR, 2000) desenvolveu e aplicou o algoritmo tabu search TATI no
agendamento de cursos, o qual ele adaptou mais tarde para um problema mais complexo e com
mais restrições. A duração de uma aula não é fixa, e existem dez diferentes tipos de movimentos
(mover uma aula para outro dia, mudar a duração das aulas, etc.) Quando o agendamento de uma
18
aula em um dia particular é modificado, pode ser mudado para outro período (possivelmente em
outro dia). Porém, para um determinado número de interações esta tabela move a aula para um
período no dia original.
Lopes e Schoeffel (2002), tratam sobre o problema da reservas de salas de aula. Em seu
artigo, propõe uma solução para a alocação de salas de aula baseada em pesquisa operacional.
Segundo o artigo, foi desenvolvido um protótipo de um sistema para controle das salas. Este
protótipo é divido em duas partes fundamentais: um sistema local, onde são feitos cadastros e
alocações para salas de aula, e outra parte voltada para internet, onde podem ser feitas consultas e
reservas temporárias de salas. As reservas de sala possuem algumas restrições, como localização,
capacidade de alunos, ar-condicionado, acesso à deficiente físico entre outros. Para a validação do
algoritmo de alocação foram dados pesos às restrições, ou seja, para cada restrição é cadastrado um
grau de importância que será relevante no momento da alocação. Por exemplo, as restrições podem
ser divididas em três tipos diferentes: indispensável, importante e irrelevante, onde para cada uma é
dado um valor correspondente ao peso, como 50, 20 e 10 respectivamente. Inicialmente as
disciplinas foram agregadas em turmas, de acordo com seu curso e fase. Em seguida é calculado o
peso das restrições para cada turma em relação a cada sala, gerando uma matriz de valores. Para
uma melhor cooprensão do modelo proposto, a Figura 4 demonstra a matriz de valores mencionada
anteriormente.
Figura 4. Matriz de valores inicial Fonte: Lopes e Schoeffel (2002)
O algoritmo de alocação segue então alguns passos, descritos a seguir:
1. Subtrai-se o menor elemento de cada linha dos elementos desta mesma linha
conforme a Figura 5;
2. Subtrai-se o menor elemento de cada coluna resultante dos elementos desta mesma
coluna, conforme a Figura 6;
19
3. Procura-se uma solução que envolva apenas os elementos que são zeros. Se for
encontrada, será a melhor solução, senão testa-se a otimização traçando um número
mínimo de retas que cubra todos os zeros, cofnorme a Figura 7 ; e
4. Faz-se o teste de otimização. Se o número de retas traçadas é igual ao número de
linhas ou colunas, pode-se fazer uma atribuição ótima, caso contrário, é preciso
continuar as iterações para alcançar uma atribuição ótima, conforme a Figura 8.
Figura 5. Diminui-se o menor valor de cada linha Fonte: Lopes e Schoeffel (2002)
Figura 6. Diminui-se o menor valor de cada coluna Fonte: Lopes e Schoeffel (2002)
Figura 7. Traça-se retas que cubram todos os zeros Fonte: Lopes e Schoeffel (2002)
20
Figura 8. Matriz atualizada Fonte: Lopes e Schoeffel (2002)
Deste modo, faz-se uma atribuição garantindo soluções ótimas, achando-se os zeros no
quadro final e aplicando as restrições impostas pelas equações citadas. Os zeros cobertos por retas
representam soluções ótimas, ou seja, boas alocações de salas de aula.
Com base nos exemplos citados nesta seção, optou-se por utilizar AGs devido a sua elevada
capacidade de otimização. AGs foram empregados com sucesso por Braz Jr (2000), implementando
a sua solução para Universidade Federal de Santa Catarina (UFSC), e abordada como solução ideal
por Lucas (2000), que não chegou a implementar seu trabalho, realizando apenas um estudo sobre o
problema e sua solução proposta com base nos AGs.
2.3. ALGORITMOS GENÉTICOS
No século XIX, Charles Darwin introduziu uma idéia que revolucionaria a forma de
entender o mundo em que vivemos: a teoria da evolução. Nela, ele afirmava que as espécies
naturais vão evoluindo para adaptar-se ao meio que vivem, com o critério de que aqueles indivíduos
que melhor se adaptarem terão maior probabilidade de sobreviver até a idade adulta e se
reproduzirem, fazendo com que seus gênes passem de geração para geração (PASTORINO, 1997).
Algoritmos Genéticos são métodos de otimização e busca inspirados nos mecanismos de
evolução de populações de seres vivos. Foram introduzidos por John Holland e popularizados por
um de seus alunos, David Goldberg. Esses algoritmos seguem o princípio da seleção natural e
sobrevivência do mais apto, declarado em 1859 pelo naturalista e fisiologista inglês Charles Darwin
em seu livro “A Origem das Espécies”. De acordo com Charles Darwin, “Quanto melhor um
indivíduo se adaptar ao seu ambiente, maior será sua chance de sobreviver e gerar descendentes”.
Na natureza, a combinação de boas características provenientes de diferentes indivíduos
ancestrais pode, às vezes, produzir descendentes “superindivíduos”, cuja adaptação é muito maior
21
que a de seus ancestrais. Dessa forma, as espécies evoluem, logrando características cada vez
melhor adaptadas no meio ambiente em que vivem (FERNANDES, 2003).
Como os algoritmos genéticos baseiam-se na teoria da evolução de Charles Darwin(1859),
são empregadas nomenclaturas e padrões da biologia (genética) em sua descrição. Com base em
Lucas (2000), pode-se listar as seguintes nomenclaturas:
1. Gene: um gene serve como uma variável, um espaço para a alocação de um valor. As
características dos indivíduos são definidas a partir dos valores contidos no conjunto
de um ou mais genes que as codificam;
2. Genoma: um genoma é o conjunto de genes de um determinado indivíduo.
Tradicionalmente genomas são formados por uma cadeia única de genes (um
cromossomo), mas existem representações alternativas como a de árvores (bastante
utilizada em problemas de programação genética) de listas e de matrizes
multidimensionais;
3. Cromossomo: consiste de uma cadeia de genes. Visto que tradicionalmente são
utilizados genomas com uma cadeia simples de genes, muitas vezes este termo é
utilizado, com certa liberdade, como sinônimo para genoma;
4. Alelo: os alelos de um gene correspondem ao conjunto de valores que ele pode
assumir. Normalmente, o conjunto de alelos é o mesmo para todos genes de um
genoma;
5. Genótipo: para um algoritmo genético o genótipo de um indivíduo é a informação
codificada em um genoma (a estrutura que é manipulada durante o processo de
evolução) e o fenótipo resultante do processo de decodificação é a solução que ele
representa;
6. Fenótipo: resultado do processo de decodificação do genótipo de um indivíduo, em
um AG o fenótipo é a solução propriamente dita que este representa;
7. Alfabeto: consiste em um conjunto de símbolos que são manipulados por uma
linguagem. Para quase todos problemas tratados pelos algoritmos genéticos é
possível definir uma linguagem formal que gere a partir de um alfabeto e uma série
22
de regras pré-definidos todo o conjunto de soluções possíveis para o problema. Um
alfabeto, para os AGs é, então, o conjunto da união de todos os alelos possíveis para
os genes pertencentes ao genoma;
8. Indivíduo: um indivíduo pertencente a um algoritmo genético representa uma
possível solução para o problema a ser tratado;
9. Super-Indivíduo: um determinado genoma é considerado um super-indivíduo quando
ele apresenta um grau de adaptação significativamente superior a média. Por possuir
então uma probabilidade muito maior de ser selecionado para reprodução que seus
concorrentes, suas características tendem a proliferar pelas gerações subseqüentes,
freqüentemente causando queda na diversidade;
10. População: uma população consiste em um conjunto de indivíduos. Ela apresenta
características não observáveis nos indivíduos, tais como grau de diversidade e de
convergência; e
11. Diversidade (ou biodiversidade): característica de uma população de indivíduos, a
diversidade diz respeito ao grau de semelhança entre eles.
Com base em Pastorino (1997) pode-se concluir que na evolução das espécies, a adaptação
ao meio ambiente não é sentida, pois está ocorrendo constantemente, não se conseguindo desta
forma um super-indivíduo perfeito, uma vez que a natureza tenta otimizar os indivíduos de cada
espécie e nas circunstâncias atuais. A natureza nos trata como autênticos seres descartáveis,
sacrificando aqueles que neste momento não se adaptem ao contexto e dando maior capacidade de
sobrevivência aos que mostram uma maior grau de adaptação.
Este processo não deve ser entendido como um processo determinístico, pois se um
indivíduo se adaptar ao contexto, o que pode-se afirmar é que este indivíduo terá uma maior
probabilidade de conservar seus genes na geração posterior, mas isto é só uma probabilidade, não é
muito seguro, pois sempre há uma possibilidade de apesar do indivíduo ser superdotado ele não se
reproduzir, portanto o que pode-se afirmar é que a espécie, tratada como conjunto, adapta-se ao
meio em que vive (ibidem).
A informática permite que se crie populações digitais que se otimizam de acordo com suas
funções, seguindo padrões genéticos e de seleção natural. Quando designamos uma aplicação de
23
AG nós devemos considerar e justificar muitos aspectos teóricos descritos em bibliografias sobre os
mesmos, pois cada aplicação tem a necessidade de ter uma função apropriada, utilizada em
problemas específicos praticados com um objetivo a ser alcançado (ibidem).
Algoritmos Genéticos são uma família de modelos computacionais que podem ser utilizados
para procurar, resolver e otimizar problemas, pois são úteis por sua robustez e velocidade, sendo
designados para um tipo determinado de otimização, onde o espaço de busca é muito grande e os
métodos convencionais se demostram ineficientes.
Possíveis soluções de um problema são combinadas e alteradas, normalmente através de
mecanismos inspirados na seleção natural (de Charles Darwin), na recombinação e na mutação
genética, tendo como principais características a obtenção de um conjunto de soluções ao invés de
uma única solução (LUCAS, 2000).
Um algoritmo genético vai especializando uma população para adaptar-se a um determinado
contexto e esta adaptação vai ser definida precisamente pela função a ser otimizada (ibidem).
Segundo Goldeberg (1989 apud BRAZ JR., 2000), algoritmo genético é:
...um algoritmo de procura baseado nos mecanismos de seleção natural e genética natural. Ele combina a sobrevivência feita por uma função de avaliação entre uma cadeia de caracteres com uma estrutura de informações mudadas aleatoriamente, para formar um algoritmo de procura com algum talento inovador, o mesmo de uma procura de um ser humano. Em toda geração, um novo conjunto de criaturas artificiais (cadeia de caracteres) é criado usando bits e pedaços do teste de avaliação da geração anterior; ocasionalmente uma parte nova é testada. Enquanto aleatório, algoritmos genéticos não são nenhum passeio simples sem destino. A procura mais eficiente das informações anteriores para especular os pontos da nova procura resultam e um aumento na sua performance.
Para Barreto (1997), algoritmos genéticos baseiam-se nos mecanismos de evolução natural,
constituindo assim um paradigma de aprendizado pela máquina. Embora sejam simples, os
algoritmos genéticos tem atraído atenção das mais diversas áreas do conhecimento, como na área
das engenharias, por exemplo, otimizando processos produtivos. Sendo a otimização sua principal
característica, os algoritmos genéticos destacam-se ainda pela simplicidade de operação, facilidade
de implementação, bem como na eficácia em buscas de mínimos globais. Aplicam-se em casos
onde não se conhece claramente o modelo matemático envolvido e também em funções lineares e
não-lineares.
Já Lucas (2000) define algoritmos genéticos como:
24
Os algoritmos genéticos constituem uma técnica bastante utilizada em problemas de otimização, e baseiam a lógica de seu funcionamento nas leis de evolução natural propostas por Charles Darwin – as possíveis respostas geradas para o problema são vistas como indivíduos que competirão entre si pela oportunidade de se reproduzirem. Neste processo, os mais aptos, que representam uma melhor solução, têm maior chance de perpetuar parte de suas características, aumentando assim a probabilidade de se obter uma maior adaptação da população em geral.
Ribeiro (2004a) resume o funcionamento dos Algoritmos Genéticos a:
encontrar o ótimo de uma dada função, sobre um dado espaço de busca (chamado "população" de "indivíduos"), da seguinte maneira: uma função de avaliação é computada para cada indivíduo, ordenando a população do pior ao melhor; seleciona-se então, pares de indivíduos, sendo que os melhores tem mais chances de serem selecionados; novos indivíduos são gerados pela reprodução desses pares; e finalmente, uma nova população é gerada pela substituição de alguns indivíduos da população velha pela nova.
Atualmente, os algoritmos genéticos são empregados em áreas como robótica (RIBEIRO,
2004a), que utilizou-se de algoritmos genéticos para melhorar a navegabilidade de robôs e
melhorar a capacidade de aprendizado dos mesmos.
No apoio a problemas de recursos hídricos, utilizou-se algoritmos genéticos para otimização
de redes de distribuição de água para abastecimento, que envolve a localização de válvulas
redutoras de pressão (VRPs) para minimização de vazamentos, operação otimizada de sistemas de
bombeamento, setorização, calibração e reabilitação de redes. (RIBEIRO, 2004b).
Souza Jr (2003) desenvolveu um trabalho na área de logística, mais precisamente para a área
que se refere a transportes, como coleta e entrega, seja de objetos e mercadorias ou ainda transporte
de pessoas. Ele utilizou algoritmos genéticos para otimizar o processo de criação de rotas, fazendo
com que as rotas por ele geradas exijam menos veículos operando e consequentemente mais
economia de combustível, como também uma quantidade menor de pessoas envolvidas nas
operações.
AGs buscam sempre a otimização, que é a busca da melhor solução para um dado problema.
Consiste em tentar várias soluções e utilizar a informação obtida neste processo de forma a
encontrar soluções cada vez melhores. Um exemplo simples de otimização é a melhoria da imagem
das televisões com antena acoplada no próprio aparelho. Através do ajuste manual da antena, várias
soluções são testadas, guiadas pela qualidade de imagem obtida na TV, até a obtenção de uma
resposta ótima, ou seja, uma boa imagem (LUCAS, 2000).
25
2.3.1. Vantagens de se Utilizar Algoritmos Genéticos
Os algoritmos genéticos apresentam algumas vantagens em relação a outros possíveis
métodos para implementação do sistema proposto, como segue abaixo:
• Podem resolver problemas complexos rápida e confiavelmente;
• A implementação dos AGs é geralmente simples;
• São extensíveis a outros propósitos; e
• São fáceis de combinar com outros métodos.
Algoritmos genéticos são estruturas simples de grande eficiência para otimização de
processos, já foram utilizados com sucesso em trabalhos semelhantes por Braz JR (2000) e por
Lucas (2000), porém, foram utilizados em uma escala mais ampla, para um número maior de
“indivíduos”.
Como principal desvantagem pode ser citado o tempo de processamento, pois quanto maior
o número de indivíduos, maior o tempo de processamento. Por outro lado, quanto maior o número
de indivíduos, maiores são as chances de se chegar a uma solução ótima, pois a solução ótima pode
estar entre os indivíduos.
2.3.2. Características Primárias
De modo geral, AGs têm as seguintes características:
• AGs operam numa população(conjuntos) de pontos, e não a partir de um ponto isolado;
• AGs operam num espaço de soluções codificadas, e não no espaço de busca diretamente;
• AGs necessitam somente de informação sobre o valor de uma função objetivo para cada
membro da população, e não requerem derivadas ou qualquer outro tipo de
conhecimento; e
• AGs usam transições probabilísticas, e não regras determinísticas.
O funcionamento dos Ags pode ser compreendido analisando-se o fluxograma da Figura 9.
26
Figura 9. Exemplo do funcionamento de um algoritmo genético Fonte: Lucas (2000)
Um algoritmo genético opera sobre uma população, fazendo com que esta evolua de acordo
com uma função de adaptação. Seu funcionamento começa com a inicialização da população, e
depois o processo de seleção, reprodução e mutação ocorre a cada geração até que seja atingido
algum critério para o fim da evolução.
27
2.3.2.1. Inicialização
A inicialização básica de um algoritmo genético clássico se resume à síntese de uma
população inicial, sobre a qual serão aplicadas as ações dos passos subseqüentes do processo.
Tipicamente se faz uso de funções aleatórias para gerar os indivíduos, sendo este um recurso
simples que visa fornecer maior “biodiversidade”, fundamental para garantir uma boa abrangência
do espaço de pesquisa. Existem várias alternativas ao método randômico, destinadas a suprir
deficiências no que diz respeito a dificuldades existentes quanto à criação aleatória de indivíduos de
representação mais complexa e, fator mais considerado, a uma melhora no desempenho. Podemos
citar como exemplo o uso de algoritmos de busca heurística como geradores de populações iniciais,
especialmente em casos que apresentem um alto grau de restrições, onde o AG recebe uma
população que ainda não possui indivíduos ótimos, mas que apresentam pelo menos algumas das
características desejadas. Os operadores de inicialização mais tradicionais são, segundo Goldeberg
(1989 apud LUCAS, 2000):
• Inicialização randômica uniforme: cada gene do indivíduo receberá como valor um
elemento do conjunto de alelos, sorteado de forma aleatoriamente uniforme;
• Inicialização randômica não uniforme: determinados valores a serem armazenados no
gene tendem a ser escolhidos com uma freqüência maior do que o restante;
• Inicialização randômica com dope: indivíduos otimizados são inseridos em meio à
população aleatoriamente gerada. Esta alternativa apresenta o risco de fazer com que um
ou mais super indivíduos tendam a dominar no processo de evolução e causar o
problema de convergência prematura; e
• Inicialização parcialmente enumerativa: são inseridos na população indivíduos de forma
a fazer com que esta comece o processo de evolução possuindo todos os esquemas
possíveis de uma determinada ordem.
Como no caso biológico, não há evolução sem diversidade, ou seja, a teoria da seleção
natural ou “lei do mais forte” necessita de que os indivíduos tenham diferentes graus de adaptação
ao ambiente em que vivem. É importante que a população inicial cubra a maior área possível do
espaço de busca, com um maior número de soluções, sem se interessar se são válidas ou não
(BRAZ JR, 2000).
28
Para Barreto (1997), a população inicial pode ser obtida através da geração randômica de
indivíduos obedecendo condições de contorno previamente estabelecidas pelo usuário. O usuário
estabelece estas condições tendo em vista o seu conhecimento prévio do problema a ser otimizado.
Quanto mais restringente forem as condições de contorno, mais rápida será a convergência, pois os
valores gerados randomicamente estarão mais próximos da solução desejada. “Quanto maior o
número de elementos da população maior é a probabilidade de convergência, tendo em vista que
aumenta a probabilidade da solução desejada constar entre os elementos da população. Em
contrapartida, o tempo de processamento também aumenta”.
2.3.2.2. Avaliação
Nesta etapa, o primeiro passo da seleção em si é dado: o universo da população sofre,
indivíduo a indivíduo, um processo de avaliação, que visa representar seu grau de adaptação. Na
verdade, este é, em conjunto com a escolha da representação, o ponto do algoritmo mais dependente
do problema em si – é necessário aqui que o AG seja capaz de responder sobre quão boa uma
resposta é para o problema proposto. Atualmente, várias formas de avaliação são utilizadas: em
casos de otimização de funções matemáticas, tende a ser escolhido o próprio valor de retorno destas
aplicado ao indivíduo, e em problemas com muitas restrições, funções baseadas em penalidades são
mais comuns. A função de avaliação também é chamada de função objetivo em um grande número
de trabalhos (PASTORINO, 1997).
2.3.2.3. Seleção
É no estágio de seleção que os indivíduos são escolhidos para posterior cruzamento. Neste
ponto, fazendo uso do grau de adequação de cada um, é efetuado um sorteio onde os mais aptos
possuem maior probabilidade de se reproduzirem. Este grau é calculado a partir da função de
avaliação de cada indivíduo, e determina quão apto ele está para a reprodução em relação à
população a que pertence.
O mecanismo de seleção em algoritmos genéticos emula os processos de reprodução
assexuada e seleção natural. Em geral, gera-se uma população temporária de N indivíduos extraídos
com probabilidade proporcional à adequabilidade relativa de cada indivíduo na população
(BARRETO, 1997).
29
A Figura 10 exemplifica o esquema de seleção, ilustrando também a tendência de extinção
dos seres “mais fracos”. No caso proposto pela figura, os dois indivíduos superiores da população
representada no quadrado à esquerda tentem a se extinguir após o processo de seleção, ou seja, não
farão parte da próxima população.
Figura 10. Exemplo do processo de Seleção Fonte: Braz Jr (2000)
A seleção tem por objetivo fazer com que somente os elementos mais adaptados da geração
anterior participem do processo que irá gerar a nova população. O processo de seleção inicia-se
após a verificação do grau de de adaptação de cada gene (BARRETO, 1997).
2.3.2.4. Reprodução ou Cruzamento
Segundo Scofield (2001), “reprodução é basicamente a geração novos indivíduos a partir
dos indivíduos selecionados”.
Os indivíduos selecionados na etapa anterior são cruzados da seguinte forma: a lista de
indivíduos selecionados é embaralhada aleatoriamente criando-se, desta forma, uma segunda lista,
chamada lista de parceiros. Cada indivíduo selecionado é então cruzado com o indivíduo que ocupa
a mesma posição na lista de parceiros. Os cromossomos de cada par de indivíduos a serem cruzados
são particionados em um ponto, chamado ponto de corte, sorteado aleatoriamente. Um novo
30
cromossomo é gerado permutando-se a metade inicial de um cromossomo com a metade final do
outro. Deve-se notar que se o cromossomo for representado por uma cadeia de bits, o ponto de corte
pode incidir em qualquer posição (bit) no interior de um gene, não importando os limites do gene.
No caso de genes representados por números reais, a menor unidade do cromossomo que pode ser
permutada é o gene. A seguir, é exemplificado o processo de cruzamento através da Figura 11
(BARRETO, 1997).
Células pais
Célula reprodutivas
Célula filha
Figura 11. Esquema da reprodução sexuada (cruzamento) Fonte: Barreto (1997)
O operador de cruzamento tem como objetivo propagar os esquemas mais adequados na
população. Para isto, os pontos de corte são fundamentais, pois vão determinar quais esquemas
sobreviverão ao processo de reprodução. Um exemplo de funcionamento do operador de
cruzamento de 1 ponto pode ser observado na Figura 12, onde, dois genomas de comprimento 20
(os superiores na Figura 12 são cruzados para gerar filhos). Considerando que a coloração dos
quadrados indica o valor contido no gene aos quais eles correspondem (claro para 0 e escuro para
1), um ponto de corte é sorteado de forma a cair entre o início e o fim do genoma (no exemplo, tal
ponto é na posição 11). Caso se faça uso de uma máscara de cruzamento, esta é preenchida com
zeros até o elemento de índice igual a posição de corte, e a partir daí com uns até seu fim. É
possível observar na Figura 12 o resultado final da operação: o filho 1 recebe os genes do pai 1 de
índice 1 a 11 e do pai 2 de 12 a 20, e o filho 2 os genes restantes, ou seja, os de 1 a 11 do pai 2 e os
de 12 a 20 do pai 1.
31
Figura 12. Operador de Cruzamento de um ponto Fonte: Lucas (2000)
Dentre os operadores de cruzamento tradicionais o de um ponto é o que normalmente
apresenta o pior desempenho. Existem também variações destes operadores de cruzamento que
utilizam-se de mais pontos de corte, como ilustrado na Figura 13.
Figura 13. Operador de Cruzamento de dois pontos Fonte: Lucas (2000)
Neste caso, são escolhidos dois pontos de corte, no índice 7 e 14, respectivamente. Os filhos
recebem os genes dos pais até o primeiro ponto de corte, intercalando-se os pais, o mesmo se repete
aos demais pontos de corte, porém, com inversão dos pais. Após o segundo ponto de corte, há uma
nova inversão dos pais e novamente os filhos recebem os genes dos pais.
32
2.3.2.5. Mutação
A operação de mutação é utilizada para garantir uma maior varredura do espaço de estados e
evitar que o algoritmo genético convirja muito cedo para mínimos locais. A mutação é efetuada
alterando-se o valor de um gene de um indivíduo sorteado aleatoriamente com uma determinada
probabilidade, denominada probabilidade de mutação, ou seja, vários indivíduos da nova população
podem ter um de seus genes alterado aleatoriamente (COSTA JR, 1999).
Segundo Costa Jr (1999), o operador de mutação se aplica a cada filho de maneira
individual, e consiste em uma alteração de maneira aleatória (normalmente com probabilidade
pequena), de cada gene componente do cromossomo. Pode-se pensar a princípio que o operador de
cruzamento é mais importante que o operador de mutação, já que proporciona uma exploração
rápida do espaço de busca. No entanto, esse último garante que nenhum ponto do espaço de busca
tenha probabilidade zero para ser examinado, e é de fundamental importância assegurar a
convergência dos AGs. Se o AG foi corretamente implementado, a população evoluirá ao longo das
gerações sucessivas de tal forma que a adaptação média estendida a todos os indivíduos da
população, assim como a adaptação do melhor individuo será incrementada de tal forma a
convergir para o ótimo global. O conceito de convergência está relacionado com a idéia de
progressão para uniformidade, ou seja, um gene terá convergido quando ao menos 95% da
população compartilhar o mesmo valor desse gene.
A mutação é fator fundamental para garantir a biodiversidade, assegurando assim que o
espaço de busca provavelmente será explorado em uma parte significativa de sua extensão. Apesar
de normalmente aplicada com uma probabilidade bastante inferior à de cruzamento, ela é tida por
uma série de autores como o operador mais importante para o processo evolutivo, chegando em
alguns casos extremos a ser utilizada como o único operador de transformação no curso de evolução
do AG.
O operador de mutação possui também um papel fundamental no que diz respeito à
necessidade de evitar a convergência prematura, que ocorre quando a população se estabiliza com
uma média de adaptação pouco adequada por causa da pressão evolutiva e baixa diversidade. Isto
geralmente se dá com o surgimento de um super-indivíduo que domina o processo seletivo e, uma
vez incapaz de gerar filhos melhores, transmite suas características por toda população (LUCAS
2000).
33
2.3.2.6. Atualização
Neste ponto, os indivíduos resultantes do processo de cruzamento e mutação são inseridos
na população segundo a política adotada pelo AG. Na forma mais tradicional deste (chamada
corriqueiramente de algoritmo genético simples), a população mantém um tamanho fixo e os
indivíduos são criados em mesmo número que seus antecessores e os substituem por completo.
Existem, porém, alternativas a essa abordagem: o número de indivíduos gerados pode ser menor, o
tamanho da população pode sofrer variações e o critério de inserção pode ser variado (como, por
exemplo, nos casos em que os filhos substituem os pais, ou em que estes só são inseridos se
possuírem maior aptidão que o cromossomo a ser substituído), ou o conjunto dos n melhores
indivíduos pode sempre ser mantido, tomando-se o cuidado de não selecionar um super indivíduo
para evitar o elitismo, que acarretará em uma convergência prematura do AG (LUCAS, 2000).
2.3.2.7. Finalização
A finalização não envolve o uso de nenhum operador genético: ela simplesmente é composta
de um teste que dá fim ao processo de evolução caso o AG tenha chegado a algum ponto pré-
estabelecido de parada. Os critérios para a parada podem ser vários, desde o número de gerações já
criadas até o grau de convergência da atual população (por convergência entende-se o grau de
proximidade dos valores da avaliação de cada indivíduo da população) (LUCAS, 2000).
Com isso, pretende-se utilizar os AGs para desenvolvimento deste TCC, gerando uma grade
de horários inicial, que será avaliada e evoluída enquanto uma condição de término não for atingida.
A condição de término pode ser um número pré-definido de gerações ou o alcance de uma solução
considerada ótima. Esta solução embora pareça simples, é bem complexa se levado em
consideração a forma de avaliação das grades geradas, bem como a forma de cruzamento a ser
adotado para as mesmas.
2.4. RECURSOS COMPUTACIONAIS NECESSÁRIOS
Nesta seção, serão descritos alguns conceitos sobre a linguagem de programação PHP, sobre
o banco de dados MySQL e UML (Unified Modeling Language), que serão utilizados para
implementação deste TCC. A escolha da linguagem e do banco seguiu os pré-requisitos
estabelecidos pelos desenvolvedores web do CTTMar, que baseiam-se principalmente na linguagem
de programação PHP utilizando banco de dados MySQL.
34
2.4.1. PHP
PHP é uma linguagem que permite criar sites WEB dinâmicos, possibilitando uma interação
com o usuário através de formulários, parâmetros da URL e links. A diferença de PHP com relação
a linguagens semelhantes a Javascript é que o código PHP é executado no servidor, sendo enviado
para o cliente apenas HTML puro. Desta maneira é possível interagir com bancos de dados e
aplicações existentes no servidor, com a vantagem de não expôr o código fonte para o cliente. Isso
pode ser útil quando o programa está lidando com senhas ou qualquer tipo de informação
confidencial (CASTAGNETTO et. al, 2001).
O PHP é uma linguagem de programação em forma de script que interage com o servidor,
utilizada para a criação de páginas dinâmicas na Web. Script é a parte do código HTML
interpretada pelo browser ou pelo Servidor Web. (ANSELMO, 2000).
A programação em PHP é similar à de qualquer outra linguagem, com definição de
variáveis, criação de funções, realização de loops, enfim, com todos os comandos utilizados para o
desenvolvimento de sistemas. O diferencial do PHP em relação às outras linguagens é a sua
capacidade de interagir com a Web, transformando páginas estáticas em dinâmicas fontes de
informação (SOARES, 2000).
Segundo Anselmo (2000), este tipo de script funciona da seguinte forma:
• O cliente realiza uma solicitação através de uma página HTML;
• Esta solicitação chega ao Servidor Web através da rede;
• O servidor então analisa a solicitação e reconhece que a resposta deve ser dada através
de uma página PHP;
• O servidor traduz a página PHP para uma página HTML; e
• A resposta em HTML é que aparece no browser do cliente.
O que diferencia PHP de um script CGI escrito em C ou Perl é que o código PHP fica
embutido no próprio HTML, enquanto no outro caso é necessário que o script CGI gere todo o
código HTML, ou leia de um outro arquivo. Em seguida, a Figura 14 mostra como é tratada a
requisição de um cliente a uma página com código PHP (CASTAGNETTO et. al, 2001).
35
Figura 14. Esquema de funcionamento do PHP Fonte: Castagnetto et. al (2001)
Desta maneira, o cliente não tem acesso ao código fonte embutido na página a qual ele fez a
requisição, o que torna o ambiente PHP mais seguro e confiável por não exibir informações
sigilosas em sua página html de retorno.
2.4.1.1. Aplicações de PHP
Para Castagnetto et. al (2001), basicamente, qualquer coisa que pode ser feita por algum
programa CGI pode ser feita também com PHP, como coletar dados de um formulário, gerar
páginas dinamicamente, processar os dados ou enviar e receber cookies.
PHP tem como uma de suas características mais importantes o suporte a um grande número
de bancos de dados, como dBase, Interbase, mSQL, mySQL, Oracle, Sybase, PostgreSQL e vários
outros. Construir uma página baseada em um banco de dados torna-se uma tarefa extremamente
simples com PHP (ANSELMO, 2000).
Além disso, PHP tem suporte a outros serviços através de protocolos como IMAP, SNMP,
NNTP, POP3 e, logicamente, HTTP. Ainda é possível abrir sockets e interagir utilizando outros
protocolos (SOARES, 2000).
2.4.1.2. Surgimento da Linguagem PHP
A linguagem PHP teve origem durante o outono de 1994 por Rasmus Lerdorf. As primeiras
versões não foram disponibilizadas, tendo sido utilizadas em sua home-page apenas para que ele
pudesse ter informações sobre as visitas que estavam sendo feitas. A primeira versão utilizada por
outras pessoas foi disponibilizada em 1995, e ficou conhecida como “Personal Home Page Tools”
(ferramentas para página pessoal). Era composta por um sistema bastante simples que interpretava
algumas macros e alguns utilitários que rodavam “por trás” das home-pages: um livro de visitas, um
contador e algumas outras coisas (CASTAGNETTO et. al, 2001).
Em meados de 1995 o interpretador foi reescrito, e ganhou o nome de PHP/FI, o “FI” veio
de um outro pacote escrito por Rasmus que interpretava dados de formulários HTML (Form
36
Interpreter). Ele combinou os scripts do pacote Personal Home Page Tools com o FI e adicionou
suporte a mSQL, nascendo assim o PHP/FI, que cresceu bastante, e as pessoas passaram a
contribuir com o projeto (ibidem).
Estima-se que em 1996 PHP/FI estava sendo usado por cerca de 15.000 sites pelo mundo, e
em meados de 1997 esse número subiu para mais de 50.000. Nessa época houve uma mudança no
desenvolvimento do PHP. Ele deixou de ser um projeto de Rasmus com contribuições de outras
pessoas para ter uma equipe de desenvolvimento mais organizada. O interpretador foi reescrito por
Zeev Suraski e Andi Gutmans, e esse novo interpretador foi a base para a versão 3 (ibidem).
Atualmente, a versão atual do PHP é a versão 5, de 08 de junho de 20042. No site não
haviam dados sobre a quantidade aproximada de downloads desta versão para estimar um número
aproximado de usuários.
2.4.1.3. Cliente-Side Scripts
São responsáveis pelas ações executadas no browser, sem contato com o servidor. Os
exemplos mais comuns de aplicações client-side são imagens e textos que mudam com o passar do
mouse e os java scripts (CASTAGNETTO et. al, 2001).
Os scripts client-side são muito úteis para fazer validações de formulários sem utilizar
processamento do servidor, com isso não provocando tráfego na rede (ibidem).
2.4.1.4. Server-Side Scripts
São responsáveis pelas ações executadas no servidor. Os exemplos mais comuns de
aplicações server-side são os scripts cgi´s e PHP (CASTAGNETTO et. al, 2001).
No momento em que o usuário solicita uma URL, o servidor apresentará no browser um
código html dinâmico, isto é muito útil para construções de aplicações baseadas em informações
on-line. A Figura 15 mostra o esquema de funcionamento do cliente-side scripts e do server-side
scripts (ibidem).
2 A versão atual do PHP pode ser conseguida através do link http://www.php.net/get/php-5.0.0RC3-Win32.zip/from/a/mirror
37
Figura 15. Esquema de funcionamento entre requisições do cliente e servidor Fonte: Castagnetto et. al (2001)
2.4.1.5. ASP X PHP
Enquanto o ASP só é executado em plataformas microsoft, o PHP suporta a maioria das
plataformas que provêem acesso e serviços da internet, é distribuído sobre GPL (Licença Pública
Geral), ou seja, não se precisa pagar para usar o PHP (CASTAGNETTO et. al, 2001).
Ambas linguagens de programação operam no lado do servidor, através de requisições feitas
pelos clientes. ASP é muito utilizada em servidores Windows NT, Windows 2000 Server e
Windows 2003 (ANSELMO, 2000).
2.4.1.6. Estrutura de Programas PHP
Inicialmente aparecem os comandos HTML que serão enviados ao browser sem qualquer
formatação pelo PHP. Nesta parte coloca-se a inicialização do HTML (<html>, <head>, <body>,
etc.) e quaisquer outras informações úteis à melhor apresentação da página Web.
Podem existir páginas totalmente escritas PHP, as quais utilizam-se das Tags HTML para
elaborar a página que será enviada ao usuário.
No meio do código HTML pode ser inserido o código PHP, que começa sempre pela
expressão <?php e termina com a expressão ?>. Entre essas expressões pode-se atribuir valores a
variáveis, chamar ou definir funções, acessar banco de dados, formatar resultados, enfim, todos os
recursos disponíveis na linguagem PHP.
38
2.4.2. MYSQL
MySQL é um sistema de banco de dados SQL bastante popular distribuído sob a licença
GNU-GPL. O MySQL é um servidor de banco de dados pequeno, compacto e fácil de usar, ideal
para aplicações de pequeno e médio porte. Ele é uma implementação cliente/servidor composta por
um daemon servidor mysqld por diversos programas clientes diferentes. Ele está disponível para
diversas plataformas UNIX e Windows. Em plataforma UNIX, ele utiliza encadeamentos, o que o
torna um servidor de banco de dados de alto desempenho e altamente escalável. O MySQL suporta
ANSI SQL.92 nível de entrada e padrão SQL. ODBC nível 0-2 (CASTAGNETTO et. al, 2001).
O MySQL armazena cada tabela no banco de dados como um arquivo em separado no
diretório do banco de ddos. O tamanho máximo de uma tabela pode ficar entre 4GB e o limite
máximo do tamanho de arquvios suportado pelo sistema operacional. O MySQL também é muito
fácil de gerenciar. Você não precisa de um administrador de banco de dados treinado para a
administração ou instalação de um banco de dados MySQL (ibidem).
Trata-se de um banco de dados relacional de código aberto. Ele é distribuído gratuitamente
para plataforma UNIX e OS/2, e, para as plataformas Microsoft, é necessária a obtenção de uma
licença após um período de testes de 30 dias. Portanto, o MySQL apresenta uma grande vantagen
no custo se comparado a outros bancos de dados relacionais. O custo para a licença é de
aproximadamente U$$ 495,00 sem suporte e U$$ 1.500,00 com direito a suporte técnico. (MYSQL,
2004).
2.4.2.1. Recursos de Banco de Dados Não Presentes no MySQL
Embora o MySQL seja um sistema de banco de dados de fácil compreensão, deve-se ficar
atento às suas limitações, ou seja, rotinas e funcionalidades que não estão presentes no MySQL,
conforme descrito à seguir (CASTAGNETTO et. al, 2001):
• Sub-Selects – aninhamentos de declarações select;
• RolBack – restauração do banco ao estado inicial antes de executar alguma alteração nos
dados;
• Store-Procedures – conjunto de comandos compilados e armazenados no servidor de
banco de dados e
39
• Exibições – uma saída de uma consulta não pode ser tratada como uma tabela virtual,
portanto não podendo ser vista como uma “consulta armazenada”.
Caso haja necessidade da utilização de alguma das funcionalidades descritas acima, deverá
ser utilizado outro banco de dados (CASTAGNETTO et. al, 2001).
2.4.2.2. Utilização
Moura Fé (2004) diz em seu artigo que a empresa HP anunciou suporte e integração à sua
plataforma de hardware ao banco de dados MySQL, entre outros (INFOEXAME, 2004).
Em entrevista ao site eWEEK, o vice-presidente de marketing para MySQL, Zack Urlocker, disse que desde o ano passado o uso do MySQL vem crescendo muito no meio corporativo, sobretudo nos segmentos de varejo, telecomunicações e serviços financeiros. “Estamos assistindo a um crescente interesse de companhias que desejam desenvolver uma estratégia completa de código aberto, que vai além do Linux, envolvendo todo o LAMP (Linux, Apache, MySQL, PHP)”, diz o executivo.(ibidem)
O provedor de acesso e serviços Terra3 oferece a seus usuários acesso ao banco de dados
MySQL com uma cota de até 30 MB. Todos os seus fóruns são armazenados nesta plataforma de
banco.
2.4.2.3. Versão
A primeira conferência de usuários do MySQL foi inaugurada com a divulgação do código-
fonte do MySQL 5.0, próximo lançamento da companhia. Como fornecedora de software aberto
para base de dados, a companhia suíça está trilhando seu caminho para ingressar em mercados
dominados pelos fornecedores proprietários, tais como Oracle, IBM, Microsoft e Sybase (MYSQL,
2004).
São realizados cerca de 29 mil donwloads por dia do MySQL, estimando-se um total de
aproximadamente 4 milhões de usuários. Em relação a licenças, existem dois tipos. Um destes tipos
prevê que as empresas que utilizam o software gratuitamente, tem o dever de tornar pública
qualquer modificação realizada no código-fonte.O outro modelo, para os usuários que preferem
manter as alterações dentro da empresa, requer o pagamento de uma taxa pela privacidade (ibidem).
3 Provedor de serviços Terra: http://site.web.terra.com.br/servicos.htm
40
A versão 5.0 do MySQL inclui sistemas de alerta automático em caso de problemas e
procedimentos armazenados, que permitem a reconstrução de um comando para uso futuro. A renda
da companhia é proveniente de serviços, certificações e cursos, além das versões pagas dos
produtos (MYSQL, 2004).
2.4.3. UML
Para realizar a modelagem do sistema, será utilizada a UML (Unified Modeling Language),
pois apresenta características necessárias e adequadas. Como o sistema baseia-se principalmente no
algoritmo genético, UML será utilizada principalmente para dar uma idéia geral da aplicação ao
leitor, de forma simples e objetiva, não sendo objetivo deste trabalho estudar e analisar a fundo
todos os recursos disponíveis na UML para modelagem do sistema.
Segundo MULLER (1999), a UML se adequa perfeitamente a modelagem de Banco de
Dados, seja ela relacional, pós-relacional ou orientada a objetos, pois tem como principais
características o reaproveitamento, flexibilidade e independência.
Quando os desenvolvedores adotam a UML para modelar toda a aplicação, conseguem
esquemas de banco de dados mais coesos do que quando usam a abordagem entidade-
relacionamento, isto por causa da abrangência dos diagramas. Uma classe da UML pode contemplar
todos os gatilhos (triggers) e procedimentos (stored procedures) que devem constar nas tabelas
armazenadas fisicamente, além dos atributos, relacionamentos e cardinalidades necessárias
(ibidem).
De acordo com Conallen (2004), as aplicações Web estão ficando cada vez mais complexas
no que diz respeito a criação e manutenção, necessitando de um planejamento através de
abordagens para modelagem de sistemas tais como a UML.
Entretanto, a UML não foi concebida para modelar fielmente tais aplicações e, para isso,
fora adicionada uma extensão que contempla componentes específicos de sistemas Web como
páginas do cliente, páginas do servidor, entre outros.
Segundo Conallen (2004), na extensão para a Web, as páginas clientes ou servidoras são
tratadas igualmente como classes. Sua diferenciação é feita por meio de ícones (forma visual) e
estereótipos (forma descritiva), sendo que os estereótipos ainda descrevem o comportamento lógico
destas páginas.
41
O diagrama use-case representa a visão do usuário em um cenário de uso de um sistema que
está sendo modelado. Os use-cases evoluíram de um trabalho feito por Ivar Jacobsen na indústria de
telecomunicações nos anos 60. Nessa ocasião, Jacobsen aplicou o conceito de casos de tráfego e
funções para o mesmo propósito com que os use-cases são utilizados hoje. A popularidade dos use-
cases se dá por dois motivos: primeiramente, pela sua simplicidade de uso e, segundo, pela sua
facilidade de aprendizado(SALM JR e THIRY, 2004).
Os use-cases possuem diversos propósitos na engenharia de software. Para o autor, eles
podem ser usados para capturar e documentar requisitos; para validar funcionalidades em rotinas de
teste; e para promover as funcionalidades de um produto de software (ibidem).
Será utilizado também o diagrama de sequência, que mostra a interação entre os objetos ao
longo do tempo e apresenta os objetos que participam da interação e a sequência de mensagens
trocadas (ibidem).
Com isso, será desenvolvido o sistema utilizando a linguagem de programação PHP e o
banco de dados MySQL. Existem algumas limitações quanto a utilização da linguagem PHP em
relação ao desempenho de processamento, partindo-se do ponto de que PHP é uma linguagem
voltada para o desenvolvimento de páginas web. Porém, como o universo da aplicação não é tão
extenso, talvez seja possível obter bons resultados de processamento utilizando-se PHP. Contudo,
se o desempenho não for satisfatório, facilmente pode-se migrar o processamento da aplicação para
linguagem de programação C, cujo desempenho é superior, desenvolvendo-se um sistema a parte
encarregado apenas do processamento e geração da grade de horários referentes às reservas. Este é
um item a ser analisado durante a etapa de desenvolvimento, onde os testes de desempenho serão
feitos conforme a necessidade.
[FIM DE SEÇÃO. Não remova esta quebra de seção]
42
3. DESENVOLVIMENTO
A proposta deste trabalho é desenvolver um sistema baseado em Algoritmos Genéticos para
otimização das reservas dos laboratórios de informática do CTTMar, pertencentes ao curso de
Ciência da Computação, da UNIVALI.
3.1. MODELAGEM DO SISTEMA
A modelagem do sistema foi feita utilizando-se embasamento na linguagem UML. Será
apresentado a seguir o diagrama de Use Cases, com as descrições de seus processos e cenários e
também o diagrama ER (Entidade Relacionamento) atual do banco de dados existente, bem como as
alterações necessárias para implementação do processo de otimização das reservas.
3.1.1. Diagrama de Use-Cases
O diagrama de Use Cases (Figura 16) demonstra a interação do docente com o sistema bem
como as interações do coordenador dos laboratórios, principal operador encarregado (ator) do
sistema.
Docente Cadastrar Pre-Reserva
Cadastrar Software
Gerar Reservas
Cadastrar Laboratório
Cadastrar Usuário
Cadastrar Restrição
Gerar Relatório
Coordenador
Figura 16. Use Case do Sistema Proposto.
O coordenador dos laboratórios é o responsável pelo gerenciamento dos laboratórios,
cabendo a ele a maior parte das atribuições em relação ao sistema. O docente fica encarregado
apenas de entrar com os dados referentes às suas reservas.
Para uma melhor compreensão do processo Gerar Relatório, a Figura 17 mostra um maior
detalhamento dos sub-processos vinculados a este processo.
Curso
Software
Laboratório
Gerar Relatório
Disciplina
Figura 17. Use-Case do Processo Gerar Relatório.
3.1.1.1. Descrição dos Use Cases
A seguir serão descritos os Use Cases do sistema proposto, que envolvem o docente e o
coordenador dos laboratórios.
Use-Case: – Docente cadastra Pré-Reserva Contexto: O docente deseja incluir a sua solicitação de pré-reserva no sistema. Objetivo: O docente deseja utilizar o laboratório. Ações: O docente, após ter se logado ao sistema, entra em uma área restrita para cadastro de pré-reservas. Ele poderá incluir sua pré-reserva e clicar em inserir, para inserir no banco de dados a sua solicitação. Use-Case: – Coordenador cadastra Pré-Reserva Contexto: O coordenador deseja incluir a sua solicitação de pré-reserva no sistema, pois ele também é um docente. Objetivo: O coordenador deseja utilizar o laboratório.
44
Ações: O coordenador, após ter se logado ao sistema, entra em uma área restrita para cadastro de pré-reservas. Ele poderá incluir sua pré-reserva e clicar em inserir, para inserir no banco de dados a sua solicitação. Use-Case: – Coordenador cadastra Software Contexto: O coordenador deseja incluir um novo software no sistema. Objetivo: O coordenador deseja disponibilizar um novo software aos docentes. Ações: O coordenador, após ter se logado ao sistema, entra em uma área restrita para cadastro de software, onde ele terá que digitar o nome do software e selecionar os laboratórios nos quais este estará disponível. Use-Case: – Coordenador cadastra Laboratório Contexto: O coordenador deseja incluir um novo laboratório no sistema. Objetivo: O coordenador deseja disponibilizar um novo laboratório aos docentes. Ações: O coordenador, após ter se logado ao sistema, entra em uma área restrita para cadastro de laboratório, onde ele terá que digitar o nome do laboratório, quantidade de computadores e relacionar softwares disponíveis. Use-Case: – Coordenador cadastra Restrição Contexto: O coordenador deseja incluir uma nova restrição no sistema. Objetivo: O coordenador deseja atribuir um novo filtro ao processo de otimização de reservas. Ações: O coordenador, após ter se logado ao sistema, entra em uma área restrita para cadastro de restrição, onde ele terá que selecionar o laboratório e o software a ele restrito. Use-Case: – Coordenador Cadastra Usuário Contexto: O coordenador deseja cadastrar um novo usuário. Objetivo: O coordenador deseja cadastrar um novo usuário no sistema para ter acesso a funções exclusivas, como cadastrar usuários, alterar senhas, gerenciar cotas de impressão e gerar grade de reservas. Ações: O coordenador, após ter se logado ao sistema, entra em uma área restrita para cadastrar usuários, digita o login do usuário e em seguida seleciona as funções às quais deseja que o usuário tenha acesso. Use-Case: – Coordenador Gera Reservas Contexto: O coordenador deseja gerar a grade de reservas. Objetivo: O coordenador deseja gerar a grade de reservas baseado nas pré-reservas encaminhadas pelos docentes, armazenadas na tabela PRE_RESERVA. Ações: O coordenador, após ter se logado ao sistema, entra em uma área restrita para gerar reservas, clica em “gerar grade de reservas”. É exibida uma tela ao coordenador com as grades de reservas geradas por data, bem como uma lista contendo as pré-reservas que não puderam ser atendidas. O coordenador pode então aceitar ou não a grade atual clicando em “Aceitar” ou em “Anular” para voltar à etapa anterior e modificar os parâmetros utilizados pelo processo de geração. Use-Case: – Coordenador Gera Relatório Contexto: O coordenador deseja gerar relatórios sobre os laboratórios. Objetivo: O coordenador deseja obter informações sobre os laboratórios, como utilização, softwares e quantidade de computadores. Ações: O coordenador, após ter se logado ao sistema, entra em uma área restrita para gerar relatórios, escolhe o relatório que deseja gerar.
45
Use-Case: – Gera Relatório Software Contexto: O coordenador deseja gerar relatórios software. Objetivo: O coordenador deseja obter informações sobre o software mais utilizado, bem como a lista de todos os software utilizados nas reservas com sua respectiva porcentagem de uso. Ações: O coordenador, após ter se logado ao sistema, entra em uma área restrita para gerar relatórios, escolhe o relatório referente à Software. Use-Case: – Gera Relatório Disciplina Contexto: O coordenador deseja gerar relatórios disciplina. Objetivo: O coordenador deseja obter informações sobre a disciplina que mais utiliza o laboratório, bem como a lista de todas as disciplinas que utilizam os laboratórios com suas respectivas porcentagens de uso. Ações: O coordenador, após ter se logado ao sistema, entra em uma área restrita para gerar relatórios, escolhe o relatório referente à Disciplina. Use-Case: – Gera Relatório Laboratório Contexto: O coordenador deseja gerar relatórios laboratório. Objetivo: O coordenador deseja obter informações sobre o laboratório mais utilizado, bem como a lista de todos os laboratórios com sua respectiva porcentagem de uso. Ações: O coordenador, após ter se logado ao sistema, entra em uma área restrita para gerar relatórios, escolhe o relatório referente à Laboratório. Use-Case: – Gera Relatório Curso Contexto: O coordenador deseja gerar relatórios curso. Objetivo: O coordenador deseja obter informações sobre o curso que mais utiliza os laboratórios, bem como a lista de todos os cursos com seus respectivos porcentuais de uso. Ações: O coordenador, após ter se logado ao sistema, entra em uma área restrita para gerar relatórios, escolhe o relatório referente à Curso.
Estas use cases descrevem o funcionamento das rotinas comuns a docentes e ao coordenador
dos laboratórios. Foi utilizada a UML apenas para dar uma visão geral dos processos ao leitor, de
forma que possa compreender melhor a estruturação do sistema, bem como as funções pertinentes
ao mesmo
3.1.2. Diagrama de Seqüência
O diagrama de sequência tem como objetivo demonstrar mais detalhadamente como ocorre
a interação do coordenador dos laboratórios com os processos responsáveis pela geração da grade
de reservas. Estes processos consistem basicamente em automatizar e otimizar as pré-reservas. O
algoritmo genético está embutido no processo de otimização, o qual depende do processo de
automatização. A Figura 18 ilustra o diagrama de sequência proposto.
46
: CoordenadorSISLAB Gerar Reservas Automatizar
Pré-ReservasOtimizar
Pré-ReservasBanco MySQL
TELA
Solicita Geração de Pré-Reservas
Iniciar Geração
Automatizar
Seleciona Pré-Reservas
Grade Horária Automatizada
Grade Otimizada
TELA
ACEITA RESERVAS
GRAVA RESERVAS
APAGA PRÉ-RESERVAS
Transações Efet ivadas Com Sucesso
TELA
Figura 18. Diagrama de Sequência do processo Gerar Reservas.
3.1.3. Diagrama ER
O diagrama ER (Entidade Relacionamento) visa mostrar graficamente qual a estrutura atual
do banco de dados do SISLAB, bem como as alterações que serão necessárias para o
desenvolvimento do sistema proposto.
47
A Figura 19 mostra a estrutura atual do banco de dados do SISLAB para fins ilustrativos. O
diagrama ER referente à estrutura atual do banco de dados está disponível no Anexo 1 deste TCC.
Figura 19. Diagrama ER atual da estrutura do banco de dados do SISLAB
Fonte: Laboratório de Informática – CTTMar – UNIVALI
Com base neste diagrama ER, foi feito um estudo referente às necessidades de adaptação ao
diagrama de modo que o TCC possa ser implementado. As adaptações necessárias consistem
principalmente na criação de novas tabelas e alteração de outra, como descrito a seguir:
1. Criar a tabela PRE_RESERVA, que conterá os dados referentes à pré-reserva;
2. Criar uma view da tabela DISCIPLINA da base de dados da UNIVALI (SECADI),
que será necessária à pré-reserva;
3. Criar uma view da tabela CURSO da base de dados da UNIVALI (SECADI), que
será necessária à pré-reserva;
4. Criar a tabela DATAS_PR, que armazenará todas as datas para cada solicitação de
pré-reserva;
48
5. Criar a tabela RESTRICAO onde ficarão armazenados os horários de término das
aulas que não sejam do curso de Ciência da Computação;
6. Criar a tabela REQ_SOFTWARE_PR, que armazena todas as requisições de
software feitas pelos docentes para as pré-reservas; e
7. Acrescentar o campo COD_DISCIPLINA à tabela RESERVA, para que possa ser
gerado o relatório referente à disciplina que mais utiliza os laboratórios para aula.
A Figura 20 mostra para fins ilustrativos, as alterações necessárias no diagrama ER atual do
banco de dados para que este possa ser adequado à implementação do TCC. As alterações
necessárias consistem na criação de novas tabelas e alteração de outras. O diagrama ER com as
alterações necessárias pode ser melhor visualizado no Apêndice 1 deste TCC.
Figura 20. Diagrama ER com as alterações necessárias
Com estas alterações, o banco de dados estará apto a dar total funcionalidade aos objetivos
deste trabalho, tanto para otimização de reservas quanto para geração de relatórios referentes à sua
utilização, como software, curso, disciplina, etc.
49
3.1.4. Dicionário de Dados Atual
As tabelas utilizadas pelo atual SISLAB correspondem à Tabela 1. Nesta tabela estão os
nomes das tabelas como sua descrição.
Tabela 1. Tabela com a relação de tabelas do banco de dados dos laboratórios
Nome da Tabela Descrição ATENDENTE Tabela contendo os privilégios do usuário SITUACAO Tabela contendo a situação da conta do usuário USUARIO Tabela de usuários
UTILIZACAO Tabela de utilização dos laboratórios SOFTWARE Tabela de software
LAB_STATUS Tabela de Status do Laboratório LOCAL Tabela de laboratórios
RESERVA Tabela de reservas REQ_SOFTWARE Tabela de requisição de software EQUIPAMENTO Tabela de equipamentos
REQ_EQUIP Tabela de requisição de equipamentos PUNICAO Tabela de punições
MENSAGEM Tabela de mensagens LOG Tabela de LOG
HIST_IMPRESSAO Tabela de histórico de impressão FUNCIONARIO Tabela de funcionários e professores
CURSO Tabela de cursos CASTIGO Tabela de Castigos ALUNO Tabela de Alunos
Fonte: Laboratório de Informática do CTTMar
Cada tabela possui um conjunto particular de colunas, que define as características de seus
dados. Cada atributo possui um domínio particular de valores definido por tipos de dados possíveis
para esta coluna.
Tipos de Dados:
• INTEGER: Números Inteiros que variam entre -32768 á 32765;
• VARCHAR(X): Caracteres numéricos e alfabéticos em quantidade definida por X; e
• DATETIME: Um data válida.
A Tabela 2 lista as tabelas bem como suas colunas com os respectivos tipos de dados. Estas
são as tabelas atuais utilizadas pelo SISLAB.
50
Tabela 2. Tabela com a relação de tabelas, colunas e tipos de dados
Nome da Tabela Nome das Colunas Tipo de dados da Coluna
ATENDENTE
COD_USUARIO P_1 P_2 P_3 P_4 P_5
VARCHAR(15) VARCHAR(1) VARCHAR(1) VARCHAR(1) VARCHAR(1) VARCHAR(1)
SITUACAO COD_SITUACAO DESC_SITUACAO
INTEGER VARCHAR(50)
USUARIO
COD_USUARIO COD_SITUACAO
COD_ATENDENTE NOME EMAIL SENHA
SENHA_EXPIRADA QUANT_PAG
PAG_IMPRESSA DATA_CADASTRO
TELEFONE
VARCHAR(15) INTEGER
VARCHAR(15) VARCHAR(50) VARCHAR(50) VARCHAR(100)
INTEGER INTEGER INTEGER
VARCHAR(15) VARCHAR(15)
UTILIZACAO
COD_UTIL COD_USUARIO
DATE_UTIL HORA_INICIAL HORA_FINAL
EQUIPAMENTO
INTEGER VARCHAR(15)
DATETIME DATETIME DATETIME
VARCHAR(20) SOFTWARE COD_SOFTWARE
DESC_SOFTWARE INTEGER
VARCHAR(50) LAB_STATUS ID_STATUS
DESC_STATUS INTEGER
VARCHAR(50)
LOCAL COD_LOCAL DESC_LOCAL CAPACIDADE
INTEGER VARCHAR(50)
INTEGER
MENSAGEM
COD_USUARIO COD_MENSAGEM
DATA HORA PARA
MENSAGEM VISIVEL
VARCHAR(15) INTEGER
VARCHAR(15) VARCHAR(15) VARCHAR(15) VARCHAR(255) VARCHAR(1)
REQ_SOFTWARE COD_RESERVA COD_SOFTWARE
INTEGER INTEGER
EQUIPAMENTO COD_EQUIP DESC_EQUIP
INTEGER VARCHAR(50)
REQ_EQUIP COD_RESERVA COD_EQUIP
INTEGER INTEGER
51
Nome da Tabela Nome das Colunas Tipo de dados da Coluna PUNICAO COD_PUNICAO
DESC_PUNICAO INTEGER
VARCHAR(50)
RESERVA
COD_RESERVA COD_USUARIO
COD_ATENDENTE COD_LOCAL ID_STATUS
DATA_RESERVA HORA_INICIAL HORA_FINAL
OBS
INTEGER INTEGER
VARCHAR(15) VARCHAR(15)
INTEGER VARCHAR(15) VARCHAR(15) VARCHAR(15) VARCHAR(15)
LOG
COD_LOG COD_USUARIO
DESCRICAO DATA HORA
INTEGER VARCHAR(15) VARCHAR(150) VARCHAR(15) VARCHAR(15)
FUNCIONARIO
COD_USUARIO PROF_CTTMAR
RESERVAR_LAB
VARCHAR(15) VARCHAR(1) VARCHAR(1)
CURSO COD_CURSO DESC_CURSO
INTEGER VARCHAR(50)
HIST_IMPRESSAO
COD_USUARIO COD_HIS
DATA HORA
QUANT_PAG DESC_IMPRESSAO
ORIGEM
VARCHAR(15) INTEGER
VARCHAR(15) VARCHAR(15)
INTEGER VARCHAR(15) VARCHAR(15)
ALUNO COD_USUARIO COD_CURSO
VARCHAR(15) INTEGER
CASTIGO
COD_CASTIGO COD_USUARIO COD_PUNICAO
DATA_OCORRENCIA DATA_INICIO
DATA_FIM
INTEGER VARCHAR(15)
INTEGER VARCHAR(15) VARCHAR(15) VARCHAR(15)
Fonte: Laboratório de Informática do CTTMar
3.1.5. Dicionário de Dados com as Alterações Necessárias
Como foram necessárias alterações na base de dados atual do SISLAB, a Tabela 3 contém as
novas tabelas criadas na base de dados de forma que a implementação do TCC fosse possível.
52
Tabela 3. Tabela com a relação de tabelas a serem acrescentadas ao Banco de dados
Nome da Tabela Descrição DATAS_PR Tabela contendo as datas das solicitações das pré-reservas DISCIPLINA Tabela contendo as informações referentes à disciplina RESTRICAO Tabela contendo as restrições que serão utilizadas pelo AG
REQ_SOFTWARE_PR Tabela com as requisições de software das pré-reservas REST_SOFTWARE Tabela que faz a ligação entre os software restritos com os laboratórios
PRE_RESERVA Tabela contendo as pré-reservas
A Tabela 4 lista as tabelas que foram criadas bem como suas colunas e os tipos de dados
referentes às mesmas.
Tabela 4. Relação de tabelas a serem criadas e suas respectivas colunas e tipos de dados
Nome da Tabela Nome das Colunas Tipo de dados da Coluna DATAS_PR COD_DATAPR
COD_PR DATA
INTEGER INTEGER
VARCHAR(8) DISCIPLINA COD_DISCIPLINA
COD_CURSO DESC_DISCIPLINA
INTEGER INTEGER
VARCHAR (50)
RESTRICAO COD_RST
COD_LOCAL COD_DISCIPLINA
INTEGER INTEGER INTEGER
REQ_SOFTWARE_PR
COD_PR COD_SOFTWARE COD_DISCIPLINA
INTEGER INTEGER INTEGER
REST_SOFTWARE
COD_RSW COD_REST
COD_SOFTWARE
INTEGER INTEGER INTEGER
PRE_RESERVA
COD_PR COD_DISCIPLINA
COD_USUARIO HORA_INICIAL HORA_FINAL NUMALUNOS
INTEGER INTEGER
VARCHAR(15) VARCHAR(5) VARCHAR(5)
INTEGER
Com estas alterações, fez-se viável a implementação do TCC, tendo em vista que o mesmo
baseia-se em uma base de dados para geração e otimização da grade de reservas.
3.2. IMPLEMENTAÇÃO
Na primeira etapa deste TCC, foi desenvolvida a entrada de dados para pré-reserva em PHP,
obedecendo aos padrões web do CTTMar, que já foi utilizada para a solicitação de pré-reservas dos
docentes no início do segundo semestre de 2004, mais precisamente de 15 de julho até 10 de agosto
53
de 2004. Esta tela de entrada de dados, sofreu algumas alterações, de maneira que pudesse ser
escolhido mais de um software para a mesma reserva, bem como algumas alterações em seu layout.
A Figura 21 ilustra a nova página de entrada de dados.
Figura 21. Nova tela de entrada de dados para Pré-Reserva
Foram realizadas um total de 60 solicitações de pré-reservas utilizando esta página de
entrada de dados, o que gerou um total de 265 reservas, contabilizadas as datas solicitadas por cada
pré-reserva (uma pré-reserva pode referir-se a uma ou a várias datas). Com isso, também foram
geradas 85 solicitações de software para estas pré-reservas. As solicitações de pré-reservas, bem
como as datas referentes às mesmas e os respectivos softwares utilizados para as mesmas, foram
armazenadas em tabelas de banco de dados MySQL.
Para melhorar o desempenho do AG e diminuir o tempo de processamento, optou-se em
fazer a geração das grades de reservas iniciais de uma maneira que algumas restrições existentes
sejam obedecidas. Dessa maneira, os descendentes destas grades já esteão próximos da grade ideal,
54
diminuindo assim o esforço realizado pelo AG para a otimização. Para isso, a etapa de
implementação foi dividida em duas partes principais. A primeira parte é responsável pela
automatização da grade de reservas, onde são geradas as grades iniciais para que na segunda parte,
denominada otimização, o AG possa utilizá-las como parâmetro para obtenção de uma grade
considerada ótima. Existe ainda a terceira parte, que consistiu na elaboração da geração dos
relatórios gerenciais referentes as reservas cadastradas.
3.2.1. Automatização
Com os dados obtidos através das solicitações de pré-reservas feitas pelos docentes
armazenados em tabelas, partiu-se para o desenvolvimento da parte referente a automatização da
geração da grade de reservas, ou seja, a elaboração automatizada da grade de reservas, agrupadas
por data. Em um primeiro momento, todas as solicitações foram agrupadas conforme a data da
solicitação, inicialmente em uma matriz e seu resultado exibido em forma de uma tabela HTML que
reúne as informações de cada pré-reserva, como data, hora inicial, hora final, solicitante, código da
disciplina, quantidade de alunos, etc. A Figura 22 serve de ilustração para a tabela HTML gerada.
DATA HORA_INICIAL HORA_FINAL NOME COD_DISCIPLINA NUMALUNOS NOME_CURSO SOFTWARE
17:00 19:00 PROF01 2438 20 Biotecnologia IDEA
13:30 15:10 PROF03 2416 40 Biotecnologia STATISTICA
15:20 18:50 PROF02 2406 22 Biotecnologia MICROSOFT OFFICE
09:50 12:20 PROF04 2898 10 Engenharia Ambiental
STELLA SCILAB
SISBAHIA
28/07/2004
19:00 21:00 PROF01 2438 20 Biotecnologia IDEA
Figura 22. Tabela HTML contendo um agrupamento por data das Pré-Reservas
Esta tabela foi gerada para que o coordenador dos laboratórios pudesse distribuir as reservas
entre os laboratórios de uma forma mais simplificada e organizada (pois os docentes passaram a
fazer a solicitação de pré-reservas através da página, e não mais via e-mail), o que representou uma
melhora significativa em relação à forma como eram feitas anteriormente. Em um segundo
momento, utilizando a mesma matriz que gera a tabela HTML citada anteriormente, implementou-
se a distribuição automática das pré-reservas entre os laboratórios, observando a ocorrência de
choques de horário. Nesta etapa, são geradas duas grades contendo as solicitações das pré-reservas
distribuídas pelos laboratórios, estas agrupadas por data. Esta distribuição é feita de forma estática,
55
iniciando sempre pelo último laboratório, no caso, o laboratório 6 para a geração da primeira grade
e iniciando do laboratório 1 para a geração da segunda grade.
Para que a distribuição das pré-reservas pelos laboratórios fôsse realizada, implementou-se
um algoritmo que inicialmente seleciona todas as solicitações de pré-reservas do banco e as retorna
em uma QUERY. Algumas colunas desta QUERY são então armazenadas em uma nova matriz. As
colunas salvas na matriz são referentes ao código da pré-reserva, data, código do curso, número de
alunos e as solicitações de software para aquela pré-reserva. Desta forma, a matriz vai sendo
montada linha a linha, até que o total de solicitações seja satisfeito.
Com a matriz preenchida, parte-se para a etapa de alocação dos laboratórios para as pré-
reservas. A etapa de alocação consiste basicamente em dois laços. O primeiro laço varre a QUERY
contendo as pré-reservas, e o segundo laço fica responsável pela distribuição da mesma pelos
laboratórios. O segundo laço tenta alocar algum laboratório para a pré-reserva atual e caso não
consiga, a pré-reserva é inserida em uma matriz temporária para que ao final do processo, possa ser
inserida em uma tabela para conferência por parte do coordenador dos laboratórios.
O algoritmo que faz a verificação dos choques de horários recebe como parâmetros a matriz
onde serão armazenadas as pré-reservas distribuídas pelos laboratórios, a data a ser verificada bem
como a hora final, a hora inicial e o número do laboratório inicial, que refere-se ao último
laboratório, no caso, o laboratório 6. Os dados passados por parâmetro são analisados, laboratório a
laboratório até que o número total de laboratórios tenha sido checado. O algoritmo retorna um array
contendo a lista dos laboratórios disponíveis. Com este resultado, a pré-reserva é então alocada para
o primeiro laboratório disponível da lista.
É interessante ressaltar que este processo de automatização oferece apenas a conferência de
choques de horários para uma mesma data em um mesmo laboratório. Poderia aprimorar-se este
processo para verificar também a capacidade de alunos, hora final das pré-reservas que são
agendadas para os laboratórios do curso de Ciência da Computação e principalmente a questão de
software, como por exemplo, o AUTOCAD, porém, como isto já refere-se à otimização, tais
aprimoramentos ficam a critério do AG.
56
3.2.1.1. Rotina de Distribuição das Pré-Reservas
Como a tabela HTML gerada agrupa as pré-reservas por data, a rotina de distribuição das
pré-reservas gera duas grades de reservas que servem de base para o AG, como população inicial.
Um parâmetro no cabeçalho desta rotina serve para dizer ao algoritmo de distribuição se o mesmo
deve iniciar a distribuição pelo último laboratório (no caso, o laboratório 6, ou pelo primeiro, no
caso, o laboratório 1). Esse parâmetro pode ser o símbolo “<” para iniciar a distribuição à partir do
menor laboratório (no caso, laboratório 1) ou “>” para iniciar a distribuição do maior laboratório
(no caso, o laboratório 6).
Se a distribuição é chamada com o parâmetro “<”, o laboratório atual passa a ser o
laboratório 1 e ela gera a grade partindo do laboratório atual até o maior laboratório possível. Ao
ocorrer um choque de horário, o laboratório atual é incrementado, passando a ser o laboratório 2 e
assim sucessivamente, enquanto o laboratório atual for menor ou igual ao número de laboratórios,
no caso, 6. Caso o laboratório atual seja alocado, o laboratório atual volta a ser o primeiro e as
distribuições continuam sendo feitas. Se o laboratório atual que está sendo alocado é incrementado
até chegar ao número máximo de laboratórios existentes, a pré-reserva é inserida em uma matriz
que contém as datas e os códigos das pré-reservas que não puderam ser alocadas por falta de
laboratórios, devido aos choques de horário. A mesma técnica aplica-se ao caso de gerar uma grade
de reservas partindo-se do último laboratório, porém, em vez de incrementar o laboratório atual no
caso de choques de horário, o mesmo é decrementado enquanto ele seja maior do que 1.
A Figura 23 ilustra a organização das matrizes com seus respectivos nomes e dados a serem
armazenados nas respectivas colunas. A ordem destas colunas é de fundamental importância para o
funcionamento correto dos algoritmos de automatização e otimização.
Matriz ALOCADAS
COD_LOCAL DATA HORA_INICIAL HORA_FINAL COD_PR
Matriz RESTRIÇÕES
COD_LOCAL HORA_FINAL COD_SOFTWARE CAPACIDADE
Matriz GRADE
COD_PR COD_LOCAL DATA HORA_FINAL COD_CURSO NUMALUNOS COD_SOFTWARE COD_USUARIO
# Figura 23. Estrutura das matrizes utilizadas na implementação do sistema
57
Esta é a estrutura de colunas das matrizes utilizadas na implementação deste TCC. A matriz
GRADE serve de base para o AG, e parte do princípio que cada linha desta matriz refere-se a uma
solicitação de pré-reserva, ou seja, a um indivíduo e cada coluna refere-se a um alelo. A grade
forma um conjunto de indivíduos, ou seja, forma uma população.
É importante ressaltar que são geradas duas matrizes na etapa de automatização. A primeira
possui a distribuição dos laboratórios iniciada à partir do último laboratório, e a segunda possui a
distribuição iniciada à partir do primeiro laboratório. Essas matrizes servirão de base para a geração
das grades de reservas, que consistem em matrizes onde apenas as datas comuns ficam agrupadas,
diferente das matrizes iniciais onde embora exista este agrupamento, possuem todas as datas com
suas respectivas solicitações de pré-reserva.
3.2.2. Otimização
O processo de otimização é o responsável pela implementação do AG, que tem como
objetivo distribuir as pré-reservas entre os laboratórios da melhor maneira possível. Ele consiste
basicamente em um laço com cinco etapas, que são: Inicialização da população, avaliação da
população, cruzamento dos selecionados, avaliação dos resultantes e atualização da população. Este
laço é aplicado a todas as datas que possuem alguma solicitação de pré-reserva. Cada etapa descrita
anteriormente foi implementada em forma de rotina, para que a estruturação do AG ficasse mais
clara e para facilitar alterações, se necessárias.
3.2.2.1. Rotina de Inicialização
Esta rotina baseia-se nas matrizes geradas no processo de automatização, pois as mesmas já
foram elaboradas para servir de base para o AG. Essas matrizes consistem na distribuição dos
laboratórios pelas pré-reservas obedecendo aos choques de horário, sendo a primeira distribuída a
partir do laboratório 6, sendo decrementado o número do laboratório no caso de choques de horário
e a segunda é distribuída a partir do laboratório 1, sendo incrementado o número do laboratório
atual no caso de um choque de horário. Essas matrizes englobam todas as pré-reservas solicitadas,
agrupadas por data, da menor para a maior data.
Com essas duas matrizes, parte-se para a geração das grades a serem cruzadas entre si. Isso
ocorre através de um laço que tem uma variável iniciada com a menor data solicitada, varre todas as
matrizes comparando essa data com a data da matriz. Se forem iguais, a grade recebe a linha da
58
matriz que contém a mesma data. Isso se repete para as duas grades, uma para cada matriz. Ao final,
têm se duas grades para apenas uma data. Essas grades são avaliadas e posteriormente são cruzadas,
gerando assim uma terceira grade. Com isso, a variável data passa para a data imediatamente
superior, e novamente as grades são geradas, agora, para uma outra data.
A Figura 24 serve de ilustração para uma grade inicial, baseada na matriz gerada na etapa de
automatização, sobre a qual foi gerada uma grade para a data 20040728 (aaaa/mm/dd) e que serve
de base para o algoritmo genético.
COD_PR COD_LOCAL DATA HORA_FINAL COD_CURSO CAPACIDADE COD_SOFTWARE COD_USUARIO
11 6 20040728 12:20 3 10 25,3,22 PROF04
12 6 20040728 15:10 1 40 24 PROF02
21 5 20040728 15:30 3 20 13 PROF01
4 6 20040728 18:50 1 22 16 PROF03
18 5 20040728 21:00 1 20 13 PROF01
19 4 20040728 19:00 1 20 13 PROF01
20 6 20040728 21:00 1 20 13 PROF01
Figura 24. Exemplo de grade que serve de base para o AG
A primeira linha desta matriz serve apenas para que o leitor possa ter uma idéia da
distribuição dos valores pela matriz. Esta ordem é de fundamental importância para o
funcionamento do AG. As demais linhas correspondem a cada pré-reserva solicitada para a data em
questão, no caso, na terceira coluna (28/07/2004). Cada coluna é um alelo, e cada grade um
indivíduo.
Como pode ser visto, a grade ilustrada pela Figura 25 inicia a distribuição dos laboratórios
pelo labortório 6, e conforme a ocorrência de choques de horário, vai sendo decrementado. Os
laboratórios que foram alocados para as pré-reservas estão representados na segunda coluna
(COD_LOCAL). A grade ilustrada refere-se à grade 1, a grade 2 é semelhante, sendo alterada
apenas a coluna referente ao COD_LOCAL pela nova distribuição, que inicia com o laboratório 1.
3.2.2.2. Rotina de Avaliação
Esta rotina encarrega-se de atribuir uma penalidade a uma grade horária. Quanto maior for a
penalidade, maior será a rejeição da mesma. A rotina avalia as restrições, tais como, número de
alunos superior ou inferior à capacidade do laboratório, hora de término das aulas além do horário
59
permitido naquele laboratório bem como a questão de software a ser utilizado. O retorno desta
rotina é um array contendo as penalidades para cada pré-reserva. Quanto menor a penalidade,
menos irregularidades, portanto, a grade é melhor. Inicialmente, a rotina recebe como parâmetros
uma matriz contento uma grade com as reservas a serem avaliadas (vide Figura 25), outra matriz
contendo as restrições existentes referentes à hora final e capacidade (vide Figura 26) e uma outra
matriz contendo a relação dos software que possuem restrição.
Ao ser chamada, a rotina inicializa três variáveis contendo os pesos referentes a cada uma
das três restrições possíveis, no caso, restrição de capacidade, de hora de término da aula e restrição
de software. O maior peso é dado para a restrição de software, pois implica em uma série de fatores
burocráticos, como licença de software, entre outros. Portanto, tem um peso maior para fazer com
que a penalidade seja aumentada e para a pré-reserva sendo avaliada.
A Figura 25 ilustra a matriz RESTRICOES com seus respectivos nomes de coluna e valores
e serve para ilustrar os dados contidos na matriz, de modo que possam ser feitas as respectivas
avalizações.
COD_LOCAL HORA_FINAL COD_SOFTWARE CAPACIDADE
6 22:30 1 24
6 22:30 3 24
5 22:30 3 20
5 22:30 25 20
3 19:00 5 36
Figura 25. Exemplo da matriz restrições com suas respectivas colunas e valores.
A verificação inicia-se com um laço que percorre a matriz GRADE (vide Figura 25) e outro
laço que percorre a matriz RESTRICOES (vide Figura 26), comparando os campos referentes ao
código do local (COD_LOCAL) das duas matrizes. Caso seja o mesmo local, o próximo passo é a
verificação do código do curso para que possa ser feita a restrição de horários. No caso, se o curso
não for Computação, há restrição de horário. Desta forma, compara-se a hora final da matriz
GRADE com hora final da matriz RESTRICOES. Se a hora final da matriz GRADE for maior que a
hora final da matriz RESTRICOES, a nota da grade é incrementada com o peso referente à hora
final. O próximo passo é checar a capacidade dos laboratórios, ou seja, se as pré-reservas foram
alocadas de maneira que não se tenha mais alunos do que computadores e nem mais computadores
60
do que alunos, com uma tolerância de 40% abaixo e 20% acima da capacidade do laboratório em
questão (Estes parâmetros também são ajustáveis, bem como os pesos). Se o número de alunos
contido na matriz GRADE estiver fora deste intervalo, a nota é novamente incrementada com o
preso referente à capacidade. E por último, é verifado a questão de software. Para que esta
verificação seja feita, é necessário um laço que verifica todas as solicitações de software para a pré-
reserva sendo avaliada e as compara com a matriz referente aos programas restritos. Se algum dos
sofware estiver cadastrado na matriz que contém os programas restritos, e o código do laboratório
(COD_LOCAL) da matriz contendo os programas for diferente do código do laboratório da matriz
GRADE, a nota é incrementada com o peso referente à software. Desta maneira faz - se a avaliação
da grade horária linha a linha, ou seja, pré-reserva a pré-reserva.
Como retorno desta rotina, temos um array que contém as penalidades individuais de cada
pré-reserva. Inicialmente essa penalidade se aplicava à grade somente, e não individualmente a cada
pré-reserva. Porém, isso fazia com que uma grade que contivesse apenas uma penalidade de
software pudesse ser descartada se comparada a uma grade que contivesse várias outras
penalidades, porém, somando um valor menor. Fazendo a avaliação por pré-reserva e não por grade,
apenas as pré-reservas que apresentarem uma elevada penalidade são descartadas (substituídas) por
pré-reservas com uma penalidade menor, não descartando-se assim a grade inteira.
3.2.2.3. Cruzamento
Esta rotina recebe como parâmetro uma estrutura contendo as grades a serem cruzadas bem
como suas respectivas penalizações bem como o número da grade atual a ser cruzada. Esta estrutura
é um array de arrays, ou seja, cada linha desta estrutura contém uma coluna que é uma grade, e
outra coluna que corresponde às notas das pré-reservas desta grade.
A rotina de cruzamento baseia-se nesses parâmetros e dá início a um laço que varre cada
uma das matrizes referentes às penalidades das grades em questão comparando as penalidades de
ambas as grades. A grade resultante é composta pelas pré-reservas que obtiveram a menor
penalidade, ou seja, pelas pré-reservas com os laboratórios mais apropriados. Para melhor
compreender esta rotina, a Figura 26 ilustra duas grades a serem cruzadas.
A Figura 26 ilustra duas grades que serão cruzadas, referentes ao dia 28/07/2004. A grade1 é
composta pela distribuição dos laboratórios iniciando pelo laboratório 6 e a grade 2 é composta pela
61
distribuição dos laboratórios iniciando pelo laboratório 1, como pode ser observado na segunda
coluna das grades.
Figura 26. Grades a serem cruzadas, penalidades e grade resultante.
Como pode ser observado, logo abaixo da grade 1 e abaixo da grade 2 existem duas
matrizes, contendo o código da pré-reserva e sua respectiva penalidade. Abaixo, o resultado do
cruzamento, ou seja, a grade resultante. A rotina de cruzamento compara as penalidades por pré-
reserva, como por exemplo, a pré-reserva 11 (COD_PR, primeira coluna). A penalidade desta pré-
reserva sendo alocada ao laboratório 6 foi 84, enquanto que a mesma pré-reserva sendo alocada ao
laboratório 1 apresentou penalidade de 153. Com isso, a rotina de cruzamento compara as duas
notas. Como a nota da pré-reserva que corresponde a grade 1 é menor do que a nota que
corresponde a pré-reserva da grade 2, a grade resultante passa a ser composta pela pré-reserva da
grade 1. O mesmo aplica-se a pré-reserva 12, que na grade 1 obteve uma penalidade de 7 e na grade
62
2 obteve a mesma penalidade. Diante deste empate, a grade resultante recebe a pré-reserva referente
à grade 2.
A Figura 27 ilustra duas novas grades, referentes ao dia 25/08/2004, para que fique mais
clara a compreensão do leitor sobre o processo de cruzamento que ocorre entre as grades.
Figura 27. Outro exemplo de cruzamento entre as grades.
O processo de cruzamento funciona de maneira simples, porém, muito eficaz, resultando em
grades otimizadas. Um aprimoramento possível de ser feito seria em relação a grade resultante, que
nem sempre é a melhor possível. Pois como pode ser observado, a grade resultante consiste nas pré-
reservas que apresentaram a menor penalidade, porém, a grade perfeita é aquela composta por pré-
reservas que tenham sua penalidade igual a zero. Com isso, uma rotina que objetivasse zerar as
penalidades atribuindo outros laboratórios as pré-reservas, fazendo a devida avaliação e validação
da mesma poderia otimizar ainda mais a grade resultante, obtendo assim, uma grade mais próxima
da ideal.
63
3.2.2.4. Atualiza População
Esta rotina atualiza a estrutura contendo as grades resultantes. A grade resultante do
processo de cruzamento é inserida na estrutura que contém as grades iniciais e suas respectivas
penalidades. Sendo assim, mantém-se na estrutura as grades iniciais e a grade resultante, para que
venha a ser impelementada alguma rotina para zerar as penalidades objetivando uma melhor
otimização, tenha-se guardada a grade resultante da etapa anterior para que seja comparada com a
nova.
3.2.2.5. Atualização do Banco de Dados
Uma vez executadas as etapas anteriores, um laço garante a passagem do AG por todas as
datas com pré-reservas existentes. Ao final do laço, têm-se uma estrutura com todas as pré-reservas
otimizadas. As grades otimizadas desta estrutura são então exibidas na tela do computador ou salvas
em forma de arquivo para que o coordenador ou responsável pela geração das grades possa editá-las
e salvá-las definitivamente no banco.
Após salvas as reservas no banco, as tabelas usadas para geração das reservas, mais
especificamente as tabelas PRE_RESERVA, REQ_SOFTWARE_PR e DATAS_PR são zeradas, ou
seja, todo seu conteúdo é apagado, o que impossibilita a geração de novas grades horárias até que o
coordenador dos laboratórios libere novamente a tela de solicitação de pré-reservas. Caso haja
necessidade de alterar alguma das reservas cadastradas, basta editá-las e fazer as alterações
necessárias. Estas tabelas são apagadas porque sua utilização limita-se à geração da grade de
reservas final. Uma vez gerada esta grade, as solicitações de pré-reservas não são mais úteis e
podem ser descartadas.
A Figura 28 ilustra a saída do sistema, ou seja, apresenta as grades otimizadas por data, já no
padrão web utilizado pelo CTTMar.
64
Figura 28. Tela de saída do sistema, já com as pré-reservas agendadas.
3.2.3. Relatórios
Em relação aos relatórios que foram propostos por este TCC, que consistem basicamente
relatórios referentes à utilização de software nas aulas agendadas, às disciplinas que mais utilizam
os laboratórios, no laboratório mais utilizado bem como na questão do curso que mais utiliza os
laboratórios consistem basicamente em consultas ao banco de dados, mais especificamente na
tabela RESERVAS, da qual são extraídas as informações necessárias aos demais relatórios.
O relatório de software consiste em um agrupamento das reservas com o software mais
utilzado, em ordem decrescente. É feita uma consulta no banco buscando todas as reserva que tem
um ou mais software vinculados, contabilizando o total de ocorrências para cada software. Ao final,
o resultado é ordenado em ordem decrescente.
65
O relatório de disciplinas que mais utilizam o laboratório consiste em um agrupamento das
reservas de forma que as disciplinas sejam contabilizadas. Isso é feito atráves de uma consulta no
banco de dados que retorna estes dados.
O reltaório referente ao curso que mais utillza o laboratório é feito da mesma maneira, onde
o agrupamento das reservas é feito pelo curso. Existem ainda alguns cursos que não estão
cadastrados na base de cursos, pois esta base contém apenas os cursos necessários para que seja
feita a pré-reserva. Desta maneira, os cursos que não pertencem ao CTTMar, não participam do
processo de solicitação de pré-reserva, e suas reservas são feitas diretamente ao coordenador dos
laboratórios.
O relatório do laboratório mais utilizado parte do princípio que sua utilização é baseada nas
aulas agendadas, e não em sua utilização real. Muitas aulas são agendadas e o docente por algum
motivo, acaba não comparecendo, enquanto outras são dadas em tal laboratório sem que seja feita a
reserva. O resultado deste relatório baseia-se única e exclusivamente no conteúdo das reservas
alocadas para cada laboratório, que são agrupadas e exibidas de forma decrescente, ou seja, do
laboratório mais utilizado para o laboratório menos utilizado.
66
4. CONCLUSÕES
Dos objetivos propostos por este trabalho, a pesquisa sobre sistemas semelhantes foi
concluída e seu resultado utilizado como fundamentação teórica e referência bibliográfica. A
pesquisa e análise sobre AGs foi realizada principalmente fazendo-se um comparativo entre a teoria
e seu emprego na prática, no caso, analisando as maneiras como alguns autores conseguiram
otimizar seus sistemas baseados em AGs. A implementação deste TCC baseou-se principalmente
nos estudos realizados por Lucas (2000) e Braz Jr (2000), dos quais apenas o segundo chegou a
implementar o sistema.
Outro objeivo diz respeito a obter domínio sobre a linguagem PHP e determinar os padrões
web do CTTMar. Este objetivo foi alcançado através da implementação deste TCC, pois para tanto
o conhecimento sobre PHP e domínio sobre os padrões do CTTMar foram fundamentais. A
implementação das rotinas de cadastro, alteração e exclusão foram concluídas e são utilizadas para
solicitação das pré-reservas pelos docentes, sempre no início de cada semestre e foram
implementadas rigorosamente seguindo os padrões de páginas web do CTTMar.
O objetivo referente a implementação do AG foi divido em duas etapas. A etapa de
automatização, que monta uma grade com todas as pré-reservas e as agrupa por data, já fazendo
uma alocação inicial de laboratórios para a mesma foi concluída e já foi utilizada no início do
segundo semestre do ano de 2004. A segunda etapa trata da otimização e está totalmente concluída,
atendendo às necessidades de otimização que foram propostas por este TCC.
Um fator preocupante em relação aos AGs encontrado nas pesquisas referentes ao uso dos
AGs foi a grande necessidade de processamento que os mesmos exigiam dos micro-computadores,
o que fazia com que o tempo de otimização fôsse elevado. Porém, com os avanços tecnológicos
existentes hoje e levando-se em consideração o grande poder de processamento dos micro-
processadores atuais, tal fator deixa de ser um fator determinante quanto a escolha dos Algoritmos
Genéticos como técnica a ser utilizada nos mais diversos problemas, pois nos estudos feitos sobre
sua utilização, todos apontavam AGs como técnica que requer alto poder de processamento, e em
consequência disso, um aumento significativo no tempo necessário à sua otimização. Das pesquisas
realizadas, algumas datam do ano de 2002, outras de 2001, de 1999 e até de 1997, anos nos quais os
micro-processadores não tinham a capacidade de processmento que tem hoje. [FIM
67
O sistema desenvolvido foi validado e será utilizado pelo coordenador dos laboratórios para
fazer a distribuição das reservas que são solicitadas pelos docentes. Embora este sistema seja
utilizado somente duas vezes por ano (no início de cada semestre), tem uma grande serventia, pois
automatiza o processo de solicitação de reservas e faz a distribuição de maneira que todas as
restrições sejam satisfeitas. Alguns aprimoramentos poderiam ser adicionados ao processo de
otimização, como por exemplo, prioridades de alocação para disciplinas que dependem única e
exclusivamente do laboratório para aula. Desta maneira, o sistema implementado atende as
necessidades propostas para seu desenvolvimento, deixando claro que melhorias podem ser
adicionadas ao mesmo de maneira que este sistema seja capaz de atender e satisfazer da melhor
maneira possível seus objetivos.
FIM DE SEÇÃO. Não remova esta quebra de seção]
68
REFERÊNCIAS BIBLIOGRÁFICAS
ALCÂNTARA, Andréia Almeida, FIGUEIRA FILHO, Carlos Santos da, BRASIL, Cibelle César do Amaral, ARANHA, Débora Cristina da Silva, BARBOSA, Geórgia Pinto. Home Pages: recursos e técnicas para criação de páginas www. Rio de Janeiro: Campus, 1998.
ANSELMO, F. PHP e MySQL para Windows. Florianópolis: Visual Books, 2000.
BARRETO, Jorge Muniz. Inteligência Artificial: no limiar do século XXI. Florianópolis: PPP edições, 1997.
BRAZ JR, Osmar de Oliveira. Otimização de horários em instituições de ensino superior através de algoritmos genéticos. Dissertação (Mestrado em Engenhaira de Produção) - Universidade Federal de Santa Catarina, Florianópolis, 2000. Disponível em: <http://teses.eps.ufsc.br/Resumo.asp?1186>. Acesso em 17 mar. 2004.
CASTAGNETTO, Jesus, RAWAT, Harish, SCHUMANN, Sascha, SCOLLO, Chris, VELIATH, Deepak. Professional PHP programando. Tradução: Equipe Makron Books de Tradução Técnica. Revisão Técnica: Marcos Jorge. São Paulo: MAKRON Books, 2001. ISBN: 85-346-1289-7.
CONALLEN, Jim. Modeling Web application architectures with UML. Disponível em: <http://www.rational.com/media/whitepapers/webapps.pdf>. Acesso em: 15 jun. 2004.
COSTA, Eduardo Oliveira, DELLA BRUNA, Marlonn. Resolução de “Timetabling” utilizando evolução cooperativa. Disponível em: <http://www.sbc.org.br/reic/edicoes/2003e1/cientificos/ResolucaoDeTimetablingUtilizandoEvolucaoCooperativa.pdf>. Acesso em 12 abr. 2004.
DARWIN, Charles. A origem das espécies. EDUSP, 1985.
LOPES, Maurício Capobianco; SCHOEFFEL Pablo. Um método de alocação para o problema de reservas de sala de aula. artigo científico. [2002]. Disponível em <http://www.cbcomp.univali.br/anais/pdf/2002/sin018.pdf>. Acesso em: 22 abr. 2004.
LUCAS, Diogo Correa. Algoritmos Genéticos: um estudo de seus conceitos fundamentais e aplicação no problema de grade horária. Monografia (Bacharelado em Informática)-Universidade Federal de Pelotas, Pelotas, 2000. Disponível em: <http://www.ufpel.tche.br/prg/sisbi/bibct/acervo/info/2000/Mono-Diogo.pdf>. Acesso em 20 abr. 2004.
MOURA FÉ, Ana Lúcia. HP anuncia suporte para MySQL e Jboss. Revista InfoExame. Disponível em: <http://info.abril.com.br/aberto/infonews/062004/01062004-0.shl>. Acesso em: 15 jun. 2004.
MULLER, Robert J. Database design for smarties: using UML for data modeling. San Francisco : Morgan Kaufmann Publishers, 1999.
MYSQL. Disponível em: <http://www.mysql.com/news-and-events>. Acesso em: 20 jun 2004.
PASTORINO, Alexandre Sandin. Algoritmos Genéticos: aplicações e perspectivas. artigo científico. [1997]. Disponível em: <http://ia.ucpel.tche.br/ioia/Algoritc.doc>. Acesso em: 05 maio 2004.
RIBEIRO, Andréa D.; VASATA, Mônica; SCHNEIDER, André M. Algoritmos genéticos aplicados a robôs móveis autônomos. Disponível em: <http://www.inf.uri.com.br/algoritmos_geneticos.htm>. Acesso em: 20 abr. 2004a.
RIBEIRO, Luisa Fernanda. Idéias básicas dos algoritmos genéticos. Disponível em <http://www.icmc.usp.br/~eventos/luisa.pdf>. Acesso em: 20 abr. 2004b.
SALM JR, José Francisco; THIRY, Marcello. Processo de desenvolvimento de software com
UML. Disponível em: <http://www.eps.ufsc.br/disc/procuml>. Acessado em: 17 jun. 2004.
SOARES, W. Programando em PHP: Conceitos e Aplicações. São Paulo: Érica, 2000.
SCOFIELD,Wendrer Carlos Luz. Aplicação de algoritmos genéticos ao problema job-shop. Monografia (Bacharelado em Ciência da Computação)-Universidade Federal de Ouro-Preto, Ouro Preto, 2002. Disponível em: <http://www.decom.ufop.br/prof/marcone/Disciplinas/InteligenciaComputacional/MonografiaWendrer%20PO1.zip>. Acesso em 17 jun. 2004.
SOUZA JR, Elmo Melquíades de. Estudo de métodos para resolução do problema dinâmico da coleta e entrega utilizando algoritmos genéticos. Monografia (Bacharelado em Ciência da Computação)-Universidade Federal de Lavras, Lavras, 2003. Disponível em: <http://www.comp.ufla.br/curso/ano2003/Estudo_de_metodos_para_resolucao_do_problema_dinamico_da_coleta_e_entrega_utilizando_algoritmos_geneticos.pdf>. Acesso em: 18 jun. 2004.
[FIM DE SEÇÃO. Não remova esta quebra de seção]
70
APÊNDICE 1 – DIAGRAMA ER DO BANCO DE DADOS COM AS ALTERAÇÕES NECESSÁRIAS
ANEXO 1 – DIAGRAMA ER ATUAL DO BANCO DE DADOS
72
ANEXO 2 – ARTIGO CIENTÍFICO
73