Fretum: Sistema web de armazenamento de arquivos...de relat orios de atividades, ou seja, com ele o...

Sant’Clear Ali Costa

Fretum: Sistema web de armazenamento

de arquivos

Sao Jose – SC

Julho / 2013

Sant’Clear Ali Costa

Fretum: Sistema web de armazenamento

de arquivos

Monografia apresentada a Coordenacao doCurso Superior de Tecnologia em Sistemasde Telecomunicacoes do Instituto Federalde Santa Catarina para a obtencao do di-ploma de Tecnologo em Sistemas de Teleco-municacoes.

Orientador:

Prof. Diego de Medeiros, M. Eng.

Curso Superior de Tecnologia em Sistemas de TelecomunicacoesInstituto Federal de Santa Catarina

Sao Jose – SC

Julho / 2013

Monografia sob o tıtulo “Fretum: Sistema web de armazenamento de arquivos”, de-

fendida por Sant’Clear Ali Costa e aprovada em 24 de Julho de 2013, em Sao Jose, Santa

Catarina, pela banca examinadora assim constituıda:

Prof. Diego da Silva de Medeiros, M. Eng.Orientador

Prof. Ederson Torresini, M. SC.IFSC

Guillaume Barrault, Dr.WaveTech Solucoes Tecnologicas Ltda.

Agradecimentos

Agradeco a todos que contribuıram para eu chegar ate aqui. Em especial meus pais

por terem me proporcionado a educacao que tenho hoje. A Minha namorada Bruna

Amante que sempre esteve comigo nos bons e maus momentos, que tentou me dar apoio

de todas as formas que estiveram ao alcance dela. A toda equipe da WaveTech Solucoes

Tecnologicas que me deram grandes incentivos e apoio no desenvolvimento deste trabalho.

Agradeco especialmente, ao Dr. Guillaume Barrault que foi o grande incentivador deste

trabalho e ao Diego Tefili que prestou imenso auxılio na formatacao e correcoes deste

documento.

Sou grato tambem a todos os professores pelo conhecimento passado a mim. Com

destaque aqueles que tiveram grande paciencia comigo nos momento de dificuldades, que

tornaram as aulas mais empolgantes e didaticas como Maria Claudia de A. Castro, Sil-

viana Cirino, Ederson Torresini, Volnei V. Rodrigues, Mario de Noronha Neto, Eraldo

Silveira e Silva, Jaci Destri e tambem o meu orientador Diego Medeiros, por sua presteza

e ajuda durante o desenvolvimento deste trabalho.

Resumo

Nos dias atuais, cada vez mais equipamentos estao conectados a internet. Os disposi-tivos da linha Smart (telefones, televisores, geladeiras, entre outros) estao cada vez maisentrando nos lares das pessoas e se tornando itens indispensaveis no dia a dia. Mesmona informatica convencional, sistemas originalmente com deposito de informacao localestao migrando para o acesso na nuvem. Sao exemplos disso os programas de escritorio earmazenamento de arquivos via web.

Este trabalho acompanha essa popularizacao da convergencia de aplicacoes para oambiente da internet, atraves do sistema web de armazenamento de arquivos em Javacriado nesse trabalho, o qual esta disponıvel para suprir uma demanda especıfica daempresa WaveTech Solucoes Tecnologicas, uma empresa da area de engenharia biomedicaque tem seus desenvolvedores descentralizados em outros estados do Brasil, e que tem anecessidade de controlar os arquivos criados por terceiros atraves de uma interface webintuitiva dispensando a necessidade de treinamento.

O sistema desse trabalho permite o controle de privilegio de envio de arquivos e geracaode relatorios de atividades, ou seja, com ele o usuario pode enviar e carregar arquivos deou para um servidor remoto. Esse sistema registra as acoes de envio, carregamento eexclusao de arquivos. O administrador desse sistema pode definir quem tem permissaopara enviar e/ou carregar arquivos.

Abstract

Nowadays, more and more equipments are conected to internet. The Smart devices(telephones, televisions, regrigerators, etc) are entering people’s homes and are becomingindispensable to modern lives. Even in conventional computing, local information reposi-tory systems are migrating to on cloud access. Office programs and web-based file storageare examples.

This work follows the popularization of the convergence of internet-based applications,through the file storage web system developed in this work. This system is availableto feed the WaveTech Solucoes Tecnologicas’s specific demand, a biomedic-engineering’senterprise which has descentralized developpers in other Brazil states. The enterprisehas the necessity to control files created by third party through a intuitive web interface,dispensing the need of training.

The system of this work allows privilege’s control of file sending and activity reportgeneration, or in other words, with the system the user can sending and receive files toand from a remote server. This system records actions of sending, receiving and excludingfiles. The administrator can define who has the permission to sending and receiving files.

Sumario

Lista de Figuras

Lista de Tabelas

Lista de sımbolos p. 13

1 Introducao p. 14

1.1 Requisitos nao funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . p. 14

1.1.1 Facilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 14

1.1.2 Implementacao . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 15

1.1.3 Recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 16

2 Revisao bibliografica p. 18

2.1 Historia da internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 18

2.2 Camadas de rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19

2.3 O modelo cliente servidor . . . . . . . . . . . . . . . . . . . . . . . . . p. 20

2.4 HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23

2.5 PaaS OpenShift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23

2.6 Banco de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25

2.7 Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25

2.7.1 JSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25

2.7.2 Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27

2.7.3 Spring Security . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 27

2.7.4 Prime Faces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 28

2.8 Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 29

2.9 IDE Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30

3 Desenvolvimento p. 32

3.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 32

3.2 Domınio do problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 33

3.3 Requisitos funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 34

3.3.1 Identificacao dos atores do sistema . . . . . . . . . . . . . . . . p. 34

3.3.1.1 Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . p. 34

3.3.1.2 Administrador . . . . . . . . . . . . . . . . . . . . . . p. 34

3.3.2 Limites do sistema . . . . . . . . . . . . . . . . . . . . . . . . . p. 35

3.3.2.1 Applet Area Administrativa . . . . . . . . . . . . . . . p. 35

3.3.2.2 Applet Regiao . . . . . . . . . . . . . . . . . . . . . . p. 35

3.3.3 Principais casos de utilizacao . . . . . . . . . . . . . . . . . . . p. 35

3.4 Modelo de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 41

3.5 Modelo de classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 44

3.5.1 ArquivoBean . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 45

3.5.2 UsuarioBean . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 47

3.5.3 Regra de negocio . . . . . . . . . . . . . . . . . . . . . . . . . . p. 49

3.6 Diagramas de sequencia . . . . . . . . . . . . . . . . . . . . . . . . . . p. 51

3.6.1 Regra de negocio . . . . . . . . . . . . . . . . . . . . . . . . . . p. 51

3.6.2 Novo usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 52

3.6.3 Editar usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 54

3.6.4 Ativar usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 55

3.6.5 Atribuir privilegios ao usuario . . . . . . . . . . . . . . . . . . . p. 56

3.6.6 Excluir usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 57

3.6.7 Enviar arquivo . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 58

3.6.8 Carregar arquivo . . . . . . . . . . . . . . . . . . . . . . . . . . p. 62

3.6.9 Excluir arquivo . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 63

4 Configuracao da aplicacao p. 65

4.1 Implantacao do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 65

4.1.1 Parametros dos frameworks . . . . . . . . . . . . . . . . . . . . p. 78

4.1.1.1 JSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 79

4.1.1.2 Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . p. 80

4.1.1.3 Spring Security . . . . . . . . . . . . . . . . . . . . . . p. 80

5 Resultados p. 84

6 Conclusao p. 93

6.1 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 93

Lista de Abreviaturas p. 95

Referencias p. 97

Lista de Figuras

1 Interesse pelas principais linguagens de programacao - Pesquisa realizada

em 21/05/2013 no Google Trends . . . . . . . . . . . . . . . . . . . . . p. 16

2 Modelo TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 20

3 Modelo cliente/servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 21

4 Escalonamento automatico dos recursos . . . . . . . . . . . . . . . . . . p. 24

5 Pagina basica da camada de visualizacao . . . . . . . . . . . . . . . . . p. 26

6 Mapeamento objeto relacional para entidades de banco de dados . . . . p. 27

7 Configuracao basica do Maven . . . . . . . . . . . . . . . . . . . . . . . p. 30

8 Injecao de dependencia . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 30

9 Domınio do problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 34

10 Diagrama de Caso de Uso (DCDU) da Regiao . . . . . . . . . . . . . . p. 37

11 Diagrama de Caso de Uso (DCDU) da Area Administrativa . . . . . . p. 41

12 Modelo de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 43

13 Modelo de classe do ArquivoBean . . . . . . . . . . . . . . . . . . . . . p. 46

14 Modelo de classe do UsuarioBean . . . . . . . . . . . . . . . . . . . . . p. 48

15 Modelo de classe da regra de negocio . . . . . . . . . . . . . . . . . . . p. 50

16 Diagrama de sequencia Regra de Negocio Usuario . . . . . . . . . . . . p. 51

17 Diagrama de sequencia Salvar Usuario . . . . . . . . . . . . . . . . . . p. 53

18 Diagrama de sequencia Editar Usuario . . . . . . . . . . . . . . . . . . p. 55

19 Diagrama de sequencia Ativar ou Desativar Usuario . . . . . . . . . . . p. 56

20 Diagrama de sequencia Atribuir Privilegios ao Usuario . . . . . . . . . p. 57

21 Diagrama de sequencia Excluir Usuario . . . . . . . . . . . . . . . . . . p. 58

22 Diagrama de sequencia Envio de Arquivo . . . . . . . . . . . . . . . . . p. 61

23 Diagrama de sequencia Carregar Arquivo . . . . . . . . . . . . . . . . . p. 63

24 Diagrama de sequencia Excluir Arquivo . . . . . . . . . . . . . . . . . . p. 64

25 Conta OpenShift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 66

26 Servidor JBoss AS 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 66

27 Servidor JBoss AS 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 67

28 Gerenciador de sistemas implantados . . . . . . . . . . . . . . . . . . . p. 68

29 Informacoes sobre o sistema implantado . . . . . . . . . . . . . . . . . p. 68

30 Adicionar banco de dados . . . . . . . . . . . . . . . . . . . . . . . . . p. 69

31 Selecionar MySQL 5.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 69

32 Confirmar a escolha do MySQL . . . . . . . . . . . . . . . . . . . . . . p. 70

33 Gerenciador de sistemas implantados . . . . . . . . . . . . . . . . . . . p. 70

34 Git clone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 71

35 Import do Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 72

36 Importacao Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 73

37 Pasta do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 74

38 Carregar projeto no Eclipse . . . . . . . . . . . . . . . . . . . . . . . . p. 74

39 Endereco Terminal Seguro - Security Shell (SSH) do repositorio . . . . p. 75

40 Acesso remoto do repositorio via SSH . . . . . . . . . . . . . . . . . . . p. 75

41 Criacao de diretorio fısicos para o sistema . . . . . . . . . . . . . . . . p. 76

42 Binarios do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 76

43 Commit do Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 77

44 Configuracao do banco de dados . . . . . . . . . . . . . . . . . . . . . . p. 78

45 Estrutura de diretorios . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 79

46 Configuracoes do JSF . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 80

47 Configuracoes do Hibernate . . . . . . . . . . . . . . . . . . . . . . . . p. 81

48 Configuracoes do Spring Security . . . . . . . . . . . . . . . . . . . . . p. 82

49 Configuracoes do caminho do banco de dados para o Spring Security . . p. 83

50 Botao para entrar na area de dialogo de acesso ao sistema . . . . . . . p. 84

51 Dialogo para acesso ao sistema . . . . . . . . . . . . . . . . . . . . . . . p. 85

52 Tela principal para usuarios nao administradores . . . . . . . . . . . . . p. 85

53 Tela principal para usuarios administradores . . . . . . . . . . . . . . . p. 86

54 Diretorio sem recurso de envio de arquivos . . . . . . . . . . . . . . . . p. 87

55 Lista de arquivos expandida em uma segunda tela . . . . . . . . . . . . p. 87

56 Diretorio com recurso de envio de arquivos . . . . . . . . . . . . . . . . p. 88

57 Area administrativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 89

58 Area de cadastro de usuarios . . . . . . . . . . . . . . . . . . . . . . . . p. 90

59 Recursos de filtragem e de ordenacao de valores . . . . . . . . . . . . . p. 91

60 Area de registros de atividades dos usuarios . . . . . . . . . . . . . . . p. 92

Lista de Tabelas

1 Mensagem de requisicao HTTP . . . . . . . . . . . . . . . . . . . . . . p. 22

2 Mensagem de resposta HTTP . . . . . . . . . . . . . . . . . . . . . . . p. 22

Lista de sımbolos

Sımbolo Descricao

Objeto da API Java

Objeto deste trabalho

Tipo enumerado

Atributo privado

Atributo publico

Metodo privado

Metodo publico

Pacote

Humano ou entidade maquina que interage com

o sistema para executar um trabalho.

0...* Zero ou mais

1...* Um ou mais

Chave Primaria

Chave estrangeira

Atributo pode ser nulo

Atributo nao nulo

Relacionamento de muitos

Relacionamento de 1

Entidade de Banco de Dados

14

1 Introducao

A WaveTech Solucoes Tecnologicas e uma empresa da area de engenharia biomedica.

Para o desenvolvimento de seus produtos ela conta com parceiros distribuıdos no territorio

Brasileiro. Atualmente, o principal ramo de atuacao e o desenvolvimento de firmware para

aparelhos auditivos, incluindo implementacao de algoritmos de processamento de audio e

especificacao de requerimentos para o hardware correspondente. A WaveTech participa,

ainda, do desenvolvimento do primeiro chip nacional voltado totalmente para aparelhos

auditivos. Nos projetos em andamento, estao envolvidas outras duas empresas, localizadas

em outros estados.

Para centralizar a troca de conteudo digital entre estas tres empresas, os gerentes de

projetos decidiram pelo desenvolvimento de um sistema web no qual cada empresa possa

hospedar separadamente seus arquivos. Dessa forma, o sistema deveria ser dividido em

tres diretorios, sendo um destinado para cada empresa.

1.1 Requisitos nao funcionais

Nesta secao sera apresentada uma analise, em subsecoes, dos requisitos que justificam

a concepcao do sistema Fretum.

1.1.1 Facilidade

O sistema que e descrito nesse documento foi pensado para ser intuitivo. Cada area

de interacao entre o usuario e o sistema sao compostas de uma lista, a qual e possıvel de

forma direta executar uma acao.

1.1 Requisitos nao funcionais 15

1.1.2 Implementacao

A WaveTech e uma start up. Nessa fase ela visa uma otimizacao de seus gastos e

