39
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 ...cristina/SistemaWebRLE.pdf · implementação, implantação e integração do sistema. O quarto capítulo demonstra os

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]