Este documento apresenta um estudo sobre mapeamento objeto-relacional utilizando o framework Hibernate. O trabalho descreve o mapeamento objeto-relacional, Hibernate e suas vantagens, um estudo de caso de um sistema de gestão de custos em TI desenvolvido com Hibernate, e detalhes da implementação do sistema.

1. FERNANDO ANTONIO BARBEIRO CAMPOS
ESTUDO DE MAPEAMENTO OBJETO-RELACIONAL COM
FRAMEWORK HIBERNATE
BATATAIS
2011

2. FERNANDO ANTONIO BARBEIRO CAMPOS
ESTUDO DE MAPEAMENTO OBJETO-RELACIONAL COM
FRAMEWORK HIBERNATE
Monografia apresentada ao Centro
Universitário Claretiano como parte dos
requisitos para obtenção do título de
Especialista em Desenvolvimento de
Projetos em Java com Banco de Dados.
Orientador: Profº. Dr. Rodrigo de
Oliveira Plotze.
BATATAIS
2011

3. FERNANDO ANTONIO BARBEIRO CAMPOS
Monografia apresentada ao Centro Universitário Claretiano como parte dos
requisitos para obtenção do título de Especialista em Desenvolvimento de
Projetos em Java com Banco de Dados. Orientador Profº. Dr. Rodrigo de
Oliveira Plotze.
ESTUDO DE MAPEAMENTO OBJETO-RELACIONAL COM
FRAMEWORK HIBERNATE
Orientador: Profº. Dr. Rodrigo de Oliveira Plotze.
Examinador: ______________________________________
Examinador: ______________________________________
Batatais, ____ de ____________ de 2011.

4. Dedicatória
A meus pais, Maria Aparecida e Reinaldo, pela educação, afeto, ensinamentos
e por acreditarem incondicionalmente em meus sonhos.
A minha tia Marinda e minha avó Palmira (in memorian) por terem sempre me
acolhido como filho.
A minha namorada Lidiane, pelo amor, atenção e compreensão em todos os
momentos.

5. Agradecimentos
AGRADEÇO primeiramente a Deus, por ter proporcionado saúde, paz e
sabedoria; ao orientador e amigo Rodrigo Plotze pela dedicação, paciência e,
sobretudo, por ter amparado com seu profundo conhecimento durante todo o
estudo; aos meus amigos e colegas pelos momentos de descontração e apoio;
a todos que contribuíram de forma direta ou indireta para a realização deste
trabalho.