confidencialidade no desenvolvimento de seus produtos.

O Fretum poderia ter sido facilmente concebido com as Interface de programacao

de aplicativos - Application Programming Interfaces (APIs) gratuitas que os servicos de

armazenamento de arquivos comerciais oferecem, pois elas permitem criar sistemas de

armazenamento de arquivos particulares. O uso dessas APIs poderiam ter sido uma

vantagem para o desenvolvimento do Fretum se nao fosse o fato de que e necessario ter

chave de autenticacao para esses servicos dentro do sistema desse trabalho tornando-o

subordinado a eles (GOOGLE, 2013)(DROPBOX, 2013).

No entanto para o sistema desse trabalho havia uma restricao de projeto, a saber

nao deveria ser dependente de um servico de armazenamento de arquivos como DropBox,

Google Drive, Ubuntu One, etc.

Estar dependente de um sistema de armazenamento de arquivos de terceiros pode ser

um grande problema. Por exemplo eles podem ser custosos devido a possıveis reajustes

de precos para nıveis acima dos quais a empresa considera viavel. Alem disso, eles podem

ser extintos.

Devido as consideracoes anteriores foi decidido a pesquisa de uma tecnologia que

permitisse o desenvolvimento do sistema desse trabalho. Em geral, para o processo de

criacao de software, a escolha de uma tecnologia e determinada por restricoes do mundo

real, como por exemplo, treinamento, investimento previo, custo e disponibilidade. Nao

existe uma regra definida para estabelecer a melhor opcao de linguagem de programacao

para a resolucao de um problema (PYTHON, 2013).

Ao escolher uma linguagem de programacao para o desenvolvimento desse trabalho

alguns requisitos deveriam ser atendidos como:

• Gratuidade;

• Popularidade, para aumentar as chances de encontrar, em um curto prazo, profissi-

onais para fazer manutencao e evolucao do sistema;

• Possuir elementos que possibilitassem tornar o processo de desenvolvimento de soft-

ware mais eficiente;

• Ter suporte por meio de artigos, foruns na web, frameworks, etc.


Na pesquisa de uma tecnologia foram encontradas algumas bem populares entre mui-

tas existentes, a saber Java, PHP, Python e Ruby. Todas elas sao gratuitas e possuem

elementos que possibilitam tornar o processo de desenvolvimento de software mais eficiente

por meio do paradigma de programacao orientado a objetos. No entanto a popularidade

entre as linguagens apresentam diferencas. Na Figura 1 e possıvel verificar, em uma pes-

quisa realizada atraves do Google Trends, o interesse das pessoas, no mundo, por essas

linguagens de programacao. Nota-se no grafico em linha azul que o Java e o mais popular.

Essa analise, de certa forma, tambem faz com que o Java seja o candidato mais forte para

atender o requisito do ultimo item da lista apresentada. A Oracle e uma rede mundial de

produtos de tecnologia, a qual detem os direitos sobre a tecnologia Java afirma1 que eles

possuem a maior comunidade mundial de desenvolvedores de aplicativos, administradores

de banco de dados e arquitetos de software.

Figura 1: Interesse pelas principais linguagens de programacao - Pesquisa realizada em21/05/2013 no Google Trends

1.1.3 Recursos

Para o desenvolvimento do sistema desse trabalho foi necessario:

• Um computador, o qual foi comprado com o Windows 7 Home Premium instalado;

1Disponıvel em: <http://www.java.com/en/about/>


• Um ambiente integrado de desenvolvimento. Nesse caso, o Eclipse com o JDK 7

configurado;

• Um servidor web para fazer testes de implantacao com o projeto desse trabalho.

Dentre varios que possuem a maquina virtual Java, o escolhido foi o JBoss, de

forma aleatoria, pois todos os pesquisados atendem a necessidade de testes locais;

• Criar uma conta em uma plataforma web para implantar o sistema web de armaze-

namento de arquivos. Nesse caso, o OpenShift que dentre varios pesquisados tem

o plano de conta gratuita de 1GB com recursos ilimitados de servidores, banco de

dados, entre outros.

Fora o computador todos o recursos utilizados sao opensources com licencas de uso

gratuitas.

18

2 Revisao bibliografica

Esse trabalho e direcionado aquelas pessoas que estao iniciando seus estudos em te-

lecomunicacoes e se interessa no desenvolvimento web. Dessa forma sera dada uma in-

troducao sobre redes, internet e o modelo cliente servidor. Em seguida sera abordada de

forma introdutorias as tecnologias que foram utilizada para o desenvolvimento do sistema

web desse TCC.

E para aqueles que querem se aprofundar na modelagem de sistemas, na secao De-

senvolvimento e feita uma analise em etapas do Fretum.

2.1 Historia da internet

Na decada de 1960 comecaram pesquisas para resolver um problema que existia na-

quela epoca que era o fato de que equipamentos computacionais de diversos fabricantes

nao podiam se comunicar entre si. Isso era algo que fazia com que o trabalho de pes-

quisadores fosse duplicado de modo que os custos tambem (FOROUZAN; FEGAN et al.,

2008).

Para otimizar os esforcos e diminuir os gastos, a Agencia de Projetos de Pesquisa

Avancados - Advanced Research Project Agency (Arpa) do Departamento de Defesa -

Department of Defense (DoD) dos Estados Unidos se reuniu com a Associacao para Ma-

quinaria da Computacao - Association for Computing Machinary (ACM) e mostrou suas

ideias para a Arpanet, uma pequena rede que tinham seus computadores interconecta-

dos. No caso a ideia era que, independente de fabricante, cada host pudesse se conectar

a outro host1 chamado Processador de mensagens de interface - The Interface Message

Processor (IMP) e ele entre outros IMPs que possuıssem outros hosts conectados a eles.

Entao em 1972 a Arpanet junto com outros pesquisadores trabalharam no projeto que

chamaram de Interneting Project que depois veio a ser a descricao dos protocolos para que

1Host: Em sistemas operacionais, o terminal host normalmente indica um multi-usuario de computadorou software de prestacao de servicos para os terminais de computador(WALTERS, 2001).

2.2 Camadas de rede 19

pacotes pudessem ser entregues de um ponto ao outro (FOROUZAN; FEGAN et al., 2008).

Hoje a Internet nao e mais uma rede unica, mas uma rede mundial de pequenas

redes locais, com outras redes de maior abrangencia, de dispositivos conectados a elas.

Basicamente, quando uma pessoa quer ter uma conexao com a Internet ela contrata os

servicos de um Provedor de acesso a Internet - Internet Service Provider (ISP). Na

Internet, ISPs locais se conectam com ISPs regionais que se conectam com Nacionais que

por sua vez se conectam com os Ponto de acesso a rede - Network Access Points (NAPs)

para que tenha acesso aos ISPs Internacionais (FOROUZAN; FEGAN et al., 2008). E dessa

forma que um host se comunica com outro em qualquer parte do mundo.

Para que essas interconexoes entre dispositivos diversos, alguns protocolos (regras)

foram padronizados para que projetistas da Internet pudessem criar os equipamentos do

seu nucleo e programadores pudessem criar aplicacoes da Internet. Exemplos sao a Web

que usa o Protocolo de Transferencia de Hipertexto - Hipertext Transfer Protocol (HTTP).

Por sua vez o Correio Eletronico que usa o Protocolo de transferencia de correio simples -

Simple Mail Transfer Protocol (SMTP). E a aplicacao de Transferencia de Arquivos que

usa o Protocolo de Transferencia de Arquivos - File Transfer Protocol (FTP)(KUROSE;

ROSS, 2010).

2.2 Camadas de rede

A Internet e um conjunto de redes. Para que essas redes possam se conectar, um mo-

delo precisou ser adotado, o TCP/IP. Ele descreve uma arquitetura formada por protoco-

los divididos em 5 camadas: Aplicacao, Transporte, Rede, Enlace de Dados e Fısica. Essa

divisao tem o objetivo de organiza-los segundo suas responsabilidades. A Figura 2 exibe

essas camadas bem como alguns exemplos dos protocolos contidos em cada uma(KUROSE;

ROSS, 2010).

Cada camada tem uma responsabilidade bem definida dentro do modelo TCP/IP. A

camada de aplicacao da a possibilidade de uma pessoa ou um software acessar os recursos

de rede. A camada de Transporte garante que as mensagens entre processos acontecam

e prove a recuperacao de erros. A camada de rede envia os pacotes da origem ao destino

fornecendo ligacao entre rede. E a camada Enlace de Dados ordena os bits em Frames2

entregando os Frames de um equipamento ao outro (no a no). A camada Fısica trata de,

apenas, sinais eletromagneticos e prove especificacoes mecanicas e eletricas(TANENBAUM,

2”Frame: Grupo de bits que representam um bloco de dados(FOROUZAN; FEGAN et al., 2008, p. 1083)”

2.3 O modelo cliente servidor 20

Figura 2: Modelo TCP/IP

2010). Percebe-se que devido a essas definicoes os diversos projetistas de rede podem

focar em uma determinada camada e criar seus produtos para que a interconexao entre

redes seja possıvel (FOROUZAN; FEGAN et al., 2008).

2.3 O modelo cliente servidor

A aplicacao Web3 foi a responsavel por fazer a Internet se tornar tao popular e inte-

rativa como e nos dias atuais. Por isso e importante conhecer o modelo em que ela esta

baseada e alguns detalhes por dentro dessa aplicacao.

De 1970 a 1980 as aplicacoes de textos como correio eletronico, acesso a computado-

res remotos, transferencia de arquivo e bate-papo eram conhecidas no meio academico.

Porem, por volta da decada de 90 a aplicacao Web surgiu dando inıcio ao crescimento

exponencial da Internet fazendo com que ela se popularizasse efetivamente. Ela possibi-

litou aos usuarios a navegacao entre arquivos que contem referencias de ligacao (link) a

outros arquivos conhecidos como paginas web, possibilitando, alem do link entre paginas,

ter acesso a conteudos altamente interativos(KUROSE; ROSS, 2010).

A aplicacao Web esta baseada no modelo cliente/servidor. Nesse modelo o cliente

e um host que faz pedidos de informacao a outro host denominado servidor que, ao

inves de pedir, fica ativo, passivo, permanentemente esperando a solicitacao de uma in-

formacao qualquer para retornar uma resposta. A Figura 3 mostra um desenho desse

modelo(KUROSE; ROSS, 2010), onde e possıvel notar que o host e representado na forma

do computador que roda um programa Navegador e o servidor representado em uma torre.

3”Web: A WWW e um servico cliente servidor distribuıdo, no qual um cliente, usando um browser,pode acessar um servico hospedado em um servidor(FOROUZAN; FEGAN et al., 2008, p. 851)”


Figura 3: Modelo cliente/servidor

Um cliente ou servidor nada mais e que um programa de computador. Na web, quem

implementa o programa cliente sao os navegadores web, um exemplo pode ser citado, o

Google Chrome. O programa servidor sao os servidores web, por exemplo Apache Tomcat.

Dessa forma, quando um dado navegador web esta executando num computador local e

um servidor web esta executando em um computador remoto, o navegador pode vir a

fazer uma solicitacao de uma pagina web. Entao um par de processos e criado para que

a interacao entre cliente e servidor ocorra.

O protocolo HTTP determina como sera a estrutura das mensagens trocadas entre

cliente e servidor, dentro do escopo da aplicacao Web, e de que modo eles as trocam.

Inicialmente, quando um cliente quer enviar uma mensagem para um servidor, ou vice-

versa, o cliente usa o protocolo Transmission Control Protocol - Protocolo de Controle

de Transmissao (TCP) da camada de transporte, do modelo TCP/IP, pela interface

socket(KUROSE; ROSS, 2010). Um exemplo de uma mensagem de requisicao HTTP pode

ser vista na Tabela 1:

Nessa mensagem e possıvel observar o alto nıvel de abstracao. O primeiro campo

mostra o tipo de pedido, no caso GET e a versao do protocolo HTTP. O Host especifica

o hospedeiro no qual a pagina web reside. O campo Connection especifica o tipo de

conexao. Close especifica que apos enviar o objeto para o cliente a conexao sera fechada e


Tabela 1: Mensagem de requisicao HTTP

Tipo de pedido: GET / HTTP/1.1\r\n

Host: www.wavetech-st.com\r\n

Connection: keep-alive\r\n

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n

User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64)AppleWebKit/537.17 (KHTML,like Gecko)

Chrome/24.0.1312.52 Safari/537.17\r\n

Accept-language: pt-BR,pt;q=0.8,en-US;q=0.6,en;q=0.4\r\n

Keep-Alive a conexao permanece aberta por um certo tempo. O campo Accept especifica

o tipo de dados que serao aceitos. O campo User-agent o tipo de agente usuario, no caso

o tipo do navegador web. E o campo Accept-language e um dos muitos tipos de cabecalho

de negociacao que pode surgir(KUROSE; ROSS, 2010).

No modelo cliente-servidor, para toda requisicao existe uma resposta. Abaixo, na

Tabela 2, esta um exemplo de uma mensagem de resposta HTTP do servidor.

Tabela 2: Mensagem de resposta HTTP

HTTP/1.1 200 OK\r\nDate: Mon, 21 Jan 2013 23:23:46 GMT\r\nServer: Apache\r\nLast-modified: Thu, 29 Nov 2012 13:28:41 GMT\r\nContent-length: 83\r\nConnection: Keep-Alive\r\nContent-type: text/html\r\n

Nesse exemplo o campo Connection segue a mesma explicacao do exemplo de men-

sagem de requisicao HTTP. O campo date especifica a data, seguido da hora, em que

o servidor enviou a resposta. O campo Server mostra o nome do servidor que criou a

mensagem. O campo Last-modified especifica a data e a hora em que o objeto foi criado

ou modificado pela ultima vez. O campo Content-length indica a quantidade de bytes

que tem o objeto que esta sendo enviado. O campo Content-type mostra que o objeto

2.4 HTML 23

que esta sendo enviado e um tipo de texto em formato de arquivo html. A mensagem

”200 OK ”significa que o pedido foi bem sucedido e a informacao esta sendo entregue com

mensagem de resposta. (KUROSE; ROSS, 2010).

2.4 HTML

Linguagem de Marcacao de Hipertexto - HyperText Markup Language (HTML) foi

criada por Tim Berners-Lee para o desenvolvimento de paginas Web. Paginas web sao

hipertextos, ou seja, documentos que podem estar ligados entre si. Na pratica, quando

um usuario acessa uma pagina web por um navegador ele pode sair desse documento e ir

para outro, atraves de uma marcacao HTML denominada Link e da mesma forma voltar

para o documento anterior.(W3C, 2013b, 2013a).

