TCC Fernando Matos Final PDF

FACULDADE DE BALSAS
CURSO DE SISTEMAS DE INFORMAO
DESENVOLVIMENTO DE UM SISTEMA WEB PARA ENVIAR,

ARMAZENAR E RECEBER DOCUMENTOS OFICIAIS
Fernando Ferreira Matos
BALSAS MA
2013
FACULDADE DE BALSAS

Trabalho de Concluso de Curso apresentado

como exigncia parcial para obteno do ttulo
de Bacharel em Sistemas de Informao Faculdade de Balsas, sob a orientao do Professor Marcos David Souza Ramos.
Balsas - MA
2013
FACULDADE DE BALSAS
A Comisso Examinadora, abaixo assinada, aprova o Trabalho de Concluso de

Curso (TCC)

Elaborada por
como requisito parcial para obteno do grau de Bacharel em Sistemas de
Informao
BANCA EXAMINADORA
Prof. Marcos David Sousa Ramos

Prof. Orientador
Prof. Msc. Jefferson Fontinele Da silva

Membro da Banca Examinadora
Prof. Msc. Cleverton Marlon Possani

Membro da Banca Examinadora
3
AGRADECIMENTOS
Agradeo primeiramente a Deus, a meu orientador Marcos David Souza Ramos neste
trabalho, a minha Famlia, a meus colegas e amigos.
4
RESUMO
Este trabalho visa mostrar o desenvolvimento do sistema web, para informatizar os processos
de envio, armazenamento e recebimento de documentos oficiais utilizados pelos diversos setores da prefeitura municipal de Balsas-MA. Baseado em padres Web Model-ViewController (MVC) e alguns dos frameworks mais importantes para o desenvolvimento Web
em Java como, Java Server Faces (JSF), Hibernate e Spring Security. O trabalho ainda expe
conceitos teis sobre configuraes de arquivos, anotaes e CDI, necessrios para o entendimento da estrutura e do desenvolvimento do mesmo. O trabalho tem como resultado final o
desenvolvimento do sistema web, com a finalidade de automatizar os processos de envio de
documentos oficiais utilizado na estrutura interna da prefeitura municipal de Balsas-MA.
Palavras-chaves: Desenvolvimento Web. Padres. Frameworks.
5
ABSTRACT
This work aims to show the development of web system to computerize the process of sending, receiving and storage of official documents used by various sectors of the city hall Balsas-MA. Web-Based Model-View-Controller (MVC) and some of the most important frameworks for web development in java as Java Server Faces (JSF), Hibernate and Spring Security
standards. the work also presents useful concepts about settings files, notes and CDI required
for understanding the structure and development of the same. The work is the final result of
the web system development, in order to automate the process of sending official documents
used in the internal structure of the municipal government of Balsas-MA.
Keywords: Web Development. Standards. Frameworks.
6
LISTA DE FIGURAS
FIGURA 1: Representao da comunicao interna da Prefeitura de Balsas - MA ................ 12
FIGURA 2: Ciclo de vida em Cascata ..................................................................................... 19
FIGURA 3: Ambiente de Desenvolvimento NetBeans IDE 7.3 .............................................. 22
FIGURA 4: Ciclo de vida JSF .................................................................................................. 28
FIGURA 5: Arquitetura do Hibernate para plataforma Java ................................................... .34
FIGURA 6: Estrutura do Projeto .............................................................................................. 40
FIGURA 7: Configurao do JSF ............................................................................................ 41
FIGURA 8: Apresenta a Configurao do Spring .................................................................... 41
FIGURA 9: Apresenta a Configurao do Spring Security ..................................................... 42
FIGURA 10: Apresenta a Configurao do Prime Faces ......................................................... 42
FIGURA 11: Configurao do Spring Security-applicationContext.xml ................................ 42
FIGURA 14: Arquivo hibernate.cfg.xml .................................................................................. 44
FIGURA 15: Declarao da Anotao @Entity....................................................................... 45
FIGURA 16: Declarao da Anotao @Entity e @GeneratedValue ..................................... 45
FIGURA 17: Declarao da Anotao @OneToOne............................................................... 46
FIGURA 18: Declarao da Anotao @Column ................................................................... 47
FIGURA 19: Classe Usuario.java ............................................................................................ 47
FIGURA 20: Mtodo gravar .................................................................................................... 48
FIGURA 21: Formulrio de Login (index.xhtml ..................................................................... 50
FIGURA 22: Classe SegurancaBean ........................................................................................ 51
FIGURA 23: Pgina de Login ................................................................................................. 52
FIGURA 24: Weld ................................................................................................................... 53
FIGURA 25: Arquivo beans.xml ............................................................................................. 53
FIGURA 26: Configurao do CDI no arquivo Context.xml .................................................. 54
FIGURA 27: Configurao do CDI no arquivo web.xml ........................................................ 54
FIGURA 28: Ilustrao do Escopo Request ............................................................................. 55
FIGURA 29: Session ................................................................................................................ 56
FIGURA 30: Sem injeo de Dependncia .............................................................................. 57
FIGURA 31: Com Injeo de Dependncia ............................................................................. 57
FIGURA 32: Anotao @PostConstruct ................................................................................. 58
7
FIGURA 33: Criao da Tabela ............................................................................................... 58
FIGURA 34: Criao do Mtodo da tabela .............................................................................. 59
FIGURA 35: Criao da Coluna Data ...................................................................................... 59
FIGURA 36: Cdigo da Classe Documento responsvel por retorna data............................ 59
FIGURA 37: Criao da Coluna Assunto ................................................................................ 60
FIGURA 38: Criao da Coluna Destinatrio .......................................................................... 60
FIGURA 39: Mtodo secretariaNome...................................................................................... 60
FIGURA 40: Criao da Coluna Documentos ......................................................................... 60
FIGURA 41: Mtodo Selecionar .............................................................................................. 61
FIGURA 42: Classe DocumentoDownloadBean ..................................................................... 61
FIGURA 43: Pgina do Formulrio ......................................................................................... 61
FIGURA 44: Pgina do Formulrio Coluna Assunto............................................................... 62
FIGURA 45: Boto Enviar ...................................................................................................... 62
FIGURA 46: Mtodo Salvar .................................................................................................... 63
FIGURA 47: Pgina que Mostrar os Documentos ................................................................... 64
FIGURA 48: Pgina para Enviar Documento .......................................................................... 64
8
LISTA DE TABELAS
TABELA 1: Lista dos pacotes Hibernate e uma descrio resumida de cada um deles .......... 35
9
LISTA DE ABREVIATURAS E SIGLAS
API
Application Programming Interface
CDI
Context and Depen- dency Injection
DAO
Data Access Object
EJB
Enterprise JavaBeans
GUI
Componentes de Interfaces de Usurio
HTML
Hypertext Markup Language
HTTP
Hypertext Transfer Protocol
HTTPS
HyperText Transfer Protocol Secure
IDE
Integrated Development Enviroment
J2EE
Java 2 Platform Enterprise Edition
JDBC
Java Database Connectivity
JDK
Java Development Kit
JSF
Java Server Faces
JSP
Java Server Pages
JSTL
JavaServer Pages Standard Tag Library
LDAP
Lightweight Directory Access Protocol
MVC
Model-View-Controller
OO
Orientada a Objetos
ORM
Mapeamento Objeto Relacional
PDF
Portable Document Format (Formato de Documento Porttil).
SQL
Structured Query Language (Linguagem de Consulta Estruturada)
URL
Uniform Resource Locators (Localizador Uniforme de Recursos)
XHTML
Extensible Hypertext Markup Language
XML
Extensible Markup Language (Linguagem de Marcao Estendida)
10
SUMRIO
1 INTRODUO .................................................................................................................... 12
1.1 Justificativa.................................................................................................................... 14
1.2 Objetivos ....................................................................................................................... 14
1.2.1 Objetivo Geral ............................................................................................................ 14
1.2.2 Objetivos Especficos ................................................................................................. 14
1.3 Metodologia .................................................................................................................. 14
1.4 Organizao da Monografia .......................................................................................... 14
2 REVISO BIBLIOGRFICA ............................................................................................. 16
2.1 Engenharia de Software ................................................................................................. 16
2.1.1 Metodologia de desenvolvimento de sistemas .......................................................... 16
2.1.2 Processo de Software .................................................................................................. 17
2.1.3 Modelos de processo de software .............................................................................. 18
2.1.4 Engenharia de requisitos ............................................................................................. 18
2.1.5 Modelos de ciclo de vida ........................................................................................... 19
2.2 NETBEANS .................................................................................................................. 21
2.3 MVC (Model-View-Controller) ..................................................................................... 22
2.3.1 Padro MVC segundo JSF........................................................................................... 25
2.4 JavaServer Faces ............................................................................................................ 25
2.4.1 Ciclo de vida do JSF .................................................................................................... 27
2.4.2 Pginas HTML ............................................................................................................ 31
2.4.3. Navegao entre pginas ............................................................................................ 32
2.4.4. Componentes .............................................................................................................. 32
2.5 Hibernate ........................................................................................................................ 33
2.6 Spring Security ............................................................................................................... 37
2.7 PrimeFaces ..................................................................................................................... 37
3 DESENVOLVIMENTO........................................................................................................ 39
3.1 Estrutura do Projeto ........................................................................................................ 39
3.2 Configurao do arquivo web.xml ................................................................................. 41
3.3 Configurao do Sprint Security .................................................................................... 42
3.4 Configurao do Hibernate............................................................................................. 44
3.5 Anotaes ....................................................................................................................... 45
3.6 Construo da tabela Usurio ......................................................................................... 47
11
3.7 UsuarioDAO ................................................................................................................... 48
3.8 Spring Security ............................................................................................................... 49
3.9 Pgina de Login .............................................................................................................. 50
3.10 CDI ............................................................................................................................... 52
3.11 Formulrio para Mandar Arquivo................................................................................. 61
4 CONCLUSO ...................................................................................................................... 65
4.1 Consideraes Finais ...................................................................................................... 65
4.2 Trabalhos Futuro ............................................................................................................ 65
5 REFERNCIAS BIBLIOGRFICAS ................................................................................. 66
6 APNDICES ........................................................................................................................ 68
6.1 Apndice A Documentos de Requisito........................................................................ 68
12
1 INTRODUO
Sabe-se que a comunicao responsvel pelo sucesso ou fracasso em uma organizao em relao troca de informao, fazendo a passar de um ponto para outro, utilizando
processos de emisso, transmisso e recepo de mensagens por meio de mtodos ou sistemas
convencionais (FERREIRA, 2005).
A Prefeitura Municipal de Balsas-MA vem passando por problemas relacionados
comunicao na transmisso de documentos oficiais, causado pela demora em que determinados documentos saiam do seu destino de origem e cheguem at seu destino final. A mesma
dividida fisicamente por setores e seus respectivos subsetores, todos localizados em locais
diferentes, necessitando manter uma constante comunicao entre os mesmos, que feita por
troca de documentos oficiais. A prefeitura de Balsas-MA no possui um sistema de software
que atenda s suas necessidades referentes comunicao interna, na mesma existe uma
grande quantidade de documentos oficiais armazenados, como ofcios, licitaes e outros,
sem contar que, novos documentos so gerados diariamente.
A Figura1 uma representao de como funcionar a comunicao interna da mesma, com foco no envio e recebimento de documentos oficiais.
Figura 1. Representao da comunicao interna da Prefeitura Municipal de Balsas MA
A Figura 1 representa o funcionamento da comunicao interna da prefeitura municipal de balsas, onde as secretarias de sade, educao, infraestrutura e comunicao entre
outras, so reparties da mesma e so localizadas e locais diferentes, onde necessita manter
em comunicao com a prefeitura municipal. Se as secretarias desejam enviar documentos
13
oficiais para a prefeitura municipal de Balsas-MA, um funcionrio tem que percorrer um caminho entre as mesmas at a Prefeitura Municipal de Balsas-MA, para realizar a entrega dos
mesmos, causando assim: Demora no envio e no recebimento dos documentos oficiais; Riscos
de acidentes de trabalho com funcionrios na realizao da entrega dos documentos oficiais
em que tem que se locomover entre as ruas da cidade; Se o prefeito ou funcionrios (a) competentes a receberem determinados documentos no estiverem presentes na cidade, eles (a)
no tero como receber os documentos.
A necessidade de um sistema automatizado para a Prefeitura Municipal de BalsasMA, surgiu como ponto de partida ao estudo e desenvolvimento de um sistema web em que
foi observado que o mecanismo utilizado para enviar e receber documentos oficiais utilizados
pela prefeitura municipal de Balsas-MA e seus setores contm problemas em relao demora da execuo no envio e recebimento de documentos oficiais.
O objetivo deste trabalho foi desenvolver um sistema Web que atenda as necessidades
da prefeitura municipal de Balsas-MA em relao a troca de documentos oficiais entre seus
setores. Espera-se que o software desenvolvido, quando for implantado, permita minimizar o
tempo gasto nos envios e recebimentos dos documentos oficiais, permitindo assim uma rpida
comunicao entre seus setores e a mesma.
14
1.1 Justificativa
A administrao pblica de Balsas MA, passa hoje por problemas de comunicao
entre os setores que a constitui e a prpria prefeitura municipal, onde tudo o que realizado
documentado e aprovado por secretarias por meio de seus respectivos supervisores ou secretrios e pelo Prefeito, em que esses documentos precisam ser repassados para os setores que a
constitui. Porm o envio ou a entrega desses documentos feito manualmente atravs de um
funcionrio pblico, que se desloca de uma partio at outra para realizar a entregar dos
mesmos, tornando assim um processo demorado, e que acaba dificultando o processo de organizao da mesma.
O sistema web desenvolvido para a Prefeitura Municipal de Balsas-MA, propulsionar
que os documentos sejam enviados com mais rapidez e segurana, visando melhorar a comunicao interna da mesma em relao transmisso de documentos oficiais.
1.2 Objetivos
1.2.1 Objetivo geral:
Desenvolver um sistema web para a Prefeitura Municipal de Balsas-MA, que possa
enviar, armazenar e receber documentos oficiais.
1.2.2 Objetivos especficos:

Efetuar um levantamento bibliogrfico das tecnologias envolvidas no desenvolvimento do sistema web;
Fazer um levantamento dos requisitos do sistema a ser elaborado;
Desenvolver o sistema proposto.
1.3 Metodologia
A pesquisa cientifica tem por objetivo a busca de conhecimento e permitir que o
mesmo possa ser vivel na resoluo de determinado problema, com a finalidade de colocar
em prtica o conhecimento que foi adquirido, suficiente para realizar o desenvolvimento do
sistema proposto.
15
O trabalho ser desenvolvido para Prefeitura Municipal de Balsas-MA. No ano de
2013.
A metodologia do trabalho consistir em:
Pesquisas Bibliogrficas: Sero realizados estudos em livros, tutoriais, publicaes e artigos onde possa contribuir no aperfeioamento do conhecimento em
relao s ferramentas que sero utilizadas para o desenvolvimento do sistema
web;
Ser adotada a metodologia de desenvolvimento em Cascata;
Reunies com funcionrios da prefeitura municipal de Balsas-MA: Com o propsito de aprimorar o conhecimento de como funciona o mecanismo de entrega
dos documentos oficiais;
Levantamento de requisitos: Sero levantados atravs de entrevista formal com
os responsveis pelas secretarias e setores da administrao pblica de BalsasMA;
Implementao do sistema;
1.4 Organizao da monografia
Este trabalho est organizado da seguinte forma: Captulo 2 Reviso Bibliogrfica,

Captulo 3 Desenvolvimento e o Captulo 4 Concluso.
16
2.
REVISO BIBLIOGRFICA
A reviso bibliogrfica consistir na apresentao de conceitos de diferentes autores sobre
MVC que ser utilizado para separao da aplicao, Hibernate para mapeamento objeto relacional, Spring Security para autenticao e autorizao de usurios no sistema, tambm ser
apresentado conceitos sobre JSF, Prime Faces e engenharia de software.
2.1 Engenharia de Software
Engenharia de software metodologia de desenvolvimento e manuteno de sistemas
modulares, com as seguintes caractersticas: processo (roteiro) dinmico, integrado e inteligente de solues tecnolgicas; adequao aos requisitos funcionais do negcio do cliente e
seus respectivos procedimentos pertinentes; efetivao de padres de qualidade, produtividade e efetividade em suas atividades e produtos; fundamentao na Tecnologia da informao
disponvel, vivel, oportuna e personalizada; planejamento e gesto de atividades, recursos,
custos e datas (REZENDE, 2005).
MAFFEO (1992 apud REZENDE, 2005, p.5.) considera-se que os objetivos primrios da
Engenharia de Software so o aprimoramento da qualidade dos produtos de software e o aumento da produtividade dos engenheiros de software, alm do atendimento aos requisitos de
eficcia e eficincia, ou seja, efetividade.
2.1.1 Metodologia de Desenvolvimento de Sistemas

Uma metodologia completa constitui-se de uma abordagem organizada para atingir um
objetivo, por meio de passos preestabelecidos. um roteiro, um processo dinmico e iterativo
para o desenvolvimento estruturado de projetos, sistemas ou software, visando a qualidade,
produtividade e efetividade de projetos (REZENDE, 1997).
A metodologia deve auxiliar o desenvolvimento de projetos, sistemas ou software, de
modo que os mesmos atendam de maneira adequada s necessidades do cliente ou usurio,
com os recursos disponveis e dentro de um prazo ideal definido em conjunto com os envolvidos. No deve limitar a criatividade profissional, mas deve ser um instrumento que determine
um planejamento metdico, que harmonize e coordene as reas envolvidas. O que limita a
criatividade no a metodologia, mas os requisitos de qualidade, produtividade e efetividade
de um projeto (REZENDE, 2005).
17
2.1.2 Processo de Software
Um processo de software um conjunto de atividades e resultados associados que geram
um produto de software. Essas atividades so, em sua maioria, executadas por engenheiros de
software (SOMMERVILLE, 2005).
Segundo REZENDE (2005):
Os processos de software ou processos de desenvolvimento de software tm conceitos equivalentes a metodologia de desenvolvimento e manuteno de software, pois
ambos so roteiros de elaborao de software que devem contemplar fases, subfases,
produtos externados e pontos de avaliao de qualidade.
Um processo um conjunto de passos parcialmente ordenados, constitudos por atividades, mtodos, prticas e transformaes, usado para atingir uma meta. Essa meta est associada a um ou mais resultados concretos finais, que so os produtos da execuo do processo
(FILHO, 2001).
Segundo SOMMERVILLE (2005), existem quatro atividades de processo fundamentais
comuns a todos os processos de software. Essas atividades so:
1. Especificao do software: A funcionalidade do software e as restries em sua operao devem ser definidas.
2. Desenvolvimento do software: O software deve ser produzido de modo que atenda as
suas especificaes.
3. Validao do software: O software tem de ser validado para garantir que ele faz o que
o cliente deseja.
4. Evoluo do software: O software deve evoluir para atender s necessidades mutveis
do cliente.
Diferentes processos de software organizam essas atividades de maneiras diversas e so
descritos em diferentes nveis de detalhes. Os prazos das atividades variam, do mesmo modo
que os resultados de cada atividades. Diferentes organizaes podem utilizar processos diferentes para produzir o mesmo tipo de produto (SOMMERVILLE, 2005).
Os processos de software so complexos e, como todos os processos intelectuais, dependem de julgamento humano. Por causa da necessidade de utilizar o julgamento e a criatividade, tentativas de automatizar processos de software tm tido sucesso limitado (SOMMERVILLE, 2005).
18
Uma razo pela qual existe uma abordagem limitada para a automao de processos a
imensa diversidade dos processos de software. No h um processo ideal, e diferentes organizaes desenvolveram abordagens inteiramente diferentes para o desenvolvimento de software (SOMMERVILLE, 2005).
2.1.3 Modelos de Processo de Software

Um modelo de processo de software uma representao abstrata de um processo de software. Cada modelo de processo representa um processo a partir de uma perspectiva particular, de uma maneira que proporciona apenas informaes parciais sobre o processo (SOMMERVILLE, 2005).
2.1.4 Engenharia de Requisitos

O processo de engenharia de requisitos leva produo de uma documentao de requisitos, que a especificao para o sistema. Os requisitos geralmente so apresentados em dois
nveis de detalhes nesse documento (SOMMERVILLE, 2005).
Engenharia de requisitos um estgio particularmente importante do processo de software, uma vez que erros nesse estgio inevitavelmente produzem problemas posteriores no projeto e na implementao do sistema (SOMMERVILLE, 2005).
Existem quatro fases principais no processo de engenharia de requisitos:
1- Estudo de Viabilidade feita uma estimativa para verificar se as necessidades
dos usurios que foram identificadas podem ser satisfeitas com a utilizao das
atuais tecnologias de software e hardware. O estudo decidir se o sistema proposto ser vivel, do ponto de vista comercial, e se poder ser desenvolvido
certas restries oramentrias existentes. Um estudo de viabilidade deve ser
relativamente barato e rpido.
2- Levantamento e anlise de requisitos Este o processo de obter os requisitos
do sistema pela observao de sistemas existentes, pela conversa com usurios
e compradores em potencial, pela anlise de tarefas assim por diante.
3- Especificao de requisitos a atividade de traduzir as informaes coletadas

durante a atividade de anlise em um documento que defina um conjunto de
requisitos. Dois tipos de requisitos podem se includos nesse documento. Os
requisitos dos usurios so declaraes abstratas dos requisitos de sistema para
19
o cliente e os usurios finais do sistema; os requisitos do sistema so uma descrio mais detalhada da funcionalidade a ser fornecida.
4- Validao de requisitos Essa atividade verifica os requisitos quanto a sua pertinncia, consistncia e integridade. Durante esse processo, inevitavelmente so
descobertos erros na documentao de requisitos. Os requisitos devem ento
ser modificados, a fim de corrigir esses problemas.
2.1.5 Modelos de Ciclo de Vida

Em engenharia de software, processos podem ser definidos para atividades como desenvolvimento, manuteno, aquisio e contratao de software. Podem-se definir subprocessos
para cada um desses, um processo de desenvolvimento abrange subprocessos de determinao
dos requisitos, anlise, desenho, implementao e testes (FILHO, 2009).
No modelo de ciclo de vida em Cascata (Figura 2), os principais sub processo so executados em estrita sequncia, o que permite demarc-los com pontos de controles bemdefinidos. Esses pontos de controle facilitam muito a gesto dos projetos, o que faz com que
esse processo seja, em princpio, confivel e utilizvel em projetos de qualquer escala. Por
outro lado, se interpretado literalmente, um processo rgido e burocrtico, em que as atividades de requisitos, anlise e desenho tm de ser muito bem dominada, pois, teoricamente, o
processo no prev a correo posterior de problemas nas fases anteriores. O modelo em cascata puro de baixa visibilidade para o cliente, que s recebe o resultado final do projeto. Na
prtica, sempre necessrio permitir que, em fases posteriores, haja reviso e alterao de
resultados das fases anteriores (FILHO, 2009).
Figura 2: Ciclo de Vida em Cascata.
20
Requisitos:
Os problemas que os engenheiros de software tm para solucionar so, muitas vezes,
imensamente complexos. Compreender a natureza dos problemas pode ser muito difcil, especificamente se o sistema for novo. Consequentemente, difcil estabelecer com exatido o
que o sistema deve fazer. As descries das funes e das restries so os requisitos para o
sistema; e o processo de descobrir, analisar, documentar e verificar essas funes e restries
chamado de engenharia de requisitos (SOMMERVILLE, 2003).
Alguns dos problemas que surgem durante o processo de engenharia de requisitos so
resultantes de falta de uma ntida separao entre esses diferentes nveis de descrio (SOMMERVILLE, 2003).
Os requisitos do usurio, os requisitos de sistema e a especificao de projeto de software podem ser definidos como se segue:
1- Requisitos do usurio so declaraes, em linguagem natural e tambm em diagramas
sobre as funes que o sistema deve fornecer e as restries sob as quais deve operar.
2- Requisitos de sistema estabelecem detalhadamente as funes e as restries de sistema. O documento de requisitos de sistema deve ser preciso. Ele pode servir como um
contrato entre o comprador do sistema e o desenvolvedor do software.
3- Especificao de projeto de software uma descrio abstrata do projeto de software.
Segundo Sommerville (2003), os requisitos de sistema de software so, frequentemente, classificados como funcionais ou no funcionais.
1- Requisitos funcionais So declaraes de funes que o sistema deve fornecer,
como o sistema deve reagir a entradas especificas e como deve se comportar em
determinadas situaes.
2- Requisitos no funcionais So restries sobre os servios ou as funes oferecidas
pelo sistema. Entre eles destacam-se restries de tempo, restries sobre o processo de desenvolvimento, padres, entre outros.
Anlise:
Fluxo cujo objetivo detalhar, estruturar e validar os requisitos, de forma que estes
possam ser usados como base para o planejamento detalhado (FILHO, 2009).
21
Desenho:
Fluxo cujo objetivo formular um modelo do produto que sirva de base para implementao (FILHO, 2009).
Implementao:
Fluxo cujo objetivo realizar o desenho em termos de componentes de cdigos (FILHO, 2009).
Testes:
Fluxo cujo objetivo verificar os resultados da implementao (FILHO, 2009).
2.2 Netbeans
O NetBeans considerada uma das melhores IDEs open source do mercado. Desenvolvida pela Sun Microsystems e mantida pela comunidade, a cada nova verso vem se mostrando uma madura e consistente ferramenta para desenvolvimento Java. Em matria de desenvolvimento Web, essa IDE muito madura, sendo uma excelente alternativa para aqueles
que desejam desenvolver aplicaes Web de forma simples e rpida (GONALVES, 2007).
Segundo GONALVES (2007), SANTOS (2007):
O NetBeans foi Desenvolvida pela Sun Microsystems e mantida pela comunidade,
considera uma das melhores IDEs open sourse do mercado. um projeto que se dedica a prover ferramentas aplicveis ao processo de desenvolvimento de software e
que possa ser utilizado por desenvolvedores e demais usurios, entidades e corporaes como base para a criao dos seus prprios produtos.
A comunidade desse projeto um grupo de pessoas interessadas que residem nas mais
diversas partes do mundo que contribuem entre si de diversas formas, como, postando na lista
de discusses mensagens onde qualquer pessoa pode acess-las para busca ajuda nos problemas enfrentados com o uso dessa ferramenta e tambm para compartilhar os sucessos obtidos
com elas (SANTOS, 2007).
Segundo Santos (2007), Qualquer pessoa pode obter gratuitamente o instalador do
NetBeans no web site do projeto e est autorizada a fazer uso dele tanto para propsitos no
comerciais quanto para fins comerciais.
22
Figura 3- Ambiente de Desenvolvimento NetBeans IDE 7.3
Tela principal do NetBeans IDE 7.3. O mesmo ser utilizado como ambiente de Desenvolvimento web para o sistema web proposto.
O NetBeans conta com um sistema de depurao, mostrando variveis no declaradas,
falhas de digitao, mtodos inexistentes e ainda possibilitar importaes de bibliotecas atravs de auxilio da ferramenta (GONALVES, 2007).
O ambiente NetBeans mostra como principal ferramenta de desenvolvimento com a
tecnologia JAVA. Atravs dele o programador consegue mais recursos que podem auxiliar na
produtividade para o desenvolvimento do seu software. Neste ambiente possvel montar
uma arquitetura a nvel de classes em trs camadas, denominada MVC: Modelo-Viso e Controle.
2.3 MVC (Model-View-Controller)

Atualmente ainda muito comum a prtica de desenvolver aplicaes web construda
com cdigo HTML e cdigo servidor em uma mesma pgina, criando uma embaraosa confuso. exatamente isso que acontece em JDBC e JSTL, cdigos de SQL, juntas a cdigos de
programao, e sadas de resultados ao usurio, tudo em um s local (GONALVES, 2007).
Esse tipo de desenvolvimento conhecido como embutir a lgica de negcios ao resultado final. Essa prtica e condenada pelos desenvolvedores atuais, principalmente os de
23
aplicaes escritas em JSP. Graas a essa condenao, o paradigma do modelo MVC foi incorporado no desenvolvimento, criando assim dois modelos para desenvolvimento de aplicaes escritas em Java: Model 1 (Modelo 1) e Model 2 (Modelo 2), baseados no paradigma
MVC (GONALVES, 2007).
O Model 1:
A primeira arquitetura, conhecida como Model 1, muito comum no desenvolvimento
de aplicaes Web, chamada de page-centric. Esta arquitetura fornece o modo mais fcil de
reunir uma aplicao Web. Envolvendo simplesmente a construo de uma aplicao como
um conjunto de pginas JSP (GONALVES, 2007)
O Model 2:
uma arquitetura mais sofisticada que usa Servlets e pginas JSP. Foi batizada de
Model 2 (Modelo 2), que est baseada em uma adaptao da arquitetura MVC. Nessa implementao, um Servlet usado como um Controlador, recebendo pedidos do usurio, enquanto efetuando mudanas no Modelo, e fornecendo a Apresentao ao usurio (GONALVES,
2007).
Segundo GONALVES (2006):
As Servlets so classes Java que so instanciadas e executadas em associao com
servidores Web, atendendo requisies realizadas por meio de protocolo http. Os objetos Servlets quando acionados podem enviar a resposta na forma de uma pgina
HTML ou qualquer outro contedo MIME.

O MVC um conceito (paradigma) de desenvolvimento e design que tenta separar
uma aplicao em trs partes distintas. Uma parte, a Model, est relacionada ao trabalho atual que a aplicao administrativa, outra parte, a View, est relacionada a
exibir os dados ou informaes dessa uma aplicao e a terceira parte, Controller,
em coordenar os dois anteriores exibindo a interface correta ou executando algum
trabalho que a aplicao precisa completar.
A viso a camada responsvel pela apresentao. Ela recebe o estado do modelo

atravs do controlador. Os objetos dessa camada recebem os dados de entrada do usurio que
sero repassados para o controlador (FOX, 2006).
A camada do controlador interliga a camada da viso camada de negcio ou modelo,
ou seja, a fronteira entre ambas as camadas. No framework JSF quem faz o papel do controlador o servlet FacesContex, que retira da solicitao do usurio os dados de entrada e interpreta o que eles significam para o modelo. Obriga o modelo a se atualizar e disponibiliza o
novo estado do modelo para a viso (BASHAM et al, 2008).
24
O modelo a camada que abriga a verdadeira lgica de negcio. Possui as regras para
obteno e atualizao do estado e fornece ao controlador o acesso aos dados, pois a nica
parte do sistema que se comunica com o banco de dados (BASHAM et al, 2008).
A ideia do padro MVC dividir uma aplicao em trs camadas: modelo, visualizao e controle. O modelo responsvel por representar os objetos de negcio, manter o estado
da aplicao e fornecer ao controlador o acesso aos dados. A visualizao representa a interface com o usurio, sendo responsvel por definir a forma como os dados sero apresentados
e encaminhar as aes dos usurios para o controlador. J a camada de controle responsvel
por fazer a ligao entre o modelo e a visualizao, alm de interpretar as aes do usurio e
as traduzir para uma operao sobre o modelo, onde so realizadas mudanas e, ento, gerar
uma visualizao apropriada.
Model: O Model (modelo) o objeto que representa os dados do programa.
Maneja esses dados e controlam todas suas transformaes. Esse modelo no tem conhecimento especifico do controlador (Controller) e das apresentaes (View), nem
sequer contm referncia a eles. Portando, o Model so as classes que trabalham no
armazenamento e busca de dados. Por exemplo, um cliente pode ser modelado em
uma aplicao, e pode haver vrios modos de criar novos clientes ou mudar informaes de um relativo cliente.
View: A View (apresentao) o que maneja a apresentao visual dos dados
apresentados pelo Model. Em resumo, a responsvel por apresentar os dados resultantes do Model ao usurio. Por exemplo, uma Apresentao poder ser um local administrativo se logam em uma aplicao. Cada administrador poder visualizar uma
parte do sistema que o outro no v.
Controller: O Controller (controlador) o objeto que responde as ordens executadas pelo usurio, atuando sobre os dados apresentados pelo modelo, decidindo
como o modelo devera ser alterado ou devera ser revisto e qual apresentao devera
ser exibida. Por exemplo, o controlador recebe um pedido para exibir uma lista de clientes interagindo com o Modelo e entregando uma apresentao onde esta lista poder
ser exibida.
25
2.3.1 Padro MVC segundo JSF
No JSF, o controle composto por um Servlet denominado FacesServlet, por arquivos
de configurao e por um conjunto de manipuladores de aes e observadores de eventos. O
FacesServlet responsvel por receber requisies da WEB, redirecion-las para o modelo e
ento remeter uma resposta. Os arquivos de configurao so responsveis por realizar associaes e mapeamentos de aes e pela definio de regras de navegao. Os manipuladores
de eventos so responsveis por receber os dados vindos da camada de visualizao, acessar o
modelo, e ento devolver o resultado para o FacesServlet (KITO, 2005).
Segundo KURNIAWAN (2002):

Um servlet uma classe Java que pode ser automaticamente carregada e executada
por um Container. O container gerencia as instncias dos servlets, alm de prover os
servios de redes necessrios para as requisies e respostas.
Com o padro MVC ser possvel dividir a aplicao em trs camadas: modelo, visualizao e controle. Atravs desse padro ser possvel fazer a manuteno do sistema com
mais facilidade (GONALVES, 2007). O JSF basear-se nesse padro de projeto, e uma de
suas melhores vantagens e a clara separao entre a visualizao e regras de negcio (modelo), o mesmo ser utilizado como linguagem de programao web no desenvolvimento do
trabalho.
2.4 JavaServer Faces

O Java Server Faces JSF um framework utilizado para desenvolvimento de aplicaes Web, que executam do lado do servidor, desenvolvidas pela Sun Microsystem. Essa tecnologia faz parte da plataforma J2EE (Java 2 Platform Enterprise Edition) que oferece um
conjunto de tecnologias e solues robusta para a Web.
Segundo Gonalves (2006), Um framework uma estrutura de suporte definida, em
que um outro projeto de software pode ser organizado e desenvolvido.
26
Segundo Kito (2005):
O JSF executado do lado do servidor em um container Web padro como, por
exemplo, o Tomcat. Quando o usurio clica em um boto em uma aplicao swing2
ele vai disparar um evento que pode ser tratado diretamente no cdigo do programa
desktop. Em contraste, os navegadores Web no conhecem os componentes do JSF
ou eventos, pois o browser s sabe interpretar HTML (HyperText Markup Language). Ento quando um boto clicado pelo usurio em um aplicativo Faces gerada uma requisio que ser enviada atravs do browser para o servidor pelo protocolo HTTP. O Faces responsvel por traduzir essa requisio em um evento que
ser processado pelo aplicativo no servidor. responsvel tambm por garantir que
cada elemento da interface do usurio definidas no servidor seja exibida corretamente para o navegador.

JSF (JavaServer Faces) uma tecnologia do mundo Java EE e desenhado para
simplificar o desenvolvimento de aplicaes web. JSF torna fcil o desenvolvimento
atravs de componentes de interfaces de usurio (GUI) e conecta esses componentes
a objetos de negcios. Tambm automatiza o processo de uso de JavaBeans e na navegao de pginas.
Java Server Faces o framework para desenvolvimento de aplicao web padro da

Java EE. Ele mantido pela Java Community Process JSR-314, que define o padro para desenvolvimento de interfaces dentro do modelo orientado a componentes. Essa caracterstica ,
na maioria das vezes, o maior obstculo para o aprendizado da maioria dos desenvolvedores,
principalmente os que conhecem algum framework baseados em aes, como por exemplo,
Struts (SOUSA, p.8-18).
O objetivo principal do JSF tornar o desenvolvimento Web mais rpido e fcil. Permite aos desenvolvedores pensar em termos de componentes, eventos, backing beans ou Managed Beans. Managed Beans so Java Beans3 que podem ser usados para gerenciar melhor o
comportamento dos componentes em uma pgina JSP. Na prtica voc pode criar backing
beans diferentes para um ou mais componentes em uma pgina. O JSF permite pensar em
estruturas de alto nvel e suas interaes, ao invs de requisio e resposta. A complexidade
do desenvolvimento Web no visualizada pelos programadores, permitindo que os desenvolvedores se concentrem mais na lgica de negcio da sua aplicao (KITO, 2005).
A arquitetura JSF favorece o surgimento de ferramentas RAD (Desenvolvimento rpido de aplicaes) atravs da arquitetura de componentes, da infraestrutura da aplicao e do
conjunto de componentes padres. Para a IDE Eclipse, h diversos plug-ins, como o WTP, o
Jboss Tools e MyEclipse. J o NetBeans oferece um suporte avanado com recursos de dragand-drop para montagem de pginas, alm de oferecer componentes mais avanados que os
27
padres, cabe ressaltar que estes recursos esto atrelados a um modelo de desenvolvimento
que o usurio deve seguir, caso contrrio os recursos so bem limitados (SOUSA, p.8-18).
Os componentes JSF so orientados a eventos, ou seja, possvel processar eventos
gerados pelo cliente, como um clique no boto ou alterao do valor de um campo de texto.
Por padro, h um conjunto de componentes bsicos para manipulao de formulrios, mas o
Faces oferece uma infraestrutura para criao de novos componentes. Dentre os componentes
de terceiros, os mais conhecidos so os Jboss RichFaces e Apache Tomahawk (SOUSA, p.818).
O framework JSF responsvel por interagir com o usurio (cliente), e fornece ferramentas para criar uma apresentao visual, a aplicao lgica e a lgica de negcios de uma
aplicao Web. Porm, o escopo de JSF restringindo camadas de apresentao. A persistncia de banco de dados e outras conexes de back-end esto fora do escopo de JSF (GONALVES, 2007).
2.4.1 Ciclo de vida do JSF

Toda requisio realizada dentro do contexto JSF passa por um processo de seis fases,
conhecidas como ciclo de vida JSF. Em suma, durante esse processo restaurada a rvore de
componentes, os valores so lidos, convertidos e validados; eventos so executados e uma
resposta gerada para o usurio. Os eventos so executados, na grande maioria, aps uma
dessas seis fases. Numa requisio podemos passar por todas essas fases ou por nenhuma,
dependendo do tipo de pedido, de erros que ocorrem durante as validaes, converses e do
tipo de resposta (SOUSA, p.8-18).
A Figura 4 mostra o fluxo de execuo de uma requisio gerada pelo cliente pelo ciclo de vida JSF. O processo inicia-se assim que a requisio recebida pelo servlet do JSF.
importante lembra que JSF construdo em cima da API do Servlet.
28
Figura 4. Ciclo de vida JSF
Restore View
A requisio recebida pelo FacesController, que extrair a View ID usada para identificar a pgina JSP associada a ela. Uma View a representao de todos os componentes que
compem uma determinada pgina. Uma vez que a pgina est em mos, realizada uma
tentativa de restaurao desta View que, geralmente, restaurada com base em um campo
oculto, ou baseada na sesso de usurio. A rvore de componentes da View obtida atravs de
duas formas: Initial View e Postback, que so executados de maneiras distintas (SOUSA, p.818).
A Initial View ocorre quando a pgina acessada pela primeira vez ou quando a pgina acessada via HTTP GET. O contexto JSF cria rvore de componentes, com base na View
acessada, e a mesma gravada na propriedade viewRoot do objeto FacesContext. Esse objeto contm todas as informaes relacionadas requisio que so necessrias para manipular
o estado dos componentes GUI de uma pgina de uma determinada requisio. Como no h
nenhum valor de entrada a ser processado, o fluxo avana para a ltima fase, a Render Response (SOUSA, p.8-18).
J o Postback ocorre quando o usurio interage com o formulrio da pgina, seja alterando um valor de campo de texto ou clicando num link ou boto. Nesses casos, a requisio
29
enviada para a mesma pgina da qual foi submetido o formulrio. Como a View j existe, ela
precisa ser restaurada; nesse caso, o JSF utiliza as informaes restauradas para reconstruo
do estado da View. Uma vez reconstrudo o estado, o fluxo passa para a prxima fase do ciclo
de vida (SOUSA, p.8-18).
Apply Request Values

Tambm conhecido como processo de decodificao, a fase Apply Request Values
responsvel por atribuir aos componentes o valor submetido atravs de parmetros enviados
no request. Todo componente que aceita a entrada de valores possui uma propriedade que
recebe o valor original enviado pelo usurio. Esse valor obtido com base do ID do componente. Um componente pode ser renderizado mais de uma vez, geralmente em virtude de uma
interao. Para garantir um ID nico para cada componente, o JSF adiciona como prefixo o
ID do componente pai, o ID resultante conhecido como Client Id. Por exemplo, o Client Id
de uma caixa de texto com ID nome dentro de um formulrio com ID cadastro ser cadastro:nome (SOUSA, p.8-18).
Todo componente possui uma propriedade immediate que indica se o valor deve ser
convertido e validado nesta fase. J em componentes do tipo comando, como um link ou boto, essa propriedade usada para ignorar todos os valores do formulrio. A utilizao dessa
opo ser para botes cancelar ou para link que aceitam valores de um controle especfico.
Concluda a decodificao, verificado se houve algum erro de validao ou converso. Caso
exista algum erro, o ciclo avana para a fase Render Response; caso contrrio, o ciclo avana
para a prxima fase (SOUSA, p.8-18).
Process Validation
Nesta fase assegurado que todos os valores enviados so vlidos. A validao desempenhada diretamente pelo componente e tambm pode ser delegada para um ou mais validadores. Antes disso, o valor submetido pelo usurio precisa ser convertido, o que feito por
meio de um conversor padro ou atravs de um conversor especfico (SOUSA, p.8-18).
Uma vez validado o valor enviado pelo usurio, o mesmo verificado com o valor do
componente; caso seja diferente, gerado um evento de alterao de valor. Nesse ponto,
eventos value-change e qualquer outro evento associado a esta fase so executados pelos listeners apropriados. Caso todos os valores submetidos sejam vlidos, a execuo passa para a
30
prxima fase do ciclo; em caso de erros, a pgina renderizadas com as mensagens de validao (SOUSA, p.8-18).
Update Model Values

Nesta fase temos os valores enviados atualizados, convertidos nos tipos de dados desejados, validados e associados aos objetos de modelo e aos Backing Beans. E tudo isso sem
qualquer cdigo de aplicao, essa a grande vantagem de se usar Faces: o desenvolvedor
foca apenas na implementao das lgicas de negcio, e as tarefas repetitivas e tediosas so
executadas automaticamente. Completada essa fase, a execuo para a prxima fase (SOUSA,
p.8-18).
Invoke Application
Essa fase responsvel por chamar qualquer evento ou ao registrados para a requisio. Nesse momento, a aplicao tem o estado necessrio para executar todos os eventos e
lgicas de negcios da aplicao. H dois tipos de mtodos que podem ser chamados neste
momento: action handlers e event listeners (SOUSA, p.8-18).
Action handlers so usadas para controle de paginao. Nesse contexto, dependendo
da lgica de negcio processada, definida a qual pgina o usurio deve ser redirecionado.
Um action handlers um mtodo de um Backing Bean sem argumentos que retorna uma
string que determinar a pgina de destino. Por ser um mtodo sem argumentos, o action
handler no contm a informao de qual componente chamou a ao (SOUSA, p.8-18).
Event listener no tem retorno e recebe como parmetro um objeto do tipo ActionEvent, que contm informaes relacionadas ao evento, como o componente que o originou, a
phaseld relacionada ao ciclo de vida JSF. Por no ter retorno, este tipo de ao ideal para
executar lgica de negcios quando o usurio clica em um boto e um campo atualizado, ou
selecionando uma opo de uma caixa de seleo, que determina a exibio de valores adicionais. Os mtodos listener podem ser criados dentro de Backing Beans ou em classes separadas, mas h uma vantagem em se criar classes separadas que a possibilidade de reutilizao
em mais de uma pgina (SOUSA, p.8-18).
31
Render Response
Esta a ultima fase do ciclo de vida JSF, todo o processamento no nvel de framework
e no nvel da aplicao j foi realizado. Essa ltima fase tem dois objetivos: o primeiro gerar
e enviar a resposta para o usurio e o segundo salvar o estado da View para ser restaurada no
prximo request, caso a pgina venha requisit-la novamente (SOUSA, p.8-18).
Durante a renderizao dos componentes, os conversores so novamente chamados
para transformar o objeto em uma String para ser visualizada. Depois de completada a fase, o
container web transmite fisicamente a resposta para o usurio, a qual exibida no navegador
(SOUSA, p.8-18).
2.4.2 Pginas HTML

Uma pgina web um documento adequado para Word Wide Web que pode ser acessado por um navegador web e apresentado em algum dispositivo de sada como tela de computador, celular, TV ou similares. Em geral. E declarada usando HTML ou XHTML. Pode ser
esttica ou ser gerada dinamicamente no servidor web. composta por componentes visuais
tais como caixas de combinao (comboboxes) (NUNES; MAGALHES, p. 22-36).
Em JSF declaramos uma pgina web dinmica usando Facelets ou JSP. Esta declarao representada em memria como um conjunto de componentes visuais e no visuais
chamado rvore de componentes. Uma das responsabilidades da rvore de componentes
renderizar a pgina web (NUNES; MAGALHES, p. 22-36).
O processamento da rvore de componentes inicia quando um evento de um componente de ao enviado ao servidor. Por exemplo, o clique de um boto. Este processamento
composto por seis fases: identificao ou criao da rvore (1), recuperao dos parmetros
da requisio (2), converso e validao dos parmetros (3), atualizao de valores nos controladores de pgina (4), invocao da ao (5), e rederizao da resposta (6), (NUNES; MAGALHES, p. 24-35).
Um recurso interessante das pginas JSF que o desenvolvedor pode desenh-las ainda sem controladores associados e j ter a noo aproximada da identificao visual final. Em
outras palavras, no necessrio fazer pginas em HTML primeiro e depois converter em
XHTML do JSF. As pginas podem ser desenhadas com os componentes que sero usados na
aplicao, mais ainda sem classes Java associadas (NUNES; MAGALHES, p. 24-35).
32
2.4.3 Navegao entre pginas
Conceitualmente, o sistema de navegao JSF semelhante ao sistema de navegao
do Struts. S que em JSF no temos as to conhecidas ActionForward, mas, por outro lado,
temos o navigation handler, que o corao do sistema de navegao. E ele que determina
qual ser a prxima pgina a ser carregada. A base de trabalho de um navigation handler a
resposta de action events. E a resposta de uma action event est associada com um action method que executa uma determinada lgica de negcio e retorna uma determinada String como
resultado ou pode ser um valor fixo na propriedade action de um link ou um boto. As regras
de navegao so definidas no arquivo de configurao (SOUSA, p.14-26).
2.4.4 Componentes
Em pginas JSF declaramos os componentes visuais e no visuais que formaro a rvore de componentes. O conceito de componente criado no JSF muito rico: classes Java
definem comportamentos e atributos de componentes que podem ser renderizados no s em
HTML, como tambm em outras linguagens de marcao (NUNES; MAGALHES, p. 2435).
Ainda na renderizao HTML, a infraestrutura para componentes em JSF possibilitou
que o conjunto bsico de componentes visuais fosse significativamente ampliado por bibliotecas de componentes de terceiros, como Apache Tomahawk, Jboss Richfaces, Oracle ADF
Faces e IceSoft IceFaces (NUNES; MAGALHES, p. 24-35).
Para o desenvolvedor isto significa que funcionalidades interativas desejadas na web e
bastaknte conhecidas em aplicaes desktop esto disponveis sem que este desenvolvedor
precise dominar HTML, Javascript e CSS (NUNES; MAGALHES, p. 24-35).
Entretanto, em uma aplicao no rara a situao em que precisamos criar componentes compostos: combinar vrios componentes prontos em uma rea para reuso. Uma rea
de login, uma rea de botes de ao, um menu com busca integrada e uma caixa de texto
combinada com suas respectivas mensagens de erro e informao so alguns exemplos (NUNES; MAGALHES, p. 24-35).
No JSF o conceito de componentes compostos foi incorporado a partir das ideias de
templating do Facelets. Entretanto, evoludo a partir dos maduros recursos existentes na soluo Tag Files do JSP e dos prprios conceitos de componentes j disponveis na especifica-
33
o. Para criar um componente composto JSF basta criar um arquivo XHTML e public-lo na
pasta de recursos (NUNES; MAGALHES, p. 24-35).
Managed Beans (Controladores de pgina)

Controladores de pginas tm como responsabilidade disponibilizar dados e mtodos
que possam ser referenciados por uma pgina web para entrada de dados, apresentao de
dados ou tratamento de eventos. Em JSF os controladores so chamados de Managed Beans
(SOUSA, p.14-26).
Existem dois tipos de controladores: aqueles que no referenciam as classes de componentes no cdigo Java e o que referenciam. Os primeiros so chamados backing beans e a
referncia classe de componente chamada vnculo a componentes ou Component Binding.
Os controladores de pgina que no referenciam componentes so chamados POJOs e apenas
utilizam vnculo a dados (Data Binding) e vnculo a mtodos (Method Binding). Nos controladores de pgina JSF a configurao do Managed Bean e feita usando a anotao
@ManagedBean e alguma das anotaes de escopo (SOUSA, p.14-26).
O JSF ser utilizado como linguagem de programao para o desenvolvimento do sistema Web utilizando como ambiente de desenvolvimento o NetBeans, junto com o Hibernate
para mapeamento objeto/relacional.
2.5
Hibernate
Hibernate uma ferramenta para mapeamento objeto/relacional para ambiente Java. O
termo mapeamento objeto/relacional (ORM) refere-se tcnica de mapeamento de uma representao de dados em um modelo de objetos para um modelo de dados relacionais, baseado
em um esquema E/R. O hibernate no cuida somente do mapeamento das classes Java para
tabelas do banco de dados (e dos tipos de dados Java para os tipos de dados SQL), mas tambm prov facilidades para consultar e retorna os dados da consulta, e pode reduzir significativamente o tempo de desenvolvimento em contrapartida ao tempo gasto pelas operaes manuais dos dados feitas com SQL e JDBC (PRIMO; SANTOS, p.46-57).
34
Segundo Gonalves (2007):
O Hibernate um framework que se relaciona com o banco de dados, onde esse relacionamento conhecido como mapeamento objeto/relacional para Java, deixando
o desenvolvedor livre para se concentrar em problemas da lgica do negcio. Sua
simplicidade em configurao, d ao desenvolvedor algumas regras para que sejam
seguidas como padres de desenvolvimento ao escrever sua lgica de negcio e suas
classes persistentes. De resto, o Hibernate se integra suavemente ao seu sistema se
comunicando com o banco de dados como se fosse diretamente feito por sua aplicao. Uma mudana de banco de dados, nesse caso, no se torna traumtica, alterando
apenas um ou outro detalhe na configurao do Hibernate.
O Hibernate uma ferramenta de consulta e persistncia objeto/relacional de alta performance. Uma das solues ORM mais flexveis e poderosas do mercado, ele faz o mapeamento de classes Java para tabelas de banco de dados e de tipos de dados Java para tipos de
dados SQL (PRIMO; SANTOS, p.46-57).
Ele fornece consultas e facilidades para retorno dos dados que reduzem significativamente o tempo de desenvolvimento. A meta do projeto do Hibernate aliviar os desenvolvedores de 95% das tarefas comuns de programao relacionada persistncia, como a codificao manual com SQL e a API JDBC. O Hibernate gera o SQL para a aplicao, no necessitando o tratamento dos result sets (comuns nas conexes manuais com JDBC), faz a converso entre registros e objetos e permite que sua aplicao seja portvel para qualquer banco
de dados SQL. (PRIMO; SANTOS, p.46-57).
Arquitetura
O projeto Hibernate composto por vrios pacotes Java. Cada pacote tem uma funcionalidade especfica e alguns deles s so disponveis a partir da verso 5.0 do Java SE e do
Java EE. A Figura 5 apresenta um quadro ilustrativo.
Figura 5: Arquitetura do Hibernate para plataforma Java.
35
Os pacotes apresentados na Figura 5 so obrigatrios para o desenvolvimento utilizando o Hibernate. O nico pacote que deve estar sempre presente independente da plataforma
Java utilizada o Core. Alm desses pacotes existem outros que agregam outras funcionalidades ao framework e que podem ser adicionados mediante a necessidade do desenvolvedor
da aplicao, so eles: Hibernate Shard, Hibernate Validator, Hibernate Search e Hibernate
Tools (PRIMO; SANTOS, p.46-57). A Tabela 1 apresenta uma lista e uma descrio resumida de todos os pacotes.
Pacote
Descrio
Hibernate Core
Hibernate para Java, APIs nativas e metadados XML
Hibernate Annotation
Mapeia as classes com anotaes do JDK 5.0
Hibernate EntityManager
API de persistncia Java padro para Java SE e Java EE
Hibernate Shards
Framework para particionamento horizontal de dados
Hibernate Validator
API para anotao e validao da integridade dos dados
Hibernate Search
Integrao do Hibernate com o Lucene para indexao e

consulta de dados.
Hibernate Tools
Ferramentas de desenvolvimento para Eclipse e Ant.
Jboss Seam
Framework para aplicao JSF, Ajax e EJB 3.0/Java EE

5.0.
Tabela 1. Lista dos pacotes Hibernate e uma descrio resumida de cada um deles
Hibernate Core
O Hibernate Core est presente em todas as possveis arquiteturas Java onde se possa
utilizar o Hibernate. O Hibernate prov transparent persistence (persistncia transparente); o
nico requisito para uma classe ser persistente ter declarado um construtor default, ou seja,
sem argumentos. Ele oferece ainda opes de consulta sofisticadas, seja com SQL diretamente, ou uma linguagem de query orientada a objeto e independente de SGBD HQL (Hibernate
Query Language), ou ainda, com uma API de queries Criteria muito til para gerar queries
dinamicamente (PRIMO; SANTOS, p.46-57).
36
Outras caractersticas do Hibernate Core:
Modelo de Programao Natural Hibernate suporta o idioma OO natural: herana, polimorfismo, composio e colees Java;
Suporte para modelo de objetos com granularidade fina uma rica variedade de
mapeamento para colees e objetos dependentes;
Sem aumento no tempo de construo do bytecode No acontece a gerao de
cdigo extra ou de bytecode no processo de build da aplicao.
Hibernate Annotations
O Hibernate, como toda ferramenta para mapeamento objeto/relacional, requer metadados que governem as transformaes dos dados de uma representao para outra (e viceversa). Estes metadados eram tradicionalmente fornecidos por arquivos XML, mas a partir da
verso 3.2 do Hibernate, pode-se usar as anotaes do JDK 5.0 para fazer o mapeamento
(PRIMO; SANTOS, p.46-57).
Hibernate EntityManager
A especificao EJB 3.0 reconhece a vantagem e o sucesso do mapeamento objeto/relacional feito de forma transparente, estabelecendo uma API padro inspirada no Hibernate. O Hibernate EntityManager, junto com o Hibernate Annotations, implementam as interfaces e as regras do ciclo de vida definidos pela nova especificao EJB 3, utilizando por baixo a maturidade do Hibernate Core (PRIMO; SANTOS, p.46-57).
O Entity Manager o objeto principal da API EntityManager. Ele usado para acessar
um banco de dados de uma determinada unidade de persistncia. Uma unidade de persistncia
define o banco de dados e as respectivas classes persistentes para as quais o Entity Manager
prov suporte para criao, atualizao, remoo e consultas. Uma aplicao poder definir
vrias unidades persistentes, uma para cada banco de dados que acessar (PRIMO; SANTOS,
p.46-57).
37
2.6 Spring Security
O Spring Security surgiu da necessidade de melhorar o suporte segurana oferecido
pela especificao Java EE. O framework centraliza a configurao em um nico XML, dispensando configuraes do container e tornando a aplicao web um arquivo WAR auto contido (ZANINI, p.28-38).
Segundo Jamacedo (2013), Spring Security um framework responsvel por cuidar
da autenticao e autorizao de usurios em aplicaes web.
Para comear a utiliz-lo basta adicionar seus JARs ao classpath, configurar um filtro
e um listener no web.xml e criar um application contexto (XML de configurao). O XML
centraliza todas as configuraes de autenticao e autorizao. As tags <intercept-url> definem quais roles podem acessar cada grupo de URLs. A tag <authentication-provider> define a
fonte de dados para as informaes de usurios (banco de dados, arquivos de propriedades,
LDAP, etc.) (ZANINI, ano).
Quando necessrio, possvel utilizar os eventos publicados pelo framework a cada
sucesso ou falha na autenticao ou autorizao. Ouvir os eventos permite criar complexos
casos de gerenciamento de usurios. O Spring Security ainda oferece integrao com a API de
servlets, taglibs para facilitar a codificao de JSPs, suporte HTTPS, segurana em mtodos
com uso de anotaes e suporte a autenticao com LDAP ou certificados X509 (ZANINI,
p.28-38).
Com o Spring Security possvel criar um mecanismo de autenticao e autorizao
para aplicaes web em questo de minutos. O framework foca facilitar a implementao dos
casos de uso mais frequentes, porm oferece valiosos pontos de extenso para requisitos mais
complexos. Por fim, disponibilizar suporte a inmeros diferentes tipos de autenticao e integrao com as mais usadas tecnologias na rea de segurana (ZANINI, p.28-38).
O Spring Security e aplicvel a qualquer aplicao web que necessite restringir seus
recursos para diferentes tipos de usurios, bem como assegurar que se autentiquem de forma
prtica e segura (ZANINI, p.28-38).
2.7 PrimeFaces
A biblioteca do PrimeFaces composta por cerca de 100 componentes de interface
todos estes personalizados e de cdigo aberto, e implementa tecnologia AJAX, grficos ani-
38
mados JavaScript entre outros. A utilizao do PrimeFaces em projetos proporciona uma infinita gama de possibilidades para criao de layouts j que em seu ShowCase a cerca de 30
temas diferentes que podem ser facilmente adicionados ao seu projeto (Santos, et.al. 2010).
AJAX a sigla de Asynchronous JavaScript and XML, no uma tecnologia e
sim o uso de tecnologias incorporadas que tem as principais o Javascript e o XML,
onde juntos so capazes de torna o navegador mais interativo, utilizando-se de solicitaes assncronas de informaes. sim um conjunto de tecnologia; cada uma
com sua forma de exibir e interagir com o usurio.
O primeFaces ser usado na construo das interfaces, ela uma biblioteca que define
componentes JSF.
39
3. DESENVOLVIMENTO
A partir de agora ser dado incio ao processo de desenvolvimento do projeto. Colocando em prtica todos os conhecimentos adquiridos, atravs dos estudos realizados sobre as
diversas ferramentas que sero utilizadas, bem como um maior aprofundamento do contedo
no decorrer do desenvolvimento, onde sero mostrados os passos importantes para o desenvolvimento e funcionamento do mesmo.
3.1 Estrutura do Projeto

O projeto sysPrefeitura apresentado na Figura 6, teve incio com as configuraes dos
arquivos XML, que se encontra no diretrio WEB-INF, so eles, os arquivos applicationContext.xml e web.xml. No projeto ainda foram criadas quatro pastas:
1. Resources: Contm as pastas css e imagens.
2. Sistema: Contm a pgina index.xhtml que s poder ser acessadas por usurios
logado no sistema.
3. Templates: Contm uma pgina que define o layout da pgina em topo, contedo
e rodap.
4. Pginas Web: Contm as pginas index.xhtml, que ter o formulrio de login, a
pgina login_falhou.xhtml e acesso_negado.xhtml, que ser acionadas caso os dados do usurio esteja incorretos.
O projeto ainda conta com o pacote de cdigo fonte que contm os pacotes Default,
com.sysprefeitura.beans, com.sysprefeitura.model.daos, com.sysprefeitura.model.entidades e
com.sysprefeitura.util.
O pacote com.sysprefeitura.beans possui a classe UsuarioBean. O JavaBeans so classes que possuem o construtor sem argumentos e mtodos de acesso get e set. (GONALVES,
2007).
O pacote com.sysprefeitura.daos possui a classe UsuarioDAO. O padro DAO (Data
Access Object) o padro mais utilizado para acesso a dados contido em um banco de dados.
Ele fornece uma interface independente, na qual voc pode usar para persistir objetos de dados. A ideia colocar todas as funcionalidades encontradas no desenvolvimento de acesso e
trabalho com dados em um s local, tornando simples sua manuteno (GONALVES,
2007).
40
Tipicamente um DAO inclui mtodos para inserir, selecionar, atualizar e excluir objetos de um banco de dados. Dependendo de como implementado o padro DAO, pode se ter
um DAO para cada classe de objetos em uma aplicao ou poder ter um nico DAO que
responsvel por todos os objetos (GONALVES, 2007).
Figura 6: Projeto sysPrefeitura
41
3.2 Configurao do arquivo web.xml
O diretrio WEB-INF possui o arquivo web.xml, que o Deployment Descriptor da
aplicao. Ele contm informaes de configurao como parmetros de inicializao, mapeamento de Servlets entre outros (PEREIRA, p.52-60).
Para facilitar o entendimento do arquivo web.xml, o mesmo foi dividido em varias
partes separadas por comentrios. A Figura 6 apresenta a estrutura do projeto e onde se encontra o arquivo web.xml.
Na primeira parte da configurao do arquivo web.xml foi configurado o JSF apresentado na Figura 7, includo o servlet Faces Servlet, que ser responsvel pelas renderizaes
feitas pelo JSF.
Figura 7: Configurao do JSF.
Na segunda parte temos a configurao do Spring apresentado na Figura 8, onde est

sendo mapeado um listener (ContextLoaderListener) que responsvel por inicializar o contexto do Spring na aplicao. Esse contexto ser utilizado pelo Spring para fabricar beans,
injetar as dependncias, publicar eventos, entre outros (PEREIRA, p.52-60).
A Figura8: Apresenta a configurao do Spring.
42
Na terceira parte temos a configurao do Spring Security apresentado na Figura 9,
que descrever um filtro HTTP para interceptar todas as URLs acessadas e conferir suas permisses de acesso. Por isso, o filtro aplicado com o url-pattern /*.
A Figura9: Apresenta a configurao do Spring Security.
E na ltima parte temos a configurao do Prime Faces apresentado na Figura 10, utilizando o tema delta. Caso o desenvolvedor pretenda mudar o tema da aplicao, basta s trocar o nome delta na configurao, pelo nome do novo tema.
A Figura10: Apresenta a configurao do Prime Faces.
3.3 Configurao do Spring Security

As configuraes do Spring so muitas extensas e se dividem em configuraes gerais,
do banco de dados e de segurana (PEREIRA, p.52-60).
As configuraes do Spring Security apresentada na Figura 11, 12 e 13, so feitas no
arquivo applicationContext.xml dentro do pacote WEB-INF, nesse arquivo criamos as regras
de segurana da aplicao.
A Figura11: Configurao do Spring Security-applicationContext.xml.
43
A tag <http> a tag root de todas as configuraes de seguranas da aplicao, seu
atributo auto-config marcado com true configura o framework para utilizar autenticao
HTTP-Basic, cria um formulrio de login de autenticao padro para configurar o logout
(PEREIRA, p.52-60).
A tag <intercept-url> usada para determinar o conjunto de padres de URL que a
aplicao est interessada em controlar o acesso e a respectiva restrio. O atributo pattern
descreve o caminho que ser feito o controle e o atributo access define a restrio. Desta forma todas as pginas que estive dentro da pasta sistema s sero acessadas por usurio autenticado (PEREIRA, p.52-60).
O objetivo da tag <form-login> configurar o caminho da pgina de login (atributo
login-page), bem como a pgina que o usurio ser redirecionado caso a login falhe (atributo
authentication-failure-url) (PEREIRA, p.52-60).
Ainda no mesmo arquivo de configurao iremos mapear as informaes do banco de
dados: usurio, senha, url e driver para que o Spring crie e gerencie o dataSource.
Por fim, na tag <authentication-manager> definimos que o authentication-provider

que o Spring Security ir executar vai ser o dataSource.
44
3.4 Configurao do Hibernate
A configurao do hibernate apresentado na Figura 14, foi realizado em uma arquivo
dentro do pacote de Cdigos-fonte no pacote <pacote default>, esse arquivo o hibernate.cfg.xml. Nesse arquivo podem ser descritas vrias unidades de persistncia, diferenciadas
pelo nome, e cada qual com as seguintes propriedades: driver de banco de dados, usurio e
senha de acesso, url de acesso ao banco e dialeto utilizado. Existe um dialeto especifico para
cada banco de dados (PRIMO; SANTOS, p.46-57).
As configuraes aqui esto divididas em elementos <property/>, onde cada um contm um atributo chamado name, indicando o que ele faz.
Figura14: Arquivo hibernate.cfg.xml
Em sequncia temos cada valor do atributo name listado por ordem de apario na
configurao do Hibernate.
Hibernate.dialect: o dialeto no qual o Hibernate dever utilizar para se comunicar
com o banco de dados. Para configurao do hibernate foi utilizado o dialeto
org.hibernate.dialect.MySQLDialect, pois na aplicao foi utilizado o banco de
dados MySQL, e o valor que define a forma de gerao foi o update (GONALVES, 2007).
45
Hibernate.connection.driver_class: nome da classe do drive JDBC do banco de
dados que est sendo utilizado. No caso a configurao est utilizando o driver do
MySQL (GONALVES, 2007).
Hibernate.connection.url: a URL de conexo especfica do banco de dados que
est sendo utilizado (GONALVES, 2007).
Hibernate.connection.username: o nome de usurio com o qual o Hibernate deve
se conectar ao banco de dados. No caso, pela configurao root (GONALVES,
2007).
Hibernate.hbm2ddl.auto: Esta propriedade define que as tabelas do banco de dados sero geradas automaticamente pelo Hibernate. Existem dois valores que define a forma de gerao: o valor create-drop informa que o banco sempre recriado
na inicializao e o valor update denota que o banco atualizado apenas se houver
alterao no modelo, ou seja, aps a incluso de novos mapeamentos ou modificao em mapeamentos existentes (PRIMO; SANTOS, p.46-57).
Depois de ser criada a classe usurio para gerao da tabela, e necessrio mapear a
mesma, adicionando na configurao do hibernate em < mapping> seguindo do nome class, o
caminho exato da classe que ser mapeada.
3.5 Anotaes
O objetivo das anotaes possibilitar a declarao de metadados nos nossos objetos,
isto , configuraes de uma classe podem ficar dentro dela, em vez de em um XML.
Toda classe Java que ser persistida em um banco de dados atravs do Hibernate
considerada uma entidade e declarada utilizando a anotao @Entity (acima da declarao
da classe) (PRIMO; SANTOS, p.46-57). Na Figura15, temos um exemplo da declarao da
anotao @Entity.
Figura15: Declarao da anotao @Entity
A anotao @Table definida em nvel de classe e permite que voc descreva o nome
da tabela que ser utilizada para o mapeamento da entidade. Se nenhum @Table for declara-
46
da, os valores padres sero utilizados: no caso o prprio nome da classe (PRIMO; SANTOS,
p.46-57).
O @Table elemento tambm contm um esquema e um catlogo de atributos, e eles
precisam ser definidos. Voc tambm pode definir restries de unicidade para a tabela usando o @UniqueConstraint anotao em conjunto com @Table (PRIMO; SANTOS, p.46-57).
A anotao @Id permite que o usurio defina qual propriedade a chave primria da
sua entidade. A propriedade pode ser preenchida pela prpria aplicao ou ser gerada pelo
Hibernate. possvel definir a estratgia para gerao graas anotao @GeneratedValue
(PRIMO; SANTOS, p.46-57). Na Figura16, temos a declarao da anotao @Entity e
@GeneratedValue.
Figura16: Declarao da anotao @Entity e @GeneratedValue.
So quatro tipos possveis de anotao @GeneratedValue.

1) TABLE utiliza uma tabela com a informao dos ltimos Ids para gerao dos
prximos;
2) IDENTITY utilizado quando voc possui bancos que no suportam sequence,
mas suportam colunas identidade;
3) SEQUENCE utilizando uma sequence para gerar a chave primria;
4) AUTO utiliza uma das estratgias acima de acordo com o banco de dados.
Associao Um-para-Um (OneToOne)

possvel associar entidades atravs de um relacionamento um-para-um usando a
anotao @OneToOne apresentado na Figura 17. Existem trs casos para utilizao deste tipo
de relacionamento: ou as entidades associadas compartilham os mesmos valores da chave
primaria; ou uma chave estrangeira armazenada por uma das entidades ou uma tabela associativa usada para armazenar o link entre duas entidades (PRIMO; SANTOS, p.46-57).
Figura 17: Declarao da anotao @OneToOne.
47
A anotao @Column permite mapear as colunas de uma tabela. No cdigo abaixo,
Figura 18, est sendo mapeada a coluna login e senha.
Figura 18: Declarao da anotao @Column.
3.6 Construo da tabela Usuarios

A primeira tabela a ser criada foi a de usuarios, para autenticao e autorizao no
banco de dados com Spring Security. O primeiro passo foi criao do pacote
com.sysprefeitura.model.entidade no projeto sysPrefeitura, como foi explicado anteriormente. Nesse pacote foi criada a Classe Usuario, essa ser mapeada com anotaes e usar o
Hibernate para manipulao dos objetos em banco de dados. A tabela usurio responsvel
por guarda o id, login, senha, nome, permissao e secretaria_id. A Figura 19 apresenta a criao da classe usurio para ser persistida.
package com.sysprefeitura.model.entidades;
import java.io.Serializable;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;
import javax.persistence.OneToOne;
import javax.persistence.Table;
/* *A anotao @Entity indica que a classe uma classe persistente e a anotao
@Table(name="usuarios") denota a tabela onde os dados sero persistidos. **/
@Entity
@Table(name="usuarios")
public class Usuario implements Serializable{
/* *A anotao @Id define qual propriedade a chave primria da entidade * */
@Id
@GeneratedValue /* * A anotao @GeneratedValue Define a estratgia para a gerao de Id, nesse caso ser gerada automaticamente pelo banco de dado. * */
/* Para realizar o mapeamento e necessrio que para cada campo da tabela seja criada
uma varivel do tipo correspondente */
private Long id;
@OneToOne
/* Associa entidades atravs de um relacionamento um-para-um. */
48
private Secretaria secretaria;
private String permissao;
private String nome;
@Column (unique = true) /* Ir mapear as colunas login e senha da tabela usuarios. */
private String login;
private String senha;
/* O mapeamento exige que para cada varivel criada existam os mtodos get e set */
Figura 19: Classe Usuario.java
3.7 UsuarioDAO
Para adicionar ao sistema comportamentos de gravar um cadastro foi adicionado ao
pacote com.sysprefeitura.model.daos, a Classe UsuarioDAO, que ir fazer acesso aos dados
no banco.
Foi criado nessa classe o mtodo, gravar (), apresentado na Figura 20, tem a incumbncia de armazenar novos cadastros no banco de dados.
Figura 20. Mtodo gravar.
A classe HibernateUtil traz a sesso atravs do mtodo getSessionFactory(), iniciando

assim uma sesso, atravs do objeto Session criado nessa classe. Esse mtodo utiliza um objeto do tipo Transaction. Quando utilizado em conjunto com um objeto Session, permite transaes em um banco de dado relacional. Para gravar os dados vindo do objeto Usuario, o mtodo merge () do objeto Session utilizado. A transao efetuada atravs do mtodo commit
(). Em caso de erro, a clusula catch chama o mtodo rollback () para desfazer a transao.
Depois de utilizado, o objeto Session fechado atravs da clusula finally, atravs do mtodo
close ().
49
3.8 Spring Security
Autenticao
A autenticao a verificao das credenciais (nome de usurio e senha) da tentativa
de conexo. Esse processo consiste no envio de credenciais do cliente para o servidor em um
formulrio de texto simples ou criptografado usando um protocolo de autenticao. O Spring
Security possui vrias formas de realizar a autenticao. Por exemplo, podemos utilizar o
formulrio de login que gerado automaticamente pelo framework ou contruir um prprio
formulrio personalizado. Os usurios da aplicao que sero autenticados podem ser definidos diretamente no arquivo XML de configuraes do framework ou em um banco de dados
(PEREIRA, p.52-60).
Autorizao
Autorizao utilizada para verificar se determinado usurio previamente autenticado
possui permisso para usar, manipular ou executar o recurso em questo. a concesso de
uso para determinados tipos de servio, dada a um usurio previamente autenticado(PEREIRA, p.52-60).
O Spring Security possui uma abordagem declarativa para a segurana, baseada em
roles (papis). Por exemplo, uma aplicao de uma pousada poderia ter dois roles: um ADMIN, que possui permisso para cadastrar acomodaes e reserv-las, e um COMUM, que
possui permisso apenas para reserv-las. Dessa forma os usurios que forem utilizar essa
aplicao teriam que possuir algum desses roles (PEREIRA, p.52-60).
O projeto sysPrefeitura possuir dois roles: um ROLE_SUPER, destinado ao administrador do sistema, que possuir permisso para cadastrar e excluir usurios e para cadastrar e
excluir setores, e um ROLE_ADMIN, destinado ao usurio, que possuir permisso para enviar, excluir e baixar documentos oficiais.
OBS: Para dar continuao ao projeto foi primeiro necessrio criar a tabela usurios
com hibernate para autenticao e autorizao no banco de dados utilizando Spring Security,
como foi mostrado acima. A tabela usurio responsvel por guarda o id, login, senha, nome,
permissao e secretaria_id.
50
3.9 Pgina de Login (index.xhtml)
A Figura 21 apresenta o formulrio da pgina index.html de login, onde temos os
campos de login, senha e um boto Acesse sua Conta que redireciona a aplicao para uma
rea restrita (/sistema/index.xhtml), caso senha e login estiverem corretos. O formulrio ainda
contm o atributo required com o valor true para que o mesmo passe a ser obrigatrio em seu
preenchimento. Para que uma mensagem aparea, caso o usurio no preencha um campo,
est sendo utilizado o atributo requiredMessage, que receber a mensagem que ser mostrada
ao usurio. O atributo value est sendo usado para dar o nome ao campo, no caso e-mail e
senha. O atributo action est definindo o local para onde sero enviados os dados do formulrio.
Figura 21: Formulrio de login (index.xhtml)
Entendendo o processo de autenticao

A pgina index.xhtml, mostrada na Figura 21, contm o formulrio com os campos
j_username e j_password que armazenaro as credenciais do usurio. Esses dados sero sub-
51
metidos para a classe SegurancaBean mostrado na Figura 22, quando o usurio clicar no boto
Acesse sua conta.
Essa classe responsvel por receber o pedido de autenticao e verificar se as credenciais do usurio so vlidas. Para realizar esse processo ela invoca o mtodo doLogin ()
dentro da classe SegurancaBean.
Figura 22. Classe SegurancaBean
Caso no seja encontrado o usurio no banco de dados, o framework interrompe o fluxo de autenticao e redireciona o usurio para a pgina de usurio/senha incorreto. Se existir
um usurio com o j_username e j_password informado o usurio ter acesso ao sistema, ou
seja, a pgina index.xhtml dentro da pasta sistema. A Figura 23 mostra a pgina de login.
52
Figura 23. Pgina de Login (index.xhtml)
Deste modo foi concluda as configuraes estruturais da aplicao que consistiram

em criar o projeto, configurar os arquivos XML para integrar o Spring, Spring Security, JSF e
PrimeFaces, configurao do hibernate, criao da tabela usurio no banco de dados para
autenticao e autorizao no sistema utilizando Spring Security e a criao do formulrio da
pgina de login, bem como a criao das classes UsuarioDAO e SegurancaBean.
3.10 CDI
A CDI uma especificao Java, cujo nome completo Context and Depen- dency
Injection for Java EE (CORDEIRO, p. 1-208).
Para configurar o CDI necessrio copiar todos os arquivos weld-servlet.jar que foram baixados para a pasta do projeto, no caso foi copiado para sysprefeitura/lib/Weld_CDI. A
Figura 24 abaixo apresenta todos os arquivos Weld que foi adicionado no projeto.
53
Figura 24. Weld
Segundo Cordeiro (2013), Um pacote CDI So aquelas classes utilitrias que ns j

temos prontas dentro de um jar, em que podemos injetar instncia delas dentro da nossa aplicao colocando um arquivo chamado beans.xml dentro da pasta WEB-INF da nossa aplicao. A Figura 25 apresenta a configurao do arquivo beans.xml.
Figura 25: Arquivo beans.xml
54
Arquivo de configurao do Weld no Tomcat no arquivo Context.xml na Figura 26
Figura 26: Configurao do CDI no arquivo Context.xml
Em seguida necessrio adicionar no arquivo web.xml o listener do Weld. A Figura 27

apresenta o arquivo web.xml com o listener do Weld.
Figura 27: Configurao do CDI no arquivo web.xml
A CDI uma API para injeo de dependncias e contextos. Em Seam e Spring, as

dependncias funcionam, principalmente, nomeando beans e os vinculando aos seus pontos
de injeo pelos nomes. A atribuio principal da anotao @Named definir o bean com o
objetivo de resolver instrues EL na aplicao, normalmente por meio dos resolvedores JSF
EL (CORDEIRO, p. 1-208).
Escopo de requisio com @RequestScoped O escopo request
o mais comum em uma aplicao web, pois toda interao entre o browser e o servidor um request. Esse escopo define um ciclo de vida que se inicia no momento em que a
requisio do usurio chega no servidor, e dura todo o processamento e tambm todo o processo de gerao da resposta para o usurio. Somente quando a resposta para o usurio terminada que o request termina. Parece simples, mas preciso ficarmos atentos principalmente
a essa ltima parte: a gerao da resposta para o usurio. No adianta acompanharmos a execuo passo a passo dentro da lgica da aplicao e achar que est tudo certo, pois se algo
ocorrer depois do processamento, mas antes da gerao da resposta terminar, ainda podemos
ter problema, pois o ciclo como um todo que importa (CORDEIRO, p. 1-208). Uma forma
de tentarmos ilustrar o funcionamento desse escopo atravs da Figura 28 a seguir:
55
Figura 28: Ilustrao do Escopo Request
A Figura 28 exemplificamos a chamada da URL /editar.jsf. Onde o bean criado no

momento em que a requisio chega no servidor, e termina no momento em que sai dele
(CORDEIRO, p. 1-208).
Escopo de sesso como @SessionScoped
O processo de criao e descarte de um bean no muda se o escopo request ou session, o que muda quando o processo ocorre. Enquanto o request compreende cada invocao
ao servidor feita pelo cliente, a sesso engloba todas as requisies de um mesmo cliente. Para
facilitar, s imaginar o processo de autenticao em uma aplicao web. Enquanto tivermos
com o browser aberto, estaremos logados na aplicao, isso porque as informaes de autenticao costumam ficar no escopo de sesso. Cada vez que acessamos uma aplicao pela primeira vez, comum determinado navegador, criada uma nova sesso. Mas isso no cria automaticamente os beans de escopo sesso, estes geralmente so criados quando utilizados pela
primeira vez, e duram enquanto a sesso existir. Enquanto conseguimos perceber pelo console
que, no escopo request, os objetos so recriados a cada solicitao; como escopo sesso, s
perceberemos essa criao uma vez para cada browser utilizado. Geralmente a sesso mantida atravs de um cookie ou ento algum parmetro na url que gerado pelo servidor, assim
conseguimos abrir mais de uma sesso se usarmos browsers diferente sou a chamada sesso
annima suportada pelos navegadores mais modernos. Para testar a criao sesses, possvel fechar o browser e abrir novamente pra criar uma nova sesso, mas isso no significa que
a antiga ser fechada. Geralmente o que ocorre quando um usurio fecha o browser e usar
alguma opo sair da aplicao, que a sesso ficar inativa no servidor, ocupando recursos
desnecessariamente, at que o time out seja alcanado. Isso geralmente ocorre aps trinta mi-
56
nutos de inatividade (CORDEIRO, p. 1-208). A seguir a Figura 29 ilustrar esse funcionamento.
Figura 29: Session
O escopo de sesso serve para armazenar informaes que devem estar em memria
durante toda a navegao do usurio na aplicao. Outros exemplos podem ser as permisses
do usurio, informaes de perfil de acesso, nome, hora do login, entre outras que possam ser
interessantes dependendo da aplicao (CORDEIRO, p. 1-208).
57
Anotao @Inject e @PostContruct
A anotao @Inject usada para marcar o local onde ser feita a injeo. Para solicitar
a injeo de uma dependncia basta utilizarmos a anotao @javax.inject.Inject. Dessa forma
a CDI procura em seu contexto uma classe candidata a suprir essa dependncia, e como por
padro toda classe dentro de um pacote CDI candidata a ser injetada, no precisamos fazer
nenhuma configurao nas classes (CORDEIRO, p. 1-208).
No cdigo abaixo Figura 30 est sendo apresentada a classe CadastroBean sem injeo, onde o mtodo salvar apresenta uma instancia da classe UsuarioDAO.
Figura 30: Sem injeo de Dependncia
J no cdigo abaixo na Figura 31 est usando injeo, onde est injetando a classe
UsuarioDAO na classe CadastroBean pela anotao @Inject, observa-se que no mtodo salvar
no precisa mais instanciar a classe UsuarioDAO, como foi instanciado no cdigo acima.
Figura 31: Com Injeo de Dependncia.
58
A anotao @PostConstruct apresentada na Figura 32, usada para que nossos beans
saibam quando esto prontos ,com todas as dependncias satisfeitas, e assim possam fazer
algo.
Figura 32: Anotao @PostConstruct
Para
dar
continuidade
ao
desenvolvimento
do
sistema,
no
pacote
com.sysprefeitura.model.daos foi adicionado mais uma classe, a classe DocumentoDAO. E no

pacote sysprefeitura.model.entidades foi adicionado mais uma entidade, a classe Documento
ser responsvel por gerar a tabela documentos no banco de dados e no pacote sysprefeitura.Beans foi criado as classes DocumentoBean e documentoDownloadBean. Essas classes
sero acessadas pela pgina index.xhtml, que est em uma rea restrita dentro da pasta sistema. A mesma s poder ser acessada por usurios que estiverem logados no sistema. As listagens abaixo apresenta o formulrio da pgina index, onde foi separada em partes diferentes
por comentrios para melhor entendimento.
A primeira parte apresenta a tag do PrimeFaces <p:dataTable/>, que criar uma tabela
na pgina e recebe todos os documentos pertencentes ao usurio logado no sistema atravs do
mtodo listaDocumentos(), da classe documentoBean, no atributo value. A Figura 33 apresenta a criao da tabela e na Figura 34 esta sendo apresentado seu mtodo.
Figura 33. Criao da tabela.
59
Figura 34. Mtodo da tabela.
Na mesma possui uma coluna para a data do documento que criada atravs da tag
<p:columm headerText> que recebe o nome Data como o nome da coluna. A tag
<h:outputText value=#{d.data}> acessa a classe Documento no pacote syspefeitua.model.entidades e receber a data atual e em seguida na tag <f:convertDateTime> a data e
convertida e mostrada em dia, ms e ano. A Figura 35 abaixo mostra a criao da coluna Data
e na Figura 36 mostra o cdigo da classe Documento que responsvel por retorna a data.
Figura 35. Criao da coluna Data.
Figura 36. Cdigo da classe Documento responsvel por retorna data.
As anotaes que contm @Temporal so tipos baseados em informaes armazenadas relativas ao tempo. O uso dessa anotao inclui um atributo chamado de TemporalType
com um valor enumerado. Esses valores so: DATE, TIME e TIMESTAMP para representar
os tipos de Java.sql (GONALVES, 2007). Nesse caso foi utilizado o valor DATE.
A tag <p:column> , mostrado na Figura 37 criar a coluna Assunto e receber o nome do
assunto do documento digitado pelo usurio que esto armazenados na tabela documentos.
60
Figura 37. Criao da coluna Assunto.
Em seguida e criada mais uma coluna que recebe o nome de todas as secretarias que
receberam os documentos. A tag <h:outputText> tem um atributo value que recebe a classe
documentoBean que busca o mtodo secretariasNome, esse mtodo recebe o nome da secretaria para onde o documento foi enviado, caso for enviado pra mais de uma secretaria os nomes
das mesma ser separado por uma virgula, porm uma virgula era sempre inserida no final do
nome da ultima secretaria. Para resolver esse problema foi utilizado um return, que conta toda
a String e apaga dois caracteres do fim da String, e em seguida foi adicionado um ponto no
fim da String. Figura 38 criao da coluna destinatrio e Figura 39 seu mtodo.
Figura 38. Criao da coluna Destinatrio.
Figura 39. Mtodo secretariaNome.
Na coluna Documentos, para cada documento listado criado um boto <p: commandButton> que receber o valor baixar que chama a ao selecionarDocumento(d) na classe
documentoBean. A Figura 40 mostra a criao da coluna na tabela e na Figura 41 mostra o
cdigo correspondente ao mtodo selecionarDocumento(d).
Figura 40. Criao da Coluna Documentos
61
Figura 41. Mtodo selecionar
Em seguida na Figura 42 temos a classe documentoDownloadBean e o mtodo file.
Figura 42: Classe DocumentoDownloadBean
3.11 Formulrio para Manda Arquivo

Para manda um arquivo necessrio acessa a pgina documento_form.xhtml que contm o formulrio com os campos para serem preenchidos.
A tag <h:outputLabel> receber o atributo value que coloca o nome para na pgina,
em seguida na tag <p:selectManyCheckbox> mostrar todas as secretaria cadastradas no banco de dados atravs do mtodo secretarias(). A tag <f:selectItems> permite que seja selecionada as secretarias para que seja enviado algum arquivo pra mesma. Figura 43 apresenta o
formulrio da pgina.
Figura 43. Pgina do formlario
Para que o usurio pudesse adicionar um nome para o documento que ele queira enviar
foi adiciona no formulrio um campo com o nome assunto que receber o nome digitado pelo
usurio. Em seguida foi criado um boto que Permite procurar um arquivo atravs do mtodo
62
arquivo (). Figura 44 tem o formulrio da pgina com a criao da coluna assunto e seu boto
procura arquivo.
Figura 44. Pgina do formulrio coluna assunto.
Para que os arquivos fosse salvos no banco de dados foi criado o mtodo salvar(), da
classe documentoBean. A Figura 45 abaixo apresenta o cdigo no formulrio que aciona a
classe documentoBean e seu mtodo salvar, e na Figura 46 apresenta o mtodo que salva o
arquivo no banco, esse mtodo na hora que o usurio tenta enviar o arquivo ele faz uma comparao entre o arquivo escolhido pelo usurio com os tipos de arquivos que o sistema suporta, se o arquivo tiver extenso diferente de pdf, docx e doc o sistema mostrara uma mensagem
de No permitido esse tipo de arquivo, caso contrario o arquivo ser salvo com sucesso no
banco de dados e uma mensagem ser mostrada para o usurio de arquivo enviado com sucesso.
Figura 45:Boto Enviar.
63
Figura 46. Mtodo salvar.
por
fim,
sistema
usar
classe
FacesUtils
presente
no
pacote
com.sysprefeitura.util que contm um mtodo showFacesMessage, responsvel por mostra

mensagem no sistema. Essa mensagem e apresentada atravs do switch case, ou seja, caso
contrrio. Para o caso 1 foi associado mensagens de erro e ao caso 2 para mensagens de informao. O cdigo acima mostra como essa classe trabalhar.
A Figura 47 apresenta a pgina que mostrar os documentos recebidos pelo usurio
logado no sistema e na Figura 48 apresenta a pgina para o envio de documentos.
64
Figura 47: Pgina que mostrar os documentos
Figura 48: Pgina para enviar documento.
65
4. CONCLUSO
4.1 Consideraes Finais
Com o sistema desenvolvido por este trabalho, espera-se que o mesmo quando implantado na prefeitura municipal de Balsas-MA consiga realizar de forma mais rpida a comunicao feita por troca de documentos oficiais.
Essa soluo foi concebida com a realizao dos estudos e anlise feitos em diversos
frameworks, softwares e padres utilizados para a separao da aplicao, que possibilitou
para o projeto uma soluo vivel para o seu desenvolvimento.
As tecnologias baseadas na Web permitira aos usurios a oportunidade de enviar, armazenar e receber documentos oficiais de qualquer partio da estrutura interna da mesma
que esteja cadastrada no sistema, a partir de qualquer navegador Web.
O propsito deste trabalho foi apresentar as ferramentas utilizadas para o desenvolvimento do sistema proposto, bem com mostrar passo a passo o desenvolvimento do mesmo.
4.2 Trabalhos Futuro

Como trabalho futuro ser implementado no sistema o MD5, que um tipo de "impresso digital" de um arquivo, usado para determinar se um arquivo baixado de um FTP no
se alterou ao chegar ao micro, utilizando-se de um checksum de 128 bits. O checksum uma
soma matemtica baseadas no contedo dos dados em processamento, para verificar correo.
66
5 REFERNCIAS BIBLIOGRFICAS
BASHAM, B.; SIERRA K.; BATES B. Head first servlets & jsp, 2 Edition.
OREILLY.2008.
CORDEIRO, Gilliard. CDI Integre as dependncias e contextos do seu cdigo Java. Casa
do Cdigo, So Paulo, p. 1- 208.
FERREIRA, A. (Ed). Aurlio Jnior: portugus. Editora Positivo Ltda, 2005.
FILHO, W. Engenharia de Software fundamentos, mtodos e padres. LTC Livros Tcnicos e Cientficos Editora S.A., 2005.
FOX, C. Introduction to software engineering design: processes, principles, and patterns
with uml 2. 1 st ed. Boston: Pearson, 2006.
GONALVES, E. Desenvolvendo Aplicaes Web com JSP Servlets, JavaServer Faces,
Hibernate, EJB3 Persistence e Ajax. Editora Cincia Moderna Ltda., 2007.
GONALVES, E. Dominando NetBeans. Editora Cincia Moderna Ltda., 2006.
JAMACEDO 2013 Jamacedo. Disponvel em: http://jamacedo.com/2011/01/crud-jsf-2-parte3-seguna-com-spring-security-3/, Acessado em 04 de abril de 2013.
KITO, D. JAVASERVER FACES IN ACTION. Mann Foreword by Ed Burns: MANNING.
2005.
KURNIAWAN, B. Java para a Web com Servlet, JSP e EJB. Rio de Janeiro: Editora Cincia
Moderna Ltda., 2002.
NUNES, Vinny; MAGALHES, Eder. Aprendendo JSF 2.0 com ScrumToys. Java Magazine, Rio de Janeiro, p.22-36.
PEREIRA, Tiago. Spring Security 3, JSF 2 e JPA 2. Java Magazine, Rio de Janeiro, p. 5260.
PRIMO, Izalmo; SANTOS, Samuel. Desenvolvendo com Hibernate. Java Magazine, Fortaleza, p.46-57.
67
REZENDE, D. Engenharia de software e sistemas de informao. BRASPORT LIVROS E
Multimdia Ltda., 2005.
SANTOS, R. Java na Web. Axcel Books do Brasil Editora Ltda., 2007.
SOMMERVILLE, I. Engenharia de Software. Pearson Education do Brasil., 2005.
SOUSA, Marcos. Desenvolvendo com JavaServer Faces - Parte 1. Java Magazine, Rio de
Janeiro, p.8-18.
SOUSA, Marcos. Desenvolvendo com JavaServer Faces - Parte 2. Java Magazine, Rio de
Janeiro, p.14-26.
ZANINI, Michel. Spring Security. Java Magazine, Rio de Janeiro, p.28-38.
68
APNDICE A
DOCUMENTOS DE REQUISITOS
69
SUMRIO
1 IDENTIFICAO DOS REQUISITOS ............................................................................... 70

1.1 Finalidade ....................................................................................................................... 70
1.2 Casos de Uso .................................................................................................................. 70
1.3 Diagrama de Caso de Uso .............................................................................................. 71
1.4 Descrio dos Casos de Uso ........................................................................................... 71
1.5 Identificao das Entidades e Atributos do Sistema ...................................................... 79
1.6 Identificao das Classes DAO e seus mtodos para acesso ao Banco de Dados .......... 79
70
1 IDENTIFICAO DOS REQUISITOS
1.1 Finalidade
Tem por finalidade descrever e especificar os requisitos que devem ser atendidos pelo
sistema de forma a atender as necessidades dos usurios, bem como definir o sistema a ser
feito, para o desenvolvedor do mesmo.
1.2 Casos de Uso
[RF001] Login de Usurios.

[RF002] Cadastrar Usurio .
[RF003] Excluir Usurio.
[RF004] Cadastrar Secretaria.
[RF005] Excluir Secretaria.
[RF006] Enviar Documentos
[RF007] Anexar Documentos.
[RF008] Receber Documentos.
[RF009] Download de Documentos.
[RF010] Excluir Documentos.
[RF011] Lista Documentos.
[RF012] Lista Usurios.
[RF013] Lista Secretarias
71
1.3 Diagrama de Caso de Uso
1.4 Descrio dos Casos de Uso

[RF001] Efetuar Login
Ator: Administrado e usurio.

Descrio do caso de uso: Entrada: Este caso de uso permite que o usurio acesse o
sistema.
Pr-condies: Somente o administrador do sistema e os usurios cadastrados tero
acesso ao mesmo.
Processo: O sistema verificar se o administrado/usurio est cadastrado no sistema, se
for tero acesso ao mesmo.
Sada: Mensagem de confirmao bem sucedida do Login efetuado com sucesso.
Ps-Condio: No h ps-condio.
Fluxo Principal
72
1. O caso de uso se inicia quando o administrado/usurio tem a necessidade de logar
no sistema.
2. O sistema exibir uma tela de login de usurios.
3. O administrado/usurio insere na tela exibida seu e-mail e senha.
4. O sistema verifica as informaes de login [FA001].
5. O sistema apresenta uma tela indicando que o usurio est logado no sistema
6. O caso de uso se encerra.
Fluxo Alternativo
[FA001] E-mail e/ou senha errados.
1. O sistema verifica se o e-mail e senha so validos.
2. O sistema exibe uma mensagem erro informando que o e-mail e/ou senha esto incorretos.
3. O caso de uso retorna ao passo 3 do fluxo principal.
[RF002] Cadastrar Usurio
Ator: Administrador.
Descrio do caso de uso: Este caso de uso permite que o administrado cadastre usurios no sistema.
Entradas: O administrador acessa o sistema com seu login e senha e insere nos campos o nome do usurio, senha, e-mail e o perfil para o usurio que ser cadastrado.
Pr-condies: Somente o administrador do sistema poder cadastrar usurios.
Processo: O cadastro ser includo no banco de dados.
Sada: Mensagem de confirmao bem sucedido do cadastro caso tenha sido efetuado
com sucesso, seno, mensagem de erro.
Ps-Condio: Usurio cadastrado.
Fluxo Principal
1. O caso de uso se inicia quando o administrador do sistema tem a necessidade de
efetuar o cadastro de usurio.
2. O administrador loga no sistema.
3. O administrador insere os dados dos usurios no sistema. [FA001]
4. O administrador confirma os dados do cadastro.
73
Fluxo Alternativo
[FA001] Usurio j cadastrado
1. O sistema verifica se o usurio j est cadastrado.
2. O sistema exibe uma mensagem de erro informando que o usurio inserido j existe.
3. O caso de uso retorna ao passo 3 do fluxo principal.
[RF003] Excluir Usurio
Ator: Administrador
Descrio do caso de uso: Este caso de uso permite que o administrador exclua usurios do sistema.
Entradas: O administrador acessa o sistema com seu login e senha e excluir o usurio
cadastrado.
Pr-condies: Somente o administrador do sistema poder excluir o usurio cadastrado.
Processo: O cadastro ser excludo no banco de dados.
Sada: Mensagem de confirmao bem sucedido da alterao do cadastro caso tenha
sido efetuado com sucesso, seno, mensagem de erro.
Fluxo Principal
excluir o usurio cadastrado.
2. O administrador loga no sistema.
3. O administrador escolher o do usurio que ser excludo.
4. O administrador excluir os dados do cadastro do usurio.
[RF004] Cadastrar Secretaria

Descrio do caso de uso: Este caso de uso permite cadastrar secretarias.
Entradas: O administrador acessa o sistema com seu login e senha e insere no campo
o nome da Secretaria que ser cadastrada.
Pr-condies: Somente o administrador do sistema poder cadastrar uma secretaria.
74
Processo: O cadastro ser includo no banco de dados.
Sada: Mensagem de confirmao bem sucedido do cadastro caso tenha sido efetuado
com sucesso, seno, mensagem de erro.
Fluxo Principal
efetuar o cadastro de uma secretaria.
2. O administrador logar no sistema.
3. O administrador insere o nome da secretaria no campo.
4. O administrador confirma o dado do cadastro.
[RF005] Excluir Secretaria
Ator: Administrador
Descrio do caso de uso: Este caso de uso permite excluir secretarias cadastradas no
sistema.
Entradas: O administrador acessa o sistema com seu login e senha e excluir a secretaria cadastrada.
Pr-condies: Somente o administrador do sistema poder excluir a secretaria cadastrada.
Processo: O cadastro ser excludo no banco de dados.
Sada: Mensagem de confirmao bem sucedido da alterao do cadastro caso tenha
Fluxo Principal
excluir a secretaria cadastrada.
2. O administrador logar no sistema.
3. O administrador escolher a secretaria que ser excluda.
4. O administrador excluir a secretaria cadastrada.
75
[RF006] Enviar Documento
Ator: Usurio.
Descrio do caso de uso: Este caso de uso permite enviar documentos para setores
da estrutura interna da mesma.
Entradas: Deve receber como entrada o nome do setor para onde ser enviado o documento, juntamente com o nome do assunto do que o documento se trata e o documento
anexado [RF007].
Pr-condies: O usurio deve t logado no sistema.
Sada: Mensagem de confirmao bem sucedido do envio do documento, caso tenha
Fluxo Principal
1. O caso de uso se inicia quando o usurio tem a necessidade de enviar documentos
oficiais.
2. O sistema exibir uma tela contendo a opo documentos.
3. O usurio escolher a opo novo documento, o sistema redirecionara para uma tela de envio de documentos.
4. O usurio entrada o nome do setor para onde ser enviado o documento, juntamente com o nome do assunto do que se trata o documento.
5. O usurio anexar o documento para enviar [RF007].
6. O usurio confirma os dados e envia o documento.
[RF007] Anexar Documento
Ator: Usurio.
Descrio do caso de uso: Este caso de uso permite anexar documentos oficiais para
que sejam enviados.
Entradas e pr-condies: Deve receber como entrada o caminho absoluto para anexar um documento no sistema.
Sadas e ps-condio: Documento anexado.
Fluxo Principal
76
1. O caso de uso se inicia quando o usurio precisa anexar um documento.
2. O sistema exibe na tela a opo para anexar documentos.
3. O usurio escolhe o documento que ser anexado.
[RF008] Receber Documento
Ator: Usurio.
Descrio do caso de uso: Este caso de uso permite que usurios recebam documentos oficiais que foram enviados dos setores da estrutura interna da mesma.
Pr-condies: Documentos enviados.
Ps-condio: Documentos recebidos.
Fluxo Principal
1. O caso de uso se inicia quando o usurio envia um documento para uma dos setores cadastrados [RF006].
2. O sistema exibe na tela os documentos recebidos.
3. O usurio poder baixar ou excluir os documentos [RF009], [RF010].
[RF009] Download de Documento
Ator: Usurio.
Descrio do caso de uso: Este caso de uso permite que usurios faa download dos
documentos oficiais que foram recebidos dos setores da estrutura interna da mesma.
Sada: Download realizado com sucesso.
Fluxo Principal
1. O caso de uso se inicia quando o usurio deseja fazer download do documento
oficial.
2. O usurio escolher o documento.
3. O usurio faz o download do documento.
77
[RF010] Excluir Documento
Ator: Usurio.
Descrio do caso de uso: Este caso de uso permite que usurios excluam documentos oficiais que foram recebidos dos setores da estrutura interna da mesma.
Sada: Documento excludo com sucesso.
Fluxo Principal
1. O caso de uso se inicia quando o usurio deseja exclui um documento oficial.
2. O usurio escolher o documento.
3. O usurio excluir o documento.
[RF011] Lista Documentos
Ator: Usurio.
Descrio do caso de uso: Este caso de uso permite que o usurio liste todos os documentos oficiais que foram recebidos dos setores da estrutura interna da mesma.
Sada: Documentos listados.
Fluxo Principal
1. O caso de uso se inicia quando o usurio deseja listar os documentos oficiais.
2. O usurio escolher em documento a opo lista.
3. O sistema listar os documentos e mostrar na tela.
[RF012] Lista Usurios
78
Descrio do caso de uso: Este caso de uso permite que o administrador do sistema
liste todos os usurios cadastrados no mesmo.
Pr-condies: No h ps-condio.
Ps-condio: No h ps-condio.
Sada: Usurios listados.
Fluxo Principal
1. O caso de uso se inicia quando o administrador do sistema deseja listar todos os
usuarios cadastrados no mesmo.
2. O administrado escolher em usurio a opo lista.
3. O sistema listar os usurios e mostrar na tela.
[RF013] Lista Secretarias
Descrio do caso de uso: Este caso de uso permite que o administrador do sistema
liste todas as secretarias cadastradas no mesmo.
Pr-condies: No h ps-condio.
Ps-condio: No h ps-condio.
Sada: Secretarias listadas.
Fluxo Principal
1. O caso de uso se inicia quando o administrador do sistema deseja listar todas as
secretarias cadastradas no mesmo.
2. O administrado escolher em secretaria a opo lista.
3. O sistema listar as secretarias e mostrar na tela.
79
1.5 Identificao das Entidades e Atributos do Sistema
1.6 Identificao das Classes DAO e seus mtodos para acesso ao Banco de Dados
80
Clemilda Izaias Santos

Bibliotecria CRB 13/626
Matos, Fernando Ferreira
Desenvolvimento de um sistema web para enviar, armazenar e receber documentos oficiais / Fernando Ferreira Matos. Balsas, 2013.
68f.:il.
Monografia (Graduao em Sistemas de Informao) Curso de
Sistemas de Informao, Faculdade de Balsas - UNIBALSAS / Balsas,
2013.
1. Desenvolvimento web. 2. Frameworks. 3. Padres. I. Ttulo.
CDU 004 (812.1Balsas) (02)
M425d

TCC Fernando Matos Final PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

TCC Fernando Matos Final PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

FACULDADE DE BALSAS

CURSO DE SISTEMAS DE INFORMAO

DESENVOLVIMENTO DE UM SISTEMA WEB PARA ENVIAR,

Fernando Ferreira Matos

Fernando Ferreira Matos

DESENVOLVIMENTO DE UM SISTEMA WEB PARA ENVIAR,

Trabalho de Concluso de Curso apresentado

A Comisso Examinadora, abaixo assinada, aprova o Trabalho de Concluso de

DESENVOLVIMENTO DE UM SISTEMA WEB PARA ENVIAR,

Prof. Marcos David Sousa Ramos

Prof. Msc. Jefferson Fontinele Da silva

Prof. Msc. Cleverton Marlon Possani

Application Programming Interface

Context and Depen- dency Injection

Data Access Object

Componentes de Interfaces de Usurio

Hypertext Markup Language

Hypertext Transfer Protocol

HyperText Transfer Protocol Secure

Integrated Development Enviroment

Java 2 Platform Enterprise Edition

Java Database Connectivity

Java Development Kit

Java Server Faces

Java Server Pages

JavaServer Pages Standard Tag Library

Lightweight Directory Access Protocol

Mapeamento Objeto Relacional

Portable Document Format (Formato de Documento Porttil).

Structured Query Language (Linguagem de Consulta Estruturada)

Uniform Resource Locators (Localizador Uniforme de Recursos)

Extensible Hypertext Markup Language

Extensible Markup Language (Linguagem de Marcao Estendida)

Figura 1. Representao da comunicao interna da Prefeitura Municipal de Balsas MA

1.2.2 Objetivos especficos:

1.4 Organizao da monografia

Este trabalho est organizado da seguinte forma: Captulo 2 Reviso Bibliogrfica,

2.1.1 Metodologia de Desenvolvimento de Sistemas

2.1.3 Modelos de Processo de Software

2.1.4 Engenharia de Requisitos

3- Especificao de requisitos a atividade de traduzir as informaes coletadas

2.1.5 Modelos de Ciclo de Vida

Figura 2: Ciclo de Vida em Cascata.

Figura 3- Ambiente de Desenvolvimento NetBeans IDE 7.3

2.3 MVC (Model-View-Controller)

Segundo GONALVES (2007):

A viso a camada responsvel pela apresentao. Ela recebe o estado do modelo

Segundo KURNIAWAN (2002):

2.4 JavaServer Faces

Segundo GONALVES (2007):

Java Server Faces o framework para desenvolvimento de aplicao web padro da

2.4.1 Ciclo de vida do JSF

Figura 4. Ciclo de vida JSF

Apply Request Values

Update Model Values

2.4.2 Pginas HTML

Managed Beans (Controladores de pgina)

Figura 5: Arquitetura do Hibernate para plataforma Java.

Hibernate para Java, APIs nativas e metadados XML

Mapeia as classes com anotaes do JDK 5.0

API de persistncia Java padro para Java SE e Java EE

Framework para particionamento horizontal de dados

API para anotao e validao da integridade dos dados