protÓtipo de um sistema de controle de reservas...
TRANSCRIPT
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE CIÊNCIAS DA COMPUTAÇÃO
(Bacharelado)
PROTÓTIPO DE UM SISTEMA DE CONTROLE DE RESERVAS DE SALA DE AULA DA UNIVERSIDADE
REGIONAL DE BLUMENAU
TRABALHO DE CONCLUSÃO DE CURSO SUBMETIDO À UNIVERSIDADE REGIONAL DE BLUMENAU PARA A OBTENÇÃO DOS CRÉDITOS NA
DISCIPLINA COM NOME EQUIVALENTE NO CURSO DE CIÊNCIAS DA COMPUTAÇÃO — BACHARELADO
PABLO SCHOEFFEL
BLUMENAU, JUNHO/2001
2001/1-56
PROTÓTIPO DE UM SISTEMA DE CONTROLE DE RESERVAS DE SALA DE AULA DA UNIVERSIDADE
REGIONAL DE BLUMENAU
PABLO SCHOEFFEL
ESTE TRABALHO DE CONCLUSÃO DE CURSO, FOI JULGADO ADEQUADO PARA OBTENÇÃO DOS CRÉDITOS NA DISCIPLINA DE TRABALHO DE
CONCLUSÃO DE CURSO OBRIGATÓRIA PARA OBTENÇÃO DO TÍTULO DE:
BACHAREL EM CIÊNCIAS DA COMPUTAÇÃO
Prof. Maurício Capobianco Lopes — Orientador na FURB
Prof. José Roque Voltolini da Silva — Coordenador do TCC
BANCA EXAMINADORA
Prof. Maurício Capobianco Lopes Prof. Wilson Pedro Carli Prof. Roberto Heinzle
“O término de uma etapa nada
mais é do que um sinal que estamos preparados para enfrentar
a próxima.”
AGRADECIMENTOS
Agradeço a todos aqueles que fizeram parte desses anos de graduação, aos
amigos que fiz e que, com certeza, continuarão sendo grandes amigos.
Em especial aos amigos da Divisão de Registros Acadêmicos, que me deram
uma força imensa e aos amigos de turma: Cristiano, Murilo, Cacá, Juliano e todos os
outros que de algum modo contribuiram na grandeza de nossos estudos.
Agradeço a minha família que sempre me acompanha e que é a maior riqueza da
minha vida.
Agradeço a Edna que já faz parte da minha vida e que sempre me incentiva nos
momentos difíceis.
Agradeço ao professor Maurício que me auxiliou e incentivou muito, dando os
caminhos para a realização desse trabalho.
SUMÁRIO
LISTA DE FIGURAS ............................................................................................................ VII
LISTA DE QUADROS ......................................................................................................... VIII
RESUMO .................................................................................................................................IX
ABSTRACT ..............................................................................................................................X
1 INTRODUÇÃO.....................................................................................................................1
1.1 OBJETIVOS........................................................................................................................3
1.2 ESTRUTURA .....................................................................................................................3
2 TÉCNICAS DE ALOCAÇÃO ..............................................................................................5
2.1 PESQUISA OPERACIONAL.............................................................................................5
2.1.1 FORMULAÇÃO DO PROBLEMA .................................................................................6
2.1.2 CONSTRUÇÃO DO MODELO.......................................................................................7
2.1.3 OBTENÇÃO DE UMA SOLUÇÃO ................................................................................7
2.1.4 TESTE DO MODELO E DA SOLUÇÃO........................................................................7
2.1.5 ESTABELECIMENTO DE CONTROLES......................................................................7
2.1.6 IMPLANTAÇÃO..............................................................................................................8
2.2 PROBLEMA DE DESIGNAÇÃO (ATRIBUIÇÃO)..........................................................8
3 ANÁLISE ESSENCIAL......................................................................................................12
3.1 VANTAGENS DA ANÁLISE ESSENCIAL ...................................................................12
3.2 O MODELO ESSENCIAL ...............................................................................................13
3.2.1 MODELO AMBIENTAL...............................................................................................13
3.2.1.1 LISTA DE EVENTOS .................................................................................................14
3.2.1.1.1 EVENTO ORIENTADO POR FLUXO DE DADOS.............................................14
3.2.1.1.2 EVENTO ORIENTADO POR CONTROLE ..........................................................15
3.2.1.1.3 EVENTO ORIENTADO POR TEMPO..................................................................15
3.2.1.2 DIAGRAMA DE CONTEXTO ...................................................................................15
3.2.1.3 DECLARAÇÃO DOS OBJETIVOS DO SISTEMA...................................................16
3.2.2 MODELO COMPORTAMENTAL................................................................................16
3.2.2.1 DFD DE NÍVEL ZERO................................................................................................17
3.2.2.2 MÉTODO DE OBTENÇÃO DO MODELO DE DADOS ..........................................17
3.3 O MODELO DE IMPLEMENTAÇÃO............................................................................18
3.3.1 CONSTRUÇÃO DO MODELO LÓGICO DE DADOS................................................18
3.3.2 CARACTERÍSTICAS DE PROCESSAMENTO ..........................................................18
3.3.3 INTERFACE HOMEM X MÁQUINA ..........................................................................19
4 DESENVOLVIMENTO PARA INTERNET......................................................................20
4.1 HYPER TEXT MARKUP LANGUAGE (HTML) ..........................................................20
4.2 ACTIVE SERVER PAGES (ASP) ...................................................................................21
4.2.1 CONCEITOS ..................................................................................................................21
4.2.2 REQUISITOS .................................................................................................................22
4.2.3 VANTAGENS ................................................................................................................23
5 DESENVOLVIMENTO DO PROTÓTIPO ........................................................................25
5.1 TRABALHOS CORRELATOS........................................................................................25
5.2 REQUISITOS PRINCIPAIS DO PROBLEMA ...............................................................25
5.3 ESPECIFICAÇÃO DO PROTÓTIPO ..............................................................................26
5.3.1 MODELO AMBIENTAL...............................................................................................26
5.3.1.1 LISTA DE EVENTOS .................................................................................................26
5.3.1.2 DIAGRAMA DE CONTEXTO ...................................................................................28
5.3.1.3 DECLARAÇÃO DOS OBJETIVOS DO SISTEMA...................................................29
5.3.2 MODELO COMPORTAMENTAL................................................................................30
5.3.2.1 DIAGRAMA DE FLUXO DE DADOS.......................................................................30
5.3.3 MODELO DE IMPLEMENTAÇÃO..............................................................................32
5.3.3.1 MODELO DE DADOS ................................................................................................33
5.4 IMPLEMENTAÇÃO ........................................................................................................33
5.4.1 TÉCNICAS E FERRAMENTAS UTILIZADAS...........................................................34
5.4.2 INTERFACE...................................................................................................................38
5.5 OPERACIONALIDADE DA IMPLEMENTAÇÃO........................................................48
5.6 RESULTADOS E DISCUSSÃO ......................................................................................50
6 CONCLUSÕES ...................................................................................................................51
6.1 LIMITAÇÕES E DIFICULDADES ENCONTRADAS ..................................................51
6.2 EXTENSÕES ....................................................................................................................52
7 REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................53
LISTA DE FIGURAS Figura 1 : Exemplo dos modos de processamento do sistema.................................................18
Figura 2 : Diagrama de Contexto.............................................................................................29
Figura 3 : DFD - Parte I............................................................................................................31
Figura 4 : DFD – Parte II..........................................................................................................31
Figura 5 : MER do sistema.......................................................................................................33
Figura 7 : Tela de Autenticação................................................................................................39
Figura 8 : Tela Principal...........................................................................................................40
Figura 9 : Cadastro de Sala.......................................................................................................41
Figura 10 : Cadastro de Restrições da Turma..........................................................................41
Figura 11 : Tela da Alocação das Salas....................................................................................43
Figura 12 : Gráfico das Características das Salas.....................................................................44
Figura 13 : Relatório de Salas...................................................................................................45
Figura 14 : Relatório de Turma por Sala..................................................................................46
Figura 15 : Página da Internet..................................................................................................47
Figura 16 : Página de Salas Disponíveis..................................................................................48
Figura 17 : Exemplo de alocação .............................................................................................50
LISTA DE QUADROS Quadro 1 : Matriz inicial ............................................................................................................8
Quadro 2 : Passo 1 - Diminui-se o menor valor de cada linha. ..................................................9
Quadro 3 : Passo 2 - Diminui-se o menor valor de cada coluna. ...............................................9
Quadro 4 : Passo 3 - Traça-se as retas que cubram os zeros. ...................................................10
Quadro 5 : Matriz atualizada depois do passo 4.......................................................................10
Quadro 6 : Traça-se novamente as retas sobre os zeros. ..........................................................10
Quadro 7 : Lista de Eventos .....................................................................................................26
Quadro 8 : Implementação do Passo 1 .....................................................................................34
Quadro 9 : Implementação do Passo 2 .....................................................................................35
Quadro 10 : Procedure que traça retas do passo 3....................................................................35
Quadro 11 : Acha nodo válido para alocação...........................................................................37
Quadro 12 : Implementação do Passo 4 ...................................................................................37
Quadro 13 : Características das salas e turmas.........................................................................49
RESUMO
Este trabalho propõe o desenvolvimento de um protótipo para a realização do controle
de reservas de salas de aula da Universidade Regional de Blumenau. O protótipo permite,
através de um algoritmo baseado na Pesquisa Operacional, otimizar o processo de alocação
das turmas nas salas, satisfazendo algumas restrições impostas. Também permite o controle,
gerenciamento do espaço físico das salas através da geração de relatórios detalhados e a
alocação de salas para empréstimos ocasionais, estes podendo ser feitos localmente ou
remotamente através da Internet.
ABSTRACT
This project proposes a prototype development for the accomplishment of the
Blumenau Regional University classrooms reservation control. The prototype allows, through
an algorithm based on the Operational Research, to optimize the groups allocation process in
the classroom, satisfying some imposed restrictions. It also allows the classrooms physical
space control and management through the detailed reports generation and the classrooms
allocation for ocasional loans, which could be done locally or remotely through the Internet.
1 INTRODUÇÃO
Sistemas de informação são um conjunto de elementos interdependentes
(subsistemas), logicamente associados, para que, de sua interação, sejam geradas
informações necessárias à tomada de decisões. Segundo Figueiras (2000), sistemas de
informação são uma série de dados trabalhados que possibilitam ao executivo a tomada
de decisão.
Quando qualquer empresa ou instituição possui um grande número de
informações a serem controladas, existe quase uma obrigação em existir sistemas
informatizados de informações, os quais tornam as tarefas mais descomplicadas e as
tomadas de decisão mais precisas e fundamentadas.
A Universidade Regional de Blumenau (FURB) é uma das maiores
universidades do estado de Santa Catarina, tanto em números (alunos, professores,
funcionários, área construída, etc.) quanto em estrutura. Atualmente, a FURB é formada
por aproximadamente quinze mil alunos, três mil funcionários e mil professores.
Devido a esta dimensão, os sistemas de informação têm grande influência na
otimização dos processos que envolvem a universidade. Esses processos são executados
por diversos setores dentre os quais destacam-se:
a) o setor financeiro, onde são controlados os dados referentes às mensalidades,
taxas e tudo que diz respeito à parte financeira da universidade;
b) o setor de recursos humanos, onde são controlados dados sobre os
funcionários, incluindo professores, funcionários concursados e contratados;
c) o setor acadêmico e de ensino, onde são controlados dados dos acadêmicos,
cursos, turmas.
Dentro do setor acadêmico e de ensino, destaca-se a Divisão de Registros
Acadêmicos (D.R.A), que é o setor da universidade responsável pelos dados dos
acadêmicos, desde seu ingresso até sua saída. São funções da D.R.A., entre outras,
arquivar documentos pessoais, gerar boletins, resumos de matrícula, históricos de cada
acadêmico, organizar horários e salas de aula, providenciar documentos, efetuar
matrículas e transferências.
Segundo PROEN (1999), são responsabilidades da D.R.A. da FURB:
a) organizar, coordenar e controlar as atividades relativas ao registro do corpo
discente, compreendendo matrículas, controles acadêmicos, transferências,
freqüência, rendimento escolar, emissão de certificados, históricos e
certidões, e outros pertinentes à sua área de atuação;
b) programar a distribuição das áreas físicas relativas ao ensino de graduação,
ouvidos os Diretores das Unidades Universitárias;
c) assessorar os demais órgãos da Universidade no âmbito de ensino.
E, segundo PROEN (1999), são responsabilidades da Seção de Registros
Discentes, que faz parte da D.R.A. :
a) participar na elaboração da proposta do calendário acadêmico;
b) programar e realizar as matrículas do corpo discente;
c) manter atualizado o cadastro e registros acadêmicos do corpo discente;
d) elaborar guias de transferência;
e) instruir os pedidos de mudanças de turno e curso, de transferências externas,
de adaptações e das demais solicitações acadêmicas.
Para organizar esse montante de informações e otimizar os processos que as
envolvem, é importante a existência de sistemas informatizados, os quais existem,
porém não englobam todas as atividades.
Uma das atividades que ainda não é controlada por sistemas informatizados é o
controle de reservas de salas de aula, sendo que, atualmente, a Divisão de Registros
Acadêmicos da Universidade Regional de Blumenau realiza, manualmente, todo o
controle de salas, tanto para as reservas semestrais das turmas de graduação quanto para
reservas temporárias (empréstimos). Para isso, são feitas pranchas de madeira onde são
registradas as salas e os horários ocupados, sendo uma prancha para cada turno das
turmas de graduação e outra para reservas temporárias efetuadas por terceiros. Essas
pranchas são, basicamente, tabelas onde são descritas as salas e suas características,
como: bloco, número, capacidade, tipo de cadeiras, etc.. e os horários em cada dia da
semana, onde são registrados para quem está reservada cada sala.
Sendo assim, esse trabalho propõe-se a desenvolver um protótipo de um sistema
para o controle das salas da FURB, sendo dividido em duas partes: um sistema local,
onde serão feitos os cadastros necessários, assim como a alocação das turmas nas salas e
outra voltada para Internet, onde serão feitas consultas e reservas temporárias,
automatizando o processo, economizando tempo e diminuindo a probabilidade de erros.
Para a especificação do sistema será utilizada a análise essencial, com suporte da
ferramenta Power Designer. Para o desenvolvimento do protótipo a nível local será
utilizado o ambiente Delphi 5 e a nível remoto será utilizada a tecnologia de
programação para a Internet ASP.
1.1 OBJETIVOS
Esta proposta tem como objetivo o desenvolvimento de um protótipo de um
sistema para a alocação das salas de aula da FURB, a fim de automatizar o processo.
Como objetivos específicos do trabalho destacam-se:
a) a utilização de um algoritmo de alocação para otimizar a alocação das turmas
de graduação nas salas;
b) o desenvolvimento de uma página para a Internet, onde poderão ser feitas
consultas e reservas ocasionais (empréstimos);
c) disponibilizar relatórios sobre dados das salas e suas ocupações;
d) disponibilizar gráficos estatísticos sobre as salas e as reservas efetuadas.
1.2 ESTRUTURA
Este trabalho está organizado da seguinte forma:
O primeiro capítulo apresenta a introdução, contextualização, justificativa e
objetivos do trabalho.
O segundo contextualiza as técnicas de alocação, com ênfase na pesquisa
operacional e no algoritmo a ser utilizado.
O terceiro relata conceitos de análise essencial, que será usada na especificação
do protótipo.
O quarto traz uma visão geral sobre desenvolvimento para Internet envolvendo
principalmente a tecnologia ASP, que será utilizada no desenvolvimento do protótipo.
O quinto capítulo apresenta o desenvolvimento do protótipo, tanto sua
especificação, como a implementação;
O sexto e último capítulo traz as conclusões, extensões e sugestões encontradas
com o desenvolvimento do trabalho.
2 TÉCNICAS DE ALOCAÇÃO
Técnicas de alocação são maneiras de se encontrar uma solução ótima para
combinar conjuntos de espaços e objetos ou tarefas e recursos, fazendo com que, para
cada recurso ou objeto exista sempre um espaço ou tarefa correspondente. Essas
técnicas precisam ser utilizadas quando os recursos disponíveis não são suficientes para
permitir que todas as tarefas sejam executadas da maneira mais eficiente possível ou
quando essa função torna-se muito complexa para ser feita sem uso de alguma técnica
matemática.
Segundo Davis (1991), problemas de alocação apresentam grande dificuldade
em seu tratamento pelos seguintes motivos:
a) complexidade computacional: os problemas de alocação são da classe NP-
Completo, o que quer dizer que a partir de um tamanho razoável dos dados de
entrada torna-se impossível explorar todo espaço de busca. Além disso,
métodos que façam uso de heurísticas para limitar este espaço não podem
garantir que sempre encontrarão uma resposta ótima;
b) conhecimento de domínio: problemas de alocação devem levar em
consideração restrições que com freqüência estão fortemente vinculadas a
conhecimento específico ao domínio de que fazem parte.
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.
Considerações a respeito da pesquisa operacional e suas técnicas serão detalhadas nos
próximos capítulos.
2.1 PESQUISA OPERACIONAL
Segundo Shamblin (1979), a pesquisa operacional (P.O.) é um método científico
de tomada de decisão. Segundo Bronson (1985), a P.O. diz respeito à alocação de
recursos escassos e é tanto uma arte como uma ciência. A arte reside na habilidade de
exprimir os conceitos de eficiente e de escasso por meio de um modelo matemático bem
definido para uma determinada situação, enquanto a ciência consiste na dedução de
métodos computacionais para solucionar tais modelos.
O termo “P.O.” parece ter sido empregado pela primeira vez em 1939, mas só na
Segunda Guerra Mundial o termo pesquisa operacional começou a ser usado por
cientistas que pretendiam resolver problemas estratégicos e táticos de administração
militar.
Os primeiros textos de P.O. só surgiram na década de 50, quando a matéria foi
considerada digna de figurar nos currículos das universidades. Após isso, esse método
espalhou-se pelas organizações industriais e, com o advento dos computadores
avançados, tornou-se comum na solução de problemas organizados.
Existem alguns problemas típicos que são resolvidos usando P.O., para os quais
foram desenvolvidas técnicas específicas de modelagem e obtenção de soluções. São
eles:
a) alocação;
b) estoque;
c) substituição ou reposição;
d) filas de espera;
e) seqüência e coordenação;
f) determinação de rotas;
g) situações de competição;
h) busca de informação.
Existem seis fases principais a serem considerados no estudo de pesquisa
operacional que serão detalhadas a seguir.
2.1.1 FORMULAÇÃO DO PROBLEMA
É essencial que o problema em consideração seja claramente definido, pois é
quase impossível obter uma resposta certa a partir de um problema errado. Deve-se
estabelecer bem os objetivos, os cursos alternativos de ação, as restrições e o efeito do
sistema sobre os outros sistemas a ele relacionados.
2.1.2 CONSTRUÇÃO DO MODELO
Na construção do modelo do problema ou sistema em questão trata-se,
geralmente, de um modelo matemático. O modelo matemático é um conjunto de
equações que descreve o sistema ou o problema. Geralmente, esse modelo contém dois
tipos de equações: a função objetivo e as restrições.
A função objetivo é a expressão matemática da finalidade do estudo, por
exemplo, a operação matemática do lucro ou do custo de uma operação particular.
Restrições são expressões matemáticas de limitações de uma operação.
2.1.3 OBTENÇÃO DE UMA SOLUÇÃO
A obtenção da solução consegue-se determinando a solução ótima para o modelo
e depois aplicando esta solução ao problema real. Muitas vezes, as complexidades
matemáticas do modelo tornam impossível a solução ótima e deve bastar então uma
“boa” solução. Mas, se o modelo foi bem formulado ou testado, as soluções permitirão
uma boa aproximação do ótimo real.
2.1.4 TESTE DO MODELO E DA SOLUÇÃO
O teste pode ser feito de dois modos:
a) usando-se os dados passados, faz-se uma comparação do desempenho real do
sistema e do desempenho indicado pelo modelo;
b) fazendo o sistema operar sem mudanças e comparando seu desempenho com
o desempenho do modelo.
2.1.5 ESTABELECIMENTO DE CONTROLES
Os controles são montados para detectar quaisquer mudanças significativas nas
condições sobre as quais se baseia o modelo. Evidentemente, se as condições mudarem
muito e o modelo passar a não ser mais uma representação exata da realidade, este
modelo estará invalidado. Por isso é preciso que se criem alguns métodos de detecção
que indiquem imediatamente as mudanças no sistema de modo que o modelo possa ser
revisto para indicar estas mudanças.
2.1.6 IMPLANTAÇÃO
Nesta última fase do estudo de P.O., deve-se explicar o sistema à administração
responsável e, preferencialmente, descrever o sistema usando dados do problema real,
ou seja, exemplificando os algoritmos com valores já existentes.
2.2 PROBLEMA DE DESIGNAÇÃO (ATRIBUIÇÃO)
Segundo Ackoff (1971), um dos problemas clássicos da P.O. é o problema de
atribuição, que pode consistir em atribuir homens a funções ou tarefas, caminhões a
rotas de entrega, motoristas a caminhões, turmas a salas de aula ou problemas a equipes
de pesquisa, onde cada tarefa necessita de um único recurso e cada recurso pode ser
usado em somente uma tarefa.
Segundo Shamblin (1979), este modelo preocupa-se em atribuir certo número de
origens a um mesmo número de destinos visando otimizar uma função-objetivo
(geralmente custo ou lucro). Matematicamente, o modelo de designação é definido
como a otimização (maximização ou minimização) da função:
££ cijxij
em que cij são os coeficientes de custo (lucro) sujeito às restrições e xij representa os
recursos alocados:
£ xij = 1,0 j = 1,2,3,...n
A seguir será apresentada uma solução para um método de designação, onde será
buscada a minimização de custo.
É importante destacar que o autor não propõe algoritmos gerais para a solução
do problema no caso apresentado.
Quatro construções diferentes A, B, C e D devem ser levantadas em um campus
universitário por quatro empreiteiras 1, 2, 3 e 4. Cada empreiteira deve construir um
edifício. As propostas de cada empreiteira aparecem no quadro 1.
Quadro 1 : Matriz inicial
n n i=1 j=1
n i=1
Construção
Empreiteira 1 2 3 4
A 48 48 50 44
B 56 60 60 68
C 96 94 90 85
D 42 44 54 46
Passo 1. Subtrai-se o menor elemento de cada linha dos elementos desta mesma
linha. Na linha da empreiteira A, por exemplo, o menor valor é 44. Portanto, este valor
deve ser subtraído dos elementos daquela linha (Quadro 2).
Quadro 2 : Passo 1 - Diminui-se o menor valor de cada linha.
Construção
Empreiteira 1 2 3 4
A 4 4 6 0
B 0 4 4 12
C 11 9 5 0
D 0 2 12 4
Passo 2. Subtrai-se o menor elemento de cada coluna dos elementos desta
mesma coluna (Quadro 3).
Quadro 3 : Passo 2 - Diminui-se o menor valor de cada coluna.
Construção
Empreiteira 1 2 3 4
A 4 2 2 0
B 0 2 0 12
C 11 7 1 0
D 0 0 8 4
Passo 3. Procura-se achar, então, 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. Às vezes este passo
provoca dificuldades pois freqüentemente há muitas maneiras de traçar estas retas. Isto
não faz diferença desde que o número de retas seja mínimo e as retas sejam traçadas
horizontal ou verticalmente (Quadro 4).
Quadro 4 : Passo 3 - Traça-se as retas que cubram os zeros.
Construção
Empreiteira 1 2 3 4
A 4 2 2 0
B 0 2 0 12
C 11 7 1 0
D 0 0 8 4
Passo 4. Depois de traçado o número mínimo de retas, faz-se o teste de
otimização. Se o número de retas for igual a n ( o número de linhas ou colunas), pode-se
fazer uma atribuição ótima. Senão, é preciso continuar as iterações para uma solução
ótima.
Como o número de retas é 3 e n=4, tem-se que realizar uma iteração buscando a
solução ótima. Isto pode ser feito escolhendo-se o menor elemento não coberto pelas
retas traçadas (neste caso é o elemento 1, que está na linha da empreiteira C, coluna 3) e
subtraindo este mesmo de todos os demais elementos não cobertos pelas retas, assim
como somando este elemento aos elementos que se encontrarem na intersecção das retas
(Quadro 5).
Quadro 5 : Matriz atualizada depois do passo 4.
Construção
Empreiteira 1 2 3 4
A 3 1 1 0
B 0 2 0 13
C 10 6 0 0
D 0 0 8 5
Passo 5. Testa-se novamente a otimização. Se o número de retas for igual a n é
possível uma atribuição ótima, caso contrário deve-se fazer outra iteração (Quadro 6).
Quadro 6 : Traça-se novamente as retas sobre os zeros.
Construção
Empreiteira 1 2 3 4
A 3 1 1 0
B 0 2 0 13
C 10 6 0 0
D 0 0 8 5
Passo 6. Como o número de retas é igual a n, faz-se uma atribuição ótima,
achando-se os zeros no quadro final e aplicando as restrições impostas pelas equações
citadas. A atribuição ótima para este problema é:
a) a empreiteira A constrói o edifício 4, pois foi onde ocorreu o único zero da
linha desta construção;
b) a empreiteira C constrói o edifício 3, pois tirando a coluna 4 sobra somente
um zero, que é na coluna 3;
c) a empreiteira B constrói o edifício 1, com a eliminação das colunas 3 e 4;
d) a empreiteira D constrói o edifício 2.
Assim, o custo total, resgatado da matriz inicial (Quadro 1) é:
44 + 56 + 90 + 44 = 234
3 ANÁLISE ESSENCIAL
Segundo Pompilho (1994), a tarefa de especificar os sistemas de informações
que compõem uma empresa é uma das mais complexas e, em última análise, é um
processo de solução de problemas. Para ser bem feita requer não apenas conhecimentos
de computação, mas também vários conhecimentos conexos.
Há evidências e argumentos teóricos de que a inadequação dos sistemas é
comum porque os profissionais de informática tendem, durante a fase de
desenvolvimento dos sistemas, a dar maior atenção aos aspectos pertinentes à eficiência
ou ao desempenho, em detrimento dos aspectos relativos à eficácia ou à adequação dos
sistemas às necessidades dos usuários. Este tema costumava ser relegado a um plano
inferior e, infelizmente, essa ainda tem sido a regra em algumas situações, atualmente.
Muitas vezes, encontram-se soluções brilhantes do ponto de vista da performance da
máquina, mas que não resolvem o problema do usuário.
Normalmente, quando um analista inicia o desenvolvimento de um sistema, ele
sabe pouco ou quase nada sobre o sistema a ser desenvolvido. Portanto, o
desenvolvimento começa com uma fase de aprendizado. A obtenção dos requisitos
necessários ao sistema torna-se bastante dificultada, pois o usuário expõe o seu
problema em linguagem natural, podendo ainda não ser capaz de expressar
adequadamente suas necessidades.
A técnica de análise essencial tem como uma de suas propostas fundamentais o
uso de eventos como base para o particionamento dos sistemas.
3.1 VANTAGENS DA ANÁLISE ESSENCIAL
Segundo Pompilho (1994), pode-se ressaltar as seguintes vantagens da análise
essencial em relação à análise estruturada:
a) a análise essencial começa pelo modelo essencial, economizando duas etapas
de modelagem na análise estruturada (modelo físico atual e modelo lógico
atual);
b) a análise estruturada aborda duas perspectivas do sistema (funções e dados),
ao passo que a análise essencial aborda três perspectivas (funções, dados e
controles), sendo, portanto, mais completa;
c) a análise essencial propõe uma forma de particionamento baseada em
eventos, a qual tem se mostrado mais efetiva do que a abordagem “top-down”
utilizada na análise estruturada, pois torna mais fácil a identificação das
funções e entidades que compõem o sistema;
d) a análise essencial permite a construção dos modelos de dados e de funções
concomitantemente, o que garante a correspondência entre os dois modelos.
A análise essencial é constituída por três modelos: o modelo essencial, o modelo
de controle e o modelo de implementação, que serão detalhados a seguir.
3.2 O MODELO ESSENCIAL
Segundo Apostila (2001), descrevendo quais os requisitos a que o sistema deve
atender, sem se preocupar como isto poderá ou será implementado.
Sendo assim, o modelo essencial se subdivide em dois outros modelos:
a) modelo ambiental: voltado para fora do sistema, para o ambiente em que está
inserido. Representa a interface do sistema com o mundo exterior;
b) modelo comportamental: voltado para dentro do sistema, para o
comportamento de suas partes internas. Mostra como ele deve reagir
internamente a estímulos do ambiente externo.
3.2.1 MODELO AMBIENTAL
Segundo Apostila (2001), o modelo ambiental é o modelo que define:
a) a fronteira do sistema com o ambiente onde ele se situa, determinando o que
é interno e o que é externo a ele.
b) as interfaces entre o sistema e o ambiente externo, determinando que
informações chegam ao sistema vindas do mundo exterior e vice-versa.
c) os eventos do ambiente externo ao sistema aos quais este deve responder.
Pompilho (1994) afirma que é de fundamental importância, na especificação de
um sistema, definir quais os elementos do ambiente em que o sistema se acha inserido,
onde ele vai operar, a que necessidades ele deve atender, independentemente da maneira
que será usada na implementação. É esse conjunto de elementos que chama-se modelo
ambiental.
Uma boa seqüência para a especificação do sistema é:
a) construir a lista de eventos;
b) desenhar o diagrama de contexto do sistema;
c) elaborar a declaração de objetivos do sistema.
3.2.1.1 LISTA DE EVENTOS
Segundo Mcmenamin (1991), todo sistema pode ser visto como uma reunião de
funções que devem ser ativadas para produzir as respostas desejadas, sendo essas
funções ativadas por estímulos causados pela ocorrência de determinados eventos. Os
eventos constituem o cerne de um sistema e podem ser definidos como acontecimentos
do mundo exterior que requerem uma resposta do sistema.
O primeiro passo na análise de um sistema é descobrir quais os eventos que vão
provocar os estímulos aos quais o sistema deve responder. Normalmente, só se
consideram eventos externos ao sistema, ou seja, aqueles que não pode interferir em sua
ocorrência; mais precisamente, são completamente independentes do sistema.
Os eventos são classificados quanto à natureza, ou seja, o tipo de estímulo que eles
provocam no sistema, podendo ser: evento orientado por fluxo de dados, evento
orientado por controle ou evento temporal.
3.2.1.1.1 EVENTO ORIENTADO POR FLUXO DE DADOS
Segundo Pompilho (1994), um evento orientado por fluxo de dados é aquele em
que o estímulo é a chegada ao sistema de um fluxo de dados enviado por uma entidade
externa. É a chegada do fluxo de dados que vai ativar uma função.
Geralmente, uma estrutura frasal que atende às necessidades de descrição dos
eventos orientados por fluxo de dados é do tipo:
sujeito + verbo transitivo na voz ativa + complementos verbais
Ex: cliente paga prestação.
3.2.1.1.2 EVENTO ORIENTADO POR CONTROLE
Segundo Pompilho (1994), um evento orientado por controle é aquele em que o
estímulo é a chegada ao sistema de um fluxo de controle.
Geralmente, uma estrutura frasal que atende às necessidades de
descrição dos eventos orientados por controle é do tipo:
a) sujeito + verbo transitivo na voz ativa + complementos verbais
b) sujeito + verbo na voz passiva
Ex: a diretoria autoriza o pagamento de uma fatura.
3.2.1.1.3 EVENTO ORIENTADO POR TEMPO
Segundo Apostila (2001), um evento orientado por tempo não é disparado por
nenhum fluxo de dados. É como se o sistema dispusesse de um relógio interno que
determinasse a passagem do tempo.
Geralmente, uma estrutura frasal que atende às necessidades de descrição dos
eventos orientados por tempo é do tipo:
advérbio de tempo + verbo no infinitivo + complementos verbais
Ex: mensalmente é gerado relatório de vendas.
3.2.1.2 DIAGRAMA DE CONTEXTO
Segundo Pompilho (1994), considerando-se que todo sistema está circunscrito a
um universo de interesse e que cada entidade externa estabelece uma fronteira entre o
sistema e o ambiente em que ele está inserido, pode-se afirmar que uma possível
representação de um sistema é aquela em que ele apresenta-se como uma única grande
função, cercada pelas entidades externas que com ele interagem, por intermédio de
fluxos de dados.
Segundo Pompilho (1994), existem quatro preocupações que devem ser
consideradas quando se formula um diagrama de contexto:
a) denominar as entidades externas pelo papel que elas desempenham em
relação ao sistema, e não pela pessoa ou entidade específica que o faz;
b) num diagrama de contexto, não pode haver fluxo de dados partindo
diretamente de uma entidade externa em direção a outra, pois o fluxo estaria
fora do contexto do sistema;
c) não confundir a entidade externa com o mecanismo usado para enviar um
fluxo de dados;
d) não devem aparecer diálogos típicos da fase de implementação, com exceção
dos fluxos que representam relatórios.
3.2.1.3 DECLARAÇÃO DOS OBJETIVOS DO SISTEMA
A declaração de objetivos deve ser elaborada em poucas frases, simples e
precisas, em linguagem destituída de jargão técnico, para ser entendida pelos usuários
do sistema. Também não pode incluir recursos tecnológicos, tendo que restringir-se
apenas à essência do problema e não pode descer a detalhes que digam respeito a
opções de tecnologia.
3.2.2 MODELO COMPORTAMENTAL
Segundo Apostila (2001), o Modelo Comportamental é definido do ponto de
vista interno, é o modelo interior do sistema. Descreve de que maneira o sistema,
enquanto um conjunto de elementos inter-relacionados, reage, internamente, como um
todo organizado, aos estímulos do exterior. A melhor maneira de se particionar um
sistema é de acordo com eventos significativos a que o sistema deve responder. A partir
do diagrama de contexto e da lista de eventos, adota-se a seguinte conduta para obter o
particionamento do sistema em funções:
a) para cada evento do sistema, desenha-se uma função ou processo de resposta
ao evento;
b) desenha-se o DFD de respostas para cada evento;
c) parte-se para a integração de todos os processos internos considerando, para
cada fluxo de dados gerado, quais são os dados de entrada necessários ao
processo gerador da resposta.
A integração dos DFDs de respostas aos eventos gera o DFD preliminar.
Partindo do DFD preliminar, usando a abordagem “top-down”, pode-se decompor as
funções encontradas, para obter os DFDs de níveis mais baixos.
3.2.2.1 DFD DE NÍVEL ZERO
Segundo Pompilho (1994), o DFD de nível zero representa o nível de DFD
imediatamente abaixo do nível do Diagrama de Contexto.
Para se construir o DFD de nível zero, agrupa-se as funções em um ou mais
níveis superiores. Para tanto, algum critério deve ser usado. Um critério de agrupamento
bastante razoável é considerar o grau de coesão e de acoplamento entre as funções.
3.2.2.2 MÉTODO DE OBTENÇÃO DO MODELO DE DADOS
Para elaborar um bom modelo de dados, não é suficiente conhecer os conceitos e
tipos de estruturas usados na modelagem de dados. Há que se dispor de uma estratégia
que facilite a percepção de quais são os principais componentes (classes de entidades,
atributos, relacionamentos, etc.) do modelo do sistema a ser especificado.
A seguir, tem-se uma lista de passos a serem seguidos:
a) classificar os eventos em ordem cronológica (montar uma matriz de
precedência entre os eventos);
b) para cada evento:
- identificar as entidades envolvidas;
- identificar os atributos das entidades;
- eleger os atributos identificadores das entidades e o tipo da entidade
(primária, dependente ou associativa);
- identificar os relacionamentos entre as classes de entidades;
- identificar o tipo de mapeamento de cada relacionamento (um-para-
muitos, zero-para-muitos, etc.);
- identificar o tipo de cada relacionamento (normal, dependência,
associativo, categoria ou papel).
3.3 O MODELO DE IMPLEMENTAÇÃO
Segundo Apostila (2001), o modelo de implementação tem por finalidade
produzir um modelo para a implementação do sistema, a partir de suas especificações
conceituais e dos requisitos para ele estabelecidos. Corresponde ao modelo físico que
aparecerá para o usuário e é o último passo antes do início da fase de projeto.
As atividades necessárias para a construção do modelo de implementação são as
seguintes:
a) construir o modelo lógico de dados;
b) determinar as características de processamento de cada função ou processo;
c) especificar a interface homem-máquina.
Estas atividades serão detalhadas a seguir.
3.3.1 CONSTRUÇÃO DO MODELO LÓGICO DE DADOS
É o passo onde mapea-se o modelo conceitual para o modelo lógico. Eis
algumas regras para esse mapeamento:
a) cada tabela representa uma classe de entidades;
b) cada coluna da tabela representa o atributo de uma classe de entidades;
c) a chave primária da tabela é formada pelas colunas que representam os
atributos identificadores da classe de entidades;
d) cada linha da tabela representa uma entidade da classe de entidades;
e) um relacionamento entre duas classes de entidades define uma dependência
entre os dados das tabelas correspondentes.
3.3.2 CARACTERÍSTICAS DE PROCESSAMENTO
Segundo Pompilho (1994), todo sistema possui várias partes, as quais podem ter
modos diferentes de processamento. Basicamente, cada parte do sistema pode ter um
dos modos de processamento como ilustrados na Figura 1:
Figura 1 : Exemplo dos modos de processamento do sistema.
3.3.3 INTERFACE HOMEM X MÁQUINA
A interface homem x máquina é, com certeza, uma atividade de grande interesse
para o usuário. Costuma-se consumir um tempo considerável nessa atividade. Segundo
E. Yourdon, citado em Pompilho (1994), essa atividade envolve quatro subatividades
inter-relacionadas:
a) escolha dos dispositivos de entrada e de saída;
b) formato de todas as entradas oriundas das entidades externas do sistema;
c) formato de todas as saídas que fluam para as entidades externas do sistema;
d) seqüência e temporização das entradas e saídas em sistemas on-line.
Inúmeras recomendações podem ser dadas para se elaborar uma boa interface,
entre as quais:
a) solicitar entradas e fornecer saídas consistentemente;
b) solicitar informações em uma seqüência lógica para o usuário;
c) dar ao usuário a possibilidade de tela que ele deseja (orientada por menu ou
por comando);
d) quando um processamento for demorado, exibir mensagens periódicas;
e) prover valores “default” nas entradas;
f) utilizar sons e cores com coerência.
SISTEMA
PARTES MANUAIS
PARTES AUTOMATIZADAS
PROCESSAMENTO “BATCH”
(POR LOTES)
PROCESSAMENTO “ON LINE”
PROCESSAMENTO EM TEMPO REAL
4 DESENVOLVIMENTO PARA INTERNET
A internet foi criada na década de 60 nos Estados Unidos e, a princípio, tinha a
finalidade de conectar algumas instituições locais. Em 1993 foi liberada para uso
comercial e chegou no Brasil em dezembro de 1994. A internet foi propagada para o
mundo principalmente depois do início da década de 90 e tornou-se um grande meio de
mídia e interação, tornando-se um dos maiores e mais usados meios de propaganda,
serviços e informativos.
Existem várias formas de comunicação pela internet, entre elas destacam-se o
file transmission protocol (FTP), que é um protocolo de transmissão de dados via
internet, o chat, que é uma ferramenta para a comunicação on line de dois ou mais
usuários e o browser, que é a ferramenta para visualização de páginas de conteúdo.
No início da Internet e consequentemente da World Wide Web, todo e qualquer
resultado apresentado pelo browser ao cliente era estático, ou seja, o mesmo conteúdo
era apresentado para um ou outro cliente. Não havia interatividade entre o usuário e o
servidor. O browser solicitava informações e o servidor enviava os resultados em forma
de páginas HTML.
4.1 HYPER TEXT MARKUP LANGUAGE (HTML)
A linguagem HTML foi uma das pioneiras e se tornou um padrão para a
construção de páginas para internet. HTML significa HyperText Markup Language, e é
o acrônimo que sugere o grupo de pequenos códigos que utiliza-se para criar páginas da
Web. Stauffer (1997).
Segundo Cantú (1999), a linguagem HTML é um formato muito difundido para
hipertexto na Web. HTML é o formato que os navegadores da Web normalmente lêem e
é um padrão definido pelo W3C (World Wide Web Consortium), que é uma das
entidades que controla a internet. Ao construir um site Web, sempre precisa-se escolher
uma estratégia de mínimo denominador comum para oferecer suporte à maioria dos
navegadores em uso, a não ser que esteja-se objetivando um grupo específico de
usuários, aos quais se peça para que adotem determinado navegador (como acontece em
situações de intranet).
Segundo Weissinger (1999), a linguagem HTML fornece uma formatação muito
detalhada de conteúdo textual estático. Este conteúdo pode conter imagens, tabelas,
textos e hyperlinks, que são atalhos para outras páginas, cuidadosamente formatados,
resultando em um meio muito potente através do qual se apresentam as informações.
Entretanto, apesar do nível muito baixo de interatividade dos hyperlinks e sua
habilidade de mover o usuário de uma página para outra, a própria HTML não permite
verdadeira interatividade. A HTML não permite à página da Web reagir à entrada do
usuário de nenhuma maneira além da navegação para outra página.
Apesar da internet estática evoluir rapidamente para a inclusão de gráficos e
sons, a Web continuava estática, com pequena interatividade e muito pouca
funcionalidade além daquela provida por simples conexão de hyperlink. (Weissinger,
1999).
De acordo com Weinman (1997), com o avanço da Internet, tanto em relação ao
conteúdo disponibilizado, quanto às tecnologias usadas, cada vez mais procura-se criar
e desenvolver páginas que proporcionem maior interação com o usuário e que detenham
mais a sua atenção.
Assim, surgiram inúmeras linguagens e tecnologias para o desenvolvimento de
aplicações para internet de conteúdo dinâmico, com iteração do usuário, entre as quais
se destacam: CGI, ISAPIs / NSAPIs, ActiveX e ASP, o qual será detalhado a seguir.
4.2 ACTIVE SERVER PAGES (ASP)
Uma das soluções mais utilizadas atualmente é a tecnologia da Microsoft®, o
Active Server Pages (ASP), que é uma tecnologia baseada em mesclar código script e
HTML.
4.2.1 CONCEITOS
Segundo Weissinger (1999), ASP é uma tecnologia que permite que se gere
dinamicamente conteúdo transparente ao browser, utilizando criação de scripts do
servidor. Esta página de criação de scripts é interpretada pelo servidor da Web apenas
mediante solicitação do conteúdo pelo cliente.
Segundo Mitchell (2000), uma linguagem de script é uma sintaxe particular para
executar comandos em um computador. Um programa composto de comandos de uma
linguagem de script particular é referido como um script.
As páginas ASP consistem em arquivos de extensão .asp que contêm
combinações de server side scripts e comandos HTML. Server side scripts são códigos
de programa que são processados no servidor. Devido a este fato, não é necessário
preocupar-se com a linguagem que o código foi criado: o servidor é que se encarrega de
interpretá-la e de devolver uma resposta para o cliente.
Todo o código de programação existente em páginas ASP é executado no
servidor, e este retorna ao cliente somente respostas em HTML padrão – o que faz com
que aplicações ASP possam ser acessadas por qualquer browser existente no mercado.
Uma aplicação feita em ASP pode ainda conter linhas de client side script, que serão
executados na estação cliente.
Client side scripts são códigos de programa que são processados pela estação
cliente. Geralmente em aplicações voltadas à Internet, o código que é executado no
cliente cuida apenas de pequenas consistências de telas e validações de entradas de
dados.
Segundo Cantú (1999), a idéia do ASP é incluir scripts no código HTML, para
que parte do texto em uma página da Web esteja diretamente disponível, enquanto
outras informações possam ser incluídas no servidor durante a execução. O cliente
recebe um arquivo HTML puro. Com o ASP, não precisa-se recompilar um programa
no servidor para ver uma alteração, basta atualizar o script.
4.2.2 REQUISITOS
A tecnologia ASP surgiu juntamente com o lançamento do Internet Information
Server 3.0, o qual é uma solução Microsoft®, que exige que o seu servidor rode um
sistema operacional da Microsoft® (Windows 95, 98, 2000 ou NT). Alguns dos
servidores que suportam o uso de páginas ASP são:
a) Microsoft Internet Information Server versão 3.0 ou superior no Windows NT
Server;
b) Microsoft Peer Web Services versão 3.0 ou superior no Windows NT
Workstation;
c) Microsoft Personal Web Server no Windows 95 ou Windows 98.
4.2.3 VANTAGENS
As principais vantagens de se usar ASP em relação a algumas outras tecnologias são:
a) independência do browser: ASP pode rodar páginas complexas no servidor e
enviar somente os resultados para o cliente. Segundo Pires (1999), todo o
código de programação existente em páginas ASP é executado no servidor, e
este retorna ao cliente somente HTML padrão – o que faz com que aplicações
ASP possam ser acessadas por qualquer browser existente no mercado.
b) páginas x bancos de dados: ASP permite visualizar, atualizar e adicionar
informações nos servidores. Segundo Mitchell (2000), é possível ler e
modificar o conteúdo de um banco de dados por uma página ASP. Entretanto,
o mais útil recurso do ASP é a capacidade de facilmente interagir com um
banco de dados. Outro motivo para utilizar-se bancos de dados por uma
página ASP é que um vasto número de aplicativos existentes que utiliza
bancos de dados para armazenar dados.
c) segurança do código fonte: Como o servidor retorna somente o resultado
HTML, o código fonte (lógica) fica preservado. De acordo com Mitchell
(2000), o código de ASP existe somente no servidor. Este código, que é
cercado pelos delimitadores <% e %>, é processado completamente no
servidor, não podendo o cliente não pode acessar esse código de ASP.
Portanto, todo código ASP que foi criado fica inacessível ao usuário, podendo
a este ver somente o resultado apresentado em HTML.
d) linguagens: ASP pode, por exemplo, utilizar-se de comandos em VBScript,
JavaScript e HTML. Segundo Wille (1999), uma das grandes vantagens do
ASP é que ele aceita várias linguagens, o que significa que o programa não é
limitado às linguagens de script padrão fornecidas pela Microsoft®.
Segundo Wille (1999), como uma linguagem de script por si só não sabe o que é
um servidor da Web (ou como enviar dados a um cliente, por exemplo), o mecanismo
do ASP fornece objetos e os disponibiliza para o seu código, permitindo que se interaja
com o browser do cliente e, por exemplo, acesse recursos do servidor.
Segundo Mitchell (2000), ao criar uma página ASP, pode-se utilizar várias
linguagens, destacando-se:
a) VBScript : semelhante à sintaxe de Visual Basic, a linguagem de script mais
comumente utilizada pelas Active Server Pages;
b) JScript : semelhante à JavaScript;
c) PerlScript : semelhante à Perl;
d) Python : uma poderosa linguagem de script comumente utilizada para
desenvolvimento de Web.
5 DESENVOLVIMENTO DO PROTÓTIPO
O desenvolvimento do protótipo consiste, principalmente, em dois processos: a
especificação e a implementação. A seguir, serão descritas as técnicas, restrições e
metodologias utilizadas para isto.
5.1 TRABALHOS CORRELATOS
Embora seja um tema bastante comum e um problema de um grande número de
instituições, poucos foram os trabalhos semelhantes encontrados, como exemplo:
a) um trabalho de conclusão do curso de Informática na Universidade Federal de
Pelotas. O trabalho versa sobre Algoritmos Genéticos, abordando um estudo
de seus conceitos fundamentais e aplicação no problema de grade horária,
onde o autor busca uma solução para o arranjo de horários e salas, dando mais
ênfase para o horário, embora não demonstre a implementação de um
algoritmo ou um sistema para solução. (Lucas, 2000).
b) SPATE (Sistema de Planejamento e Administração de Tempo e Espaço):
software de gerenciamento de espaço usado pelo Ministério da Educação e
Cultura (MEC) em algumas escolas públicas e universidades. Não demonstra
métodos de solução, mas somente resultados previstos e não realiza a
alocação automática, somente o gerenciamento de espaço usando a base de
dados. (Lopes, 2000).
c) SOLSTAR: software que auxilia na elaboração dos horários de aula e
alocação dos recursos. A alocação é feita através de dados pré-cadastrados,
como, por exemplo, quais turmas podem ser alocadas em cada sala. É
desenvolvido em Cobol. (Gattoni, 2000).
5.2 REQUISITOS PRINCIPAIS DO PROBLEMA
O trabalho consiste no desenvolvimento de um sistema para a alocação de salas
de aula na Universidade. A principal dificuldade do sistema diz respeito à alocação
semestral, uma vez que para cada sala e cada turma existem várias restrições que são
levadas em consideração quando faz-se a alocação, entre as quais:
a) capacidade / número de alunos;
b) bloco (localização);
c) acesso a deficiente físico;
d) carteiras de desenho;
e) quatro quadros;
f) ar condicionado;
g) cadeiras estofadas.
Deste modo a alocação trata de um problema complexo com diversas variáveis a
serem consideradas no processo.
5.3 ESPECIFICAÇÃO DO PROTÓTIPO
A especificação é uma das etapas mais importantes do desenvolvimento de um
sistema. É através da especificação que se tem uma visão geral do sistema, além de ter
uma linha a ser traçada no desenvolvimento propriamente dito.
A especificação do sistema desse trabalho segue a análise essencial e os passos
descritos anteriormente.
5.3.1 MODELO AMBIENTAL
No modelo ambiental são descritos os elementos do ambiente onde o sistema
está inserido, onde será mostrado a lista de eventos do sistema, o diagrama de contexto
e a declaração dos objetivos do sistema.
5.3.1.1 LISTA DE EVENTOS
Um dos procedimentos iniciais para a especificação de um sistema, seguindo a
análise essencial, é a descrição dos eventos do sistema. O quadro 7 apresenta os eventos
do sistema proposto por esse trabalho:
Quadro 7 : Lista de Eventos
N.º do
Evento Nome do Evento Tipo do Evento
1 São importados dados do Sistema Acadêmico Fluxo (F) 2 Funcionário é cadastrado (F) 3 Funcionário cadastra sala (F) 4 Funcionário cadastra tipo de restrição (F) 5 Funcionário cadastra restrição (F) 6 Funcionário cadastra restrição por turma (F) 7 Funcionário cadastra solicitante (F) 8 Funcionário efetua reserva semestral (F) 9 Solicitante efetua reserva ocasional (F) 10 Semestralmente são geradas salas com reservas por turno Temporal (T) 11 Periodicamente são geradas salas (T) 12 Periodicamente são geradas reservas efetuadas num período (T) 13 Periodicamente são geradas salas por características (T) 14 Periodicamente são geradas reservas por solicitante (T) 15 Periodicamente são geradas salas por curso (T)
A seguir é descrito cada evento detalhadamente:
1. São importados dados do Sistema Acadêmico: os dados referentes às disciplinas,
turmas, horários, semestres, habilitações e cursos são importados do sistema
acadêmico da FURB;
2. Funcionário é cadastrado: são cadastrados dados do funcionário, assim como sua
senha de acesso;
3. Funcionário cadastra sala: são cadastradas salas e suas características;
4. Funcionário cadastra tipo de restrição: são cadastrados tipos de restrições possíveis e
seus valores, ou seja, o grau de importância que será dado à restrição na alocação;
5. Funcionário cadastra restrição: são cadastradas restrições usadas nas disciplinas e
salas;
6. Funcionário cadastra restrição por turma: são cadastradas as restrições para cada
turma, ou seja, quais características que a turma precisa que a sala tenha;
7. Funcionário cadastra solicitante: são cadastrados solicitantes e seus dados, onde
solicitante pode ser qualquer pessoa ou instituição que queira emprestar ou alugar
uma sala da FURB;
8. Funcionário efetua reserva semestral: é feita alocação das turmas nas salas;
9. Solicitante efetua reserva ocasional: são feitas reservas ocasionais de terceiros,
sendo gerado um comprovante de reserva para o solicitante;
10. Semestralmente são geradas salas com reservas por turno: relatório contendo um
resumo das salas e ocupação por turno;
11. Periodicamente são geradas salas: relatório contendo todas as salas e suas
características;
12. Periodicamente são geradas reservas efetuadas num período: relatório contendo o
resumo das reservas ocasionais durante um período de tempo, onde são mostrados o
solicitante, a sala, o horário e data da reserva;
13. Periodicamente são geradas salas por característica: relatório contendo todas as salas
que tenham uma determinada característica;
14. Periodicamente são geradas reservas por solicitante: relatório contendo o resumo de
reservas ocasionais efetuadas por um solicitante, onde são mostrados os detalhes da
reserva de um solicitante (data, horário, sala, descrição);
15. Periodicamente são geradas salas por curso: relatório contendo salas de todas as
fases de um curso no semestre, onde serão mostradas as fases do curso com
respectivas salas;
5.3.1.2 DIAGRAMA DE CONTEXTO
O diagrama de contexto apresenta as entidades e seus respectivos fluxos
relacionados. A figura 2 apresenta o diagrama de contexto do sistema proposto por este
trabalho, tendo-se utilizado a ferramenta Power Designer.
Figura 2: Diagrama de Contexto
O fluxo dados acadêmicos representa o conjunto de dados importados do sistema
acadêmico, ou seja, dados referentes às disciplinas, turmas, horários, semestres, cursos e
habilitações.
5.3.1.3 DECLARAÇÃO DOS OBJETIVOS DO SISTEMA
O sistema proposto neste trabalho tem o objetivo de otimizar a alocação de salas,
diminuindo a subutilização de espaço e de automatizar o processo de controle dessas
salas, a fim de agilizar os processos que as envolvem.
Solicitante
Dados Acadêmicos
Comprovante
Reserva
Reserva_Solicitante
Sala_CursoSalas_Caracteristicas
Reservas_Periodo
Salas
Reservas_Turno
Reserva
Tipo_Restricao
Restricao
Restricao_Turma
Sala
Funcionario
Funcionario
Solicitante
1
Sistema de Controle de Sala
Sistema Acadêmico
Para essa otimização, será utilizado um algoritmo de designação, o qual provém
da pesquisa operacional.
Serão importados alguns dados do sistema acadêmico atualmente usado pela
FURB, evitando a duplicidade de dados como: disciplinas, turmas, cursos, habilitações,
horários das turmas e semestres.
Serão gerados diversos gráficos e relatórios, os quais poderão ser visualizados na
tela ou impressos, a fim de facilitar o gerenciamento das reservas e do espaço físico.
Será disponibilizada uma página na internet utilizando ASP, onde poderão ser
feitas consultas e empréstimos de salas por terceiros.
5.3.2 MODELO COMPORTAMENTAL
O modelo comportamental é o modelo interior do sistema, ou seja, quais ações o
sistema deve tomar para responder os eventos. Para demonstrar isso serão mostrados o
diagrama de fluxo de dados do sistema.
5.3.2.1 DIAGRAMA DE FLUXO DE DADOS
O diagrama de fluxo de dados (DFD) mostra todos os eventos do sistema de uma
forma mais detalhada e integrada, mostrando sua relação com as entidades e
repositórios de dados. As figuras 3 e 4 apresentam os DFD’s do sistema proposto,
usando-se a ferramenta Power Designer:
Figura 3 : DFD - Parte I
Figura 4 : DFD – Parte II
Restricao_Sala
Restricao
Disciplina
Turma
Curso
Habilitacao
Horário
Turma_Horário
Semestre
Dados Acadêmicos
Turma
Restricao Turma
Restrição Turma
Comprovante
Cd_Horário
Cd_Sala
Reserva
Cd_Solicitante
Reserva
Solicitante
Solicitante
Cd_Tipo
Restrição
Restrição
Tipo Restrição
Tipo Restrição
Sala
Sala
Funcionário
Funcionário
Funcionario
2
Cadastrar Funcionário
Funcionários
3
Cadastrar Sala
Salas
4Cadastrar
Tipo Restrição Tipos Restrição
5
Cadastrar Restrição
Restrições
Solicitante
7
Cadastrar Solicitante
Solicitantes
9Efetuar Reserva Ocasional
Reservas Ocasionais
Salas2
Horários3
6
Cadastrar Restrição da
Turma
Restrições Turma
Turmas3
Sistema Acadêmico
1
Importar Dados
Cursos
Habilitações
Horários
Turma_Horários
Semestres
Turmas
Disciplinas
Restrições2
Restrições Sala
5.3.3 MODELO DE IMPLEMENTAÇÃO
O modelo de implementação corresponde ao modelo físico que aparece para o
usuário. Para descrevê-lo será mostrado o modelo de dados do sistema.
Sala
Horário
Turma
Sala
Reserva Normal
Curso
Horário
Solicitante
Reserva_Ocasional
Salas _Curso
Reservas_Solicitante
Sala
Salas _Característica
Reserva Ocasional
Sala
Reservas _Periodo
Sala
Salas
Horário
Sigla
Reserva Normal
Reserva Ocasional
Fase
Sala
Reservas_Turno
Turma
Cd_Sala
Cd_Funcionário
Reserva Normal
Reserva
Funcionário2
8Efetuar Reserva Normal
Reservas Normais
Funcionários2
Salas3
Turmas4
10Gerar
Reservas por Turno
Reservas Ocasionais2
Reservas Normais2
Cursos2
Turma_Horarios2
Funcionário3
11
Gerar Salas com
CaracterísticasSalas4
12Gerar
Reservas por Período Reservas
Ocasionais3
13
Gerar Salas por
Característica
Funcionário4
14Gerar
Reservas por Solicitante
15
Gerar Salas por Curso
Solicitantes3
Salas5
Horários2
Turmas2
Reservas Normais4
Cursos3
5.3.3.1 MODELO DE DADOS
O modelo de dados permite uma visão global do sistema, identificando as
entidades e atributos, assim como seus relacionamentos. A figura 5 representa o modelo
entidade-relacionamento (MER) do sistema proposto.
Figura 5 : MER do sistema
5.4 IMPLEMENTAÇÃO
O protótipo tem como enfoque principal a otimização de espaço, fazendo com
que as turmas sejam alocadas nas salas da melhor maneira possível, atendendo às
restrições. Também são efetuadas reservas ocasionais, alocando-se salas de acordo com
a data, horário e restrições requeridas. O sistema importa dados já existentes das turmas,
CURSO
CD_CURSO INM_CURSO A40DS_TURNO A20DS_SIGLA A3
DISCIPLINA
CD_AREA A3CD_NUMERO_DISCIPLINA SCD_SEQUENCIA_DISCIPLINA SCD_SEMESTRE I
NM_DISCIPLINA A60
RESTRICAO
CD_RESTRICAO ICD_TIPO INM_RESTRICAO A20DS_RESTRICAO A40
TIPO
CD_TIPO INM_TIPO A20VL_TIPO S
SALA
CD_SALA IDS_BLOCO A1NR_SALA SNR_CAPACIDADE S
TURMA
CD_AREA A3CD_NUMERO_DISCIPLINA SCD_SEQUENCIA_DISCIPLINA SNR_TURMA SCD_CURSO INR_SEMESTRE SNR_ANO SNR_FASE SNR_ALUNOS SDS_GRUPO A1CD_HABILITACAO IVL_ESPECIAL A1
HORARIO
CD_HORARIO IHR_INICIO DHR_FINAL D
TURMA_HORARIO
CD_HORARIO ICD_AREA A3CD_NUMERO_DISCIPLINA SCD_SEQUENCIA_DISCIPLINA SCD_CURSO INR_SEMESTRE SNR_ANO SNR_FASE SDS_GRUPO A1CD_HABILITACAO IDIA_SEMANA A10
SEMESTRE
CD_SEMESTRE INR_ANO SNR_SEMESTRE SDT_INICIO DDT_FINAL D
SOLICITANTE
CD_SOLICITANTE INM_SOLICITANTE A60FN_SOLICITANTE A15DS_OBS A60
RESERVA_NORMAL
CD_RESERVA ICD_FUNCIONARIO ICD_SALA ICD_AREA A3CD_NUMERO_DISCIPLINA SCD_SEQUENCIA_DISCIPLINA SNR_TURMA SCD_CURSO INR_SEMESTRE SNR_ANO SNR_FASE SDS_GRUPO A1CD_HABILITACAO IDS_RESERVA A60CD_HORARIO I
FUNCIONARIO
CD_FUNCIONARIO INM_FUNCIONARIO A60
RESTRICAO_SALA
CD_SALA I
CD_RESTRICAO I
RESERVA_OCASIONAL
CD_RESERVA_OCASIONAL ICD_SOLICITANTE ICD_SALA ICD_HORARIO IDS_RESERVA_OCASIONAL A60DT_RESERVA D
RESTRICAO_TURMA
CD_RESTRICAO ICD_AREA A3CD_NUMERO_DISCIPLINA SCD_SEQUENCIA_DISCIPLINA SNR_TURMA SCD_CURSO INR_SEMESTRE SNR_ANO SNR_FASE SDS_GRUPO A1CD_HABILITACAO I
HABILITACAO
CD_CURSO ICD_HABILITACAO I
cursos, disciplinas, semestres e horários, sendo necessários cadastros de salas,
restrições, etc...
5.4.1 TÉCNICAS E FERRAMENTAS UTILIZADAS
Para a implementação do protótipo a nível local foi utilizado o ambiente de
programação Delphi 5 e banco de dados Paradox. Para internet, foi usado a tecnologia
ASP.
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 um é 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. A seguir, foi calculado o peso das restrições para cada turma em relação a cada
sala, gerando uma matriz de valores.
A partir daí foi utilizado o algoritmo de problemas de designação, proveniente
da pesquisa operacional para efetuar a alocação de reservas de salas, seguindo os passos
citados no capítulo 2. O quadro 8 mostra a execução do passo 1 do processo de
alocação, o quadro 9 mostra o passo 2 e o quadro 10 mostra os passos 3 e 4.
Nos algoritmos apresentados nos quadros, a variável GridValores é quem
armazena a matriz de valores.
Quadro 8 : Passo 1 do algoritmo de alocação
//passo 1 do algoritmo: diminui menor valor de cada linha dos valores da //mesma procedure passo1(t:TFrmAlocarNormal); var i,j,menorlinha:integer; begin //passo 1 for i:=1 to t.GridValores.RowCount-1 do begin menorlinha:=999; //encontra menor valor da linha for j:=1 to t.GridValores.ColCount-1 do begin if StrtoInt(t.GridValores.Cells[j,i])<(menorlinha) then menorlinha:=StrtoInt(t.GridVAlores.Cells[j,i]); end; //diminui menor valor da linha dos outros valores da linha
for j:=1 to t.GridValores.ColCount-1 do t.GridValores.Cells[j,i]:=InttoStr(StrtoInt(t.GridValores.Cells[j,i])-menorlinha); end;// for end;// begin
Quadro 9 : Passo 2 do algoritmo de alocação
//passo 2 do algoritmo: diminui menor valor de cada coluna dos valores da //mesma procedure passo2(t:TFrmAlocarNormal); var menorcoluna,i,j:integer; begin for i:=1 to t.GridValores.ColCount-1 do begin menorcoluna:=99; //encontra menor valor da coluna for j:=1 to t.GridValores.RowCount-1 do begin if StrtoInt(t.GridValores.Cells[i,j])<menorcoluna then menorcoluna:=StrtoInt(t.GridValores.Cells[i,j]); end; //diminui menor valor da coluna dos outros valores da mesma for j:=1 to t.GridValores.RowCount-1 do t.GridValores.Cells[i,j]:=InttoStr(StrtoInt(t.GridValores.Cells[i,j])-menorcoluna); end; end;
Nos passos 3 e 4, são utilizados três procedimentos:
a) um para contar o número de zeros de cada linha e coluna para auxiliar no
segundo passo;
b) um para traçar e contar as retas imaginárias que cubram todos os zeros da
matriz (Quadro 10);
c) outro para recalcular a matriz de valores caso o número de retas seja menor
que o número de linhas ou colunas.
Quadro 10: Procedure que traça retas do passo 3
//cont. passo 3: traça retas para cobrir todos zeros do grid procedure contaretas(f:TFrmAlocarNormal;primeira:boolean); var i,j:integer; linha,coluna:integer;//guarda valor da linha com maior numeor de zeros begin //acha zeros e localiza melhor linha //showmessage('contaretas'); zeros:=0; f.GridRetas.ColCOunt:=F.GridValores.ColCOunt;
f.GridRetas.RowCOunt:=F.GridValores.RowCOunt; for j:=1 to f.GridValores.RowCOunt-1 do begin for i:=1 to f.GridValores.ColCount-1 do begin //encontra valores maior ZEROS if StrtoInt(f.GridCOluna.Cells[i,0])>zeros then begin zeros:=StrtoInt(f.GridCOluna.Cells[i,0]); linha:=0; coluna:=i; end;//if end;//for if StrtoInt(f.GridLinha.Cells[0,j])>zeros then begin zeros:=StrtoInt(f.GridLinha.Cells[0,j]); linha:=j; coluna:=0; end;//if end;//for //showmessage('maior='+InttoStr(zeros)+' retas='+InttoStr(retas)); //traca reta for j:=1 to f.GridValores.RowCOunt-1 do begin for i:=1 to f.GridValores.ColCount-1 do begin if (f.GridValores.Cells[i,j]='0')and(f.GridColuna.Cells[0,j]<>'0')and (f.GridColuna.Cells[i,0]<>'0') then begin if f.GridColuna.Cells[i,0]=InttoStr(zeros) then begin f.GridColuna.Cells[i,0]:='0'; for x:=1 to f.GridValores.RowCount-1 do begin if f.GridValores.Cells[i,x]='0' then f.GridLinha.Cells[0,x]:=InttoStr(StrtoInt(f.GridLinha.Cells[0,x])-1); end;//for inc(retas); f.GridREtas.Cells[i,0]:='1'; exit; end else if f.GridLinha.Cells[0,j]=InttoStr(zeros) then begin f.GridLinha.Cells[0,j]:='0'; for x:=1 to f.GridValores.ColCount-1 do begin if f.GridValores.Cells[x,j]='0' then f.GridCOluna.Cells[x,0]:=InttoStr(StrtoInt(f.GridColuna.Cells[x,0])-1); end;//for inc(retas); f.GridREtas.Cells[0,j]:='1'; exit; end;//if end;//if end;//for end;//for end;//begin Também foi desenvolvida uma estrutura de árvore (Quadro 11 e 12) para
resolver a etapa final do algoritmo de alocação citado, ou seja, achar o caminho dentro
da matriz que passe somente por zeros. Isto é necessário para se chegar a solução final
do problema, pois nem sempre o primeiro caminho percorrido permite chegar a uma
solução para todas as alocações.
Quadro 11 : Acha nodo válido para alocação
//cont. passo 4:procedure que procura nodos possiveis procedure acha(t:TFrmAlocarNormal); var y,j,i:integer; possivel,achou:boolean; //indica que encontrou nodo valido begin //procura celula com valor ZERO achou:=false; for i:=1 to t.GridVAlores.ColCount-1 do begin if atual^.nivel<t.GridValores.RowCount-1 then if StrtoInt(t.GridValores.Cells[i,atual^.nivel+1])<1 then begin possivel:=true; //verifica se coluna já não foi tracada for j:=1 to atual^.nivel+1 do begin if i=atual^.coluna[j] then possivel:=false; //ja foi tracada nesta coluna end;//for // se nodo é valido, da o nome da celula e chama procedure para aloca-lo if possivel=true then begin achou:=true; col:=i; Nodo:='C'+InttoStr(i)+'-'+InttoStr(atual^.nivel+1); passo4(FrmAlocarNormal); exit; end;//if // end;//while end; end; if achou=false then begin Nodo:=' '; passo4(FrmAlocarNormal); end;//if end; //begin
Quadro 12: Implementação do Passo 4
//acha caminho, atrves de uma arvore, pra alocar toda //sala e turma, passando por zeros procedure passo4(t:TFrmAlocarNormal); var aloca,aux:pointer; //pointeiros para nodos x,i:integer; begin //aloca raiz virtual new(aloca); if nodo='raiz' then begin aloca^.nome:='raiz';
aloca^.nivel:=0; aloca^.pai:=nil; aloca^.filho:=0; aloca^.coluna[1]:=0; raiz:=aloca; atual:=raiz; //aloca outros nodos end else begin //se nao achou possibilidade, desaloca e volta um nivel if Nodo='' then begin atual:=atual^.pai; if atual<>nil then atual^.filho:=atual^.filho+1 else begin dispose(aloca); exit; end; dispose(aloca); end else begin //se vier um nodo valido aloca atual^.filhos[atual^.filho+1]:=aloca; aloca^.pai:=atual; aloca^.filho:=0; aloca^.nivel:=atual^.nivel+1; aloca^.nome:=Nodo; aloca^.coluna:=atual^.coluna; //valores das colunas já visitadas aloca^.coluna[aloca^.nivel]:=(col);//acrescenta valor da coluna atual atual:=aloca; //verifica se ja passou por todas as linhas if aloca^.nivel=t.GridValores.RowCount then begin fim:=true; showmessage('Encontrou caminho'); for i:=1 to atual^.nivel do aux:=atual; while aux^.pai<>raiz do begin //acha coluna do nodo e identifica nodo alocado com ‘X’ t.GRidValores.Cells[aux^.coluna[aux^.nivel-1],aux^.nivel-1]:='X'; aux:=aux^.pai; end; exit; end; end;//else end;//else end;//begin
5.4.2 INTERFACE
A interface é uma atividade importante no sistema, pois é através dela que o
usuário vai conhecer e reconhecer o sistema, sendo também um dos principais fatores na
usabilidade do mesmo.
As Figuras 7 a 10 mostram algumas telas do sistema proposto nesse trabalho:
Figura 7 – Tela de Autenticação
A figura 7 mostra a tela de autenticação, onde o funcionário é identificado por
seu código e senha, ambos cadastrados no sistema.
Figura 8 – Tela Principal
A tela principal do sistema (figura 8) é onde está disponível o menu principal,
o qual dá acesso às funções do sistema. As funções são as seguintes:
a) cadastros:
- salas;
- funcionários;
- solicitantes;
- restrições;
- tipos de restrições;
- restrições das turmas;
b) consultas de salas e reservas;
c) procedimentos:
- reservas normais (alocação das turmas nas salas);
- reservas ocasionais (empréstimos de salas);
d) relatórios:
- salas;
- reservas por turno;
- salas por curso;
- empréstimos por solicitante ou período;
Figura 9 – Cadastro de Sala
A tela de manutenção das salas e suas características (figura 9) é onde são
cadastrados, alterados ou excluídos bloco, número e capacidade da sala, assim como
suas características, que são escolhidas daquelas previamente cadastradas.
Figura 10 - Cadastro de Restrições da Turma
Na tela representada na Figura 10 é feito o cadastro das restrições de cada turma,
ou seja, o que cada turma necessita dentre as restrições previamente cadastradas. As
turmas também provêm de cadastros feitos anteriormente.
Figura 11 : Tela da Alocação das Salas
A Figura 11 mostra o resultado obtido da alocação das turmas nas salas. A
alocação será respectiva àquelas células que contêm ‘X’. Por exemplo, a sala C101 será
alocada para o terceiro semestre do curso 28, habilitação 0.
Figura 12 : Gráfico das Características das Salas
A Figura 12 mostra a tela onde são apresentados gráficos informativos sobre as
características das salas, dando o percentual e o número de salas que têm determinada
característica. A lista superior indica as características cadastradas, as quais podem ser
escolhidas para a formulação do gráfico.
Figura 13: Relatório de Salas
A Figura 13 mostra a tela de um dos relatórios gerados pelo protótipo, onde são
mostradas todas as salas e suas características.
Figura 14: Relatório de Turma por Sala
A figura 14 mostra o relatório onde são mostrados todas as reservas das turmas
de graduação por sala e turno. Para cada horário e dia da semana é mostrado qual turma
(Curso e Fase) está alocada em qual sala.
Figura 15: Página da Internet
A figura 15 mostra a página onde são feitas reservas de salas, informando o
código do solicitante, que é cadastrado anteriormente, e os dados da reserva. Para
procurar uma sala livre deve-se clicar no botão “Procura”.
Figura 16: Página de Salas Disponíveis
A página representada na Figura 16 mostra as salas disponíveis quando o usuário
especifica os dados da reserva. O usuário deve escolher uma sala e confirmar, voltando
para a tela de reserva (Figura 14) onde poderá confirmar a reserva.
5.5 OPERACIONALIDADE DA IMPLEMENTAÇÃO
Para apresentar um estudo de caso foram levadas em consideração cinco turmas
e cinco salas com as características mostradas no quadro 13.
Quadro 13 : Características das salas e turmas
SALAS Capacidade Carteiras
Estofadas Ar Desenho
4
Quadros Acesso
C101 50 SIM NÃO NÃO SIM SIM
C102 60 SIM NÃO NÃO NÃO SIM
D102 50 SIM NÃO NÃO SIM SIM
D201 80 SIM SIM NÃO SIM NÃO
D202 60 SIM NÃO NÃO SIM NÃO
TURMAS Alunos Carteiras
Estofadas Ar Desenho
4
Quadros Acesso
BCC1 50 SIM NÃO NÃO SIM NÃO
BCC2 55 SIM NÃO NÃO SIM NÃO
BCC3 48 SIM NÃO NÃO NÃO SIM
BCC4 57 SIM NÃO NÃO SIM NÃO
BCC5 41 SIM NÃO NÃO NÃO NÃO
Considerando que as turmas não têm restrição de bloco e que cada restrição tem
um grau de importância, que pode ser alterado, pois é associado a um peso cadastrado,
o algoritmo calcula os custos para cada turma/sala e chegará na alocação mostrada na
Figura 17.
Figura 17: Exemplo de alocação
5.6 RESULTADOS E DISCUSSÃO
O tempo de execução do algoritmo de alocação implementado no protótipo é
bastante variável dependendo do caminho a ser tomado pelo algoritmo para encontrar o
caminho final na matriz de valores, ou seja, depende dos valores de restrições das salas
e turmas.
Uma vantagem significativa em relação a trabalhos semelhantes é a integração
da otimização automática das alocações com a possibilidade do gerenciamento do
espaço físico através de relatórios e gráficos referentes aos dados cadastrados.
6 CONCLUSÕES
O trabalho atendeu o objetivo de otimizar o processo de alocação de salas,
alocando as turmas nas salas da melhor maneira possível ou próximo disso. O algoritmo
utilizado encontra o menor custo para a alocação de acordo com os valores cadastrados
para cada restrição.
Também atingiu o objetivo de agilizar os processos que envolvem reservas de
sala, além de poder fazer um gerenciamento através de relatórios e gráficos.
A página na internet facilita o processo de empréstimos ou alocação por
terceiros, podendo estes serem feitos sem o envolvimento dos funcionários,
economizando-se tempo e atendendo melhor aos usuários destes serviços.
Durante a fase de especificação do modelo, as etapas da metodologia da Análise
Essencial utilizadas possibilitaram um melhor entendimento do sistema, tornando-o
mais legível para a implementação.
O ambiente de programação Delphi demonstrou-se adequado devido às suas
facilidades de definições de interfaces e ao conhecimento prévio do autor em relação à
linguagem, dispensando o gasto de tempo no aprendizado da mesma.
O algoritmo de designação de problemas mostrou-se eficiente na alocação das
salas às turmas, sendo os valores das restrições coerentes. O algoritmo em si é bastante
eficaz, entretanto o tempo de execução varia muito em função do caminho a ser
percorrido para estabelecer a solução.
6.1 LIMITAÇÕES E DIFICULDADES ENCONTRADAS
Uma das principais dificuldades foi encontrar um algoritmo que satisfizesse a
alocação de acordo com as restrições previstas no modelo, pois foi gasto muito tempo
na procura e estudo de algoritmos matemáticos que satisfizessem o caso.
Outra dificuldade foi a importação dos dados do sistema acadêmico, onde não
foi possível importar todos os dados no tempo necessário para a conclusão deste
trabalho.
6.2 EXTENSÕES
Sugere-se, para trabalhos futuros, o complemento do sistema, atendendo também
a laboratórios, auditórios e outros.
Sugere-se também a integração do sistema com um sistema para a formulação da
grade horária, de acordo com algumas restrições como disponibilidade de professores.
7 REFERÊNCIAS BIBLIOGRÁFICAS
ACKOFF, Russel L, SASIENI, Maurice W. Pesquisa operacional. Rio de Janeiro:
Livros Técnicos e Científicos, 1971.
APOSTILA. Análise essencial – conceito. Acesso em: junho [2001]. Criado em
[2001?]. Disponível em: http://www.terravista.pt/copacabana/5531/Sistemas.html.
BRONSON, Richard. Pesquisa operacional. São Paulo: McGraw-Hill do Brasil, 1985.
CANTÚ, Marco. Dominando o Delphi 5 – A Bíblia. São Paulo: Makron Books do
Brasil, 1999.
DAVIS, L. D. Handbook of genetic algorithms. Van Nostrand Reinhold, 1991
FIGUEIRAS, Márcia Cristina da Costa, BIER, Marcelo. Sistemas de informação.
Acesso em: janeiro [2001]. Criado em [2000?]. Disponível em:
http://www.geocities.com/WallStreet/Market/4702/textos/ sisinf003.html.
GATTONI, Associados Ltda. Planejamento e serviços em informática. Acesso em:
abril [2001]. Criado em [2000?]. Disponível em: http://www.gattoni.com.br/solstar.
LOPES, Sebastião Oliveira. Sistema de planejamento de administração de tempo e
espaço, Belo Horizonte, [2000?]. Disponível em: <http://www.spate.com.br>. Acesso
em: 31 mai. 2001.
LUCAS, Diogo Correa. Algoritmos genéticos: um estudo de seus conceitos
fundamentais e aplicação no problema de grade horária. 2000. 65 f. Trabalho de
Conclusão de Curso (Bacharelado em Informática) – Instituto de Física e Matemática –
Universidade Federal de Pelotas.
MCMENAMIN, Stephen M., PALMER, John F. Análise essencial de sistemas. São
Paulo: McGraw-Hill, 1991.
MITCHELL, Scott, ATKINSON, James. Aprenda em 21 dias Active Server Pages
3.0. Rio de Janeiro: Campus, 2000.
PIRES, Hudson. Tutorial ASP. Acesso em: 15/01/2000. Criado em: agosto [1999].
Disponível em: http://Tutorial.ZZN.com.
POMPILHO, S. Análise essencial : guia prático de análise de sistemas. Rio de Janeiro:
Infobook, 1994.
PROEN. Pró-Reitoria de ensino da FURB. Acesso em: 14/03/2001. Criado em:
[1999?]. Disponível em: http://www.furb.br/hp/ensino/proen/dra.html.
SHAMBLIN, James E., Stevens, G. T. Jr. Pesquisa operacional: uma abordagem
básica. São Paulo: Atlas, 1979.
STAUFFER, Todd. Dominando o essencial : HTML 3.2. Rio de Janeiro: Campus,
1997.
WEINMAN, William E. Manual de CGI. São Paulo: Makron Books do Brasil, 1997.
WEISSINGER, A. Keyton. ASP – guia completo. Rio de Janeiro: Ciência Moderna
Ltda., 1999.
WILLE, Christoph, KOLLER, Christian. Aprenda em 24 horas Active Server Pages.
Rio de Janeiro: Campus, 1999.