A partir de 1997 o HTML se tornou um padrao. O orgao responsavel por esse padrao

e o Consorcio Rede Mundial de Computadores - World Wide Web Consortium (W3C).

Esse Grupo e liderado por Tim Berners-Lee(W3C, 2013b).

O padrao HTML tem por objetivo especificar uma forma de distribuir informacao

globalmente. Para que isso seja conseguido uma linguagem deve ser entendida por diversos

meios de acesso(W3C, 2013b).

2.5 PaaS OpenShift

Na plataforma OpenShift os desenvolvedores de aplicativos podem construir, testar,

implantar e executar seus softwares. OpenShift e uma plataforma de computacao em

nuvem da Red Hat baseada no modelo Plataforma como Servico - Platform as a Ser-

vice (PaaS). Ela cuida de toda a infra-estrutura, middleware4 e gerenciamento de rede

permitindo que os desenvolvedores se concentrem apenas na criacao de seus aplicativos.

E suporta a implantacao de softwares escritos em diversas linguagens como Java, Ruby,

PHP, Perl e Node.js(OPENSHIFT, 2013).

Outra caracterıstica da plataforma OpenShift e que ela gerencia o volume de conexoes

feito aos aplicativos implantados. Ela faz escalonamento automatico ou manual dos re-

cursos que apoiam as aplicacoes de modo que, a medida que varia o uso, o desempenho

nao e prejudicado.

4Middleware: Mediador entre software e demais aplicacoes

2.6 Banco de dados 24

Na Figura 4, na parte superior, da esquerda para direita e possıvel notar tres etapas.

Cada etapa mostra multiplos dispositivos acessando um mesmo programa web que esta

representado pela figura do foguete. Percebe-se que em cada etapa ocorre uma variacao de

pedidos direcionados ao programa web por parte dos dispositivos. Nota-se tambem que o

sistema web esta implantado na plataforma OpenShift que e representado pela figura cir-

cular estilizada. Conforme varia a demanda a plataforma faz o escalonamento automatico

dos recursos. Isso e percebido nas figuras das torres que tambem estao divididas em tres

etapas da esquerda para a direita.

Figura 4: Escalonamento automatico dos recursos. Fonte: (OPENSHIFT, 2013)

O escalonamento automatico e conseguido com a adicao de instancias dos aplicativos

implantados. Apesar desse benefıcio, o desenvolvedor pode nao querer que isso ocorra

automaticamente, entao ele pode escolher por fazer isso manualmente(OPENSHIFT, 2013).

2.6 Banco de dados

Banco de dados e um conjunto de dados que se relacionam. Dados sao informacoes

que podem ser registradas e tem algum significado.(ELMASRI et al., 2011)

2.7 Frameworks 25

Os dados no banco de dados provem de alguma fonte. Ele se relaciona com aconteci-

mentos do mundo real. Dessa forma para que o banco de dados seja preciso e confiavel, e

necessario que seja flexıvel no sentido de refletir as mudancas ocorridas no mundo real (EL-

MASRI et al., 2011)

Sistema de Gerenciamente de Banco de Dados (SGBD) e um grupo de programas que

permite a interacao com o banco de dados. O SGBD e um sistema de software que torna

facil o processo de definicao, construcao, manipulacao e compartilhamento de banco de

dados entre aplicacoes e multiplos usuarios.(ELMASRI et al., 2011)

2.7 Frameworks

Framewoks sao conjuntos de codigos pre-escritos de aplicacoes basicas distribuıdos

com o objetivo de evitar a necessidade de recriar funcoes livremente difundidas.(LARMAN,

2008).

Por exemplo, no Servidor de Faces Java - Java Server Faces (JSF) os desenvolvedores,

podem adicionar dispositivos especializados, estabelecendo subclasses das classes sobre-

pondo certos metodos. Os desenvolvedores tambem podem se conectar a varios compor-

tamentos de resposta a eventos por meio de classes de dispositivos predefinidos(LARMAN,

2008; BURNS; KITAIN, 2009).

2.7.1 JSF

JSF e um framework para desenvolvimento de sistemas web em Java. Ele e baseado

em um padrao de projeto conhecido como Modelo-Visualizacao-Controle - Model-View-

Controller (MVC) que divide a abstracao de um sistema em tres partes: Modelo, Visua-

lizacao e Controle. A abstracao Modelo sao entidades que podem interagir com o banco

de dados, bem como a Visualizacao e responsavel por desenhar componentes e fornecer

interface de interacao com os usuarios. O Controle sao entidades que mantem toda a

logica do sistema. As abstracoes Modelo e Controle podem ser implementadas em classes

de objetos Java. A implementacao do controle no JSF e denominado de ManagedBean e

o Modelo de Entity. As principais tarefas dos ManagedBeans sao:

• Fornecer dados que serao exibidos nas telas.

• Receber os dados enviados nas requisicoes.

2.7 Frameworks 26

• Executar tarefas de acordo com as acoes dos usuarios.

E a responsabilidade das Entitys e:

• Mapear objetos que representam as entidades do banco de dados.

A abstracao Visualizacao e implementada em arquivos com extensao xhtml. Nesses

arquivos podem ser inseridas diretivas HTML e de componentes JSF. As diretivas HTML

sao usadas apenas para desenhar componentes, enquanto as diretivas JSF, alem de ter

essa mesma funcao, permitem passar informacoes para os ManagedBeans.(BURNS; KITAIN,

2009; GONCALVES, 2007).

A estrutura basica de uma pagina da camada de visualizacao e mostra na Figura 5.

Todas as paginas da camada de visualizacao deve ter as declaracoes mostradas nas linhas

1, 2, 3, e 14. A primeira linha define que as paginas poderao utilizar a tecnologia HTML5.

As 2 e a 14 definem que essa pagina e uma estrutura HTML. As 3, 4 e 5 definem que

sera utilizado os recursos do JSF.

A linha 11 mostra o uso de um componente HTML do JSF, o qual exibe no cliente

web a mensagem colocada dentro das aspas do atributo value.

1 <!DOCTYPE html>

2 <html

3 xmlns="http://www.w3.org/1999/xhtml"

4 xmlns:h="http://java.sun.com/jsf/html"

5 xmlns:f="http://java.sun.com/jsf/core">

6

7 <h:head></h:head>

8

9 <h:body>

10

11 <h:outputText value="Hello world." />

12

13 </h:body>

14 </html>

Figura 5: Pagina basica da camada de visualizacao

2.7.2 Hibernate

O Hibernate e um framework utilizado para facilitar a criacao de entidades de banco de

dados, atraves da implementacao de mecanismos convenientes para consulta e recuperacao

2.7 Frameworks 27

de dados, eliminando a necessidade de o desenvolvedor ter que executar a manipulacao

manualmente atraves de um SGBD.

O Hibernate esta fundamentado sob a tecnica Mapeamento Objeto-Relacional - Object-

Relational Mapping (ORM), que permite fazer mapeamentos entre objetos relacionais e

entidades de banco de dados a fim de abstrair classes em uma linguagem orientada a

objetos para representarem as tabelas de um banco de dados. Essa tecnica foi criada para

eliminar a necessidade da criacao de codigos da Linguagem de Consulta Estruturada -

Structured Query Language (SQL) para a geracao das bases de dados. Alem disso, com

o ORM e possıvel criar uma ponte entre o Modelo Relacional e o Modelo Orientado a

Objetos. Na Figura 6 pode-se observar um exemplo de um caso real de uma classe Java

que foi mapeada para uma tabela do SGBD MySQL(HAT, 2013; MEHTA, 2008).

Figura 6: Mapeamento objeto relacional para entidades de banco de dados

O Hibernate permite que se desenvolvam classes persistentes seguindo os pilares da

orientacao a objetos como heranca, polimorfismo, etc(KING et al., 2013).

2.7.3 Spring Security

O Spring Security e um framework que pode ser utilizado para a configuracao da

estrategia de autenticacao e autorizacao em um dado sistema de software.

A seguranca e sem duvida um dos componentes mais importantes da arquitetura de

qualquer aplicacao baseada na web. Cada vez mais programas maliciosos, criminosos, e

funcionarios desonestos surgem na tentativa de obter informacoes privadas. Entao o uso

inteligente e abrangente da seguranca e um elemento chave para qualquer projeto(ALEX;

TAYLOR, 2013).

Spring Security foi desenvolvido para preencher uma lacuna no universo das biblio-

tecas Java. Padroes de seguraca do Java ou Seguranca da plataforma Java EE oferecem

2.7 Frameworks 28

algumas formas de executar autenticacao e funcoes de autorizacao, mas o Spring Security

e o melhor para essas tarefas porque empacota toda a parte de logica de seguranca de

um sistema em desenvolvimento de uma forma clara e concisa(ALEX; TAYLOR, 2013). O

Spring Security se baseia em dois conceitos:

• Autenticacao - a autenticacao e o processo de verificacao de que os usuarios de uma

dada aplicacao sao quem dizem que sao(MULARIEN, 2010).

• Autorizacao - Autorizacao envolve tipicamente dois aspectos distintos que se com-

binam para descrever a acessibilidade de um sistema protegido. A primeira e o

mapeamento de um tipo de autenticacao a uma ou mais entidades (muitas vezes

chamado de papeis). Por exemplo, um usuario casual de um site pode ser visto como

tendo autoridade visitante, enquanto um administrador de site pode ser atribuıdo

pela autoridade administrativa. A segunda e a atribuicao de permissao de uso de

determinados recursos protegidos do sistema. Isso geralmente e feito no momento

em que um sistema e desenvolvido, atraves de declaracao expressa em codigo ou

atraves de parametros de configuracao (MULARIEN, 2010).

2.7.4 Prime Faces

Primefaces e uma biblioteca de recursos baseado na especificacao JSF. Existem,

atualmente, mais de 90 componentes que podem ser utilizados em aplicacoes Java Web.

Outras bibliotecas disponıveis como Richfaces e Icefaces sao menos completas. Alguns

componentes do Primefaces merecem destaque(VARAKSIN; CALISKAN, 2013):

Captcha – Recurso muito utilizado atualmente em paginas web. Fornece uma imagem

com um texto embaralhado e solicita que o usuario digite o texto exibido na imagem

para poder prosseguir. Isso evita que programas acessem determinados conteudos do

site(VARAKSIN; CALISKAN, 2013).

Draggable – Permite que qualquer componente Primefaces seja arrastavel. Aceita

configuracoes para que a acao de arrastar aconteca somente na vertical ou horizontal,

alinhada a uma grade, e delimitada por uma area, entre outras, etc.

Editor – Cria um editor rico de texto, semelhante aos que existem na maioria dos

webmails atuais. Permite a configuracao de tipo de fonte, cor e tamanho, alinhamento,

inclusao de imagens e links, entre outros.

FileUpload – Permite a inclusao do recurso de carregamento nas paginas de uma

2.8 Maven 29

maneira muito simples. Inclui upload basico, de multiplos arquivos e barra de progresso

de upload, entre outros(VARAKSIN; CALISKAN, 2013).

Google Maps – Exibe os mapas do Google Maps com varios dos recursos da API

do Google e funcionalidades Ajax. Inclui polıgonos, controles, marcadores e Street-

View(VARAKSIN; CALISKAN, 2013).

ImageSwitch – E um visualizador de imagens do tipo slide show. Permite aplicar

diversos efeitos para a transicao das imagens(VARAKSIN; CALISKAN, 2013).

Layout – Permite criar layouts elaborados com espacos que possam ser redimensiona-

dos, contraıdos, minimizados e fechados.

ProgressBar – Cria uma barra de progresso que pode ser controlada por cliente-side

ou server-side. Aceita diversas formas de apresentacao e animacao(VARAKSIN; CALISKAN,

2013).

Tree – Exibe um componente que mostra dados em formato de arvore. Tem eventos

configuraveis e animacoes para a manipulacao dos nos da arvore(VARAKSIN; CALISKAN,

2013).

2.8 Maven

Maven e uma ferramenta para gerenciamento, construcao e implantacao de projetos.

Ele auxilia o desenvolvedor no processo de gerenciamento de dependencias, geracao de

relatorios e documentacao(CASEY et al., 2006).

A unidade basica de configuracao do Maven e um arquivo chamado Projeto Modelo

de Objeto - Project Object Model (POM). Esse arquivo deve ficar na raiz do projeto.

A estrutura, dependencias e caracterısticas do projeto sao declaradas nesse arquivo. O

menor arquivo pom.xml valido pode ser visto na Figura 7

A identificacao do projeto consiste em tres informacoes:

• groupId: um identificador da empresa. Grupo ao qual o projeto pertence. Geral-

mente o nome do site da empresa.

• artifactId: o nome do projeto.

• version: a versao atual do projeto.

2.9 IDE Eclipse 30

1 <project>

2

3 <modelVersion>4.0.0</modelVersion>

4 <groupId>fretum</groupId>

5 <atifactId>fretum</artifactId>

6 <packaging>war</packaging>

7 <version>1.0</version>

8

9 </project>

Figura 7: Configuracao basica do Maven

Existem outras informacoes que normalmente sao acrescentadas no arquivo POM.

Uma das mais importantes sao as definicoes das dependencias, pois em projetos que nao

tem o auxılio da ferramenta Maven o desenvolvedor tem que procurar na Internet, nor-

malmente nos sites dos fabricantes, as dependencias de APIs, bibliotecas ou frameworks

que sao usadas nos projetos. Apos encontrar as dependencias desejadas o desenvolvedor

ainda tem que saber como configurara-las no projeto. No entanto com a ferramenta Ma-

ven isso nao e necessario, pois bastam especificar no arquivo POM as dependencias que

sao necessarias. A Figura 8 mostra um exemplo de uma dependencia, no caso o framework

JSF, que o Maven ira carregar e configurar no projeto(CASEY et al., 2006).

1 <dependencies>

2

3 <dependency>

4

5 <groupId>javax.faces</groupId>

6 <artifactId>jsf-api</artifactId>

7 <version>2.0</version>

8

9 </dependency>

10

11 </dependencies>

Figura 8: Injecao de dependencia

2.9 IDE Eclipse

A Plataforma Integrada de Desenvolvimento - Integrated Development Environment

(IDE) Eclipse e um ambiente de desenvolvimento de software extensıvel que suporta diver-

sas linguagens de programacao. Desenvolvedores podem criar programas que se acoplem

ao Eclipse para resolver algum problema especıfico. Esses programas sao conhecidos como

plugins, e podem dar suporte as linguagens de programacao (BUDINSKY, 2004).

2.9 IDE Eclipse 31

Em 2001 integrantes da industria da Borland, IBM, MERANT, QNX Software Sys-

