Escolar Documentos
Profissional Documentos
Cultura Documentos
BATATAIS
2011
FERNANDO ANTONIO BARBEIRO CAMPOS
BATATAIS
2011
FERNANDO ANTONIO BARBEIRO CAMPOS
Examinador: ______________________________________
Examinador: ______________________________________
A minha tia Marinda e minha avó Palmira (in memorian) por terem sempre me
momentos.
Agradecimentos
sobretudo, por ter amparado com seu profundo conhecimento durante todo o
trabalho.
RESUMO
Este trabalho propõe uma pesquisa sobre as soluções e vantagens agregadas com
Java - em suas vertentes Java SE, Java EE, entre outras), que possibilitaram
(neste trabalho, chamado de GesTI), que teve uma versão implementada em Java
EE, a partir da IDE Netbeans 6.8, seguindo a modelagem de dados definida pela
UML e utilizando base de dados MySQL. Findando a pesquisa, é feita uma análise
LISTA DE FIGURAS.....................................................................................................8
INTRODUÇÃO............................................................................................................10
OBJETIVO.........................................................................................................................................................10
JUSTIFICATIVA E MOTIVAÇÃO..................................................................................................................10
ORGANIZAÇÃO DA MONOGRAFIA............................................................................................................11
CAPITULO 1...............................................................................................................13
MAPEAMENTO OBJETO-RELACIONAL..................................................................13
1.1.ORIGEM E DEFINIÇÃO............................................................................................................................13
1.2.EVOLUÇÃO................................................................................................................................................15
1.2.1.ARQUITETURA DE CAMADAS............................................................................................................................16
1.3.ESPECIFICAÇÃO JPA................................................................................................................................18
1.4.IMPLEMENTAÇÕES JPA..........................................................................................................................18
CAPITULO 2...............................................................................................................20
HIBERNATE................................................................................................................20
2.1.SURGIMENTO............................................................................................................................................20
2.2.APLICAÇÃO...............................................................................................................................................21
2.2.1.VANTAGENS E DESVANTAGENS........................................................................................................................22
2.3.APRESENTAÇÃO DE OUTROS PROVEDORES....................................................................................24
2.3.1.TOPLINK......................................................................................................................................................24
2.3.2. OPENJPA....................................................................................................................................................25
2.4.METADADOS.............................................................................................................................................25
2.4.1.METADADOS E MAPEAMENTO EM XML............................................................................................................26
2.4.2. METADADOS E MAPEAMENTO COM ANNOTATION................................................................................................29
CAPITULO 3...............................................................................................................34
ESTUDO DE CASO – GESTI (GESTÃO DE CUSTOS EM TI).................................34
3.1. DESCRIÇÃO NARRATIVA DO SISTEMA.............................................................................................34
3.2.LISTAGEM DE REQUISITOS NÃO-FUNCIONAIS................................................................................35
3.3.DIAGRAMA DE CASOS DE USO DO SISTEMA....................................................................................36
3.4.DIAGRAMA DE CLASSES DO SISTEMA...............................................................................................37
3.5.MODELAGEM DE DADOS (D-ER)..........................................................................................................39
CAPITULO 4...............................................................................................................41
DESENVOLVIMENTO................................................................................................41
4.1.COMPONENTES ARQUITETURAIS........................................................................................................41
4.1.1.PACOTE BR.COM.GESTI.MODEL.ENTITIESANNOTATION.........................................................................................43
4.1.2.PACOTE BR.COM.GESTI.MODEL.DAO..................................................................................................................43
4.1.3.PACOTE BR.COM.GESTI.MODEL.DAO.IMPLEMENTATION.........................................................................................44
4.1.4.PACOTE BR.COM.GESTI.CONTROLLER................................................................................................................46
4.1.5.PACOTES BR.COM.GESTI.VIEW.PHASELISTENER E BR.COM.GESTI.VIEW.UTIL.............................................................47
4.2.INTERFACES DO SISTEMA.....................................................................................................................48
4.2.1.TELA DE LOGIN NO SISTEMA...........................................................................................................................48
4.2.2.TELA PRINCIPAL............................................................................................................................................49
4.2.3.TELA DE EXIBIÇÃO DE FUNCIONÁRIOS...............................................................................................................49
CONCLUSÃO.............................................................................................................51
REFERÊNCIAS BIBLIOGRÁFICAS...........................................................................53
LISTA DE FIGURAS
INTRODUÇÃO
OBJETIVO
definido para pesquisa foi um assunto que relacionasse tanto banco de dados,
Este assunto, por sua vez, tem como alvo final o embasamento comprobatório
para traçar métricas das vantagens de sua utilização (ou desvantagens) e assimilar
JUSTIFICATIVA E MOTIVAÇÃO
em todo o ciclo de vida de um software, uma das questões elencadas como mais
ORGANIZAÇÃO DA MONOGRAFIA
capítulo cita a JPA (Java Persistence API) e permite ter uma visão genérica da
mesma.
de dados proposta.
EE) utilizando-se do auxílio do framework JSF (Java Server Faces), além, é claro, do
11
para demonstração do software criado. Este capítulo traz também, alguns protótipos
CAPITULO 1
MAPEAMENTO OBJETO-RELACIONAL
uma classe e estas, por sua vez, tem seus atributos e métodos para definir estado e
Uma vez definidos estes dois tópicos, Bauer e King (2005) salientam que é
a objetos.
importância e custo. Todavia, ainda na visão de Bauer e King (2005), como maneira
forma que as relações (tabelas) passam a ser representadas pelas classes, sendo
evolução do software.
1.2. EVOLUÇÃO
Roman (2002), era a dos beans de entidade gerenciados por persistência (CMP).
Esta solução faz com que a persistência seja controlada por contêiner EJB, sem
15
momento, eles não atendiam, sequer, os aplicativos menos triviais com modelos
algumas soluções que são utilizadas atualmente, como: TopLink, iBatis e o próprio
1.2.1.Arquitetura de Camadas
atraente.
camada. Assim, é comumente encontrada uma solução que trata de forma separada
baseada em padrões de projeto, é muito simples incluir uma camada específica para
sistema.
desenvolvedores.
17
Plain Old Java Objects) que, por sua vez, recebem o nome de Beans de Entidades.
Java. Sendo que a persistência é uma abstração de alto-nível sobre JDBC e a JPA
para a JPA assim como o driver do banco está para a API do JDBC.
tornam a vida dos desenvolvedores muito difícil), cabe ressaltar que estes
provedores nada mais são que frameworks facilitadores para a existência correta e
CAPITULO 2
HIBERNATE
detalhes técnicos desde seu surgimento e suas melhorias com o decorrer de anos
2.1. SURGIMENTO
baseado na ideia de que os beans gerenciados por persistência não atendiam por
modelo relacional.
Logo, ao final de 2003, o Hibernate uniu-se a empresa JBoss Inc. (por sua
vez, comprada pela Red Hat) e, desde então, esta equipe de desenvolvedores dão
2.2. APLICAÇÃO
produção. Isso é explicado pelo simples fato dele automatizar uma tarefa tediosa e,
relacional. Hibernate, por sua vez, faz esta complexa tarefa para os
2.2.1.Vantagens e Desvantagens
Segundo Bezerra (2010), há uma série de vantagens que fazem quase com
manutenção das tabelas, uma vez que elas serão conseguidas à partir do
consulta SQL (via JDBC) sem sequer ter aberto a conexão (problemas de
para gerar uma exceção são melhores controlados pelo framework que, sob
necessário definir que nem tudo é feito somente de prós e, no caso deste
que há uma série de sistemas que implementam parte das regras de negócio
objetos implementados não deve conseguir benefícios amplos com uso de Hibernate
(Linhares, 2009).
mesmos, cabendo assimilar qual a melhor adoção de acordo com o projeto a ser
outros.
utilizáveis.
2.3.1.TopLink
(Oracle, 2010).
para diversos ambientes de TI. Contudo, apesar desta informação oficial da Oracle,
2.3.2. OpenJPA
Foundation que, segundo a própria Apache Software Foundation (2010), pode ser
usado como uma camada de persistência de classes em Plain Old Java (POJO) ou
integrada a um conteiner Java EE, trabalhando junto com outros frameworks para
2.4. METADADOS
Dentre estas opções, pode haver a definição por utilizar documentos XML que
são lidos em tempo de execução pelo Hibernate (uma vez que já foram compilados
requer alguma atenção para evitar deslizes convencionais. Ela consiste em definir
26
Hibernate, ou seja, todos os atributos das classes devem ser mapeados, bem como
suas associações.
Deve ser criado um elemento XML para cada classe persistente do modelos
de objeto e o conteúdo destes arquivos, deve seguir uma estrutura XML válida com
mapeamento;
arquivos XML para mapear os objetos de uma classe, contudo, há uma sintaxe tão
rica disponível para a definição destes arquivos que há uma gama irrestrita de
soluções que podem ser tomadas a partir de um simples nó neste arquivo XML. Por
exemplo, basta imaginar uma propriedade que deve ser definida dependente de uma
média de um valor na base de dados. Pode ser criado o trecho abaixo demonstrado
comprobatório, serão trazidos mais códigos para amostragem. Neste ponto, para
antigos arquivos em XML e a substituição desta técnica para uma maneira mais
simples e adequada de sinalizar quando uma classe deve ser uma tabela, seguida
fazer uma 'anotação' de que aquele trecho tenha algum sentido diferenciado do
O código da figura acima traz uma das classes do projeto proposto com seu
devido uso das annotations. Para efeito didático, algumas destas anotações devem
entre outros;
objetos;
32
Annotation, este capítulo é encerrado para que haja uma explicação aprofundada
software.
33
CAPITULO 3
projetos da área, bem como a relação de custos entre Pessoal vs. Tarefas vs.
Mostrando suas vantagens sobre outras metodologias, desde que o projeto atenda
custos de um projeto. Automatizando assim, uma tarefa nem sempre praticada por
Enraizados estes conceitos, o sistema proposto será voltado para web, mas,
pela sua concepção correta em padrão de projetos como o MVC, nada impede que
Em uma visão de altíssimo nível, com intuito ilustrativo e sem trazer quaisquer
Uma vez destacadas estas informações, uma pessoa com um cargo atribuído
utilizando-se de quaisquer recursos que, por sua vez, compõem juntos uma relação
é preciso detalhar com um pouco mais de afinco todo o modelo de objetos presente
na aplicação.
37
para agregar funcionalidades como o uso de Design Pattern (MVC, DAO) durante a
persistidas no banco de dados, como ficará cada tabela, suas tuplas e suas colunas
em questão.
CAPITULO 4
DESENVOLVIMENTO
recursos utilizados:
A solução, apoiada pelo uso destes recursos citados e voltada para web, teve
Embasados nos conceitos do MVC, foram criados três pacotes básicos para
representandas, quase que, fielmente uma tabela do banco de dados, ou seja, são
POJO's simples.
(o nome DAO refere-se ao padrão de projetos Data Access Object), este pacote
Além das interfaces, há ainda uma fábrica de objetos neste pacote, definida
DaoFactory, que tem por padrão a criação de instâncias das implementações das
ou por Annotations).
44
um sinal similar a uma letra “I”, este sinal simboliza que a classe em questão está
verde, surge o pacote de Controller, que é uma das camadas do MVC responsável
pela troca de informações entre o Model e a View, ou seja, ele faz as notificações
final.
45
Dentre as linhas importantes, o método inserir (que inicia na linha 39) traz
acima, há uma instância de PessoaDao (que é uma das classes do Model), linha 41,
que tenta executar um método para efetivar a transação de inserção de uma pessoa
na base de dados. Os resultados desta transação são passados para a View com as
br.com.gesTI.view.util
Estes pacotes foram explicados juntos, pois sua divisão não se dá por nada
requisições enviadas ao JSF, assim, dentro deste pacote, há uma classe que verifica
pacotes, pois todo o conteúdo da view está representado pelas páginas web do
projeto.
47
desenvolvida.
administrador. Neste ponto, funcionários com este tipo de perfil podem criar tarefas,
projeto.
CONCLUSÃO
software. Eles tendem a tornar mais dinâmica a tarefa repetitiva de tratar todos os
acessos a dados (por meio de JDBC, com linguagem SQL) – o que era passível a
uso de uma solução para mapeamento dos modelos de objetos ricos em modelos de
Com isso e com a grande tendência de melhoria contínua das soluções para
surgir), as evidências indicam que cada vez maior será o número de adeptos ao
51
de software.
52
REFERÊNCIAS BIBLIOGRÁFICAS