• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
ESTUDO DE MAPEAMENTO OBJETO-RELACIONAL COM FRAMEWORK HIBERNATE
 

ESTUDO DE MAPEAMENTO OBJETO-RELACIONAL COM FRAMEWORK HIBERNATE

on

  • 8,375 views

 

Statistics

Views

Total Views
8,375
Views on SlideShare
8,372
Embed Views
3

Actions

Likes
3
Downloads
238
Comments
0

2 Embeds 3

http://www.linkedin.com 2
http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    ESTUDO DE MAPEAMENTO OBJETO-RELACIONAL COM FRAMEWORK HIBERNATE ESTUDO DE MAPEAMENTO OBJETO-RELACIONAL COM FRAMEWORK HIBERNATE Document Transcript

    • FERNANDO ANTONIO BARBEIRO CAMPOSESTUDO DE MAPEAMENTO OBJETO-RELACIONAL COM FRAMEWORK HIBERNATE BATATAIS 2011
    • FERNANDO ANTONIO BARBEIRO CAMPOSESTUDO 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
    • 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 HIBERNATEOrientador: Profº. Dr. Rodrigo de Oliveira Plotze.Examinador: ______________________________________Examinador: ______________________________________Batatais, ____ de ____________ de 2011.
    • DedicatóriaA meus pais, Maria Aparecida e Reinaldo, pela educação, afeto, ensinamentose por acreditarem incondicionalmente em meus sonhos.A minha tia Marinda e minha avó Palmira (in memorian) por terem sempre meacolhido como filho.A minha namorada Lidiane, pelo amor, atenção e compreensão em todos osmomentos.
    • AgradecimentosAGRADEÇO primeiramente a Deus, por ter proporcionado saúde, paz esabedoria; ao orientador e amigo Rodrigo Plotze pela dedicação, paciência e,sobretudo, por ter amparado com seu profundo conhecimento durante todo oestudo; 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 destetrabalho.
    • RESUMOEste trabalho propõe uma pesquisa sobre as soluções e vantagens agregadas comuso do mapeamento objeto-relacional no desenvolvimento / manutenção desoftware, com ênfase no provedor da Java Persistence API - Hibernate. Inicialmente,as etapas seguidas passam pela realização de levantamento bibliográfico sobre aconjuntura histórica e a explicação das necessidades que findaram o surgimento domapeamento objeto-relacional, bem como as evoluções de tecnologias (em especialJava - em suas vertentes Java SE, Java EE, entre outras), que possibilitaramminimizar os problemas enfrentados ao desenvolver uma aplicação orientada aobjetos que necessitasse de acesso em bancos de dados relacional. A partir disto, aespecificação JPA é tratada, juntamente com ampla definição de um de seusprovedores (Hibernate), com alguns comparativos com outros frameworks,apresentação de vantagens e desvantagens, apresentação de suas formas demapeamento de dados, entre outros. Como prova de conceito, foi definido umestudo 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 JavaEE, a partir da IDE Netbeans 6.8, seguindo a modelagem de dados definida pelaUML e utilizando base de dados MySQL. Findando a pesquisa, é feita uma análisedo desenvolvimento e apresentados os positivos resultados de um softwareconstruído com mais agilidade e poupando grande parte do tempo dedesenvolvimento. Além disso, ficam explicitas facilidades em questões comomanutenibilidade e volatilidade a mudanças de requisitos.Palavras-chaves: Java, Mapeamento Objeto-Relacional - JPA, Hibernate,Mapeamento em XML, Mapeamento com Annotation.
    • SUMÁRIOLISTA DE FIGURAS.....................................................................................................8INTRODUÇÃO............................................................................................................10 OBJETIVO.........................................................................................................................................................10 JUSTIFICATIVA E MOTIVAÇÃO..................................................................................................................10 ORGANIZAÇÃO DA MONOGRAFIA............................................................................................................11CAPITULO 1...............................................................................................................13MAPEAMENTO 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..........................................................................................................................18CAPITULO 2...............................................................................................................20HIBERNATE................................................................................................................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................................................................................................29CAPITULO 3...............................................................................................................34ESTUDO 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)..........................................................................................................39CAPITULO 4...............................................................................................................41DESENVOLVIMENTO................................................................................................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...............................................................................................................49CONCLUSÃO.............................................................................................................51REFERÊNCIAS BIBLIOGRÁFICAS...........................................................................53
    • LISTA DE FIGURASFIGURA 1 – ABSTRAÇÃO DO MAPEAMENTO O-R COM JAVA...........................14FIGURA 2 – DEMONSTRAÇÃO DE UM PROVEDOR JPA......................................18FIGURA 3 – ALTO NÍVEL DA ARQUITETURA HIBERNATE..................................21FIGURA 4 – METADADOS COM XML......................................................................28FIGURA 5 – METADADOS COM ANNOTATIONS...................................................30FIGURA 6 – DIAGRAMA DE CASOS DE USO DO SISTEMA.................................35FIGURA 7 – DIAGRAMA DE CLASSES DO SISTEMA............................................37FIGURA 8 – MODELO ENTIDADE-RELACIONAMENTO........................................39FIGURA 9 – ARQUITETURA DE PACOTES DA APLICAÇÃO CONSTRUÍDA.......41FIGURA 10 – DEMONSTRAÇÃO DE INTERFACE COM PADRÃO DAO...............43FIGURA 11 – CLASSE COM IMPLEMENTAÇÃO DO PADRÃO DAO....................44FIGURA 12 – MANAGEDBEAN DO PACOTE CONTROLLER................................45FIGURA 13 – INTERFACE DE LOGIN NO SISTEMA...............................................47FIGURA 14 – INTERFACE PRINCIPAL DO PERFIL ADMINISTRADOR................48FIGURA 15 – INTERFACE DE LISTAGEM DOS FUNCIONÁRIOS.........................49
    • 9 INTRODUÇÃO OBJETIVO O objetivo do trabalho é realizar um estudo embasado em aspectos teóricos epráticos sobre variados conteúdos assimilados do curso de Pós-Graduação emDesenvolvimento de Projetos em Java com Banco de Dados. Nesse âmbito, o temadefinido 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óriopara traçar métricas das vantagens de sua utilização (ou desvantagens) e assimilarcomparativos positivos e negativos sobre o tópico pesquisado. JUSTIFICATIVA E MOTIVAÇÃO Além de avaliar e agregar conhecimentos ao aprendizado dosado no curso, oassunto é extremamente atual e tende a comprovar grande facilitação na construçãode produtos de software de quaisquer segmentos. Isso se dá devido ao fato de que, diante de um cenário de amplas dificuldadesem todo o ciclo de vida de um software, uma das questões elencadas como maispropensas a falhas e que traz significativos problemas para analistas edesenvolvedores é, sem dúvida, a definição e a evolução do acesso a dados paraaplicações orientadas a objetos (dominantes em parte do segmento de produção desoftware) que evoluem de forma contínua. Com isso, a proposta visada é desenvolver um software manutenível, comagilidade e que atenda a volatilidade de requisitos dos clientes.
    • 10 ORGANIZAÇÃO DA MONOGRAFIA Basicamente, o trabalho é dividido em 4 (quatro) capítulos principais quepermitem desenvolver o conteúdo tratado e possibilitam a correta finalizaçãoconclusiva de toda a pesquisa e conhecimento adquirido. Um breve apanhado sobreos assuntos tratados em cada capítulo está descrito a seguir. O capítulo 1 aborda o assunto de forma macro, ou seja, traz os conceitossobre o mapeamento objeto-relacional e suas principais soluções no tratamento doproblema encontrado (onerosa forma de tratar as diferenças entre modelo relacionaladotado pelos SGBDs e a programação orientada a objetos). Além disto, estecapítulo cita a JPA (Java Persistence API) e permite ter uma visão genérica damesma. O capítulo 2, foca um detalhamento maior na ênfase da pesquisa, assim, oHibernate (provedor da JPA) é demonstrado em várias vertentes, sejam elascomparativas – quanto a outros provedores, ou seja eles qualitativas – desvendandovantagens 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 quesão as formas de mapeamento dos Metadados (Mapeamento com XML eMapeamento 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 derequisitos, diagramas de casos de uso e de classes, além da modalagem de bancode dados proposta. O capítulo 4 tratará especificamente da implementação proposta (em JavaEE) utilizando-se do auxílio do framework JSF (Java Server Faces), além, é claro, do
    • 11assunto estudado – Hibernate. Neste capítulo, os pacotes que dividem a construçãoda 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ódigopara demonstração do software criado. Este capítulo traz também, alguns protótiposdas telas implementadas.
    • 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 (JavaPersistence API). Com isto, será possível demonstrar o progresso na construção desoftware e as melhorias que podem ser agregadas aos projetos meramentealterando 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 oacesso a dados em um banco de dados relacional. Conforme citam Campos e Santuci (2009), o paradigma da orientação aobjetos tenta modelar os elementos em um sistema da mesma forma que sãopercebidos no mundo real. Desta forma, neste paradigma, os sistemas sãocompostos por objetos que possuem responsabilidades e funções, e estes,colaboram entre si para a realização de um objetivo comum.
    • 13 Na visão de Ashok, Kiong e Poo (2007), diferentemente dos softwaresproduzidos com um paradigma procedural (onde as instruções são executadassequencialmente), no paradigma orientado a objetos, cada entidade é vista comouma classe e estas, por sua vez, tem seus atributos e métodos para definir estado ecomportamento 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 erecuperar os dados que historicamente sejam criados/manipulados neste sistema.Estes dados, trabalhando juntos, tornam-se informações que permitem mensurar obom 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 dadosrelacional é muito mais utilizado comercialmente e tende a resolver a maioria dosproblemas corriqueiros de uma organização. Este modelo abstrai as entidades domundo 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 comsoluções de banco de dados relacionais. Contudo, a representação dos dados emtabelas de um sistema de banco de dados relacional é fundamentalmente diferente einadequada para as redes de objetos em uma linguagem de programação orientadaa objetos. Essa incompatibilidade, inicialmente, foi subestimada em questões comoimportância e custo. Todavia, ainda na visão de Bauer e King (2005), como maneirada atingir vantagem competitiva durante o desenvolvimento do software e com o
    • 14intuito de fugir do dispendioso acesso a dados tradicional, o Mapeamento Objeto-Relacional (ORM) é uma técnica que reduz os impedimentos da programaçãoorientada a objetos utilizando banco de dados relacionais e abstrai a solução de umaforma que as relações (tabelas) passam a ser representadas pelas classes, sendoas 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 deeconomia no desenvolvimento e melhores no ponto de vista da manutenção eevoluçã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 deresolver as dificuldades da incompatibilidade entre o paradigma OO e os sistemasde banco de dados relacionais. A mais popular na época, conforme Ambler, Jewell eRoman (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
    • 15necessitar do desenvolvimento de lógica de persistência (como JDBC ou SQL) nopróprio bean de entidade. Entre os anos de 2001 e 2003, uma série de fabricantes começou a tratarcom maior enfoque o caso das soluções de mapeamento objeto-relacional. Aindaque os beans de entidade gerenciados por persistência fosse plausíveis para omomento, eles não atendiam, sequer, os aplicativos menos triviais com modeloscomplexos de dados, Bauer e King (2005). Neste momento, esta série de fabricantes começou ou evoluíram seusmodelos de objetos-relacionais. Dentre estes produtos, é possível referenciaralgumas soluções que são utilizadas atualmente, como: TopLink, iBatis e o próprioHibernate – foco de estudo principal). 1.2.1.Arquitetura de Camadas Paralelamente a evolução do mapeamento objeto-relacional (e até com datasanteriores a ele), cresciam o número de aplicações que agregavam os padrões deprojeto como uma forma de atingir um software de melhor qualidade, maismanutenível e que permitia a especialização de desenvolvedores trabalhando emetapas específicas do projeto. Assim, o ganho em produtividade é bastante visível eatraente. Nesta vertente, há algumas classificações principais de padrões que, segundoGamma et al. (2000), englobam:
    • 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á, nestemomento, a inclusão de padrões populares como é o caso dos padrões de projetoque 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 softwarecomplexo, faz com que as aplicações sejam desenvolvidas em mais de umacamada. Assim, é comumente encontrada uma solução que trata de forma separadaa camada de apresentação, as regras de negócio e o controle das informações entreestas duas camadas anteriormente citadas. Essa conjuntura torna amplamente viável a utilização de um middleware paratratamento da camada de ORM, ou seja, imaginando uma solução modularizada,baseada em padrões de projeto, é muito simples incluir uma camada específica paratratamento da persistência dos dados, sem onerar o desenvolvimento do restante dosistema. Esta disposição de elementos, fez com que tornasse o uso de frameworkspara este mapeamento cada vez mais forte e enraizado na comunidade dedesenvolvedores.
    • 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 osframeworks que desejam implementá-la. Ou seja, ela define um meio domapeamento objeto-relacional ser convertido para objetos Java comuns (POJOs –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 daJPA) utilizado na camada de persistência traz mais produtividade para odesenvolvedor, com impacto principal no modo de controlar a persistência dentro doJava. Sendo que a persistência é uma abstração de alto-nível sobre JDBC e a JPAdefine 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 fabricantescriem implementações baseados nela e, conforme demanda, disponibilizem demodo comercial (ou não) para os desenvolvedores. Esses fabricantes queimplementam a JPA, geram os implementadores também conhecidos comoProvedores da JPA, que trazem características, funcionalidades e peculiaridades em
    • 18sua versão implementada. Por exemplo, um provedor pode trazer o tratamento decache, 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 estastornam a vida dos desenvolvedores muito difícil), cabe ressaltar que estesprovedores nada mais são que frameworks facilitadores para a existência correta eotimizada do mapeamento objeto-relacional. Desta forma, todos seguem o padrão etécnicas de mapeamento da API.
    • 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 demonstradosdetalhes técnicos desde seu surgimento e suas melhorias com o decorrer de anosde pesquisa, além de códigos explicativos, vantagens e desvantagens de seu uso ealgumas citações com outros provedores. 2.1. SURGIMENTO O início do desenvolvimento do Hibernate data do final de 2001 quando GavinKing (de forma independente e em um projeto aberto) iniciou sua implementaçãobaseado na ideia de que os beans gerenciados por persistência não atendiam porcompleto as necessidades para o problema de incompatibilidade entre POO e omodelo relacional. King e sua equipe apoiavam-se no auxílio da cada vez mais amplacomunidade de usuários de seu framework e, conforme necessidades destes, novasfuncionalidades eram implementadas. Atualmente, há dezenas de milhares deusuários com diversificados aplicativos usando o Hibernate.
    • 20 Quando a comunidade de desenvolvedores / usuários do Hibernate começoua crescer, foi notada a dificuldade em ampliar as demasiadas exigências e, comisso, foi concluído que o sucesso e melhoria do projeto necessitava de dedicaçãoexclusiva de uma equipe (integralmente). Logo, ao final de 2003, o Hibernate uniu-se a empresa JBoss Inc. (por suavez, comprada pela Red Hat) e, desde então, esta equipe de desenvolvedores dãosuporte e otimizam tal framework. 2.2. APLICAÇÃO O Hibernate, conforme citado anteriormente e baseado em informações deBauer e King (2005), tem sido utilizado em muitos milhares de aplicativos emproduçã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 mantidostodos os dias, equívocos inevitáveis entre o código orientado a objeto e os modelosde bancos relacionais exigem que seja mapeado do código OO para o modelorelacional. Hibernate, por sua vez, faz esta complexa tarefa para osdesenvolvedores e, por isso, tem tão boa aceitação. Para melhor entendimento da arquitetura Hibernate, a imagem a seguir (figura03) traz uma descrição de alto nível de sua arquitetura:
    • 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 comque as poucas desvantagens tornem-se quase imperceptíveis. Ao citar estasvantagens, 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 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 desteframework, ainda na visão de Bezerra (2010), é possível ocorrer algum overhead e omesmo tem uma forma diferente da habitual (para desenvolvedores muitoacostumados com SQL) – o que exige alguma curva de aprendizagem. Ampliando a reflexão sobre eventuais pontos negativos, é primordial lembrarque há uma série de sistemas que implementam parte das regras de negóciodiretamente no banco de dados (por meio de Triggers, procedures e outrosrecursos). Com este extensivo uso do banco de dados, certamente o modelo de
    • 23objetos implementados não deve conseguir benefícios amplos com uso de Hibernate(Linhares, 2009). Ainda assim, é totalmente possível concluir que é adequado e uma boaescolha 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 detrimentoao Hibernate. Entretanto, só haverá uma breve distinção de características dosmesmos, cabendo assimilar qual a melhor adoção de acordo com o projeto a sertrabalhado, as necessidades e orçamentos da empresa detentora do projeto, entreoutros. Questões estas que, quando levantadas, necessitam de uma melhor análisedo que meramente apresentar características. Contudo, não é enfoque da pesquisadetalhamento de todos os provedores JPA para definição do melhor e sim, aapresentação mais voltada ao Hibernate, considerando que há outros frameworksutilizáveis. 2.3.1.TopLink Toplink é um produto Oracle que, segundo o próprio site do fabricante, é umproduto voltado para aplicativos que necessitam de alto desempenho e
    • 24escalabilidade, produtividade do desenvolvedor e flexibilidade em design earquitetura, especialmente no que diz respeito as necessidades de persistência(Oracle, 2010). O TopLink é membro da família de produtos Oracle Fusion Middleware, quepromete maior agilidade, melhor tomada de decisões e redução de custos e riscopara diversos ambientes de TI. Contudo, apesar desta informação oficial da Oracle,há questionamentos informais na comunidade de desenvolvedores sobre aintegração entre funcionalidades e produtos Oracle, bem como a liberdade detrabalhar em suas IDEs. 2.3.2. OpenJPA O Apache Open JPA é um projeto, como o nome sugere, da Apache SoftwareFoundation que, segundo a própria Apache Software Foundation (2010), pode serusado como uma camada de persistência de classes em Plain Old Java (POJO) ouintegrada a um conteiner Java EE, trabalhando junto com outros frameworks paraaplicações Java EE, como Tomcat, Spring, Struts, entre outros. 2.4. METADADOS Conforme Bauer e King (2007), as ferramentas de ORM requerem metadadospara especificar o mapeamento entre classes e tabelas, propriedades, colunas,
    • 25associações e chaves estrangeiras, ou seja, entre os tipos de objetos do Java e ostipos do SQL. Todas estas informações listadas são denominadas metadados. Para melhor contextualização, metadados são dados a respeito de dados e asopções de mapeamento de metadados são a forma de indicar ao Hibernate como asclasses persistentes e suas propriedades relacionam-se com as tabelas e colunasde cada banco de dados. Dentre estas opções, pode haver a definição por utilizar documentos XML quesão lidos em tempo de execução pelo Hibernate (uma vez que já foram compiladosdurante o deploy das classes Java). Outra opção possível é a utilização de metadados com Annotation (que, porsua vez, são embasados na especificação do EJB 3.0 e consistem em inseriranotações diretamente no código Java, deixando as classes do modelo de objetosdefinidas como classes persistentes). 2.4.1.Metadados e mapeamento em XML Forma inicial, amplamente popularizada e simples de ser lida, inclusive, porseres humanos. Acrescido a isto, é facilmente manipulável em quaisquer editores detexto 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
    • 26em um arquivo XML as propriedades e os relacionamentos de uma classe para oHibernate, ou seja, todos os atributos das classes devem ser mapeados, bem comosuas associações. Deve ser criado um elemento XML para cada classe persistente do modelosde objeto e o conteúdo destes arquivos, deve seguir uma estrutura XML válida comalgum 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 • <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 dearquivos XML para mapear os objetos de uma classe, contudo, há uma sintaxe tãorica disponível para a definição destes arquivos que há uma gama irrestrita desoluções que podem ser tomadas a partir de um simples nó neste arquivo XML. Porexemplo, basta imaginar uma propriedade que deve ser definida dependente de umamédia de um valor na base de dados. Pode ser criado o trecho abaixo demonstradopara 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 estudocomprobatório, serão trazidos mais códigos para amostragem. Neste ponto, paramelhor ilustrar, há um trecho de um mapeamento da classe Pessoa (posteriormenteutilizada e explicada no estudo).
    • 28Fonte – 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 nasespecificações mais atuais do Hibernate, aproveitando-se da existências deanotações em Java incorporados desde a versão 5.0, Este mapeamento com anotações visa, justamente, sanar algunsdescontentamentos com a necessidade de uma infinidade de configurações dos
    • 29antigos arquivos em XML e a substituição desta técnica para uma maneira maissimples e adequada de sinalizar quando uma classe deve ser uma tabela, seguidado mapeamento dos seus atributos. Conforme definem Fernandes e Lima (2007), as annotations são metadadosacrescentados aos códigos-fonte, os quais são desconsiderados pelo compiladorpela 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 dorestante do código que será compilado.
    • 30 Fonte – Acervo pessoal Figura 5 – Metadados com Annotations. O código da figura acima traz uma das classes do projeto proposto com seudevido uso das annotations. Para efeito didático, algumas destas anotações devemser explicadas com um nível de detalhamento:
    • 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 • @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 comAnnotation, este capítulo é encerrado para que haja uma explicação aprofundadasob as necessidades do software proposto. Contudo, mais características serãotratadas posteriormente, quando for demonstrada a implementação completa dosoftware.
    • 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 meiode diagramas de análise e diagramas de banco de dados. Além disso, é dada umavisã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 segmentode Tecnologia da Informação, permitindo gerenciar alguns custos básicos deprojetos 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 doGesTI servem como estudo comprobatório da eficácia no uso de um framework demapeamento objeto-relacional (Hibernate) durante a construção de software.Mostrando suas vantagens sobre outras metodologias, desde que o projeto atendaalgumas necessidades, como a existência de um modelo de objetos bem definidos ecomo a separação das regras de negócio na própria aplicação em Java.
    • 34 3.2. LISTAGEM DE REQUISITOS NÃO-FUNCIONAIS O sistema, conforme definido no último tópico, será aplicado no ambiente deTecnologia da Informação, com intuito de servir como mecanismo para aferir oscustos de um projeto. Automatizando assim, uma tarefa nem sempre praticada porgestores 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 queposteriormente 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 3.3. DIAGRAMA DE CASOS DE USO DO SISTEMA Em uma visão de altíssimo nível, com intuito ilustrativo e sem trazer quaisquerdetalhamentos completos de documentação, as atividades do sistema sãoapresentadas 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 sobrecargos, níveis, pessoa, relação de pessoa e cargo, entre outros. Uma vez destacadas estas informações, uma pessoa com um cargo atribuídoparticipa de um ou mais projetos, onde está diretamente envolvida em uma ou maistarefas que compõe este projeto.
    • 36 Esta relação entre os funcionários e as tarefas de projeto são executadasutilizando-se de quaisquer recursos que, por sua vez, compõem juntos uma relaçãode custo, ou seja, uma pessoa em um cargo, envolvida em uma tarefa de projeto eutilizando um recurso (seja este lógico ou físico), gera determinados custos. Essa gestão destes custos, agregados do acompanhamento das tarefas porparte 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 presentena aplicação.
    • 37Fonte – 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
    • 38para agregar funcionalidades como o uso de Design Pattern (MVC, DAO) durante aa 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 oque este modelo de objetos resultará quando houver o processo do mapeamentoobjeto-relacional, ou seja, quando efetivamente estas informações dos objetos forempersistidas no banco de dados, como ficará cada tabela, suas tuplas e suas colunasem questão. Esta definição complementa totalmente o modelo de dados e, baseado nasregras adequadas de mapeamento, é possível notar o seguinte diagrama resultadopara um diagrama de entidade-relacionamento:
    • 39Fonte – Acervo pessoal.Figura 8 – Modelo Entidade-Relacionamento.
    • 40 CAPITULO 4 DESENVOLVIMENTO Este capítulo abrange toda a etapa de implementação da solução propostaanteriormente, além de demonstrar profundamente a construção de softwareproposta (embasada em boas práticas de programação e design patterns). Serãoexibidos detalhes de uma sequência lógica de cadastro e recuperação deinformações via Hibernate, bem como os resultados desta construção (nademonstração das telas do sistema em funcionamento). 4.1. COMPONENTES ARQUITETURAIS Antes de iniciar efetivamente a demonstração dos componentes criados paraa arquitetura do software proposto, é fundamental haver a definição de algunsrecursos 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 • Conteiner Web Apache Tomcat, em sua versão 6.0.18. A solução, apoiada pelo uso destes recursos citados e voltada para web, tevea 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 diferenciarvisualmente os pacotes servem para definir a utilização do padrão arquitetônicoMVC (Model-View-Controller). Padrão este, que encontra-se bastante enraizado nodesenvolvimento de software por prover diversas vantagens na organização e emeventuais mudanças de todo o código da solução criada. Embasados nos conceitos do MVC, foram criados três pacotes básicos paradefinir o Model do software (representação em vermelho na imagem). São eles:
    • 42 4.1.1. Pacote br.com.gesTI.model.entitiesAnnotation Este pacote é bastante simples por trazer as classes do modelo de objetosrepresentandas, quase que, fielmente uma tabela do banco de dados, ou seja, sãoPOJOs simples. A maior complexidade neste pacote é que ele trata efetivamente de todas asanotações (Annotations) realizadas para persistir as classes (leia-se entitdadesquando o raciocínio estiver do lado do banco de dados). Então, um eventualequívoco em um dos mais simples mapeamentos existentes, pode acarretar emproblemas 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 pacotedefine as interfaces que devem ser implementadas a fim de efetivarem astransações com o banco de dados. A seguir (figura 10), um trecho da codificação de uma das interfaces:
    • 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, definidaDaoFactory, que tem por padrão a criação de instâncias das implementações dasinterfaces 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 deimplementações dos DAOs é o que efetiva as transações com o banco de dadosapoiando-se no mapeamento realizado (seja esse mapeamento por Metadados XMLou por Annotations).
    • 44Fonte – 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 deum 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 pelosDAOs) que estão sendo implementados. Continuando a apresentação dos outros pacotes, com marcação visual na corverde, surge o pacote de Controller, que é uma das camadas do MVC responsávelpela troca de informações entre o Model e a View, ou seja, ele faz as notificaçõesentre um componente e outro, trazendo o benefício do fraco acoplamento na soluçãofinal.
    • 45 4.1.4. Pacote br.com.gesTI.controller Com o uso do JSF na aplicação, o pacote de Controller aqui é representadopelos ManagedBeans, ou Beans Gerenciados que, conforme explicado na descriçãoacima, trarão as informações do Model para a View e farão também o caminhoinverso, 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 Dentre as linhas importantes, o método inserir (que inicia na linha 39) trazexatamente a explicação do interfaceamento entre Model e View. Como exibidoacima, 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 pessoana base de dados. Os resultados desta transação são passados para a View com asStrings 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 osistema, 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 nadaalém da organização. Basicamente, o phaselistener é um ouvinte de todas asrequisições enviadas ao JSF, assim, dentro deste pacote, há uma classe que verificaas 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 doispacotes, pois todo o conteúdo da view está representado pelas páginas web doprojeto.
    • 47 4.2. INTERFACES DO SISTEMA Neste tópico serão apresentadas algumas imagens sobre a aplicaçãodesenvolvida. 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 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).
    • 49Fonte – Acervo pessoal.Figura 15 – Interface de listagem dos funcionários.
    • 50 CONCLUSÃO A utilização do Hibernate, ou de quaisquer outros provedores daespecificação JPA, trazem facilidades no desenvolvimento / manutenibilidade dosoftware. Eles tendem a tornar mais dinâmica a tarefa repetitiva de tratar todos osacessos a dados (por meio de JDBC, com linguagem SQL) – o que era passível auma infinidade de erros e inegavelmente definida como tarefa entediante para osresponsáveis em sua execução. Contudo, ainda apresentando amplitude nos pontos positivos trazidos notrabalho, 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 dasclasses do projeto, divididas em uma arquitetura que segue os mais diversificadospadrões de projeto e apresenta um código fracamente acoplado, ou seja, onde aspartes trabalham corretamente de forma independente, facilita demasiadamente ouso de uma solução para mapeamento dos modelos de objetos ricos em modelos dedados para o banco de dados. Com isso e com a grande tendência de melhoria contínua das soluções paraMapeamento O-R (com EJB3, Annotations e novas funcionalidades que venham asurgir), as evidências indicam que cada vez maior será o número de adeptos ao
    • 51Hibernate e ao provedores da JPA, melhorando cada vez mais o desenvolvimentode software.
    • 52 REFERÊNCIAS BIBLIOGRÁFICASAMBLER, S. W.; Jewell, T. e ROMAN, E. Dominando Enterprise JavaBeans. 2 edSão Paulo: Bookman, 2002. 508 p. Título do original: Mastering EnterpriseJavaBeans].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 inActionBEZERRA, Marcelo. Hibernate. Universidade de Brasília – CJR – Empresa Júniorde 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 daComputação) - Universidade de Franca, Franca, SP.DEITEL, H. M.; DEITEL, P. J. Java como programar. 6. ed. Tradução de EdsonFurmankiewicz. São Paulo: Pearson Education, 2005. Título do original: Java how toprogram, 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_hibernate3_guj.pdf >. Acessado em: 12 dez. 2010.MOURA, C. F. Desenvolvimento de Sistema de Auxílio a Prefeituras UsandoMapeamento 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.
    • 53ORACLE (SUN MICROSYSTEMS). JPA Containers. 2002. Disponível em:<http://blogs.sun.com/ievans/resource/images/jpaExample-containers.png >. Acessoem: 10 nov. 2010.UFCG – UNIVERSIDADE FEDERAL DE CAMPINA GRANDE. Persistência usandoHibernate. 2008. Disponível em: <http://www.dsc.ufcg.edu.br/~jacques/cursos/daca/html/hibernate/hibernate.htm > Acesso em: 20 nov. 2010.