tems, Rational Software, Red Hat, SuSE, TogetherSoft e WebGain uniram-se em um

conselho. No final de 2003 ele havia crescido para mais de 80 membros. E em 2004

foi anunciado por esse conselho a reorganizacao da Eclipse em uma corporacao sem fins

lucrativos. Originalmente esse consorcio se formou quando a IBM lancou a plataforma

de codigo aberto Eclipse que, posteriormente se tornou um orgao independente, tambem,

denominado Eclipse com o objetivo de conduzir a evolucao da plataforma para benefi-

ciar fornecedores de ofertas de desenvolvimento de software e usuario finais. A Eclipse,

ainda, disponibiliza toda tecnologia e codigo fonte da plataforma gratuitamente atraves

da licenca publica Eclipse(ECLIPSE, 2013).

32

3 Desenvolvimento

3.1 Introducao

Fretum e um sistema web de armazenamento de arquivos. Ele tem um numero de

diretorios pre-definidos. Por razao de serem 3 empresas envolvidas o numero de diretorios

e o mesmo. E permitido que qualquer usuario possa carregar os arquivos contidos neles.

No entanto o administrador do sistema pode definir quais usuarios tem privilegios de

envio em cada diretorio. Os usuarios so podem apagar os arquivos nos locais onde eles

tem permissao de envio. O sistema tem uma area administrativa a qual e visıvel somente

para administradores. Nessa area e possıvel visualizar em uma lista todos os usuarios a

qual permite:

• Dar ou tirar privilegios de envio de arquivos.

• Definir poder de administrador para os usuarios.

• Ativar ou desativar os usuarios do sistema.

• Apagar usuarios.

• Editar cadastros de usuarios.

Na area administrativa e possıvel tambem cadastrar usuarios e visualizar em uma lista

interativa de registros as interacoes de cada usuario com cada arquivo. Por exemplo, se

um dado usuario enviou um arquivo para uma dada regiao, na lista de registros estarao,

as informacoes de data, hora, nome de quem enviou, e o tipo de interacao realizada pelo

usuario em questao. A lista de registro e interativa no sentido de que permite que o

usuario possa filtrar os resultados conforme desejado.

3.2 Domınio do problema 33

3.2 Domınio do problema

Neste topico sera apresentado o domınio do problema, o qual e definido por um

conjunto de caracterısticas que descrevem uma famılia de problemas para os quais a

aplicacao deste trabalho deu a solucao. Esta analise trata apenas do problema que foi

resolvido pelo sistema. Dessa forma nao sera explorada com detalhes cada classe que o

compoe. A analise mais detalhada do modelo de classes e descrito na secao 3.5.

A classe conceitual Usuario esta relacionada com outras 3: Arquivo, Administrador

e Log. Usuario e interessado em enviar, carregar ou remover arquivos. Quando esses

interesses sao colocados em pratica o modelo conceitual Log mantem as informacoes de

cada acao. O Usuario pode ou nao ser um Administrador. No diagrama 9 observa-se no

domınio do problema que:

• e possıvel existir muitos Usuario ou nenhum;

• Usuario exclui, carrega (download) ou envia (upload) Arquivo;

• se ha Usuario ele pode ser Administrador;

• Usuario registra acoes na classe conceitual Log.

A classe conceitual Arquivo esta relacionada com outras 4: Usuario, Administrador,

Log e Regiao. Arquivo e interessado em estar armazenado em um local (Regiao). Quando

as classes conceituais Usuario e Administrador excluem, carregam ou enviam Arquivo essas

acoes sao registradas na classe conceitual Log inerente ao Arquivo. Observa-se no diagrama

9 que:

• e possıvel existir muitos Arquivo ou nenhum;

• Arquivo, quando existe, ele pertence a uma Regiao.

A classe conceitual Regiao esta relacionada com Arquivo, sendo que deve existir pelo

menos uma Regiao. Ela e responsavel por ter a informacao do local onde os arquivos

devem estar fisicamente.

A classe conceitual Administrador esta relacionada com outras 3: Usuario, Arquivo

e Log. Deve existir ao menos um Administrador. O Administrador e um Usuario com

privilegios especiais, ele gerencia privilegios e cadastra Usuario.

3.3 Requisitos funcionais 34

Figura 9: Domınio do problema

3.3 Requisitos funcionais

Requisitos funcionais sao as definicoes das funcoes do sistema deste trabalho, bem

como seus componentes. Neste topico sera apresentado essas definicoes sob a forma de

casos de uso. Sera mostrado os atores do sistema bem como uma descricao textual de

cada caso de uso seguido de uma ilustracao em diagrama.

3.3.1 Identificacao dos atores do sistema

Ator pode ser um humano ou entidade maquina que interage com o sistema para

executar um trabalho.

3.3.1.1 Usuario

O Usuario e uma pessoa que acessa o sistema por meio de conta de usuario. Ele

carrega, envia ou apaga arquivos.

3.3.1.2 Administrador

O Administrador e um Usuario com privilegios especiais, pois ele tambem tem acesso

a area administrativa.


3.3.2 Limites do sistema

Limites do sistema ou applets sao agregadores de casos de uso.

3.3.2.1 Applet Area Administrativa

A Applet Area Administrativa e um agente que permite listar, cadastrar, editar, apa-

gar, ativar ou desativar usuarios do sistema. E permitido ainda dar ou tirar privilegios,

que sao: poder de administrador e envio de arquivos em cada regiao (diretorios de ar-

mazenamento de arquivos do sistema). Possibilita visualizar registros de interacao de

cada usuario com cada arquivo do tipo data, hora, nome do arquivo e tipo de registro

(recebimento, envio ou exclusao). Tanto a listagem de usuarios quanto a de registros sao

interativas, pois permitem filtrar as informacoes exibidas.

3.3.2.2 Applet Regiao

A Applet Regiao e um agente que representa um diretorio do sistema. E permitido a

qualquer usuario listar ou carregar arquivos, no entanto apagar ou enviar so e autorizado

aos usuarios que tem privilegios para tanto.

3.3.3 Principais casos de utilizacao

Caso de uso CDU1: Operacoes com arquivo

Escopo: Aplicacao Fretum

Nıvel: Objetivo do usuario

Ator Principal: Usuario

Interessados e interesses:

– Usuario: deseja ter acesso as regioes. Nas regioes que tiver permissao deseja enviar

arquivos para elas. Nas regioes que tiver permissao deseja apagar, se necessario, os arqui-

vos. Deseja ter acesso a todas as regioes para trazer os arquivos para o seu computador.

Deseja entrar nas regioes e, imediatamente, visualizar uma lista com todos os arquivos.

– Administrador: deseja fazer todas as operacoes de usuario.


Pre-Condicoes: Usuario esta ativado para acesso ao sistema. Usuario esta autenti-

cado no sistema.

Cenarios de Sucesso - Enviar Arquivo:

1. Usuario digita a Uniform Resource Locator (URL) do software em seu navegador

web e envia o pedido para o servidor remoto.

2. O servidor remoto devolve o pedido para o navegador web, o navegador exibe duas

caixas de textos e um botao para que o usuario possa digitar nelas o login e senha

e enviar seu pedido de autenticacao.

3. O servidor confirma o pedido de autenticacao e autoriza a entrada do usuario no

sistema.

4. O usuario entra em uma regiao.

5. Imediatamente e exibido uma lista com todos os arquivos do sistema

6. O usuario escolhe um arquivo do seu computador para enviar para a regiao.

7. O usuario envia o arquivo para a regiao.

8. E feito o registro da acao descrito no item anterior.

9. O arquivo esta na regiao.

10. Imediatamente a lista de arquivos e atualizada.

11. O arquivo e exibido na lista de arquivos.

Cenarios de Sucesso - Trazer arquivo para o computador:

1. Idem “Cenarios de Sucesso - Envio de Arquivo” do 1 ao 5.

2. O usuario seleciona um arquivo da lista de arquivos.

3. O usuario escolhe um local do seu computador.

4. O usuario confirma o armazenamento do arquivo no local escolhido.


6. O arquivo esta escrito (salvo) no local escolhido.


Cenarios de Sucesso – Excluir arquivo:

1. Idem “Cenarios de Sucesso - Envio de Arquivo” do 1 ao 4.

2. O usuario escolhe um arquivo da lista de arquivos.

3. O usuario exclui o arquivo.


5. O arquivo esta excluıdo do sistema.

6. Imediatamente a lista de arquivos e atualizada.

7. O arquivo nao e exibido na lista de arquivos.

Figura 10: Diagrama de Caso de Uso (DCDU) da Regiao

Caso de uso CDU2: Area administrativa

Escopo: Aplicacao Fretum

Nıvel: Objetivo do usuario administrador

Ator Principal: Administrador


Interessado e interesse:

– Administrador: deseja cadastrar usuarios. Deseja excluir usuarios quando necessario.

Deseja ativar ou desativar a possibilidade dos usuarios de autenticar-se no sistema. Deseja

dar ou tirar a permissao dos usuarios de enviar arquivos para as regioes. Deseja dar ou

tirar a permissao de administrador dos usuarios. Deseja entrar na area administrativa e

visualizar, imediatamente, uma lista com todos os usuarios. Deseja visualizar uma lista

com o historico (log) das operacoes dos usuarios com os arquivos, sendo que esse historico

contempla dias, horarios, usuarios e regioes que eles, usuarios, enviaram, trouxeram ou

excluıram os arquivos. Deseja imprimir o historico das operacoes dos usuarios com os

arquivos, sendo que esse historico contempla dias, horarios, usuarios e regioes que eles,

usuarios, enviaram, trouxeram ou excluıram os arquivos.

Pre-Condicoes: Usuario esta ativado para acesso ao sistema. Usuario esta autenti-

cado. Usuario tem permissao de administrador.

Cenarios de Sucesso – Cadastrar usuario:

1. Usuario digita a URL do software em seu navegador web e envia o pedido para o

servidor remoto.

2. O servidor remoto devolve o pedido para o navegador web, o navegador exibe duas

caixas de textos e um botao para que o usuario possa digitar nelas o login e senha

e enviar seu pedido de autenticacao.

3. O servidor confirma o pedido de autenticacao, o usuario tem permissao de adminis-

trador, e autoriza a entrada do administrador no sistema.

4. O administrador entra na area administrativa.

5. Imediatamente e exibido uma lista com todos os usuarios do sistema.

6. O administrador entra na area de cadastro.

7. O administrador insere as informacoes do novo usuario e confirma o cadastro.

8. O Usuario esta cadastrado no sistema.

Cenarios de Sucesso – Excluir usuario:


1. Idem “Cenarios de Sucesso – Cadastro de usuario” do 1 ao 5.

2. O administrador escolhe um usuario da lista de usuarios.

3. O administrador exclui o usuario.

4. O usuario esta excluıdo do sistema.

5. Imediatamente a lista de usuarios e atualizada.

6. O usuario nao e exibido na lista de usuarios.

Cenarios de Sucesso – Ativar ou desativar o acesso do usuario no sistema:



3. O administrador ativa ou desativa o acesso do usuario no sistema.

4. O usuario esta com ou sem acesso ao sistema.


6. O usuario e exibido na lista de usuarios com o seu estado ativado ou desativado

para acesso no sistema.

Cenarios de Sucesso – Dar ou tirar a permissao do usuario de enviar arquivos

para a regiao:



3. O administrador escolhe uma ou mais regioes para dar ou tirar a permissao do

usuario de enviar arquivos para elas.

4. O administrador da ou tira a permissao do usuario de enviar arquivos para uma ou

mais regioes.

5. O usuario nao tem mais permissao para enviar arquivos para as regioes em que ele

nao tem permissao.



7. O usuario e exibido na lista de usuarios sem permissao de enviar arquivos para as

regioes em que ele nao tem permissao.

Cenarios de Sucesso – Dar ou tirar a permissao de administrador do usuario:



3. O administrador da ou tira a permissao de administrador do usuario.

4. O usuario esta ou nao com permissao de administrador.


6. O usuario e exibido na lista de usuarios sem permissao de administrador.

Cenarios de Sucesso – Visualizar o historico das operacoes dos usuarios com

os arquivos:


2. Entra na area de historico das operacoes dos usuarios com os arquivos.

3. Imediatamente e exibido uma lista das operacoes dos usuarios com os arquivos.

Cenarios de Sucesso – Imprimir o historico das operacoes dos usuarios com os

arquivos:


2. Entra na area de historico das operacoes dos usuarios com os arquivos.

3. Imediatamente e exibido uma lista das operacoes dos usuarios com os arquivos.

4. O administrador requisita a impressao da lista das operacoes dos usuarios com os

arquivos.

5. Um Portable Document Format (PDF) e exibido com a opcao de impressao.

6. O administrador imprime a lista das operacoes dos usuarios com os arquivos.

7. O historico e impresso.

3.4 Modelo de Dados 41

Figura 11: DCDU da Area Administrativa

3.4 Modelo de Dados

O modelo de dados representa como os dados estao organizados no banco de dados.

Essa organizacao se da atraves de entidades as quais se relacionam. A finalidade des-

ses relacionamentos sao para evitar informacoes redundantes no banco de dados. Dessa

forma, para o sistema desse trabalho, os dados serao organizados segundo a abstracao

de entidades mostrada na Figura 12. E importante observar que os atributos de cada

entidade segue o padrao: nome do atributo em minusculo seguido do nome da entidade

em maiusculo, como exemplo nomeUsuario .

A entidade usuario guarda dados dos usuarios. Para esse sistema, e relevante o armaze-

namento das informacoes do nome (nomeUsuario), senha (senhaUsuario), login (loginUsuario),

empresa (empresaUsuario), email (emailUsuario) e celular(celularUsuario) dos usuarios, alem

do atributo ativo (ativoUsuario) que armazena a informacao se um dado usuario pode ou


nao acessar o sistema.

E importante perceber que esse sistema permite qualificar usuarios como comuns e

administradores. Para tanto e necessario guardar as informacoes referentes aos privilegios

dos usuarios, as quais sao armazenadas na entidade permissaousuario no atributo permissao.

Ela permite ainda armazenar as informacoes referentes aos privilegios de envio de arquivos

de cada usuario. Dessa forma para armazenar os dados dos privilegios dos usuarios foi

abstraıdo o relacionamento um para muitos entre as entidades usuario e permissaousuario.

Uma caracterıstica do sistema deste trabalho e o registro da data e hora do envio,

carregamento ou exclusao de arquivos de cada usuario. Para tanto foi abstraıdo a entidade

registro que permite armazenar os dados da data e hora em que cada usuario gerenciou um

determinado arquivo apagando-o, excluindo-o ou carregando-o. Esses dados sao armaze-

