Upload
vanhuong
View
215
Download
0
Embed Size (px)
Citation preview
Franklin Felipe Wagner
Sistema Web para Gerenciamento de Laboratórios de Informática
Este Trabalho de Conclusão de Curso foi julgado e aprovado para obtenção do título de Tecnólogo em Informática, da Universidade Tecnológica Federal
do Paraná – Campus Curitiba.
Profª. MSc. Wânia Meira Matos Figueredo
Coordenadora do Curso de Tecnologia em Informática
UTFPR- DAINF
Profª. Drª Gilda M.S. Friedlaender Coordenadora da Disciplina de
TCC UTFPR- DAINF
Banca Examinadora
Profª. MSc. Ana Cristina Barreiras Kochem Vendramin Orientadora
UTFPR- DAINF
Prof. Carlos K. Hara UTFPR- DAINF
Prof. MSc. Wilson Horstmeyer Bogado UTFPR- DAINF
Franklin Felipe Wagner
Sistema Web para Gerenciamento de Laboratórios de Informática
Trabalho de Conclusão de Curso apresentado à UTFPR como requisito parcial para obtenção do título de Tecnólogo em Informática.
Orientadora: Ana Cristina Barreiras Kochem Vendramin, MSc.
Curitiba 2007
NAVIO NEGREIRO VI Existe um povo que a bandeira empresta P'ra cobrir tanta infâmia e cobardia!... E deixa-a transformar-se nessa festa Em manto impuro de bacante fria!... Meu Deus! meu Deus! mas que bandeira é esta, Que impudente na gávea tripudia? Silêncio. Musa... chora, e chora tanto Que o pavilhão se lave no teu pranto! ... Auriverde pendão de minha terra, Que a brisa do Brasil beija e balança, Estandarte que a luz do sol encerra E as promessas divinas da esperança... Tu que, da liberdade após a guerra, Foste hasteado dos heróis na lança Antes te houvessem roto na batalha, Que servires a um povo de mortalha!... Fatalidade atroz que a mente esmaga! Extingue nesta hora o brigue imundo O trilho que Colombo abriu nas vagas, Como um íris no pélago profundo! Mas é infâmia demais! ... Da etérea plaga Levantai-vos, heróis do Novo Mundo! Andrada! arranca esse pendão dos ares! Colombo! fecha a porta dos teus mares!.
Castro Alves
AGRADECIMENTOS
À Professora Ana Cristina Barreiras Kochem Vendramin pelo seu
esforço na orientação desse trabalho, à Marilia Rodrigues Santelo pela sua
ajuda em HTML e CSS e aos administradores e amigos da R.L.E.
SUMÁRIO
RESUMO ........................................................................................................8
1 INTRODUÇÃO.............................................................................................9
1.1 Apresentação ................................... ....................................................9
1.2 Justificativa da Escolha do Tema ............... .......................................9
1.3 Objetivos do Trabalho .......................... .............................................10
1.4 Conteúdo do Trabalho........................... ............................................10
2 LEVANTAMENTO BIBLIOGRÁFICO E ESTADO DA ARTE...... ..............11
2.1 Estado da Arte................................. ...................................................11
2.2 Vantagens do Sistema Desenvolvido .............. ................................12
3 METODOLOGIA...................................... ..................................................13
3.1 Levantamento dos Requisitos .................... ......................................13
3.2 Recursos empregados ............................ ..........................................13
3.3 Testes e Implantação ........................... .............................................15
4 MODELAGEM ........................................ ...................................................16
4.1 Descrição da Arquitetura ....................... ...........................................16
4.2 Requisitos Funcionais e não Funcionais ......... ...............................16
4.3 Modelagem do sistema por funcionalidade ........ ............................17
4.4 Implantação.................................... ....................................................26
5 RESULTADOS ....................................... ...................................................27
5.1 Disponibilização dos horários das salas de aula do laboratório ..29
5.2 Pedido de reserva de horário de sala de aula... ..............................32
5.3 Desligar uma ou mais máquinas de uma sala de au la ...................33
5.4 Controlar informações sobre máquinas........... ...............................33
5.5 Aceitar um pedido de reserva de um horário de s ala de aula .......35
6 CONCLUSÕES..........................................................................................36
6.1 Contribuições.................................. ...................................................36
6.2 Trabalhos Futuros .............................. ...............................................36
7 REFERÊNCIAS .........................................................................................37
LISTA DE FIGURAS
Figura 1 – Tela do programa LSoft Almoxarifado ........................................11
Figura 2 – Diagrama de Caso de Uso “Ver Horários das Salas” .................17
Figura 3 – Diagrama de classe “Ver Horários das Salas” ............................18
Figura 4 – Diagrama de Seqüência “Ver Horários das Salas” .....................18
Figura 5 – Diagrama de Caso de uso “Pedir Reserva” ................................19
Figura 6 – Diagrama de classe “Pedir Reserva” ..........................................20
Figura 7 – Diagrama de Seqüência “Pedir Reserva” ...................................20
Figura 8– Diagrama de Caso de Uso “Aceitar Reserva”..............................21
Figura 9 – Diagrama de classe “Aceitar Reserva” .......................................21
Figura 10 – Diagrama de Seqüência “Aceitar Reserva”...............................22
Figura 11 – Diagrama de Caso de Uso “Desligar Máquina” ........................22
Figura 12 – Diagrama de classe “Desligar Máquina” ...................................23
Figura 13 – Diagrama de Seqüência “Desligar Máquina” ............................23
Figura 14 – Diagrama de Caso de Uso “Modificar Informação máquina” ....24
Figura 15 – Diagrama de classe “Modificar Informação Máquina”...............25
Figura 16 – Diagrama de Seqüência “Modificar Informação máquina”........25
Figura 17 – Tela de Login. ...........................................................................27
Figura 18 – Tela Inicial do sistema. .............................................................28
Figura 19 – Tela Inicial do sistema, grupo Professores. ..............................29
Figura 20 – Tela “Verificar Horários”, escolha da data e sala ......................30
Figura 21 – Tela “Verificar Horários”, tabela com horários ..........................31
Figura 22 – Tela “Solicitar Reservas”...........................................................32
Figura 23 – Tela “Informações de Máquinas” ..............................................33
Figura 24 – Tela “Detalhes por Máquina” ....................................................34
Figura 25 – Tela “Aceitar Reservas” ............................................................35
LISTA DE SIGLAS
AJAX: Asynchronous Javascript And XML
CSS Cascading Style Sheets
DAINF: Departamento Acadêmico de Informática.
IDE: Integrated Development Environment
RLE: Rede Local de Ensino
UTFPR: Universidade Tecnológica Federal do Paraná
XML: eXtensible Markup Language
RESUMO
Esse trabalho tem por objetivo a criação de um sistema Web de fácil
acesso com alta persistência e consistência dos dados para alunos,
professores e administradores da Rede Local de Ensino (RLE) do
Departamento Acadêmico de Informática (DAINF) da Universidade
Tecnológica Federal do Paraná (UTFPR) que poderão consultar horários,
solicitar reservas de salas e gerenciar os recursos fornecidos pelo sistema.
Palavras chaves: Internet, Java, Informática, Gerenciamento.
Capítulo 1 - Introdução 9
1 INTRODUÇÃO
1.1 Apresentação
A Rede Local de Ensino (RLE) da Universidade Tecnológica Federal do
Paraná (UTFPR) é um laboratório de informática com cerca de noventa
máquinas dispostas em seis salas de aula e uma sala de administração.
Esse laboratório é utilizado por alunos da universidade em aulas ministradas
pelos professores.
Várias tarefas executadas no ambiente da RLE são repetitivas e de
difícil gerenciamento, principalmente devido à dificuldade de comunicação
entre os administradores de turnos diferentes.
Após algumas reuniões com os administradores da rede, foi verificada
a necessidade de um sistema para auxiliar no gerenciamento dessas
tarefas.
1.2 Justificativa da Escolha do Tema
Uma tarefa em que se observou o baixo rendimento devido à
necessidade de retrabalho é o levantamento e o controle do número de
patrimônio dos equipamentos e móveis dos laboratórios. Isso se devia ao
fato dos dados coletados necessitarem estar atualizados e íntegros o que,
por não possuírem uma fonte única e de fácil acesso, não acontecia,
gerando inconsistências onde a única saída viável era o relevantamento de
todas as informações.
Um outro problema observado está relacionado aos horários de
utilização dos laboratórios. Para um aluno saber se um laboratório estava
disponível ele precisava se deslocar até o local e verificar os horários nos
informativos, que nem sempre estavam atualizados. E, para um professor
efetuar uma reserva ele tinha que entrar em contato pessoalmente com
algum dos administradores da RLE. O que acontecia é que nem todos os
professores sabiam disso e nem sempre os administradores tinham as
Capítulo 1 - Introdução 10
informações em mãos ou a possibilidade de atualizá-las, pois os dados
eram dispersos e inconsistentes.
1.3 Objetivos do Trabalho
Após algumas reuniões com os administradores da rede, foi verificada
a necessidade de um sistema para auxiliar no gerenciamento de algumas
tarefas, tais como:
• Disponibilização dos horários das salas de aula do laboratório;
• Pedido de reserva de horário de sala de aula;
• Controlar informações sobre máquinas;
• Desligar uma ou mais máquinas de uma sala de aula;
• Aceitar um pedido de reserva de um horário de sala de aula.
Esse trabalho tem por objetivo a criação de um sistema Web de fácil
acesso com alta persistência e consistência dos dados que supra os
requisitos acima citados.
1.4 Conteúdo do Trabalho
O presente trabalho se divide em cinco capítulos para uma melhor
organização. O primeiro é a introdução, o qual traz informações básicas
sobre o tema do trabalho, a justificativa e os seus objetivos.
O segundo capítulo é um levantamento bibliográfico e o estado da arte
relacionado a softwares para gerenciamento de laboratórios de informática,
demonstrando os benefícios do sistema desenvolvido em relação aos
existentes hoje.
O terceiro capítulo disserta sobre a metodologia utilizada e os testes de
implementação, implantação e integração do sistema.
O quarto capítulo demonstra os resultados obtidos com o sistema.
Finalmente, o quinto capítulo apresenta as conclusões observadas.
Capítulo 2 - Levantamento Bibliográfico e Estado da Arte 11
2 LEVANTAMENTO BIBLIOGRÁFICO E ESTADO DA ARTE
Esse capítulo contempla o que há no mercado relacionado a softwares
para gerenciamento de laboratórios de informática e demonstra os
benefícios do sistema desenvolvido em relação aos existentes hoje.
2.1 Estado da Arte
Hoje no mercado não existe nenhum software que abranja todas as
necessidades detectadas para o sistema, porém existem alguns programas
que poderiam auxiliar no gerenciamento da RLE em casos pontuais.
Figura 1 – Tela do programa LSoft Almoxarifado
O programa LSoft Almoxarifado, ilustrado na Figura 1, é um software
para controle de almoxarifado e patrimônio (LSOFT, 2007). Esse software
abrange todas as necessidades de uma empresa de pequeno e médio porte
para controle de almoxarifado e patrimônio, tais como: controle de pedidos,
Capítulo 2 - Levantamento Bibliográfico e Estado da Arte 12
compras, requisições, empréstimos, devoluções, relatórios e etc. Porém, o
LSoft não possui um módulo que supra as necessidades da RLE com
relação aos Horários das aulas, além de não possuir um fácil acesso, que é
um dos requisitos encontrados no projeto. O software possui uma versão de
avaliação que perde suas funcionalidades (totais ou parciais) dentro de um
prazo estipulado pelo desenvolvedor e uma versão completa que tem um
custo de R$ 610,00.
Um outro software existente no mercado é o DTS Horário da empresa
DTS (DTS, 2007). O DTS Horário é um software comercial com a
funcionalidade de controle de horários de laboratório. O escopo desse
software atinge os requisitos necessários na RLE em relação ao controle de
horário, mas não supre os outros requisitos da RLE como, por exemplo, o
controle de informações das máquinas e o pedido de reserva de horário,
além de não ter um fácil acesso, o que é um dos requisitos do projeto.
Hoje não existe no mercado um software que, sozinho, atinja todas as
funcionalidades necessárias.
2.2 Vantagens do Sistema Desenvolvido
Dos softwares encontrados, nenhum conseguiu abranger todas as
necessidades detectadas em reuniões com os administradores da RLE.
Seria necessário contratar uma empresa de desenvolvimento de software e
criar um software específico para as necessidades da RLE.
O sistema aqui desenvolvido tem uma grande vantagem, que é o fácil
acesso, por ser um sistema web qualquer pessoa que tenha acesso a
Internet pode acessar o sistema sem a necessidade de instalação de um
software na máquina do cliente e indiferente do sistema operacional
utilizado.
Capítulo 3 - Metodologia 13
3 METODOLOGIA
3.1 Levantamento dos Requisitos
O levantamento dos requisitos foi feito na forma de reuniões com os
administradores da RLE. Nessa etapa foram questionadas as tarefas que o
sistema deveria desempenhar. Após algumas reuniões chegou-se as
seguintes necessidades:
• Disponibilização dos horários das salas de aula da RLE;
• Pedido de reserva de horário de sala de aula;
• Controlar informações sobre máquinas;
• Desligar uma ou mais máquinas de uma sala de aula;
• Aceitar um pedido de reserva de um horário de sala de aula.
Cada uma dessas tarefas se tornou uma funcionalidade do sistema.
3.2 Recursos empregados
3.2.1 Recursos Financeiros e de Pessoal
Não foi necessário nenhum recurso financeiro para execução desse
projeto, pois as máquinas utilizadas para o desenvolvimento e
implementação foram do próprio laboratório. O recurso de pessoal utilizado
foi apenas um aluno do curso de Tecnologia em Informática.
3.2.2 Recursos de Hardware
O hardware utilizado foi todo disponibilizado pela universidade, foi
necessária uma máquina para desenvolvimento, uma para o servidor WEB e
outra para o servidor de banco de dados. Além das máquinas já utilizadas
no laboratório para acesso a Internet e gerenciamento da rede.
Capítulo 3 - Metodologia 14
3.2.3 Recursos de Software
Os seguintes recursos de software foram necessários para que esse
projeto fosse implementado:
• Java : é o kit de desenvolvimento JAVA que contém todos os
pacotes e classes necessárias para a criação e execução dos
aplicativos envolvidos no trabalho. Ele é fornecido gratuitamente
pela Sun Microsystem (DEITEL, 2003);
• Netbeans IDE 5.5: o netbeans é uma IDE, um ambiente de
desenvolvimento integrado para desenvolver aplicações em Java.
É gratuito, de código aberto e multi-plataforma (NETBEANS, 2007);
• Netbeans Visual web pack : Complemento do netbeans para
desenvolvimento visual web (NETBEANS, 2007), suporte a drag ‘n
drop (arrastar e soltar) e com Componentes JavaServer Faces
ativados por AJAX;
• Tomcat : container de aplicações web da Apache, com suporte a
servlets, JSP e JSF (TOMCAT, 2007);
• PostgreSQL : Banco de dados relacional, gratuito, de código
aberto e multi-plataforma (POSTGRESQL, 2007);
• Microsoft Office : Conjunto de Ferramentas para elaboração de
documentos (MICROSOFT, 2007);
• Jude Community : ferramenta de modelagem UML (Unified
Modeling Language) orientada a objetos. O JUDE possui uma
versão livre (Jude Community) e foi utilizado para modelar o
sistema (JUDE, 2007).
Capítulo 3 - Metodologia 15
3.3 Testes e Implantação
Testes de estabilidade foram feitos utilizando as próprias máquinas da
RLE. Para um teste de estabilidade foram usadas vinte máquinas do
laboratório simultaneamente (por meio de scripts) para acessar o sistema.
Durante esses testes, nenhuma anomalia foi detectada.
A implantação do sistema foi relativamente simples, pois os softwares
e os hardwares utilizados já estavam disponíveis e configurados, foi
necessário apenas à implantação do pacote web (arquivo. war) no
repositório de aplicações já utilizado pela RLE.
Capítulo 4 – Modelagem 16
4 MODELAGEM
O presente capítulo apresenta a modelagem do sistema feita através
da Análise Orientada a Objetos. São apresentados diagramas de caso de
uso, diagramas de classe e diagramas de seqüência para cada
funcionalidade do sistema.
4.1 Descrição da Arquitetura
Por ser um sistema web, a arquitetura usada foi a de cliente-servidor,
mas também se utilizando os benefícios da arquitetura do modelo de três
camadas. A camada de apresentação ficando do lado do cliente e as
camadas de persistência e de negócio do lado do servidor.
Este modelo tem inúmeras vantagens, dentre elas está a que o
software executado em cada camada possa ser substituído sem prejuízo
para o sistema. De modo que atualizações e correções de bugs podem ser
feitas sem prejudicar as demais camadas, respostas mais rápidas nas
requisições, excelente performance tanto em sistemas que são executados
na Internet ou em uma intranet e mais controle no crescimento do sistema.
4.2 Requisitos Funcionais e não Funcionais
Para o projeto ser considerado Funcional foi necessária a criação de
um sistema Web de fácil acesso com alta persistência e consistência dos
dados, no qual um usuário da internet, após logado, acessa módulos de
acordo com seu grupo, podendo gerar requisições que serão interpretadas
pelo sistema.
Capítulo 4 – Modelagem 17
4.3 Modelagem do sistema por funcionalidade
4.3.1 Ver Horários
Figura 2 – Diagrama de Caso de Uso “Ver Horários das Salas”
A Figura 2 ilustra o caso de uso “Ver Horários das Salas”. Este caso de
uso tem como funcionalidade Usuários (Administradores, Professores e
Alunos) terem acesso aos horários de uma determinada sala do laboratório.
Pré-condições: para que o usuário possa usar esse caso de uso é
necessário que ele esteja logado no sistema.
Pós-condições: O resultado esperado é a visualização do horário de
uma determinada sala sem alteração do sistema.
Capítulo 4 – Modelagem 18
Figura 3 – Diagrama de classe “Ver Horários das Salas”
A Figura 3 ilustra o diagrama de classe da funcionalidade “Ver Horários
das Salas”. O diagrama demonstra que uma classe de controle está
associada à de interface e a uma Reserva, esta Reserva é a classe que vai
persistir no banco de dados e contém as informações relacionadas a
reserva.
Figura 4 – Diagrama de Seqüência “Ver Horários das Salas”
A Figura 4 demonstra o diagrama de Seqüência da funcionalidade “Ver
Horários das Salas”. Nela uma instância da classe de controle chama o
método da classe de interface que mostra a tela na qual o usuário vai
informar a data e sala da qual deseja ver as reservas. Então, a classe de
interface chama o método da classe de controle para buscar as reservas, a
Capítulo 4 – Modelagem 19
classe de controle chama o método que busca as reservas da classe
reserva e as devolve para a interface que as mostra na tela.
4.3.2 Pedir reserva
Figura 5 – Diagrama de Caso de uso “Pedir Reserva”
No caso de uso ilustrado na Figura 5 os usuários dos grupos
Administradores e Professores poderão pedir uma reserva de um horário de
uma determinada sala do laboratório através de um formulário, a ser aceito
ou rejeitado por um usuário do grupo Administradores (ver 4.3.3 Aceitar
Reserva).
Pré-condições: para que o usuário possa usar esse caso de uso é
necessário que o mesmo esteja logado no sistema e que ele pertença ao
grupo Administradores ou Professores.
Pós-condições: após a execução ficará persistido no sistema o pedido
de reserva, a ser aceito por um usuário do grupo Administradores.
Capítulo 4 – Modelagem 20
Figura 6 – Diagrama de classe “Pedir Reserva”
O diagrama de classe da Figura 6 expressa o fluxo entre as classes
usadas na funcionalidade “Pedir Reserva”. Uma classe de controle se
comunica com a classe reserva e com a interface com o usuário.
Figura 7 – Diagrama de Seqüência “Pedir Reserva”
A Figura 7 ilustra o diagrama de seqüência para esta funcionalidade.
Uma instância da classe de controle chama o método da interface que
mostra para o usuário a tela com o formulário de pedido de reserva, o
usuário digita os dados da reserva e confirma o pedido pressionando o
botão de confirmação. A interface chama o método do controle passando os
Capítulo 4 – Modelagem 21
dados do pedido de reserva como parâmetro, a classe de controle chama a
classe de reserva para persistir o pedido de reserva. O objeto da classe de
controle chama o de interface de usuário e este, por sua vez, mostra para o
usuário a tela de pedido aceito.
4.3.3 Aceitar reserva
Figura 8– Diagrama de Caso de Uso “Aceitar Reserva”
A Figura 8 ilustra o caso de uso em que um usuário do grupo
Administradores verifica as reservas pendentes e aceita ou rejeita cada
pedido de reserva de sala.
Pré-condições: para que o usuário possa usar esse caso de uso é
necessário que ele esteja logado no sistema e ser do grupo
Administradores.
Pós-condições: se o pedido for aceito, ele torna-se uma reserva de
sala, caso contrário o pedido é excluído do sistema.
Figura 9 – Diagrama de classe “Aceitar Reserva”
Capítulo 4 – Modelagem 22
A Figura 9 mostra o diagrama de classe da funcionalidade “Aceitar
Reserva”. Nela apresenta-se a relação entre a classe de controle com as
interfaces com o usuário e banco de dados.
Figura 10 – Diagrama de Seqüência “Aceitar Reserva”
A Figura 10 mostra o diagrama de seqüência para a funcionalidade
“aceitar Reserva” na qual uma instância da classe de controle se comunica
com a camada de dados e envia para a interface as Reservas Pendentes, o
Administrador escolhe a reserva que quer aceitar e então a interface chama
o método da classe de controle, que por sua vez chama o método da
interface com o banco de dados para aceitar a Reserva.
4.3.4 Desligar Máquina
Figura 11 – Diagrama de Caso de Uso “Desligar Máquina”
No caso de uso ilustrado na Figura 11 um usuário do grupo
Administradores escolhe uma determinada sala, podendo desligar todas as
máquinas da sala ou alguma especifica.
Capítulo 4 – Modelagem 23
Pré-condições: para que o usuário possa usar esse caso de uso é
necessário que ele esteja logado no sistema e ser do grupo
Administradores.
Pós-condições: depois de executado esse caso de uso, é gerado um
aviso para cada máquina que está sendo desligada e em um tempo
determinado (por exemplo, dois minutos), as máquinas serão desligadas.
Figura 12 – Diagrama de classe “Desligar Máquina”
O diagrama de classe da Figura 12 expressa o fluxo entre as classes
usadas na funcionalidade “desligar Máquina”. Uma classe de controle se
comunica com a interface com um sistema de controle de máquinas, que
será feito por scripts em bash e com a interface do usuário usando a classe
máquina para passagem de informações.
Figura 13 – Diagrama de Seqüência “Desligar Máquina”
A Figura 13 ilustra o diagrama de seqüência para a funcionalidade
“desligar Máquina”. Uma instância da classe de controle chama o método da
interface com o Sistema de Controle de máquina passando a sala
Capítulo 4 – Modelagem 24
selecionada como parâmetro. O sistema de controle de máquinas retorna o
estado de todas as máquinas daquela sala, a classe de controle repassa as
informações para a interface do administrador, o administrador escolhe a
máquina que deseja desligar e a interface chama o método da classe de
controle que por sua vez chama o método de desligamento da interface com
o Sistema de controle de máquinas.
4.3.5 Modificar Informação máquina
Figura 14 – Diagrama de Caso de Uso “Modificar Informação máquina”
No caso de uso ilustrado na Figura 14 um usuário do grupo
Administradores escolhe uma máquina e verifica seus detalhes, podendo
atualizá-los. As informações a respeito de cada máquina são: Números de
patrimônio (gabinete, monitor, mesa e cadeira), placa mãe, processador,
memória, placa de vídeo, disco rígido, drive de DVD, disquete. Cada uma
das informações é uma coluna no banco de dados.
Pré-condições: para que o usuário possa usar esse caso de uso é
necessário que ele esteja logado no sistema e ser do grupo
Administradores.
Pós-condições: após o uso, as informações alteradas serão persistidas
no banco de dados.
Capítulo 4 – Modelagem 25
Figura 15 – Diagrama de classe “Modificar Informação Máquina”
O diagrama de classe da Figura 15 expressa o fluxo entre as classes
usadas na funcionalidade “Modificar Informação Máquina”. Uma classe de
controle se comunica com a interface com o usuário usando a classe
máquina para persistência das informações.
Figura 16 – Diagrama de Seqüência “Modificar Informação máquina”
A Figura 16 ilustra o diagrama de seqüência para esta funcionalidade.
Uma instância da classe de controle chama o método da interface que
mostra para o usuário a tela com o as informações de uma determinada
máquina então o usuário digita os dados que deseja modificar para a
máquina e a interface chama o método do controle que registra a
modificação.
Capítulo 4 – Modelagem 26
4.4 Implantação
Para implantação do sistema na RLE foi necessário primeiramente a
criação da base de dados e a população da mesma com dados reais. As
informações necessárias foram solicitadas ao Departamento Acadêmico de
Informática da UTFPR.
Com o banco de dados já populado o próximo passo foi à implantação
do sistema no servidor WEB. Para testes, o endereço do sistema não foi
publicado e apenas os Administradores da rede acessaram-no, utilizando-se
de contas criadas para teste.
Depois de corrigidos alguns bugs, o endereço do sistema foi publicado
para todos os usuários e passaram-se alguns dias com o sistema em
observação.
Para verificação de satisfação dos usuários foi criado um formulário e
passado para uma amostra dos alunos, administradores e professores.
Capítulo 5 – Resultados 27
5 RESULTADOS
Como resultado obtido com o projeto e desenvolvimento desse
trabalho surgiu um sistema web com as funcionalidades requisitadas por
usuários da RLE.
Logo que o usuário acessa o sistema ele encontra a pagina de login,
como pode ser observado na Figura 17. Nesta tela o usuário insere seu
login e sua senha de acesso para poder acessar o sistema.
Figura 17 – Tela de Login.
As senhas utilizadas no sistema foram integradas com as senhas
utilizadas nos laboratórios.
Se os dados informados estiverem corretos o usurário será enviado
para a pagina inicial do sistema (ver Figura 18).
Capítulo 5 – Resultados 28
Figura 18 – Tela Inicial do sistema.
Como ilustra a Figura 18, na tela inicial do sistema há informações
básicas da R.L.E. juntamente com um menu. Dependendo do grupo do
usuário (Administradores, Professores ou Alunos) o menu se altera.
Capítulo 5 – Resultados 29
Figura 19 – Tela Inicial do sistema, grupo Professores.
Como é mostrado na Figura 19, apenas as funcionalidades do sistema
que podem ser acessadas pelo grupo do usuário são exibidas na tela inicial.
Segue abaixo uma breve explicação do resultado final de cada
funcionalidade.
5.1 Disponibilização dos horários das salas de aula do
laboratório
Nessa funcionalidade um usuário (aluno, professor ou administrador da
RLE) pode ver um horário de uma determinada sala.
Capítulo 5 – Resultados 30
Figura 20 – Tela “Verificar Horários”, escolha da data e sala
Conforme ilustra a Figura 20, para ver o horário de uma determinada
sala basta selecionar a sala desejada, digitar a data para a qual se deseja
saber o horário e pressionar o botão “OK”.
Capítulo 5 – Resultados 31
Figura 21 – Tela “Verificar Horários”, tabela com horários
O sistema busca todas as reservas confirmadas para a semana
daquela data e a mostra em uma tabela (ver Figura 21).
Capítulo 5 – Resultados 32
5.2 Pedido de reserva de horário de sala de aula
Nessa funcionalidade um usuário do grupo Professores ou
Administradores pode fazer um pedido de reserva de um horário para uma
determinada sala do laboratório.
Figura 22 – Tela “Solicitar Reservas”
Para isto basta preencher um formulário com as informações
pertinentes à reserva (horário, data, sala), preencher a Descrição
(informação que aparecerá na tabela de horários), preencher alguma
observação se necessária e submeter as informações pressionando o botão
pedir reserva (ver Figura 22). O sistema enviará um e-mail para o grupo de
Administradores avisando que existe uma reserva a ser aceita.
Capítulo 5 – Resultados 33
5.3 Desligar uma ou mais máquinas de uma sala de au la
Nessa funcionalidade um usuário do grupo Administradores pode
desligar uma ou mais máquinas de uma determinada sala.
Figura 23 – Tela “Informações de Máquinas”
A Figura 23 ilustra a tela de informações de máquinas, nela há a
informação de cada máquina organizada por sala. Caso deseje desligar uma
ou várias máquina, basta selecioná-las e pressionar o botão “desligar”.
5.4 Controlar informações sobre máquinas
Nessa funcionalidade um usuário do grupo Administradores pode ver e
atualizar informações (nome, hardware relacionado, números de patrimônio
e etc.) sobre uma determinada máquina.
Para acessar as informações basta, a partir da tela de informações de
máquina (ver Figura 23), escolher a máquina que deseja ver as informações
e pressionar o link “Editar”.
Capítulo 5 – Resultados 34
Figura 24 – Tela “Detalhes por Máquina”
Então, aparecerá uma página com as informações da máquina
selecionada. Pressionando o botão “Salvar”, o usuário poderá editar as
informações daquela máquina.
Capítulo 5 – Resultados 35
5.5 Aceitar um pedido de reserva de um horário de s ala de
aula
Nessa funcionalidade usuários do grupo Administradores podem
aceitar ou rejeitar pedidos de reservas.
Figura 25 – Tela “Aceitar Reservas”
Para isto, basta selecionar as reservas que o usuário logado deseja
aceitar ou rejeitar e pressionar o respectivo botão (Aceitar ou Rejeitar)
conforme ilustra a Figura 25. Os professores que pediram as reservas
aceitas ou rejeitadas irão automaticamente receber um e-mail confirmando
se a reserva foi aceita ou não.
Capítulo 6 - Conclusões 36
6 CONCLUSÕES
Fica notório que com o desenvolvimento do presente trabalho, certas
tarefas da RLE que antes eram repetitivas e de difícil gerenciamento agora
podem ser realizadas de forma simples com fácil acesso.
Para isso foi criado um sistema Web com alta persistência e
consistência dos dados para ser utilizado por administradores, professores e
alunos da RLE.
No desenvolvimento do sistema foram utilizadas tecnologias atuais e
difundidas (Java, JSP, HTML e etc..). A modelagem utilizada foi a de três
camadas, o que ajuda bastante para desenvolvimento de mais
funcionalidades caso necessário.
6.1 Contribuições
Com o fechamento desse trabalho foi possível ajudar no
desenvolvimento da Rede Local de Ensino, facilitando para alunos,
professores e administradores a execução de tarefas que antes geravam um
esforço maior.
A contribuição que o presente trabalho pode dar para a Universidade
Tecnológica Federal do Paraná é uma forma de retribuir pela oportunidade
que poucas pessoas têm de estudar em uma universidade pública.
6.2 Trabalhos Futuros
Este trabalho abre um leque de possibilidades para alunos ou
administradores da rede poderem ampliá-lo.
Por ser um sistema divido em três camadas bem definidas, novas
funcionalidades poderão ser incluídas com pouca dificuldade, de acordo
com as novas necessidades que surgirem, facilitando vários níveis de
projeto e implantação, como estrutura, acesso a banco de dados e etc.
7 REFERÊNCIAS
NETBEANS. Netbeans Integrated Development Environment . 2007.
Disponível em: <http://www.netbeans.org/> . Acesso em 12 de junho de
2007.
NETBEANS. NetBeans Visual Web Pack . 2007. Disponível em:
<http://www.netbeans.org/products/visualweb/> . Acesso em 15 de junho de
2007.
TOMCAT. Apache Tomcat . 2007. Disponível em:
<http://tomcat.apache.org/> . Acesso em 20 de junho de 2007.
POSTGRESQL. PostgreSQL: open-source database . 2007. Disponível
em: <http://www.postgresql.org/> . Acesso em 20 de junho de 2007.
MICROSOFT, Office. Homepage do office online . 2007. Disponível em:
<http://www.microsoft.com/brasil/office/> . Acesso em 20 de junho de 2007.
http://jude-users.com/en/
JUDE, Community. Jude Community Site . 2007. Disponível em:
<http://jude-users.com/en/> . Acesso em 10 de junho de 2007.
LSOFT, Almoxerifado. Lsoft Informática e tecnologia . 2007. Disponível
em: <http://www.lsoft.com.br/sistemas/sistemas.php?id=4&pg=0>. Acesso
em 20 de julho de 2007.
DTS, Tecnologia e Sistemas Ltda. Software DTS Horario . 2007. Disponível
em: <http://www.dtsba.com.br/horario/index.html>. Acesso em 10 de junho
de 2007.
Autorização
Autorizo a reprodução e/ou divulgação total ou parcial da presente
obra, por qualquer meio convencional ou eletrônico, desde que citada a
fonte.
Nome do autor: Franklin Felipe Wagner
Assinatura do autor: ____________________________
Instituição: Universidade Tecnológica Federal do Paraná
Local: Curitiba, Paraná.
Endereço: Avenida Silva Jardim, 994, ap 02, Rebouças.
E-mail: [email protected]