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.
1.1 Requisitos nao funcionais 16
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/>
1.1 Requisitos nao funcionais 17
• 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)”
2.3 O modelo cliente servidor 21
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
2.3 O modelo cliente servidor 22
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 Requisitos funcionais 35
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.
3.3 Requisitos funcionais 36
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.
5. E feito o registro da acao descrito no item anterior.
6. O arquivo esta escrito (salvo) no local escolhido.
3.3 Requisitos funcionais 37
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.
4. E feito o registro da acao descrito no item anterior.
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
3.3 Requisitos funcionais 38
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:
3.3 Requisitos funcionais 39
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:
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 ativa ou desativa o acesso do usuario no sistema.
4. O usuario esta com ou sem acesso ao sistema.
5. Imediatamente a lista de usuarios e atualizada.
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:
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 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.
6. Imediatamente a lista de usuarios e atualizada.
3.3 Requisitos funcionais 40
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:
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 da ou tira a permissao de administrador do usuario.
4. O usuario esta ou nao com permissao de administrador.
5. Imediatamente a lista de usuarios e atualizada.
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:
1. Idem “Cenarios de Sucesso – Cadastro de usuario” do 1 ao 5.
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:
1. Idem “Cenarios de Sucesso – Cadastro de usuario” do 1 ao 5.
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
3.4 Modelo de Dados 42
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.
3.4 Modelo de Dados 43
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 Modelo de classes 45
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.
3.5 Modelo de classes 47
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.
3.5 Modelo de classes 49
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.
3.5 Modelo de classes 50
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 Diagramas de sequencia 52
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.
3.6 Diagramas de sequencia 54
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.
A Figura 18 mostra as mensagens trocadas entre objetos apos um dado usuario ad-
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
3.6 Diagramas de sequencia 55
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.
A Figura 19 mostra as mensagens trocadas entre objetos apos um dado usuario ad-
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
3.6 Diagramas de sequencia 56
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
3.6 Diagramas de sequencia 57
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.
3.6 Diagramas de sequencia 58
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
3.6 Diagramas de sequencia 59
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
3.6 Diagramas de sequencia 60
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.
3.6 Diagramas de sequencia 62
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.
3.6 Diagramas de sequencia 63
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.
3.6 Diagramas de sequencia 64
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
4.1 Implantacao do projeto 67
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.
4.1 Implantacao do projeto 68
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.
4.1 Implantacao do projeto 69
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.
4.1 Implantacao do projeto 70
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
4.1 Implantacao do projeto 71
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.
4.1 Implantacao do projeto 74
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
4.1 Implantacao do projeto 75
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
4.1 Implantacao do projeto 76
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
4.1 Implantacao do projeto 77
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.
4.1 Implantacao do projeto 78
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.
4.1 Implantacao do projeto 79
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.
4.1 Implantacao do projeto 80
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.
4.1 Implantacao do projeto 81
1 <?xml version="1.0" encoding="UTF-8"?>
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
4.1 Implantacao do projeto 82
1 <?xml version="1.0" encoding="UTF-8"?>
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
4.1 Implantacao do projeto 83
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.
1 <?xml version="1.0" encoding="UTF-8"?>
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.
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.