nados nos atributo dataRegistro e tipoDoRegistro. Sendo que esse ultimo e a informacao

sobre exclusao, envio ou carregamento de arquivos. Dessa forma para que seja possıvel

o armazenamento dos dados dos usuarios e dos arquivos foi abstraıdo o relacionamento

muitos para um entre as entidades registro e usuario, e muitos para um entre as entidades

registro e arquivos.

A entidade arquivo e responsavel por armazenar as informacoes referentes ao nome do

arquivo (nomeArquivo) e a situacao do arquivo (situacaoDoArquivo). Esse ultimo atributo

e relevante para que o sistema possa determinar o caso de um arquivo ser excluıdo de um

determinado diretorio de modo que o mesmo permaneca registrado na entidade registro,

pois quando um dado usuario exclui um arquivo de um dado diretorio e necessaria uma

referencia desse arquivo para a entidade registro para que ela possa manter a informacao

de que um dia o arquivo existiu, mas que foi excluıdo do sistema.

A entidade local mantem o dado a respeito do caminho em que um determinado

arquivo esta. Para tanto foi abstraıdo o relacionamento um para muitos entre a entidade

local e a entidade arquivo.

A entidade modelutil e responsavel por manter dados util ao sistema, como exemplo

o caminho raiz dos diretorios.

Para a modelagem foi utilizado o software MySQL Workbanch da Oracle.


arquivo

codigoArquivo INT(11)

nomeArquivo VARCHAR(260)

situacaoDoArquivo VARCHAR(30)

localArquivo_codigoLocal INT(11)

Indexes

local

codigoLocal INT(11)

arquivoLocal VARCHAR(255)

Indexes

modelutil

codigoModelUtil INT(11)

propriedadeModelUtil VARCHAR(255)

Indexes

permissaousuario

usuario INT(11)

permissao VARCHAR(50)

Indexes

registro

codigoRegistro INT(11)

dataRegistro DATETIME

tipoDoRegistro VARCHAR(8)

arquivoRegistro_codigoArquivo INT(11)

usuarioRegistro_codigoUsuario INT(11)

Indexes

usuario

codigoUsuario INT(11)

ativoUsuario TINYINT(1)

celularUsuario VARCHAR(16)

emailUsuario VARCHAR(100)

empresaUsuario VARCHAR(50)

loginUsuario VARCHAR(15)

nomeUsuario VARCHAR(30)

senhaUsuario VARCHAR(12)

Indexes

Figura 12: Modelo de Dados

3.5 Modelo de classes 44

3.5 Modelo de classes

A modelagem desse sistema foi feita em camadas de forma que cada classe tem sua

responsabilidade bem definida. Para tanto o padrao de projeto MVC foi implementado.

Ele determina que um sistema seja separado em camadas de visualizacao, controle e

modelo visando como essas camadas devem interagir. Nesse padrao a camada modelo

nao pode conhecer a camada de visualizacao, bem como a camada de visualizacao nao

pode conhecer a camada modelo, sendo que a camada de controle e responsavel pela

comunicacao entre elas.

A camada de visualizacao e responsavel por exibir e coletar informacoes dos usuarios.

Nesse sistema a camada de visualizacao e implementada usando o JSF que na pratica

e composto por arquivos X Hypertext Markup Language (XHTML), onde as telas sao

desenhadas.

A camada de controle que tambem e implementada usando JSF tem a responsabilidade

de processar as informacoes dos usuarios coletadas nas telas. Os arquivos que compoe essa

camada sao os Managed Beans.

A camada modelo e responsavel por manter toda a complexidade exigida nas operacoes

de acesso a dados. Para tanto essa camada foi divida em classes de regra de negocio e

acesso a dados.

Todas as classes do sistema estao organizadas em pacotes, dessa forma cada ilustracao

nos sub-topicos a seguir de modelo de classe sera mostrada no seu respectivo pacote. Sao

7 pacotes: arquivo, usuario, util, web, filter, web.filter, web.security e web.util, de modo

que cada um segue o padrao com.wavetech st.nomedopacote. O pacote web contem as

classes de objetos Managed Beans, web.filter tem as classes de objetos de filtro de sessao

do Hibernate e de filtro HTTP, web.security contem as classes de objetos responsaveis

por validar o login e o logout, web.util tem classes de objetos responsaveis por manter

informacoes do usuario logado e gerar o arquivo em PDF do relatorio, util contem as

classes de objetos responsaveis por criar a conexao com o banco de dados, e usuario e

arquivo contem as classes de objetos responsaveis por representar e controlar os usuarios

e os arquivos respectivamente.

Todas as figuras que serao mostradas a seguir pertinentes aos diagramas de classe e

de sequencia foram criados a partir do software Architexa.


3.5.1 ArquivoBean

O ArquivoBean e caracterizado por criar uma ponte entre a camada de controle e

visualizacao para processar informacoes referentes aos arquivos. Dessa forma ela possui

metodos para salvar, excluir, enviar, carregar e obter as listas filtradas e nao filtradas

de arquivos e registros. Por exemplo, quando uma tela e aberta e nela se observa uma

lista dos arquivos de uma dada regiao (diretorio do sistema) e porque antes essa lista foi

processada pelo metodo getListaArquivos() e devolvida para a visualizacao na tela.

Quando sao executadas as acoes de salvar, enviar e excluir o registro delas e feito. O

Registro e caracterizado pelo arquivo a ser registrado (arquivoRegistro), pela data do regis-

tro (dataRegistro), pelo usuario que fez alguma acao com um dado arquivo (usuarioRegistro)

e pelo tipo do registro (tipoDoRegistro). Esse ultimo e caracterizado por fornecer o tipo do

registro podendo ser de envio (UPLOAD), de recebimento (DOWNLOAD) ou de exclusao

(DELETE).

O Arquivo e caracterizado pelo local em que ele se encontra (localArquivo), por um

nome (nomeArquivo) e pela situacao do arquivo (situacaoDoArquivo). O Local e carac-

terizado por ter o caminho em que o arquivo se encontra (arquivoLocal). A Situaca-

oDoArquivo e caracterizada por fornecer a situacao do arquivo, podendo ser: existe

no local de destino (EXISTE NO LOCAL DE DESTINO) ou nao existe no local de des-

tino (NAO EXISTE NO LOCAL DE DESTINO). A SituacaoDoArquivo existe para resolver

o problema de inconsistencia no banco de dados, pois se houver a situacao em que um

arquivo e excluıdo do sistema pelo usuario o mesmo nao pode ser apagado do banco de

dados, ja que o Registro tem como uma das caracterısticas o Arquivo, no entanto quando a

situacao citada ocorrer e necessario manter a informacao de existencia ou nao existencia

do arquivo para que esse arquivo seja ou nao exibido em uma lista por exemplo.

E por ultimo o Usuario e caracterizado por nome, email, celular, empresa em que tra-

balha, login e senha para validar a entrada no sistema, permissao e ativo para estabelecer

se o usuario pode ou nao acessar o sistema.

O modelo de classe do ArquivoBean e mostrado na Figura 13.


Figura 13: Modelo de classe do ArquivoBean


3.5.2 UsuarioBean

O UsuarioBean e caracterizado por criar uma ponte entre a camada de controle e

visualizacao para processar informacoes referentes aos usuarios. Dessa forma ela possui

metodos para inserir, excluir, editar e listar usuarios no sistema. Atraves dessa classe e

possıvel tambem dar ou tirar poderes de administrador do sistema aos usuarios.

O ContextoBean e caracterizado por criar uma ponte entre a camada de controle e visu-

alizacao para manter informacoes referentes aos usuarios logados. O CAMINHO ARQUIVOS

mantem a informacao referente ao local raiz em que se pode armazenar os arquivos dos

usuarios. Outra caracterizacao do ContextoBean e o idiomas, informacao essa referente as

possıveis lınguas disponıveis para traducao das mensagens do sistema.

O Usuario e caracterizado pelo seu nome, email, empresa em que trabalha, numero de

celular, login e senha para acesso ao sistema. Outras caracterizacoes sao se ele esta ativado

ou nao para usar o sistema e permissoes (privilegios) como poderes de administrador e ou

de envio de arquivos em cada regiao (diretorios do sistema).

O modelo de classe do UsuarioBean e mostrado na Figura 14.


Figura 14: Modelo de classe do UsuarioBean


3.5.3 Regra de negocio

As regras de negocio sao responsaveis pelas tomadas de decisao. Elas acessam dire-

tamente as classes de acesso a dados, pois sao elas que decidem o que deve ser gravado

em banco de dados ou quais informacoes obter do banco de dados, no entanto elas apenas

decidem quais operacoes em banco de dados sao necessarias, e nao como faze-las. Dessa

forma quando a regra de negocio precisa fazer uma operacao em banco de dados como

listar, salvar, etc ela solicita a classe DAOFactory a criacao de uma classe de acesso a

dados.

DAOFactory obtem todas as configuracoes de banco de dados a partir da classe Hi-

bernateUtil. Com isso ela a DAOFactory consegue criar a classe de acesso a dados que

mantem um objeto de sessao de banco de dados.

Tanto as classes de regra de negocio quanto as de acesso a dados podem ser visualizadas

na Figura 15, sendo que as classes com o padrao ArquivoRN, LocalRN, etc sao as regras de

negocio e as com o padrao ArquivoDAOHibernate, LocalDAOHibernate, etc sao as classes

de acesso a dados. Observa-se que essas ultimas sao responsaveis por manter toda a

complexidade exigida nas operacoes em banco de dados. A principal vantagem dessa

abordagem e que as classes de regra de negocio nao precisam se preocupar em como fazer

uma conexao ao banco de dados ou como ler ou escrever nele, pois bastam solicitar que

as classes de acesso a dados facam a operacao.

E importante visualizar ainda na figura 15 a classe ConexaoHibernateFilter. Ela tem

uma particularidade a respeito das unidades de persistencia1 sobre o fato que elas devem

ser inicializadas antes de serem utilizadas, e finalizadas quando nao forem mais necessarias.

A inicializacao e a finalizacao de uma unidade de persistencia deve ser realizada apenas

uma vez durante a execucao da aplicacao.

Para implementar essa caracterıstica nesse sistema, ja que foi escrito em Java, pode-se

utilizar um filtro. Os filtros de um sistema Java Web sao inicializados automaticamente

depois que a aplicacao e implantada no servidor Java e antes da primeira requisicao HTTP.

Alem disso, eles sao finalizados ao termino da execucao da aplicacao. Para adicionar um

filtro em uma aplicacao web Java, e necessario criar uma classe que implemente a interface

javax.servlet.Filter.

Um filtro pode ser registrado no servidor Java atraves da anotacao @WebFilter. Com

1Unidade de Persistencia: E um arquivo que contem todas as configuracoes de conexao de umframework ORM, no caso desse sistema o Hibernate, com o banco de dados.


essa anotacao, pode-se definir qual servlet sera associada ao filtro. Na classe ConexaoHi-

bernateFilter foi associado a servlet Faces Servlet. O metodo init() e chamado automatica-

mente na inicializacao do filtro. Na classe ConexaoHibernateFilter, esse metodo inicializa a

unidade de persistencia. O metodo destroy() e chamado automaticamente para desativar

o filtro no encerramento da aplicacao.

Figura 15: Modelo de classe da regra de negocio

3.6 Diagramas de sequencia 51

3.6 Diagramas de sequencia

Neste topico sera abordado os diagramas de sequencia. O objetivo desta analise sera

mostrar as principais trocas de mensagens entre os objetos do sistema.

3.6.1 Regra de negocio

A definicao de regra de negocio foi abordada no topico 3.5.3. A Figura 16 mostra a

troca de mensagens entre o objeto de regra de negocio e os objetos que sao responsaveis

por criar a ponte entre o banco de dados e a regra de negocio. Existem no projeto 4

objetos de regras de negocio, sao eles: ArquivoRN, LocaRN, RegistroRN e ModelUtilRN. A

detalhamento a seguir refere-se as trocas de mensagens do objeto UsuariRN, no entanto o

mesmo e valido para os demais objetos de regra de negocio.

Nota-se que o processo de trocas de mensagens se inicia no construtor do objeto

UsuarioRN, o qual chama o metodo criarUsuarioDAO() do objeto DAOFactory. Esse ultimo

e responsavel por obter uma instancia de objeto UsuarioDAOHibernate, o qual permite

a interacao direta com o banco de dados. Em seguida o objeto UsuarioDAOHibernate e

colocado na sessao atraves do metodo setSession(). E importante entender que estar na

sessao significa estar disponıvel enquanto o usuario estiver logado.

Figura 16: Diagrama de sequencia Regra de Negocio Usuario


3.6.2 Novo usuario

Um novo usuario e criado a partir da applet Area Administrativa citada no topico

3.3.2.1. E importante perceber que as applets exibidas nas DCDUs englobam um conjunto

de interesses possıveis, no entanto elas nao mostram como esses interesses podem ser

colocados em pratica pelos atores. Contudo para cada applet existe uma tela ou formulario

onde e possıvel dispor esses interesses. Dessa forma a applet Area Administrativa possui

uma tela que e construıda a partir do arquivo cadastroUsuarios.xhtml. Esse ultimo contem

um formulario de cadastro de usuarios que fica vinculado ao objeto UsuarioBean.

A Figura 17 mostra as mensagens trocadas entre objetos apos um dado usuario ad-

ministrador preencher o formulario e clicar o botao salvar da tela cadastro de usuarios.

Nessa ilustracao as linhas de vida com metodos, representados pelas caixas em vermelho,

sao criadas por objetos da plataforma Java e as em azul sao do projeto que e mencionado

nesse trabalho. Ainda na figura, em amarelo, nota-se as classes envolvidas no processo de

troca de mensagens. Percebe-se que no inıcio do processo de criacao de um novo usuario

o metodo salvar e acionado. Inicialmente ele obtem uma instancia do Faces Context.

Atraves dele e possıvel interagir diretamente com os componentes JSF da camada de

visualizacao.


Figura 17: Diagrama de sequencia Salvar Usuario


Outro ponto importante nesse processo e entender que quando o UsuarioBean e ins-

tanciado pelo JSF, e criada uma nova instancia de Usuario a qual sao atribuıdos todos

os valores preenchidos no fomulario descrito anteriormente. Esse formulario possui dois

campos de senha: um padrao e um outro para confirmar. O campo padrao e vinculado a

um atributo do objeto Usuario a ser instanciado pelo JSF e o outro a uma String do Usuari-

oBean. Dessa forma, e possıvel notar na figura que UsuarioBean obtem a senha do Usuario

instanciado atraves do metodo getSenhaUsuario(). Em seguida, e feita uma validacao da

senha do Usuario instanciado e da senha do UsuarioBean. Se essas forem diferentes uma