6. RESUMO
Este trabalho propõe uma pesquisa sobre as soluções e vantagens agregadas com
uso do mapeamento objeto-relacional no desenvolvimento / manutenção de
software, com ênfase no provedor da Java Persistence API - Hibernate. Inicialmente,
as etapas seguidas passam pela realização de levantamento bibliográfico sobre a
conjuntura histórica e a explicação das necessidades que findaram o surgimento do
mapeamento objeto-relacional, bem como as evoluções de tecnologias (em especial
Java - em suas vertentes Java SE, Java EE, entre outras), que possibilitaram
minimizar os problemas enfrentados ao desenvolver uma aplicação orientada a
objetos que necessitasse de acesso em bancos de dados relacional. A partir disto, a
especificação JPA é tratada, juntamente com ampla definição de um de seus
provedores (Hibernate), com alguns comparativos com outros frameworks,
apresentação de vantagens e desvantagens, apresentação de suas formas de
mapeamento de dados, entre outros. Como prova de conceito, foi definido um
estudo de caso de um sistema para gestão de custos em tecnologia da informação
(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
do desenvolvimento e apresentados os positivos resultados de um software
construído com mais agilidade e poupando grande parte do tempo de
desenvolvimento. Além disso, ficam explicitas facilidades em questões como
manutenibilidade e volatilidade a mudanças de requisitos.
Palavras-chaves: Java, Mapeamento Objeto-Relacional - JPA, Hibernate,
Mapeamento em XML, Mapeamento com Annotation.

7. SUMÁRIO
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

8. LISTA DE FIGURAS
FIGURA 1 – ABSTRAÇÃO DO MAPEAMENTO O-R COM JAVA...........................14
FIGURA 2 – DEMONSTRAÇÃO DE UM PROVEDOR JPA......................................18
FIGURA 3 – ALTO NÍVEL DA ARQUITETURA HIBERNATE..................................21
FIGURA 4 – METADADOS COM XML......................................................................28
FIGURA 5 – METADADOS COM ANNOTATIONS...................................................30
FIGURA 6 – DIAGRAMA DE CASOS DE USO DO SISTEMA.................................35
FIGURA 7 – DIAGRAMA DE CLASSES DO SISTEMA............................................37
FIGURA 8 – MODELO ENTIDADE-RELACIONAMENTO........................................39
FIGURA 9 – ARQUITETURA DE PACOTES DA APLICAÇÃO CONSTRUÍDA.......41
FIGURA 10 – DEMONSTRAÇÃO DE INTERFACE COM PADRÃO DAO...............43
FIGURA 11 – CLASSE COM IMPLEMENTAÇÃO DO PADRÃO DAO....................44
FIGURA 12 – MANAGEDBEAN DO PACOTE CONTROLLER................................45
FIGURA 13 – INTERFACE DE LOGIN NO SISTEMA...............................................47
FIGURA 14 – INTERFACE PRINCIPAL DO PERFIL ADMINISTRADOR................48
FIGURA 15 – INTERFACE DE LISTAGEM DOS FUNCIONÁRIOS.........................49

9. 9
INTRODUÇÃO
OBJETIVO
O objetivo do trabalho é realizar um estudo embasado em aspectos teóricos e
práticos sobre variados conteúdos assimilados do curso de Pós-Graduação em
Desenvolvimento de Projetos em Java com Banco de Dados. Nesse âmbito, o tema
definido para pesquisa foi um assunto que relacionasse tanto banco de dados,
quanto aplicações em Java (Mapeamento Objeto-Relacional com Hibernate).
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
comparativos positivos e negativos sobre o tópico pesquisado.
JUSTIFICATIVA E MOTIVAÇÃO
Além de avaliar e agregar conhecimentos ao aprendizado dosado no curso, o
assunto é extremamente atual e tende a comprovar grande facilitação na construção
de produtos de software de quaisquer segmentos.
Isso se dá devido ao fato de que, diante de um cenário de amplas dificuldades
em todo o ciclo de vida de um software, uma das questões elencadas como mais
propensas a falhas e que traz significativos problemas para analistas e
desenvolvedores é, sem dúvida, a definição e a evolução do acesso a dados para
aplicações orientadas a objetos (dominantes em parte do segmento de produção de
software) que evoluem de forma contínua.
Com isso, a proposta visada é desenvolver um software manutenível, com
agilidade e que atenda a volatilidade de requisitos dos clientes.

10. 10
ORGANIZAÇÃO DA MONOGRAFIA
Basicamente, o trabalho é dividido em 4 (quatro) capítulos principais que
permitem desenvolver o conteúdo tratado e possibilitam a correta finalização
conclusiva de toda a pesquisa e conhecimento adquirido. Um breve apanhado sobre
os assuntos tratados em cada capítulo está descrito a seguir.
O capítulo 1 aborda o assunto de forma 'macro', ou seja, traz os conceitos
sobre o mapeamento objeto-relacional e suas principais soluções no tratamento do
problema encontrado (onerosa forma de tratar as diferenças entre modelo relacional
adotado pelos SGBD's e a programação orientada a objetos). Além disto, este
capítulo cita a JPA (Java Persistence API) e permite ter uma visão genérica da
mesma.
O capítulo 2, foca um detalhamento maior na ênfase da pesquisa, assim, o
Hibernate (provedor da JPA) é demonstrado em várias vertentes, sejam elas
comparativas – quanto a outros provedores, ou seja eles qualitativas – desvendando
vantagens e desvantagens, citando seus benefícios e situações não recomendadas.
Ainda no capítulo 2, são tratadas informações fundamentais para o Hibernate que
são as formas de mapeamento dos Metadados (Mapeamento com XML e
Mapeamento com Annotations).
No capítulo 3, há a abordagem mais direta sobre o estudo de caso proposto
(Sistema para Gestão de Custos em Tecnologia da Informação, definido GesTI).
Nesta etapa, são apresentadas descrições narrativas do sistema, definições de
requisitos, diagramas de casos de uso e de classes, além da modalagem de banco
de dados proposta.
O capítulo 4 tratará especificamente da implementação proposta (em Java
EE) utilizando-se do auxílio do framework JSF (Java Server Faces), além, é claro, do

11. 11
assunto estudado – Hibernate. Neste capítulo, os pacotes que dividem a construção
da aplicação em 3 camadas (apoiadas nos pilares do MVC – Model-View-Controller),
são apresentados e explicitados. Além da presença de alguns trechos de código
para demonstração do software criado. Este capítulo traz também, alguns protótipos
das telas implementadas.

12. 12
CAPITULO 1
MAPEAMENTO OBJETO-RELACIONAL
Este capítulo demonstra o mapeamento objeto-relacional como um todo,
passando por sua origem, definições, evolução e a especificação da JPA (Java
Persistence API). Com isto, será possível demonstrar o progresso na construção de
software e as melhorias que podem ser agregadas aos projetos meramente
alterando as formas de acesso a dados.
1.1. ORIGEM E DEFINIÇÃO
Para que fique amplamente claro o entendimento do mapeamento objeto-
relacional, é necessário definir o que significa o paradigma orientado a objetos e o
acesso a dados em um banco de dados relacional.
Conforme citam Campos e Santuci (2009), o paradigma da orientação a
objetos tenta modelar os elementos em um sistema da mesma forma que são
percebidos no mundo real. Desta forma, neste paradigma, os sistemas são
compostos por objetos que possuem responsabilidades e funções, e estes,
colaboram entre si para a realização de um objetivo comum.

13. 13
Na visão de Ashok, Kiong e Poo (2007), diferentemente dos softwares
produzidos com um paradigma procedural (onde as instruções são executadas
sequencialmente), no paradigma orientado a objetos, cada entidade é vista como
uma classe e estas, por sua vez, tem seus atributos e métodos para definir estado e
comportamento de cada objeto (instâncias da classe).
Enquanto isto, independentemente da forma em que um software é
desenvolvido, torna-se primordial para a organização que o utilizará, manter e
recuperar os dados que historicamente sejam criados/manipulados neste sistema.
Estes dados, trabalhando juntos, tornam-se informações que permitem mensurar o
bom andamento dos negócios e criar conhecimento a respeito de clientes,
fornecedores, custos e, enfim, todos os segmentos da organização.
Diante deste cenário, segundo Neves (2002), o modelo de banco de dados
relacional é muito mais utilizado comercialmente e tende a resolver a maioria dos
problemas corriqueiros de uma organização. Este modelo abstrai as entidades do
mundo real como tabelas que são interconectadas pelas atividades
(relacionamentos) que criam entre si.
Uma vez definidos estes dois tópicos, Bauer e King (2005) salientam que é
bastante comum e produtivo a utilização do paradigma orientado a objetos com
soluções de banco de dados relacionais. Contudo, a representação dos dados em
tabelas de um sistema de banco de dados relacional é fundamentalmente diferente e
inadequada para as redes de objetos em uma linguagem de programação orientada
a objetos.
Essa incompatibilidade, inicialmente, foi subestimada em questões como
importância e custo. Todavia, ainda na visão de Bauer e King (2005), como maneira
da atingir vantagem competitiva durante o desenvolvimento do software e com o

14. 14
intuito de fugir do dispendioso acesso a dados tradicional, o Mapeamento Objeto-
Relacional (ORM) é uma técnica que reduz os impedimentos da programação
orientada a objetos utilizando banco de dados relacionais e abstrai a solução de uma
forma que as relações (tabelas) passam a ser representadas pelas classes, sendo
as tuplas desta tabela oriundas de cada instância da classe em questão.
Aplicativos construídos com ORM tendem a ter melhor desempenho, além de
economia no desenvolvimento e melhores no ponto de vista da manutenção e
evolução do software.
Fonte – Acervo pessoal.
Figura 1 – Abstração do Mapeamento O-R com Java.
1.2. EVOLUÇÃO
No início dos anos 2000, havia algumas soluções plausíveis no âmbito de
resolver as dificuldades da incompatibilidade entre o paradigma OO e os sistemas
de banco de dados relacionais. A mais popular na época, conforme Ambler, Jewell e
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. 15
necessitar do desenvolvimento de lógica de persistência (como JDBC ou SQL) no
próprio bean de entidade.
Entre os anos de 2001 e 2003, uma série de fabricantes começou a tratar
com maior enfoque o caso das soluções de mapeamento objeto-relacional. Ainda
que os beans de entidade gerenciados por persistência fosse plausíveis para o
momento, eles não atendiam, sequer, os aplicativos menos triviais com modelos
complexos de dados, Bauer e King (2005).
Neste momento, esta série de fabricantes começou ou evoluíram seus
modelos de objetos-relacionais. Dentre estes produtos, é possível referenciar
algumas soluções que são utilizadas atualmente, como: TopLink, iBatis e o próprio
Hibernate – foco de estudo principal).
1.2.1.Arquitetura de Camadas
Paralelamente a evolução do mapeamento objeto-relacional (e até com datas
anteriores a ele), cresciam o número de aplicações que agregavam os padrões de
projeto como uma forma de atingir um software de melhor qualidade, mais
manutenível e que permitia a especialização de desenvolvedores trabalhando em
etapas específicas do projeto. Assim, o ganho em produtividade é bastante visível e
atraente.
Nesta vertente, há algumas classificações principais de padrões que, segundo
Gamma et al. (2000), englobam:

16. 16
• Criacionais – formas de criar e instanciar objetos;
• Estruturais - apresentam formas para reunir os objetos existentes no sistema;
• Comportamentais - descrevem a maneira como os componentes comunicam-se,
além de desvincular objetos no sistema para que este possa ser variável.
Além destas três classificações iniciais, conforme Campos e Santuci (2009)
apud. Deitel (2005) com avanço da tecnologia e surgimento de novas tendências,
algumas novidades modificaram um pouco as disposições dos padrões. Há, neste
momento, a inclusão de padrões populares como é o caso dos padrões de projeto
que tratam a concorrência (multithreading) e ainda os padrões arquitetônicos, como
é o caso do MVC (Model-View-Controller).
Uma vez designada a existência e a frequência do uso destes padrões,
especialmente a junção de mais de um padrão na construção de um software
complexo, faz com que as aplicações sejam desenvolvidas em mais de uma
camada. Assim, é comumente encontrada uma solução que trata de forma separada
a camada de apresentação, as regras de negócio e o controle das informações entre
estas duas camadas anteriormente citadas.
Essa conjuntura torna amplamente viável a utilização de um middleware para
tratamento da camada de ORM, ou seja, imaginando uma solução modularizada,
baseada em padrões de projeto, é muito simples incluir uma camada específica para
tratamento da persistência dos dados, sem onerar o desenvolvimento do restante do
sistema.
Esta disposição de elementos, fez com que tornasse o uso de frameworks
para este mapeamento cada vez mais forte e enraizado na comunidade de
desenvolvedores.

17. 17
1.3. ESPECIFICAÇÃO JPA
A JPA (Java Persistence API) é uma API (Application Programming Interface)
padrão da linguagem Java com intuito de fornecer os subsídios principais para os
frameworks que desejam implementá-la. Ou seja, ela define um meio do
mapeamento objeto-relacional ser convertido para objetos Java comuns (POJO's –
Plain Old Java Objects) que, por sua vez, recebem o nome de Beans de Entidades.
Assim, seguindo as ideias de Moura (2009), um framework (implementador da
JPA) utilizado na camada de persistência traz mais produtividade para o
desenvolvedor, com impacto principal no modo de controlar a persistência dentro do
Java. Sendo que a persistência é uma abstração de alto-nível sobre JDBC e a JPA
define um modo "padrão" para mapear os objetos para os do banco de dados.
1.4. IMPLEMENTAÇÕES JPA
A JPA, por ser um padrão, permite que os mais diversificados fabricantes
criem implementações baseados nela e, conforme demanda, disponibilizem de
modo comercial (ou não) para os desenvolvedores. Esses fabricantes que
implementam a JPA, geram os implementadores também conhecidos como
Provedores da JPA, que trazem características, funcionalidades e peculiaridades em

18. 18
sua versão implementada. Por exemplo, um provedor pode trazer o tratamento de
cache, sincronização, conversão de dados, entre outros.
Para possibilitar a visualização do provedor, podemos citar que o mesmo está
para a JPA assim como o driver do banco está para a API do JDBC.
Fonte - Oracle (Sun Microsystems), 2008.
Figura 2 – Demonstração de um Provedor JPA.
Uma vez que foram citadas peculiaridades entre implementadores (e estas
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
otimizada do mapeamento objeto-relacional. Desta forma, todos seguem o padrão e
técnicas de mapeamento da API.

19. 19
CAPITULO 2
HIBERNATE
Este capítulo tratará, essencialmente, o tema da pesquisa abordada, ou seja,
o Hibernate - popular implementador (provedor) da JPA. Serão demonstrados
detalhes técnicos desde seu surgimento e suas melhorias com o decorrer de anos
de pesquisa, além de códigos explicativos, vantagens e desvantagens de seu uso e
algumas citações com outros provedores.
2.1. SURGIMENTO
O início do desenvolvimento do Hibernate data do final de 2001 quando Gavin
King (de forma independente e em um projeto aberto) iniciou sua implementação
baseado na ideia de que os beans gerenciados por persistência não atendiam por
completo as necessidades para o problema de incompatibilidade entre POO e o
modelo relacional.
King e sua equipe apoiavam-se no auxílio da cada vez mais ampla
comunidade de usuários de seu framework e, conforme necessidades destes, novas
funcionalidades eram implementadas. Atualmente, há dezenas de milhares de
usuários com diversificados aplicativos usando o Hibernate.

20. 20
Quando a comunidade de desenvolvedores / usuários do Hibernate começou
a crescer, foi notada a dificuldade em ampliar as demasiadas exigências e, com
isso, foi concluído que o sucesso e melhoria do projeto necessitava de dedicação
exclusiva de uma equipe (integralmente).
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
suporte e otimizam tal framework.
2.2. APLICAÇÃO
O Hibernate, conforme citado anteriormente e baseado em informações de
Bauer e King (2005), tem sido utilizado em muitos milhares de aplicativos em
produção. Isso é explicado pelo simples fato dele automatizar uma tarefa tediosa e,
muitas vezes, complexa de persistir objetos.
Como há uma grandiosa quantidade de desenvolvedores Java pelo mundo e,
com estes milhões, um incontável número de aplicativos são construídos e mantidos
todos os dias, equívocos inevitáveis entre o código orientado a objeto e os modelos
de bancos relacionais exigem que seja mapeado do código OO para o modelo
relacional. Hibernate, por sua vez, faz esta complexa tarefa para os
desenvolvedores e, por isso, tem tão boa aceitação.
Para melhor entendimento da arquitetura Hibernate, a imagem a seguir (figura
03) traz uma descrição de alto nível de sua arquitetura:

21. 21
Fonte – UFCG, 2008.
Figura 3 – Alto nível da arquitetura Hibernate.
2.2.1.Vantagens e Desvantagens
Segundo Bezerra (2010), há uma série de vantagens que fazem quase com
que as poucas desvantagens tornem-se quase imperceptíveis. Ao citar estas
vantagens, segue uma simples discriminação de cada uma:
• Abstrai o banco de dados: Isto significa que o desenvolvedor, que em muitos
locais precisa desempenhar mais de um papel (ex: analista, desenvolvedor, e
DBA), não necessitará ficar tão atrelado com as tarefas de criação e

22. 22
manutenção das tabelas, uma vez que elas serão conseguidas à partir do
mapeamento realizado pelo Hibernate;
• Menos código repetitivo de persistência: Os códigos SQL quando criados
repetidas vezes para realizar uma persistência em Java (normalmente com o
apoio de JDBC) tornam-se bastante tediosos e cansativos para qualquer
desenvolvedor. O Hibernate, diminui significativamente este problema;
• Melhor tratamento de exceções e gerenciamento de recursos: Qual
desenvolvedor Java nunca viveu uma embaraçosa situação de manter
conexões abertas (problemas com recursos) ou de tentar executar uma
consulta SQL (via JDBC) sem sequer ter aberto a conexão (problemas de
exceções). Estas corriqueiras falhas humanas e outros problemas aceitáveis
para gerar uma exceção são melhores controlados pelo framework que, sob
seu cuidado, também cuida do tratamento de recursos;
Uma vez citados e explicados estes cenários benéficos para o Hibernate, é
necessário definir que nem tudo é feito somente de prós e, no caso deste
framework, ainda na visão de Bezerra (2010), é possível ocorrer algum overhead e o
mesmo tem uma forma diferente da habitual (para desenvolvedores muito
acostumados com SQL) – o que exige alguma curva de aprendizagem.
Ampliando a reflexão sobre eventuais pontos negativos, é primordial lembrar
que há uma série de sistemas que implementam parte das regras de negócio
diretamente no banco de dados (por meio de Triggers, procedures e outros
recursos). Com este extensivo uso do banco de dados, certamente o modelo de

23. 23
objetos implementados não deve conseguir benefícios amplos com uso de Hibernate
(Linhares, 2009).
Ainda assim, é totalmente possível concluir que é adequado e uma boa
escolha optar pela escolha de um implementador da JPA robusto como o Hibernate.
2.3. APRESENTAÇÃO DE OUTROS PROVEDORES
Neste tópico serão apresentadas apenas duas possibilidades em detrimento
ao Hibernate. Entretanto, só haverá uma breve distinção de características dos
mesmos, cabendo assimilar qual a melhor adoção de acordo com o projeto a ser
trabalhado, as necessidades e orçamentos da empresa detentora do projeto, entre
outros.
Questões estas que, quando levantadas, necessitam de uma melhor análise
do que meramente apresentar características. Contudo, não é enfoque da pesquisa
detalhamento de todos os provedores JPA para definição do melhor e sim, a
apresentação mais voltada ao Hibernate, considerando que há outros frameworks
utilizáveis.
2.3.1.TopLink
Toplink é um produto Oracle que, segundo o próprio site do fabricante, é um
produto voltado para aplicativos que necessitam de alto desempenho e

24. 24
escalabilidade, produtividade do desenvolvedor e flexibilidade em design e
arquitetura, especialmente no que diz respeito as necessidades de persistência
(Oracle, 2010).
O TopLink é membro da família de produtos Oracle Fusion Middleware, que
promete maior agilidade, melhor tomada de decisões e redução de custos e risco
para diversos ambientes de TI. Contudo, apesar desta informação oficial da Oracle,
há questionamentos informais na comunidade de desenvolvedores sobre a
integração entre funcionalidades e produtos Oracle, bem como a liberdade de
trabalhar em suas IDE's.
2.3.2. OpenJPA
O Apache Open JPA é um projeto, como o nome sugere, da Apache Software
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
aplicações Java EE, como Tomcat, Spring, Struts, entre outros.
2.4. METADADOS
Conforme Bauer e King (2007), as ferramentas de ORM requerem metadados
para especificar o mapeamento entre classes e tabelas, propriedades, colunas,

25. 25
associações e chaves estrangeiras, ou seja, entre os tipos de objetos do Java e os
tipos do SQL. Todas estas informações listadas são denominadas metadados.
Para melhor contextualização, metadados são dados a respeito de dados e as
opções de mapeamento de metadados são a forma de indicar ao Hibernate como as
classes persistentes e suas propriedades relacionam-se com as tabelas e colunas
de cada banco de dados.
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
durante o deploy das classes Java).
Outra opção possível é a utilização de metadados com Annotation (que, por
sua vez, são embasados na especificação do EJB 3.0 e consistem em inserir
'anotações' diretamente no código Java, deixando as classes do modelo de objetos
definidas como classes persistentes).
2.4.1.Metadados e mapeamento em XML
Forma inicial, amplamente popularizada e simples de ser lida, inclusive, por
seres humanos. Acrescido a isto, é facilmente manipulável em quaisquer editores de
texto e dá a vantagem de permitir a personalização em tempo de implantação
(Bauer e King, 2005).
É uma forma de mapeamento que pode ser considerada simples, porém,
requer alguma atenção para evitar deslizes convencionais. Ela consiste em definir

26. 26
em um arquivo XML as propriedades e os relacionamentos de uma classe para o
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
algum elementos abaixo listados:
• <hibernate-mapping>: Após trazer as definições de DTD do arquivo, o
nó raiz (hibernate-mapping) é o que sinaliza para o início do
mapeamento;
• <class name=”” [table=””]>: Define o nome da classe que está sendo
mapeada e, também, o nome da tabela para qual aquela classe está
sendo mapeada – é importante citar que se o nome da tabela for igual
ao nome da classe, não será obrigatório colocar o atributo table;
• <id name=”” [column=””]>: Define o identificador chave da tabela que é
representado por um atributo da classe em questão. Seguindo a
linhagem do nó acima descrito, há a opção de definir o nome da coluna
que representa no banco de dados – caso a coluna do banco não
tenha o mesmo nome do atributo da classe.
• Dentro do nó de id, é importante existir outro nó (<generator>) caso
tenha, por exemplo, um valor auto-incremental para uma chave
definida neste id;

27. 27
• <property name=”” column=”” type=””>: Este nó é responsável por
efetivar a referência entre todos os atributos da classe e os campos da
tabela (não-chave). Ele apresenta, além das propriedades de name,
column e type, uma quantidade significativa de opções para definir
informações como por exemplo, de um campo único;
• <one-to-one name=”” class=”” cascade=””>: Mapeia um relacionamento
de um para um entre os objetos do modelo.
Há outras diversas notações para outros tipos de relacionamento (1:N, N:N),
para heranças, agregações, polimorfismo, entre outros.
Em primeiro momento, pode parecer que há limitações imensas no uso de
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
para solucionar o problema:
<property name=”media” formula=”(select AVG(valor) FROM tabelaX WHERE id_item =
3)” type=”big_decimal” />
Durante explicações da implementação do código-fonte do estudo
comprobatório, serão trazidos mais códigos para amostragem. Neste ponto, para
melhor ilustrar, há um trecho de um mapeamento da classe Pessoa (posteriormente
utilizada e explicada no estudo).

28. 28
Fonte – Acervo pessoal.
Figura 4 – Metadados com XML.
2.4.2. Metadados e mapeamento com Annotation
O mapeamento objeto-relacional baseado em anotações está presente nas
especificações mais atuais do Hibernate, aproveitando-se da existências de
anotações em Java incorporados desde a versão 5.0,
Este mapeamento com anotações visa, justamente, sanar alguns
descontentamentos com a necessidade de uma infinidade de configurações dos

29. 29
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
do mapeamento dos seus atributos.
Conforme definem Fernandes e Lima (2007), as annotations são metadados
acrescentados aos códigos-fonte, os quais são desconsiderados pelo compilador
pela existência do sinal de @ (arroba).
A funcionalidade introduzida a partir do Java 5, conforme apresentado, está
dividida em anotações simples e anotações meta. Das quais permite, literalmente,
fazer uma 'anotação' de que aquele trecho tenha algum sentido diferenciado do
restante do código que será compilado.

30. 30
Fonte – Acervo pessoal
Figura 5 – Metadados com Annotations.
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
ser explicadas com um nível de detalhamento:

31. 31
• @Entity: Definirá que aquela classe sendo implementada representa
uma entidade persistente do banco de dados;
• @Table: Proporcionará o vínculo entre o nome da tabela no esquema
de dados físico e a classe sendo mapeada. Além do nome da tabela,
há uma série de atributos aproveitáveis para algumas configurações
primordiais, como por exemplo, a definição do schema sendo utilizado,
entre outros;
• @Id, @GeneratedValue: Como as anotações sugerem, estas
informações que apareceram, respectivamente, nas linhas 12 e 13 da
figura de exemplo, servem para definir uma chave primária de uma
tabela sendo mapeada (@Id), bem como a estratégia na forma de
gerar estes valores e a coluna a qual o mesmo será atribuído;
• @Temporal: Permite mapear tipos de dados não primitivos e que
exigem alguma complexidade. No exemplo, as linhas 19 e 24 exibem o
mapeamento de um atributo do tipo 'Calendar' de java.util.* para um
tipo de dado TIMESTAMP, do banco de dados relacional;
• @Column: Marcação muito convencional utilizada para definir qual
coluna do banco de dados refere-se a qual atributo do modelo de
objetos;

32. 32
• @OneToOne: Demonstrado na figura pela linha 33, esta marcação
nada mais é que uma existência de um relacionamento entre duas
entidades do banco que também é representada no modelo de dados,
ou seja, é um relacionamento um-para-um (1:1). Também há diferentes
anotações para tratar outros relacionamento, porém, no modelo de
exemplo, não houve nenhuma ocorrência desta situação;
• Dentro do OneToOne houve uma incidência do fetch=FetchType.LAZY,
que é faz com que, ao trazer um objeto “pai” do banco de dados, o
conteúdo somente seja devolvido quando ocorrer o primeiro acesso.
Apresentados alguns detalhes sobre o mapeamento de metadados com
Annotation, este capítulo é encerrado para que haja uma explicação aprofundada
sob as necessidades do software proposto. Contudo, mais características serão
tratadas posteriormente, quando for demonstrada a implementação completa do
software.

33. 33
CAPITULO 3
ESTUDO DE CASO – GesTI (Gestão de Custos em TI)
Este capítulo demonstrará toda a especificação do sistema proposto por meio
de diagramas de análise e diagramas de banco de dados. Além disso, é dada uma
visão macro sobre todo o projeto e seus requisitos não-funcionais.
3.1. DESCRIÇÃO NARRATIVA DO SISTEMA
O GesTI é um sistema que provê auxílio estratégico às pessoas no segmento
de Tecnologia da Informação, permitindo gerenciar alguns custos básicos de
projetos da área, bem como a relação de custos entre Pessoal vs. Tarefas vs.
Recursos [sejam estes recursos lógicos (softwares agregados) ou físicos
( equipamentos utilizados )].
Ainda que reduzidos os número de funcionalidades, as implementações do
GesTI servem como estudo comprobatório da eficácia no uso de um framework de
mapeamento objeto-relacional (Hibernate) durante a construção de software.
Mostrando suas vantagens sobre outras metodologias, desde que o projeto atenda
algumas necessidades, como a existência de um modelo de objetos bem definidos e
como a separação das regras de negócio na própria aplicação em Java.

34. 34
3.2. LISTAGEM DE REQUISITOS NÃO-FUNCIONAIS
O sistema, conforme definido no último tópico, será aplicado no ambiente de
Tecnologia da Informação, com intuito de servir como mecanismo para aferir os
custos de um projeto. Automatizando assim, uma tarefa nem sempre praticada por
gestores mais relapsos (sejam quaisquer as justificativas para esta característica).
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
posteriormente sejam criadas versões para desktop e para dispositivos móveis.
Como vantagem inicial do desenvolvimento web há:
• a alta escalabilidade alcançada;
• a manutenibilidade em bons níveis de realização;
• havendo uma atualização de software, não é necessário permissão individual
de cada usuário da máquina cliente para realizar a instalação de versões;
• com o novo conceito de computação nas nuvens, nada impede de os
servidores de aplicação estarem em uma destas estruturas e mantidos por
uma equipe especializada;
• não há problemas corriqueiros como o de uso de arquivos concorrentemente
por usuários, entre outros.

35. 35
3.3. DIAGRAMA DE CASOS DE USO DO SISTEMA
Em uma visão de altíssimo nível, com intuito ilustrativo e sem trazer quaisquer
detalhamentos completos de documentação, as atividades do sistema são
apresentadas neste esboço de diagrama de casos de uso:
Fonte – Acervo pessoal
Figura 6 – Diagrama de casos de uso do sistema.
Com embasamento proporcionado pela figura 6, cabe maiores explicações,
conforme são descritas abaixo:
Há o perfil de administrador que alimenta o sistema com informações sobre
cargos, níveis, pessoa, relação de pessoa e cargo, entre outros.
Uma vez destacadas estas informações, uma pessoa com um cargo atribuído
participa de um ou mais projetos, onde está diretamente envolvida em uma ou mais
tarefas que compõe este projeto.

36. 36
Esta relação entre os funcionários e as tarefas de projeto são executadas
utilizando-se de quaisquer recursos que, por sua vez, compõem juntos uma relação
de custo, ou seja, uma pessoa em um cargo, envolvida em uma tarefa de projeto e
utilizando um recurso (seja este lógico ou físico), gera determinados custos.
Essa gestão destes custos, agregados do acompanhamento das tarefas por
parte dos funcionários é o principal objeto deste software.
3.4. DIAGRAMA DE CLASSES DO SISTEMA
Após emitir as primeiras explicações sobre o âmbito deste sistema proposto,
é preciso detalhar com um pouco mais de afinco todo o modelo de objetos presente
na aplicação.

37. 37
Fonte – Acervo pessoal.
Figura 7 – Diagrama de classes do sistema.
Neste diagrama de classes, são exibidas todas as classes comuns ao projeto,
Trazendo ainda as multiplicidades das associações delas e algumas composições –
como acontece em Projeto composto de Tarefas e Pessoa possui Endereço.
As operações de cada classe foram omitidas por questões de exibição,
entretanto, os atributos foram considerados para demonstrar do quais as
propriedades fundamentais que diferem as classes.
Posteriormente, serão definidos e explicados alguns componentes de
implementação, que são diferenciações do modelo de objetos de POJO simples

38. 38
para agregar funcionalidades como o uso de Design Pattern (MVC, DAO) durante a
a criação e manutenção do software.
3.5. MODELAGEM DE DADOS (D-ER)
Uma vez apresentado o diagrama de classes do projeto, já é possível exibir o
que este modelo de objetos resultará quando houver o processo do mapeamento
objeto-relacional, ou seja, quando efetivamente estas informações dos objetos forem
persistidas no banco de dados, como ficará cada tabela, suas tuplas e suas colunas
em questão.
Esta definição complementa totalmente o modelo de dados e, baseado nas
regras adequadas de mapeamento, é possível notar o seguinte diagrama resultado
para um diagrama de entidade-relacionamento:

39. 39
Fonte – Acervo pessoal.
Figura 8 – Modelo Entidade-Relacionamento.

40. 40
CAPITULO 4
DESENVOLVIMENTO
Este capítulo abrange toda a etapa de implementação da solução proposta
anteriormente, além de demonstrar profundamente a construção de software
proposta (embasada em boas práticas de programação e design patterns). Serão
exibidos detalhes de uma sequência lógica de cadastro e recuperação de
informações via Hibernate, bem como os resultados desta construção (na
demonstração das telas do sistema em funcionamento).
4.1. COMPONENTES ARQUITETURAIS
Antes de iniciar efetivamente a demonstração dos componentes criados para
a arquitetura do software proposto, é fundamental haver a definição de alguns
recursos utilizados:
• Sistema Gerenciador de Banco de Dados MySQL, em sua versão 5.0.45;
• Linguagens de programação Java, em sua especificação Java EE;
1. Uso dos seguintes frameworks:
1. JSF – Java Server Faces, versão 2.0;
2. Hibernate;
• Soluções para desenvolvimento web com recursos de JSP, JSTL, Ajax,
RichFaces (para tratar adequadamente as interfaces definidas com JSF),
CSS, Ajax, entre outros;

41. 41
• Conteiner Web Apache Tomcat, em sua versão 6.0.18.
A solução, apoiada pelo uso destes recursos citados e voltada para web, teve
a arquitetura definida conforme imagem a seguir.
Fonte – Acervo pessoal.
Figura 9 – Arquitetura de pacotes da aplicação construída.
Como é possível notar na figura 9, as 3 cores utilizadas para diferenciar
visualmente os pacotes servem para definir a utilização do padrão arquitetônico
MVC (Model-View-Controller). Padrão este, que encontra-se bastante enraizado no
desenvolvimento de software por prover diversas vantagens na organização e em
eventuais mudanças de todo o código da solução criada.
Embasados nos conceitos do MVC, foram criados três pacotes básicos para
definir o Model do software (representação em vermelho na imagem). São eles:

42. 42
4.1.1. Pacote br.com.gesTI.model.entitiesAnnotation
Este pacote é bastante simples por trazer as classes do modelo de objetos
representandas, quase que, fielmente uma tabela do banco de dados, ou seja, são
POJO's simples.
A maior complexidade neste pacote é que ele trata efetivamente de todas as
anotações (Annotations) realizadas para persistir as classes (leia-se entitdades
quando o raciocínio estiver do lado do banco de dados). Então, um eventual
equívoco em um dos mais simples mapeamentos existentes, pode acarretar em
problemas uma vez que for realizada a persistência dos dados.
4.1.2. Pacote br.com.gesTI.model.dao
Aproveitando dos recursos da orientação a objetos e dos padrões de projeto
(o nome DAO refere-se ao padrão de projetos Data Access Object), este pacote
define as interfaces que devem ser implementadas a fim de efetivarem as
transações com o banco de dados.
A seguir (figura 10), um trecho da codificação de uma das interfaces:

43. 43
Fonte – Acervo pessoal.
Figura 10 – Demonstração de interface com padrão DAO.
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
interfaces quando chamadas por um ManagedBean, por exemplo.
4.1.3. Pacote br.com.gesTI.model.dao.implementation
Entre os pacotes mais importantes para a aplicação proposta, o pacote de
implementações dos DAO's é o que efetiva as transações com o banco de dados
apoiando-se no mapeamento realizado (seja esse mapeamento por Metadados XML
ou por Annotations).

44. 44
Fonte – Acervo pessoal.
Figura 11 – Classe com implementação do padrão DAO.
No trecho da figura acima, nas linhas 31 e 51 é perceptível a ocorrência de
um sinal similar a uma letra “I”, este sinal simboliza que a classe em questão está
implementando métodos que foram definidos externamente (nesse caso pelos
DAO's) que estão sendo implementados.
Continuando a apresentação dos outros pacotes, com marcação visual na cor
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
entre um componente e outro, trazendo o benefício do fraco acoplamento na solução
final.

45. 45
4.1.4. Pacote br.com.gesTI.controller
Com o uso do JSF na aplicação, o pacote de Controller aqui é representado
pelos ManagedBeans, ou Beans Gerenciados que, conforme explicado na descrição
acima, trarão as informações do Model para a View e farão também o caminho
inverso, alimentando o Model com informações da View.
Para melhor demonstração, segue trecho resumido de um Bean Gerenciado.
Fonte – Acervo pessoal.
Figura 12 – ManagedBean do pacote Controller.

46. 46
Dentre as linhas importantes, o método inserir (que inicia na linha 39) traz
exatamente a explicação do interfaceamento entre Model e View. Como exibido
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
Strings de retorno e mensagem (linhas 47-48 ou 32-53).
Finalizando a explicação dos pacotes, existe as informações da View
(representação em amarelo na figura 9), que é a a fronteira entre o usuário e o
sistema, ou seja, onde o mesmo efetua as interações.
4.1.5. Pacotes br.com.gesTI.view.phaselistener e
br.com.gesTI.view.util
Estes pacotes foram explicados juntos, pois sua divisão não se dá por nada
além da organização. Basicamente, o phaselistener é um ouvinte de todas as
requisições enviadas ao JSF, assim, dentro deste pacote, há uma classe que verifica
as permissões de acesso ao usuário.
Enquanto isto, no pacote util, só existem arquivos de configuração
(.properties), que podem ser usados para criação de aplicações internacionalidas.
Contudo, as principais informações da View não se resumem a somente dois
pacotes, pois todo o conteúdo da view está representado pelas páginas web do
projeto.

47. 47
4.2. INTERFACES DO SISTEMA
Neste tópico serão apresentadas algumas imagens sobre a aplicação
desenvolvida.
4.2.1. Tela de Login no Sistema
Abaixo (figura 13), a tela de login para o sistema GesTI.
Fonte – Acervo pessoal.
Figura 13 – Interface de login no sistema.

48. 48
4.2.2. Tela Principal
Na figura 14, a tela de gerenciamento para funcionários com o perfil de
administrador. Neste ponto, funcionários com este tipo de perfil podem criar tarefas,
atribuir projetos, gerenciar os custos de um funcionário / recurso / tarefa em um dado
projeto.
Fonte – Acervo pessoal.
Figura 14 – Interface principal do perfil Administrador.
4.2.3. Tela de Exibição de Funcionários
Finalizando, a figura 15 apresenta uma tela de exibição de funcionários que,
embora na imagem apresente propositalmente um componente não populado com
os funcionários em questão, demonstra o uso de RichFaces agregado ao Java
Server Faces (da camada Controller e especialmente da View).

49. 49
Fonte – Acervo pessoal.
Figura 15 – Interface de listagem dos funcionários.

50. 50
CONCLUSÃO
A utilização do Hibernate, ou de quaisquer outros provedores da
especificação JPA, trazem facilidades no desenvolvimento / manutenibilidade do
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
uma infinidade de erros e inegavelmente definida como tarefa entediante para os
responsáveis em sua execução.
Contudo, ainda apresentando amplitude nos pontos positivos trazidos no
trabalho, algumas coisas devem ser ressaltadas:
• Como o fato do Hibernate possuir uma curva de aprendizado grande e, para um
desenvolvedor dominar toda a sua amplitude de funcionalidades, são
necessários bons anos em variados projetos.
• Há soluções que por especificação e definição, mostram-se desvantajosas no
uso de Mapeamento Objeto-Relacional. Conforme citado durante o desenvolver
da pesquisa, uma solução com muita regra de negócios definida em procedures
e triggers do próprio banco de dados, é um exemplo disto.
Apesar destas considerações, vale ressaltar que a composição adequada das
classes do projeto, divididas em uma arquitetura que segue os mais diversificados
padrões de projeto e apresenta um código fracamente acoplado, ou seja, onde as
partes trabalham corretamente de forma independente, facilita demasiadamente o
uso de uma solução para mapeamento dos modelos de objetos ricos em modelos de
dados para o banco de dados.
Com isso e com a grande tendência de melhoria contínua das soluções para
Mapeamento O-R (com EJB3, Annotations e novas funcionalidades que venham a
surgir), as evidências indicam que cada vez maior será o número de adeptos ao

51. 51
Hibernate e ao provedores da JPA, melhorando cada vez mais o desenvolvimento
de software.

52. 52
REFERÊNCIAS BIBLIOGRÁFICAS
AMBLER, S. W.; Jewell, T. e ROMAN, E. Dominando Enterprise JavaBeans. 2 ed
São Paulo: Bookman, 2002. 508 p. Título do original: Mastering Enterprise
JavaBeans].
ASHOK, S.; KIONG D. e POO, D. Object-Oriented Programming and Java. 2 ed.
Springer, 2008.
BAUER, C. e KING, G. Hibernate em Ação. Tradução de Cláudio Rodrigues Pistilli.
Rio de Janeiro: Editora Ciência Moderna, 2005. Título do original: Hibernate in
Action
BEZERRA, Marcelo. Hibernate. Universidade de Brasília – CJR – Empresa Júnior
de Computação, Brasília - DF. Disponível em: <http://svn2.assembla.com/svn/tabd3/
hibernate/hibernate_eng_soft_2007%5B1%5D.pdf> Acessado dia 04 out. 2010.
CAMPOS, F. A. B e SANTUCI, L. B.. Estudo de Aplicabilidade do Padrão MVC.
2009. 111 f. Trabalho de Conclusão de Curso (Graduação em Ciência da
Computação) - Universidade de Franca, Franca, SP.
DEITEL, H. M.; DEITEL, P. J. Java como programar. 6. ed. Tradução de Edson
Furmankiewicz. São Paulo: Pearson Education, 2005. Título do original: Java how to
program, 6th.
GAMMA, E.; HELM, R.; JOHNSON, R.; VLISSIDES, J. Padrões de Projeto:
Soluções Reutilizáveis de Software Orientado a Objetos. Tradução de Luiz ª
Meirelles Salgado. Porto Alegre: Bookman, 2000. Título do original: Design Patterns:
Elements of Reusable Object-Oriented.
LINHARES, M. Introdução ao Hibernate 3. Grupo de Usuários Java, 2005.
Disponível em: < http://www.guj.com.br/content/articles/hibernate/intruducao_hiberna
te3_guj.pdf >. Acessado em: 12 dez. 2010.
MOURA, C. F. Desenvolvimento de Sistema de Auxílio a Prefeituras Usando
Mapeamento Objeto-Relacional. 2009. Trabalho de Conclusão de Curso (Pós-
Graduação em Desenvolvimento de Projetos em Java com Banco de Dados) –
Centro Universitário Claretiano, Batatais, SP.
NEVES, D. L. F. PostgreSQL: Conceitos e Aplicações. São Paulo: Érica, 2002.

53. 53
ORACLE (SUN MICROSYSTEMS). JPA Containers. 2002. Disponível em:
<http://blogs.sun.com/ievans/resource/images/jpaExample-containers.png >. Acesso
em: 10 nov. 2010.
UFCG – UNIVERSIDADE FEDERAL DE CAMPINA GRANDE. Persistência usando
Hibernate. 2008. Disponível em: <http://www.dsc.ufcg.edu.br/~jacques/cursos/daca
/html/hibernate/hibernate.htm > Acesso em: 20 nov. 2010.