instancia do Faces Message e criada e e passado para o seu construtor o valor “A senha

nao foi confirmada corretamente”. Logo apos, o objeto Faces Message e atribuıdo ao

Faces Context pelo metodo addMessage(). Caso os valores digitados nos campos de senha

padrao e de confirmar forem iguais entao e obtida uma instancia do objeto UsuarioRN que

sera usada para salvar o usuario no banco de dados. Mas antes e obtida uma instancia

do objeto MessageDigest atraves do metodo getInstance() para definir a criptografia que

sera usada para embaralhar o atributo senha do objeto Usuario. Na sequencia, e obtida

uma instancia do objeto BigInteger. O atributo senha do objeto Usuario e passado como

parametro ao construtor de BigInteger para ser criptografado que em seguida e redefinido

em uma palavra de 16 bits pelo metodo setSenhaUsuario. Todo o processo e finalizado

com a obtencao de uma instancia do Faces Message com o valor “Cadastro realizado com

sucesso!”passado em seu construtor. Na sequencia, o objeto Faces Message e atribuıdo

ao Faces Context pelo metodo addMessage().

3.6.3 Editar usuario

As propriedades de um usuario podem ser editadas a partir da applet Area Adminis-

trativa citada no topico 3.3.2.1. Assim como comentado na subsecao 3.6.2 a applet Area

Administrativa possui uma tela, a qual alem de ter um formulario de cadastro tem uma

lista que exibe todos os usuarios do sistema. Essa lista contem, em cada linha, um botao

com uma figura de folha, a qual ao clicar faz com que o usuario seja enviado para a area

de cadastro. No entanto todas as informacoes do usuario em questao sao exibidas nos

campos de propriedades de usuario.


ministrador clicar no botao de edicao de usuario. No momento em que o botao de edicao

e acionado todas a informacoes do usuario em questao sao carregadas a partir de seu

objeto. Contudo assim como foi comentado no topico 3.6.2 o campo senha padrao e o


campo confirmar senha nao pertencem ao mesmo objeto, ja que um e parte do objeto

Usuario e o outro do objeto UsuarioBean respectivamente. Dessa forma e necessario pre-

encher o campo confirmar senha com a mesma senha do campo senha padrao. Para tanto

e possıvel observar na Figura 18 que o metodo editar() e chamado para obter a senha do

objeto Usuario, o qual e atribuıdo a String confirmaSenha do objeto UsuarioBean.

Figura 18: Diagrama de sequencia Editar Usuario

3.6.4 Ativar usuario

A ativacao ou desativacao de um usuario pode ser configurada a partir da applet Area

Administrativa citada no topico 3.3.2.1, sendo que a lista, a qual e possıvel determinar

essa acao e a mesma citada no topico 3.6.3. Essa lista contem, em cada linha, um botao

com uma figura de cırculo, o qual ao ser clicado alterna de cor, sendo verde para ativado

ou vermelho para desativado. Dessa forma so podera fazer uso do Fretum quem estiver

ativado.


ministrador clicar no botao ativar ou desativar usuario. Nota-se que no inıcio do processo

de ativar ou desativar usuario o metodo ativar() e chamado. Na sequencia percebe-se que

antes e feita uma validacao para verificar se o usuario em questao esta ativado. Isso e per-

cebido no bloco condicional atraves da chamada de metodo this.usuario.isAtivoUsuario().

Se esse usuario estiver ativado entao e atribuıdo false ao atributo ativoUsuario do ob-

jeto Usuario, o qual representa o usuario em questao. No entanto se esse usuario estiver

desativado e atribuıdo a esse atributo true.

Logo apos e criada uma instancia de objeto UsuarioRN para em seguida chamar o


metodo salvar(), o qual grava no banco de dados a alteracao de estado descrita anterior-

mente, no caso false ou true.

Figura 19: Diagrama de sequencia Ativar ou Desativar Usuario

3.6.5 Atribuir privilegios ao usuario

A atribuicao de privilegios ao usuario pode ser configurada a partir da applet Area

Administrativa citada no topico 3.3.2.1, sendo que a lista, na qual e possıvel determinar

essa acao e a mesma citada no topico 3.6.3. Essa lista contem, em cada linha, um botao

de cadeado, o qual ao ser clicado alterna de figura, sendo cadeado aberto para privilegio

de usuario administrador ou cadeado fechado para usuario comum. Cada regiao e repre-

sentada por uma figura composta de um numero e um ou dois triangulos. Triangulo verde

indica privilegio de carregar arquivo e vermelho de enviar. Ao clicar na figura o tipo de

privilegio e alterado.

A Figura 20 mostra as mensagens trocadas entre objetos apos um dado usuario clicar

em um dos botoes de atribuicao de privilegio. E percebido na figura que no inıcio do pro-

cesso o metodo atribuirPermissao() e chamado. Em seguida e obtida a lista de permissoes

(privilegios) do usuario em questao atraves do metodo getPermissaoUsuario(). Logo apos


e feita uma validacao para verificar se existe o privilegio na lista de permissoes. Se existir

a permissao e removida da lista. Isso e percebido no bloco condicional, onde e possıvel

observar na Figura 20 o metodo remove(). Se a permissao nao existir entao e adicionada

a lista atraves do metodo add().

Figura 20: Diagrama de sequencia Atribuir Privilegios ao Usuario

3.6.6 Excluir usuario

A exclusao de usuario pode ser configurada a partir da applet Area Administrativa

citada no topico 3.3.2.1, sendo que a lista, na qual e possıvel determinar essa acao e a

mesma citada no topico 3.6.3. Essa lista contem, em cada linha, um botao com figura de

lixeira, o qual ao ser clicado exibe uma janela popup, que por sua vez solicita a confirmacao

da acao excluir usuario.

A Figura 21 mostra as mensagens trocadas entre objetos apos um dado usuario admi-

nistrador clicar no botao excluir usuario. E percebido na figura que no inıcio do processo o

metodo excluir() e chamado. Na sequencia e obtida uma instancia de objeto UsuarioRN. A

seguir e chamado o metodo excluir() desse objeto, o qual exclui o usuario permanentemente

do banco de dados.


Figura 21: Diagrama de sequencia Excluir Usuario

3.6.7 Enviar arquivo

E possıvel enviar arquivo a partir da applet Regiao citada no topico 3.3.2.2. A ap-

plet Regiao possui tres telas que sao construıdas a partir dos arquivos Regiao1.xhtml,

Regiao2.xhtml e Regiao3.xhtml. Esses ultimos, cada, contem um botao que ao clicar abre

uma janela para escolher um arquivo a ser enviado. Cada tela possui um formulario que

fica vinculado ao objeto ArquivoBean.

A Figura 22 mostra as mensagens trocadas entre objetos apos um dado usuario es-

colher um arquivo e clicar o botao enviar da tela Regiao. Percebe-se que no inıcio do

processo de envio de arquivo o metodo upload() e acionado. Antes e feito uma validacao

para confirmar se o objeto arquivoUpload nao e nulo. Se nao for nulo e chamado o metodo

copiaArquivo() que tem dois parametros. O primeiro e uma nova instancia de objeto File

que e criado com o mesmo nome do arquivo contido no objeto arquivoUpload, isso e per-

cebido no metodo getName(), o qual pertence ao arquivoUpload. O outro parametro e

os dados brutos do arquivo em questao contido no objeto arquivoUpload, o qual e obtido

atraves do metodo getInputStream().

Na sequencia e criada uma nova instancia de objeto SimpleDateFormat() com o parame-

tro mascara, o qual e o formato de data que sera concatenado com o arquivo a ser enviado.

Logo apos e obtida uma nova instancia de objeto Calendar para obter atraves dele a data


atual, que em seguida e formatada atraves do objeto descrito no inıcio desse paragrafo. E

importante informar que a concatenacao entre data e arquivo foi suprimida da Figura 22,

pois para concatena-las nao e necessario a chamada de nenhum metodo, no entanto isso

acontece em seguida da resposta java/lang/String do objeto SimpleDateFormat.

Logo depois e criado um objeto FileOutputStream. Ele e nativo da plataforma Java e

possui metodos para tratar a saıda de stream de dados. Esse objeto possui um parametro,

que e uma nova instancia de objeto File, o qual recebe como passagem de valor ao seu

construtor o caminho raiz onde os dados do arquivo em questao pode ser armazenado

e o local que representa cada regiao, bem como o novo nome do arquivo, pois ele foi

concatenado com a data atual.

Antes de comecar a escrita (saıda) dos dados brutos do arquivo em questao o metodo

read() e chamado. Esse ultimo fara a leitura dos dados brutos do arquivo a ser gravado

em um local no servidor obtidos atraves do metodo getInputStream(). O metodo read() le

algum numero de bytes a partir do fluxo de entrada e armazena-os em um array. O numero

de bytes, realmente lidos, e retornado como um inteiro. Este metodo fica bloqueado ate

que os dados de entrada estejam disponıveis, ou o fim do arquivo seja detectado, ou uma

excecao seja lancada. Se o comprimento dos bytes for zero, entao os bytes nao serao lidos

e sera retornado 0. Caso contrario, ha uma tentativa de ler pelo menos um byte. Se

nenhum byte estiver disponıvel devido a stream estar no final do processo, o valor -1 e

retornado. Caso contrario, pelo menos um byte e lido e armazenado em uma variavel.

Dessa forma foi criado um laco while para escrever os dados no objeto OutputStream byte

a byte, o qual e responsavel por criar o arquivo fısico.

Terminado o processo de criacao, os objetos que tratam de streams sao finalizados.

Percebe-se na sequencia, na Figura 22, o metodo close() chamado para fechar a stream de

leitura, o flush() para liberar todos os dados contidos e close(), novamente, para fechar a

stream de saıda.

Ainda na sequencia da Figura 22 nota-se que um objeto LocalRN e instanciado.

Atraves dele e obtida uma instancia de objeto Local por intermedio do metodo getLocal()

com os parametros ContextoBean.CAMINHO ARQUIVOS e this.caminhoBase, os quais sao

o caminho raiz onde os dados do arquivo em questao pode ser armazenado e o local que

representa cada regiao respectivamente. Seguidamente e obtida uma instancia de ob-

jeto ArquivoRN, o qual permite, na sequencia, obter uma instancia de Arquivo atraves do

metodo getArquivo(). Esse ultimo tem dois parametros que sao o objeto Local e o nome

do arquivo. Isso e necessario, pois esse metodo realiza uma consulta no banco de dados


para verificar se o arquivo ja existe. Para tanto sao necessarios esses parametros para

realizacao dessa consulta. E para finalizar, o metodo salvar e chamado, o qual salva as

informacoes pertinentes ao arquivo em questao no banco de dados, como por exemplo o

local em que ele se encontra fisicamente, o registro de data e hora, usuario que enviou,

etc.


Figura 22: Diagrama de sequencia Envio de Arquivo


3.6.8 Carregar arquivo

E possıvel carregar arquivo a partir da applet Regiao citada no topico 3.3.2.2. Cada

tela dessa applet possui uma lista de arquivos, a qual corresponde ao conjunto de arquivos

contidos em um local fısico no servidor. Cada lista fica contida em um formulario, o qual

e vinculado ao objeto ArquivoBean.

Para carregar e necessario clicar em um nome de arquivo da lista. Essa acao faz com

que seja exibida uma janela para a escolha de um local em que o arquivo em questao possa

ser armazenado. A Figura 23 mostra as mensagens trocadas entre objetos apos um dado

usuario escolher e clicar em um nome de arquivo da lista. Nota-se que no inıcio do processo

de carregar arquivo o metodo configuraArquivo() e chamado. Na sequencia, e criada uma

instancia de objeto FileInputStream, o qual recebe em seu construtor o parametro Con-

textoBean.CAMINHO ARQUIVOS + this.caminhoBase + arquivo.getNomeArquivo(). Esse

objeto obtem bytes de entrada a partir de um arquivo em um sistema de arquivos. Ele

le fluxos de bytes brutos, como por exemplo os dados de um arquivo de imagem. E im-

portante perceber que o parametro que e passado para o construtor do FileInputStream

e o caminho raiz onde os dados do arquivo em questao estao armazenados, concatenado

com o local que representa a regiao de onde o arquivo esta no servidor, concatenado com

o nome desse arquivo.

Seguindo a sequencia da Figura 23, percebe-se que e instanciado um objeto DefaultS-

treamedContent, o qual recebe como parametros a instancia InputStream (stream), o for-

mato do arquivo getCurrentInstance(getNomeArquivo()) e o nome (getNomeArquivo()). O

objeto DefaultStreamedContent e uma implementacao da interface StreamedContent criada

para tratar streams para os componentes do PrimeFaces. Esse ultimo objeto e usado pela

camada de visualizacao para obter o arquivo em questao.

Em seguida e obtida uma instancia de objeto RegistroRN() para logo apos utilizar o

seu metodo salva(), o qual grava no banco de dados o registro da acao de carregar arquivo.


Figura 23: Diagrama de sequencia Carregar Arquivo

3.6.9 Excluir arquivo

E possıvel excluir arquivo a partir da applet Regiao citada no topico 3.3.2.2. Cada

tela dessa applet possui uma lista de arquivos, a qual corresponde ao conjunto de arquivos

contidos em um local fısico no servidor. Cada lista fica contida em um formulario, o qual

e vinculado ao objeto ArquivoBean.

Para excluir e necessario clicar na figura lixeira disponıvel em cada linha da lista de

arquivos. Ao clicar e aberta uma janela popup para confirmacao da acao de excluir. A

Figura 24 mostra as mensagens trocadas entre objetos apos um dado usuario clicar para

excluir um arquivo. Percebe-se que no inıcio do processo o metodo excluir() e chamado.

Em seguida, e criada uma instancia de objeto File, o qual recebe em seu construtor o

parametro arquivo.getLocalArquivo().getArquivoLocal() + arquivo.getNomeArquivo(), o qual

e necessario para apontar o local fısico em que o arquivo se encontra. Logo apos o metodo

delete() do objeto File e chamado para excluir o arquivo do local fısico.

Seguidamente e obtida uma instancia de objeto ArquivoRN() para logo apos utilizar

o seu metodo excluir(), o qual grava no banco de dados a informacao NAO EXISTE NO-

LOCAL DE DESTINO. Essa ultima estrategia e discutida no topico 3.5.1.


Logo apos e criada uma instancia de objeto RegistroRN para em seguida utilizar o seu

metodo salvar(), o qual faz o registro da acao de exclusao no banco de dados.

Figura 24: Diagrama de sequencia Excluir Arquivo

65

4 Configuracao da aplicacao

4.1 Implantacao do projeto

O sistema desenvolvido e compatıvel com servidores que possuem a maquina virtual

Java configurada, por exemplo JBoss AS, Apache Tomcat, IBM WebSphere, Oracle OC4J,

etc. Para cada um deles basta localizar o diretorio de implantacao de projetos e colar o

Fretum que deve estar comprimido no formato de arquivos de extensao .war.

A seguir e mostrado como configurar o sistema deste trabalho na plataforma OpenShift

no servidor JBoss AS 7. Os passos apresentados levam em conta o uso do Eclipse. Em

outras IDEs os passos podem ser diferentes. Apos essas configuracoes e possıvel acessa-lo

via cliente web.

Passo 1 Primeiramente e necessario criar uma conta na plataforma OpenShift. Para tanto

basta acessar o site mostrado no retangulo 1 da Figura 25 e em seguida clica no

botao Sign Up como mostrado no retangulo 2.

4.1 Implantacao do projeto 66

Figura 25: Conta OpenShift

Passo 2 Logo apos a criacao da conta o usuario e direcionado para uma tela onde e permitido

escolher qual servidor sera usado para implantacao de projetos. Para esse projeto

foi escolhido o JBoss AS 7 como mostrado na Figura 26.

Figura 26: Servidor JBoss AS 7


Passo 3 Em seguida e necessario dar um nome para o sistema e confirmar. Isso e mostrado

na Figura 27 nos retangulo 1 e 2 respectivamente.

Figura 27: Servidor JBoss AS 7

Passo 4 Posteriormente ao passo anterior e necessario acessar a area em que se encontra o

sistema, como mostrado nas figuras 28 e 29.


Figura 28: Gerenciador de sistemas implantados

Figura 29: Informacoes sobre o sistema implantado

Passo 5 Seguidamente e necessario disponibilizar o SGBD MySQL para o repositorio criado

no OpenShift. Para tanto basta clicar no botao “Add Cartridge”como mostrado na

Figura 30.


Figura 30: Adicionar banco de dados

Passo 6 Escolher o MySQL como mostrado na Figura 31.

Figura 31: Selecionar MySQL 5.1

Passo 7 Confirmar a escolha do MySQL como mostrado na Figura 32.


Figura 32: Confirmar a escolha do MySQL

Passo 8 Em seguida e necessario copiar com CTRL+C o endereco do repositorio criado na

plataforma OpenShift como mostrado na Figura 33.

Figura 33: Gerenciador de sistemas implantados

Passo 9 Supondo que o Git ja esteja previamente instalado se faz necessario a abertura de


um terminal ou prompt de comandos para logo a seguir digitar o comando git clone

mais o endereco do repositorio remoto como mostrado na Figura 34.

Figura 34: Git clone

Passo 10 Depois executar um Eclipse que possua os plugins Maven e Git previamente insta-

lados. Clicar no item de menu File, depois Import, selecionar Maven, depois setar

o workspace do projeto como mostrado nas figuras 35, 36, 37 e 38 respectivamente.


Figura 35: Import do Eclipse


Figura 36: Importacao Maven


Figura 37: Pasta do projeto

Figura 38: Carregar projeto no Eclipse

Passo 11 Esse sistema utiliza um local fısico para armazenar os arquivos. Para tanto e ne-

cessario criar diretorio no servidor remoto. Como mostrado na Figura 39 e necessario

copiar esse endereco para posteriormente utiliza-lo para acesso remoto via SSH como


mostrado nesta outra Figura 40, onde e possıvel verificar que o repositorio do sistema

foi acessado via SSH. Uma vez feito o acesso se faz necessario como ja mencionado

a criacao de diretorios como mostrado na Figura 41

Figura 39: Endereco SSH do repositorio

Figura 40: Acesso remoto do repositorio via SSH


Figura 41: Criacao de diretorio fısicos para o sistema

Passo 12 Em seguida basta adicionar o arquivo com os binarios do projeto, disponıveis no

arquivo .war e apagar o arquivo .pom Figura 42

Figura 42: Binarios do projeto

Passo 13 Logo apos basta fazer um commit e um push atraves do plugin do Git do Eclipse


como mostrado na Figura 43

Figura 43: Commit do Git

Passo 14 Neste ultimo passo deve-se configurar as tabelas ou entidades de banco de dados

para armazenar as informacoes geradas pelos usuarios atraves do sistema de ar-

mazenamento de arquivos. Para tanto e necessario acessar o repositorio remoto do

projeto via SSH e executar o SGBD MySQL atraves do comando mysql. A Figura 44

exibe os passos que devem ser realizados apos esse ultimo comando.

Um ponto importante antes de abordar os passos para criacao do banco de dados

e o de que quando e criado um repositorio no OpenShift e adicionado um SGBD

ao projeto, por padrao ja e criado um esquema de banco de dados com o nome do

repositorio em questao sem tabelas.

Voltando a Figura 44, no retangulo 1, e mostrado que deve-se selecionar o esquema

de bando de dados desejado. Em seguida precisa-se criar uma tabela, a qual o

sistema vai utilizar como referencia do local raiz em que se encontram os diretorios

de arquivos do Fretum, isso e mostrado no retangulo 2. Depois e necessario criar ao

menos um usuario com privilegio de administrador, como mostrado no retangulo 3.

Logo apos deve-se criar os diretorios do sistema, como mostrado nos retangulos 4, 5

e 6. Como mencionado o usuario criado deve ter privilegio de administrador, para

tanto deve-se fazer como mostrado no retangulo 7.


Figura 44: Configuracao do banco de dados

4.1.1 Parametros dos frameworks

Para configurar os frameworks e necessario antes entender a estrutura de diretorios

do projeto que e mostrada na Figura 45. Os diretorios que devem ser observados sao os

src main, java, resources, webapp e WEB-INF, pois os demais sao criados por default pela

IDE Eclipse.

Essa estrutura e configurada automaticamente no Eclipse a partir do plugin do Maven,

o qual define o src como o diretorio em que irao estar presentes um ou mais projetos Maven.

Nesse caso, apenas um que e o Fretum, o qual e definido como o principal main.

Dentro do main deve estar o diretorio java, no qual deve estar as classes .java.

No resource deve estar o ou os arquivos de configuracoes de frameworks de banco de

dados, que nesse caso e o Hibernate.

E o webapp e o local onde deve estar todos os arquivos responsaveis por desenhar as

telas, podendo ser com extensoes: .css, .html, xhtml, etc.

Ja no WEB-INF deve estar as configuracoes do projeto atraves do arquivo web.xml, o

qual e mencionado no topico JSF bem com as configuracoes do Spring Security.


Figura 45: Estrutura de diretorios

4.1.1.1 JSF

A configuracao basica do JSF envolve apenas o arquivo web.xml, localizado no diretorio

WEB-INF do projeto. Nesse arquivo e configurado o repasse das requisicoes ao servidor

para o JSF processar. O processamento se dara apenas para a requisicoes do tipo .jsf. A

Figura 46 mostra um exemplo de configuracao do framework JSF.

Para ativar o funcionamento do JSF basta adicionar os elementos <servlet> e <servlet-

mapping>. O elemento <welcome-file-list> e a definicao dos arquivos que poderao servir

como pagina inicial.


1 <?xml version="1.0" encoding="UTF-8"?>

2 <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://

java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-

app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://

java.sun.com/xml/ns/javaee/web-app_3_0.xsd" id="WebApp_ID" version="3.0">

3 <display-name>Fretum</display-name>

4 <welcome-file-list>

5 <welcome-file>index.html</welcome-file>

6 </welcome-file-list>

7 <servlet>

8 <servlet-name>Faces Servlet</servlet-name>

9 <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>

10 <load-on-startup>1</load-on-startup>

11 </servlet>

12 <servlet-mapping>

13 <servlet-name>Faces Servlet</servlet-name>

14 <url-pattern>*.jsf</url-pattern>

15 </servlet-mapping>

16 </web-app>

Figura 46: Configuracoes do JSF

4.1.1.2 Hibernate

A configuracao basica do Hibernate envolve apenas o arquivo hibernate.xml, localizado

no diretorio resources do projeto. Nesse arquivo e configurado os parametros de banco de

dados para que o Hibernate saiba como fazer o mapeamento dos objetos para tabelas de

banco de dados. A Figura 47 mostra um exemplo de configuracao.

No parametro dialect e configurado o dialeto de comunicacao com o SGBD, que nesse

caso e o MySQL. Em connection.datasource e configurado o caminho do banco de dados.

Quando o sistema e executado o Hibernate cria as tabelas de banco de dados com

base nos objetos entidades do sistema. Em hibernate.hbm2ddl.auto e configurado se a

cada execucao do sistema as tabelas serao excluıdas e criadas novamente ou atualizadas

se existirem. Nesse caso foi configurado para o Hibernate atualizar.

Em class e configurado as classes que serao mapeadas para entidades de banco de

dados.

4.1.1.3 Spring Security

As configuracoes do Spring Security e feita no arquivo applicationContext-security.xml.

Nele e configurado as permissoes para os diretorios do sistema e a origem dos dados dos

usuarios e permissoes. A Figura 48 mostra um exemplo de configuracao.



2 <!DOCTYPE hibernate-configuration PUBLIC

3 "-//Hibernate/Hibernate Configuration DTD 3.0//EN"

4 "http://www.hibernate.org/dtd/hibernate-configuration-3.0.dtd">

5 <hibernate-configuration>

6

7 <session-factory>

8

9 <property name="dialect">org.hibernate.dialect.MySQL5InnoDBDialect</

property>

10

11 <property name="connection.datasource">java:jboss/datasources/MysqlDS</

property> -->

12

13 <property name="hibernate.hbm2ddl.auto">update</property>

14

15 <mapping class="com.wavetech_st.usuario.Usuario" />

16 <mapping class="com.wavetech_st.arquivo.Arquivo" />

17 <mapping class="com.wavetech_st.arquivo.Local" />

18 <mapping class="com.wavetech_st.arquivo.Registro" />

19 <mapping class="com.wavetech_st.util.ModelUtil" />

20

21 </session-factory>

22

23 </hibernate-configuration>

Figura 47: Configuracoes do Hibernate

O elemento <http> e um agrupador das configuracoes referentes ao contexto web do

sistema.

A configuracao de quais paginas ou diretorios que serao seguros e efetuada com o

elemento <intercept-url>, no qual o atributo pattern expressa o padrao textual da URL,

e o atributo access e uma lista separada por vırgula dos nomes de permissoes que terao

acesso ao recurso. Poderao existir quantos <intercept-url> forem necessarios.

O elemento <form-login> configura o funcionamento da pagina de login do Spring

Security. Em login-page e configurada a URL para exibir a pagina de login do sistema. Ja

em <default-target-url> e configurada a URL a ser exibida caso o login nao seja realizado

com sucesso. E em <authentication-failure-url> e configurada a URL a ser exibida caso o

login nao seja realizado com sucesso.

O elemento <logout> e utilizado para habilitar o recurso de logout para o sistema.

Com o logout habilitado, bastara chamar a URL /j_spring_security_logout para que o

usuario seja direcionado para a pagina externa do sistema, tendo sua sessao invalidada.

A configuracao que estiver definida em <authentication-provider> determinara quais

sao os usuarios validos do sistema e suas permissoes. Para tanto sera necessario que o



2 <beans:beans xmlns="http://www.springframework.org/schema/security"

3 xmlns:beans="http://www.springframework.org/schema/beans"

4 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

5 xsi:schemaLocation="http://www.springframework.org/schema/beans

6 http://www.springframework.org/schema/beans/spring-beans

-3.0.xsd

7 http://www.springframework.org/schema/security

8 http://www.springframework.org/schema/security/spring-

security-3.1.xsd">

9

10 <http use-expressions="true">

11

12 <intercept-url pattern="/index.html" access="permitAll" />

13 <intercept-url pattern="/publico/*" access="permitAll" />

14 <intercept-url pattern="/templates/*" access="authenticated" />

15 <intercept-url pattern="/compositions/*" access="authenticated" />

16 <intercept-url pattern="/restrito/*" access="authenticated" />

17 <intercept-url pattern="/admin/*" access="authenticated" />

18 <intercept-url pattern="/regioes/*" access="authenticated" />

19

20 <form-login login-page="/publico/noticias.jsf"

21 always-use-default-target="true"

22 default-target-url="/restrito/fretum.jsf"

23 authentication-failure-url="/publico/noticias.jsf?login_error=1" />

24

25 <logout invalidate-session="true"

26 logout-url="/j_spring_security_logout" />

27

28 </http>

29

30 <authentication-manager>

31

32 <authentication-provider>

33

34 <password-encoder hash="sha" />

35

36 <jdbc-user-service data-source-ref="fretumDB"

37 users-by-username-query="SELECT emailUsuario, senhaUsuario,

ativoUsuario FROM Usuario WHERE emailUsuario = ?" />

38 </authentication-provider>

39

40 </authentication-manager>

41

42 </beans:beans>

Figura 48: Configuracoes do Spring Security


Spring faca consultas no banco de dados para verificar essas informacoes. Dessa forma

sera necessario obter o local do banco de dados, o qual sera obtido a partir do arquivo

applicationContext.xml, o qual tem o seu conteudo mostrado na Figura 49.

O elemento <password-encoder hash=“sha”> e utilizado para criptografar atraves do

algoritmo hash SHA a senha inserida pelo usuario.

Ainda sobre as configuracoes do <authentication-provider> o elemento <jdbc-user-

service> permite declarar as SQLs que fornecerao os dados que o Spring Security neces-

sita, vindas do banco de dados. O atributo data-source-ref indica o nome dado para a

configuracao criada para o banco de dados. Esse nome foi dado dentro do arquivo ap-

plicationContext.xml, o qual e o fretumDB. E em users-by-username-query e o codigo SQLs

para obter as informacoes do banco de dados a respeito do usuario.


2 <beans xmlns="http://www.springframework.org/schema/beans"

3 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

4 xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.

springframework.org/schema/beans/spring-beans-3.0.xsd">

5

6 <bean id="fretumDB" class="org.springframework.jndi.JndiObjectFactoryBean">

7

8 <property name="jndiName">

9

10 <value>java:jboss/datasources/MysqlDS</value>

11

12 </property>

13

14 </bean>

15

16 </beans>

Figura 49: Configuracoes do caminho do banco de dados para o Spring Security

84

5 Resultados

A Figura 50 mostra a pagina inicial do site da WaveTech Solucoes Tecnologicas. Nela

e possıvel visualizar o botao logar, o qual esta destacado em verde.

Figura 50: Botao para entrar na area de dialogo de acesso ao sistema

Ao clicar no botao logar o canto esquerdo do banner da pagina da WaveTech e des-

locado para a direita, como mostra a Figura 51. Em seguida e possıvel visualizar uma

caixa, a qual contem um campo para digitar o login, a senha e um botao para enviar a

requisicao dessas informacoes ao servidor em que o sistema esta hospedado.

5 Resultados 85

Figura 51: Dialogo para acesso ao sistema

Apos a requisicao do usuario em questao ser processada, e exibida, na sequencia, a tela

principal do sistema, a qual e possıvel verificar na Figura 52. Isso indica que, efetivamente,

o sistema reconheceu o usuario e a senha garantindo-lhe acesso ao sistema.

Figura 52: Tela principal para usuarios nao administradores

5 Resultados 86

Na tela principal e possıvel verificar os tres diretorios em que as empresas envolvidas

com a WaveTech poderao armazenar seus arquivos, onde a Regiao 1 representa o diretorio

1, e assim sucessivamente. E importante perceber que o usuario em questao nao e admi-

nistrador, pois, se fosse, na tela principal tambem seria exibido um botao que permitiria

ao usuario acessar a area administrativa como mostra a Figura 53. Dessa forma essa

ultima e um exemplo de que verdadeiramente o usuario em questao nao tem o privilegio

de administrador.

Figura 53: Tela principal para usuarios administradores

A Figura 54 mostra o usuario em questao acessando o diretorio 1. Nessa figura e

possıvel notar que ha uma lista dos arquivos contidos nesse diretorio conforme o esperado.

5 Resultados 87

Figura 54: Diretorio sem recurso de envio de arquivos

Cada tela que representa um diretorio possui o botao “lista”que permite exibir a

tabela de arquivos em uma janela popup, a qual possibilita ao usuario redimensionar essa

janela conforme o desejado. Isso e exibido na Figura 55.

Figura 55: Lista de arquivos expandida em uma segunda tela

5 Resultados 88

Cada tela que representa um dado diretorio tem caracterısticas diferentes para um

dado usuario. Esse ultimo, por exemplo, se tiver privilegio de envio de arquivos em

um dado diretorio vera algo como o mostrado na Figura 56. E possıvel carregar algum

arquivo para o computador local clicando no nome dele como mostrado no retangulo 1.

E permitido tambem ao usuario enviar algum arquivo para o servidor clicando no botao

“Escolher arquivo”como mostrado no retangulo 3. No entanto esse botao possibilita

apenas escolher, e nao enviar efetivamente. Para efetuar essa acao e necessario clicar no

botao “Enviar”como mostrado no retangulo 4.

Ainda na Figura 56 e possıvel verificar que quando um dado usuario tem privilegio

de envio de arquivos tambem e permitido a ele apagar um arquivo qualquer desse local.

Para tanto e disponibilizado um botao como exibido no retangulo 2.

Figura 56: Diretorio com recurso de envio de arquivos

Como ja mencionado anteriormente, aos usuarios com privilegio de administrador e

disponibilizado um botao para acesso a area administrativa como ilustrado na Figura 53.

Nessa area e possıvel gerenciar as contas de usuario, a qual e mostrada na Figura 57. E

possıvel ativar ou desativar contas de usuario clicando no botao ativar/desativar. Dois

exemplos sao mostrados nos retangulos 1 e 6 respectivamente. E importante notar que o

estado verde indica um usuario ativado enquanto o vermelho indica um usuario desativado.

Os administradores podem tambem dar e tirar privilegios de usuario administrador. Isso

e mostrado nos retangulos 4 e 7, os quais sao exemplos de que quando o cadeado esta

5 Resultados 89

aberto o usuario e administrador e fechado o mesmo nao e. Alem desses gerenciamentos

ainda e possıvel dar ou tirar privilegio de envio de arquivos nos diretorios do sistema,

os quais podem ser visualizados nos retangulos 5 e 8. Os mesmos sao dois exemplos de

que foi dado privilegio de envio de arquivos e foi retirado respectivamente no diretorio 3.

Ainda na Figura 57 e possıvel visualizar dois botoes, os quais permitem editar e apagar

usuarios, eles sao mostrados nos retangulos 2 e 3 respectivamente.

Figura 57: Area administrativa

O menu da tela da area administrativa tem um botao, o qual e mostrado no retangulo

9 da Figura 57 que ao clicar direciona o administrador para a area que possibilita-o

de cadastrar uma nova conta de usuario. A tela exibida e mostrada na Figura 58. E

importante salientar que os asteriscos (*) apos os nomes dos campos denota que o campo

e obrigatorio.

5 Resultados 90

Figura 58: Area de cadastro de usuarios

Em todas as ilustracoes mostradas sobre os resultados, foi percebido que nas telas que

exitem tabelas, seja de usuarios como de arquivos, ha um campo na maioria das colunas

como mostrado na Figura 59 nos retangulos 1 e 3. Esses campos foram disponibilizados

para fazer filtragem de registros. Nota-se que no retangulo 1 foi digitado o numero “1”e

no retangulo 3 os caracteres “te”, os quais possibilitaram a filtragem do campo Codigo de

todas as ocorrencias que tinham a ocorrencia do numero “1”e do campo Tipo do Registro

de todas as ocorrencia que tinham os caracteres “te”. Outra caracterısticas que deve ser

notado sao os botoes para ordenacao de valores nas colunas das tabelas ja citadas. Os

botoes tem o sımbolo como mostrado na Figura 59 no retangulo 2.

5 Resultados 91

Figura 59: Recursos de filtragem e de ordenacao de valores

Tambem foi criada uma area que permite aos administradores visualizarem as ativi-

dades dos usuarios no sistema. Para tanto basta clicar no botao Registros do menu da

area administrativa como destacado no retangulo 10 da Figura 57. Se um dado usuario

enviar, carregar ou deletar um dado arquivo, entao sera criado um registro para essa acao

informando a data, o nome do usuario que efetuou tal atividade, o nome do arquivo que

sofreu com tal acao e o tipo do registro; os quais podem ser de envio de arquivo (upload),

carregamento de arquivo (download) ou exclusao de arquivo (delete). A tela de registros

pode ser visualizada na Figura 60.

5 Resultados 92

Figura 60: Area de registros de atividades dos usuarios

93

6 Conclusao

Este trabalho teve como objetivo o desenvolvimento de um sistema web de armazena-

mento de arquivos com controle de privilegio de envio de arquivos e geracao de relatorios

de atividades.

Foi desenvolvido um sistema para suprir a demanda da empresa WaveTech Solucoes

Tecnologicas de um software de gerenciamento de arquivos. Neste sistema o administrador

pode determinar quais usuarios tem privilegios de envio de arquivos em determinados

diretorios. Todos os usuarios ativos podem carregar os arquivos para o seu computador. E

possıvel visualizar um historico interativo, no qual pode-se rastrear modificacoes realizadas

por cada usuario ou em cada arquivo. A interface e intuitiva e de facil acesso remoto. O

sistema deste trabalho esta funcional e operando na data da entrega desse documento.

Foi cogitado o uso das APIs disponibilizadas pelos atuais sistemas de armazenamento

de arquivos existentes. No entanto, com elas, nao e possıvel armazenar os arquivos em

um banco de dados proprio ou em um local proprio, pois ao usa-las e necessario que o

sistema a ser desenvolvido esteja atrelado aos servicos que disponibilizam essas APIs por

meio de chaves de autenticacao para esses servicos.

Dessa forma foi buscado uma linguagem de programacao que permitisse o desenvolvi-

mento do sistema desse trabalho. Essa linguagem deveria ser popular, gratuita, orientada

a objetos e com grande suporte. Num estudo realizado verificou-se que o Java era o mais

adequado para esse projeto.

6.1 Trabalhos futuros

O Fretum tem um numero de diretorios pre-definidos. Por serem 3 empresas envolvi-

das, o numero de diretorios e o mesmo. Esse era um dos requisitos que foi atendido para

a primeira versao desse sistema. No entanto para as proximas versoes sugere-se que os

diretorios sejam criados dinamicamente via software como ocorre com os atuais sistemas

6.1 Trabalhos futuros 94

web de armazenamento de arquivos. Para tanto poderia-se configurar um servidor Pro-

tocolo Leve de Acesso a Diretorios - Lightweight Directory Access Protocol (LDAP) para

interagir com o sistema de arquivos deste trabalho.

Sugere-se a criacao de um controle de permissoes de arquivos similar aos existentes

em sistemas operacionais Gnu/Linux e Unix, os quais permitem determinar quem tem

privilegios de leitura, escrita e ou execucao em arquivos ou diretorios.

Tambem seria util a implementacao da possibilidade de ler e editar os principais

formatos de arquivos online existentes como .txt, .doc, .xls, etc.

Poderia-se criar tambem um sincronizador de arquivos local/remoto para os sistemas

operacionais existentes. Esse seria util para nao haver a necessidade de abrir um cliente

web para enviar ou carregar arquivos, pois o mesmo ficaria escutando as mudancas realiza-

das em um determinado diretorio local, definido pelo usuario, e alteraria automaticamente

essas informacoes no diretorio remoto.

Outra sugestao seria criar uma API com base no Fretum e disponibilizar gratuitamente

para quem quisesse criar seus proprios sistemas de armazenamento de arquivos. Essa API

poderia ser livre para ser configurada em um banco de dados qualquer, algo que nao

acontece com as atuais APIs dos sistemas de arquivos populares.

Uma area de Chat tambem poderia ser interessante, permitindo o dialogo entre os

usuarios, facilitando a pesquisa de arquivos, etc.

95

Lista de Abreviaturas

ACM Associacao para Maquinaria da Computacao - Association for Computing Machi-

nary

API Interface de programacao de aplicativos - Application Programming Interface

Arpa Agencia de Projetos de Pesquisa Avancados - Advanced Research Project Agency

DCDU Diagrama de Caso de Uso

DoD Departamento de Defesa - Department of Defense

FTP Protocolo de Transferencia de Arquivos - File Transfer Protocol

HTML Linguagem de Marcacao de Hipertexto - HyperText Markup Language

HTTP Protocolo de Transferencia de Hipertexto - Hipertext Transfer Protocol

IDE Plataforma Integrada de Desenvolvimento - Integrated Development Environment

IMP Processador de mensagens de interface - The Interface Message Processor

ISP Provedor de acesso a Internet - Internet Service Provider

JSF Servidor de Faces Java - Java Server Faces

LDAP Protocolo Leve de Acesso a Diretorios - Lightweight Directory Access Protocol

MVC Modelo-Visualizacao-Controle - Model-View-Controller

NAP Ponto de acesso a rede - Network Access Point

ORM Mapeamento Objeto-Relacional - Object-Relational Mapping

PaaS Plataforma como Servico - Platform as a Service

PDF Portable Document Format

POM Projeto Modelo de Objeto - Project Object Model

96

SGBD Sistema de Gerenciamente de Banco de Dados

SSH Terminal Seguro - Security Shell

SMTP Protocolo de transferencia de correio simples - Simple Mail Transfer Protocol

SQL Linguagem de Consulta Estruturada - Structured Query Language

TCP Transmission Control Protocol - Protocolo de Controle de Transmissao

URL Uniform Resource Locator

XHTML X Hypertext Markup Language

W3C Consorcio Rede Mundial de Computadores - World Wide Web Consortium

97

Referencias

ALEX, B.; TAYLOR, L. Reference Documentation. 2013. Disponıvel em <http:

//jcp.org/en/jsr/overview>. Acesso em 172/02/2013.

BUDINSKY, F. Eclipse modeling framework: a developer’s guide. [S.l.]: Addison-WesleyProfessional, 2004.

BURNS, E.; KITAIN, R. JavaServerFaces Specification. [S.l.]: Version, 2009.

CASEY, J. et al. Better Builds with Maven. [S.l.]: Mergere Library Press, 2006.

DROPBOX. Getting started with Core API for Android. 2013. Disponıvel em<https://www.dropbox.com/developers/core/start/android>. Acesso em27/05/2013.

ECLIPSE. About the Eclipse Foundation. 2013. Disponıvel em <http://www.eclipse.

org/org/>. Acesso em 02/02/2013.

ELMASRI, R. et al. Fundamentals of datadata systems. [S.l.]: Pearson Addison Wesley,2011.

FOROUZAN, B. A.; FEGAN, S. C. et al. Data communications and networking. [S.l.]:McGraw-Hill, 2008.

GONCALVES, E. Desenvolvendo aplicacoes web com JSP, Servlets, Java Server Faces,Hibernate, EJB 3 Persistence e Ajax. [S.l.]: Ciencia Moderna, 2007.

GOOGLE. Quickstart: Run a Drive App in Java. 2013. Disponıvel em <https:

//developers.google.com/drive/quickstart-java>. Acesso em 27/05/2013.

HAT, R. What is Object/Relational Mapping? 2013. Disponıvel em <http:

//www.hibernate.org/about/orm>. Acesso em 20/01/2013.

KING, G. et al. Hibernate Reference Documentation, 3.6. 0. cr2 edn. 2013. Disponıvelem <http://www.hibernate.org/docs>. Acesso em 15/07/2013.

KUROSE, J.; ROSS, K. Redes de Computadores e Internet. [S.l.: s.n.], 2010.

LARMAN, C. Utilizando Uml E Padroes 3 Ed. [S.l.]: Bookman, 2008.

MEHTA, V. P. Pro LINQ Object Relational Mapping in C# 2008. [S.l.]: Apress, 2008.

MULARIEN, P. Spring Security 3. [S.l.]: Packt Pub Limited, 2010.

OPENSHIFT. OpenShift Platform as a Service (PaaS). 2013. Disponıvel em<https://openshift.redhat.com/community/paas>. Acesso em 05/02/2013.

Referencias 98

PYTHON. Comparing Python to Other Languages. 2013. Disponıvel em <http:

//www.python.org/doc/essays/comparisons/>. Acesso em 24/05/2013.

TANENBAUM, A. Computer networks. [S.l.]: Prentice Hall Professional TechnicalReference, 2010.

VARAKSIN, O.; CALISKAN, M. PrimeFaces Cookbook. [S.l.]: Packt Publishing Ltd,2013.

W3C. Visao geral do HTML5. 2013. Disponıvel em <http://www.w3c.br/cursos/

html5/conteudo/capitulo1.html>. Acesso em 10/02/2013.

W3C. What is HyperText. 2013. Disponıvel em <http://www.w3.org/WhatIs.html>.Acesso em 10/02/2013.

WALTERS, E. G. The essential guide to computing. [S.l.]: Pearson PTR, 2001.

Fretum: Sistema web de armazenamento de arquivos...de relat orios de atividades, ou seja, com ele o...

Documents

Transcript of Fretum: Sistema web de armazenamento de arquivos...de relat orios de atividades, ou seja, com ele o...