ISSN 2316-2872

T.I.S. So Carlos, v. 1, n. 1, p. 09-19, jul. 2012

Tecnologias, Infraestrutura e Software

Utilizando padres de Projeto JEE no

desenvolvimento de aplicaes web:
um estudo de caso
Leandro Lupianhez, Daniel Lucrdio
Abstract: There are many advantages of using design patterns to create web applications. Currently the use of design patterns in conjunction with the JEE technology is becoming increasingly required by the job market. So it is important to know about when and where to apply
them. This paper presents some design patterns, and a case study with practical examples of using these patterns in JEE architecture. The
and others.

Keywords: design pattern, JEE, web application

Resumo: Inmeras so as vantagens do uso de padres de projeto na criao de aplicaes WEB. Atualmente a utilizao de padres de
projeto em conjunto com a tecnologia JEE vem se tornando cada vez mais requisitada pelo mercado de trabalho. Assim importante conhecer
e saber quando e onde aplicar os padres de projeto. Este artigo apresenta alguns padres de projeto, e um estudo de caso com exemplos prticos da utilizao desses padres na arquitetura JEE. O artigo destaca que com os padres de projeto muitos benefcios so obtidos, tais como,

Palavras-Chave: padres de projeto, JEE, aplicao web

1. INTRODUO
Criar software para web com qualidade tem se tornado cada
vez mais complexo e difcil, principalmente quando se trata de
domnio em reas corporativas. Nas grandes empresas de tecnologia voltada para o mercado de software, onde se utiliza o
paradigma de Orientao a Objetos e Padres de Projeto, existe
preocupao com seus empregos corretos devido as suas complexidades.
O crescimento das aplicaes web que fazem uso da tecnologia JEE vm se tornando cada vez mais presentes no mercado. Com isso inevitvel que surjam problemas, muitos destes
relacionados com a estruturao incorreta do sistema e a falta
de conhecimento da tecnologia empregada.
Dentre os vrios problemas existentes podem-se destacar
alguns, tais como: controle de pr-processamento e ps-processamento de requisies de aplicaes web, controle e coordenao de processamento de mltiplas requisies, acesso
de negcio das aplicaes, exposio indevida da lgica de
negcio, acesso a informaes externas envolvendo operaes
complexas de rede, acesso desorganizado a fonte de dados, uti-

lizao inadequada de processamentos assncronos entre outros

(SUN MICROSYSTEMS, 2010).
Neste artigo so apresentadas solues baseadas nos principais padres de projeto utilizados em grande parte das aplicaes corporativas, de modo a proporcionar uma base de conhecimento que possa vir a ser empregada na soluo de alguns
problemas ocorridos na estruturao de um projeto de software
para web. Para tanto, foi desenvolvido um sistema denominado
GPDS1, utilizando padres de projeto, consolidando-se um referencial para outras aplicaes similares.
O desenvolvimento do sistema GPDS foram utilizados alguns padres de projeto, que proporcionaram boas prticas de
implementao, maior clareza e reaproveitamento de cdigo.
Este artigo est organizado da seguinte forma: na sesso II
apresentada uma pequena introduo sobre padres de projeto;
padres de projeto JEE; na seo IV apresentada uma discusso de trabalhos realizados anteriormente sobre o assunto
deste artigo; na seo V apresentado em forma de um estu1. Gerenciador de Processos de Desenvolvimento de Software um sistema
para controlar processos no desenvolvimento de softwares.

Departamento de Computao Universidade Federal de So Carlos (UFSCar)

Caixa Postal 676 13.565-905 So Carlos SP Brasil
Autor para correspondncia: leandro.lupianhez@gmail.com, daniel@dc.ufscar.br

Leandro Lupianhez e Daniel Lucrdio

do de caso como foram utilizados os padres de projeto JEE

no desenvolvimento de uma aplicao web; na seo VI so

Na Tabela 1, apresentada no Apndice, observa-se a categorizao dos padres de projeto GoF (Gang of Four Gangue dos Quatro), no entanto, este no o nico tipo de padro
existente, muito embora seja o mais conceituado e utilizado no
mercado, outros padres como EAM , PSiGene, DASCo, faz-se interessante o estudo em contra ponto ao padro GoF, resultando a nfase e contribuies que cada um oferece.

caso.

II. PADRES DE PROJETO

Os Padres de projeto tm o intuito de propor e catalogar
solues a problemas recorrentes na criao de projetos de software orientados a objeto, com base em solues j empregadas
com sucesso em projetos.
De acordo com Gamma et al. (2000), um padro de projeto

III. PADRES DE PROJETO JEE

Com a evoluo e maturidade da tecnologia JEE, o centro
de tecnologia Sun Java Center2
solues para problemas semelhantes ocorridos em projetos de

comunicantes que precisam ser personalizadas para resolver

um problema geral de projeto num contexto particular. Assim,
um padro de projeto nada mais do que a documentao de
uma possvel soluo de um problema em um contexto comum,
podendo assim ser adaptado integralmente as necessidades de

padro e documentar em alto nvel de abstrao as possveis

solues a serem utilizadas (SUN MICROSYSTEMS, 2010).
de arquitetura de trs camadas para o desenvolvimento de aplicaes web.
A Figura 1 ilustra um exemplo da diviso dessas camadas:

Ainda segundo os mesmos autores, em geral, a estrutura de

um padro de projeto composta por quatro elementos, onde
o primeiro elemento refere-se ao nome do padro, o segundo
elemento refere-se ao problema que o padro se prope a solucionar, o terceiro elemento refere-se soluo proposta pelo
padro e o quarto elemento refere-se s conseqncias da utilizao do padro.
Na maioria das vezes os padres so utilizados em conjunto, onde cada um assume uma responsabilidade no contexto do
problema. Com isso necessrio que os padres sejam organiseja, o que o padro se prope a fazer.
tegorias. A categoria 1, padres de criao, responsvel pelo
processamento de criao dos objetos. Por exemplo, maneiras
comuns de se instanciar objetos, abstraindo o processo de instanciao tornando assim o sistema independente de como so
criadas as instncias dos objetos.
A categoria 2, padres estruturais, responsvel pela composio de classes e objetos. Por exemplo, maneiras comuns
de se organizar classes, objetos e interfaces, assim podendo
descrever formas de se compor objetos para obter novas funcionalidades.
A categoria 3, padres comportamentais, responsvel pelo

Figura 1. Exemplo da arquitetura JEE

(TUTORIAL JAVA EE 5, 2010).

Camada de Apresentao camada que comporta as aplicaes web desenvolvidas em Java que tero acesso aos compopginas JSP3 (Java Server Pages) e JSF4 (Java Server Faces).
Camada de Negcio camada onde se encontram os compotema. nessa camada que se encontram os componentes EJB5
(Enterprise JavaBeans).

suas responsabilidades.

se a aplicao dos padres em classes e subclasses, permitindo

assim o uso de herana, enquanto que escopo de objeto refere
aplicao dos padres em instncias de classe, podendo assim

2. Sun Java Center uma consultoria da organizao Oracle focada em prover

solues de arquitetura baseada na plataforma JEE, com foco na obteno
de qualidade de servio.
3. Java Server Pages
processo de desenvolvimento de sites da web dinmicos.
4. Java Server Faces uma tecnologia que incorpora caractersticas de um

Segundo os mesmos autores, a Tabela 1 nomeia alguns pacopo.

em eventos.
5. Enterprise Java Beans um componente da plataforma JEE o qual utilizado para o desenvolvimento de aplicaes distribudas, com controle de
concorrncia, controle de transaes e maior escalabilidade.

qual os padres de projeto so aplicados. Os escopos podem ser

T.I.S. 2012; 1 (1): 09-19

10

Utilizando padres de Projeto JEE no desenvolvimento de aplicaes web: um estudo de caso

Camada de Integrao camada onde se encontram fontes

de informao como banco de dados, acesso aos dados de sistemas legados, entre outras fontes externas. Por exemplo, nessa
camada que se encontra toda a parte de persistncia de objetos
onde se empregada a tecnologia JPA6 (Java Persistence API).
Do mesmo modo que a arquitetura JEE foi dividida em trs
camadas, o catlogo de padres JEE foi organizado em trs
conjuntos de padres.
A Tabela 2, apresentada no Apndice, ilustra o catalogo de-

tar se necessrio um processamento de negcio de forma limitada. Por exemplo, uma pgina web em JSF, pode ser chamada
diretamente, ao passo que seu contedo dinmico recuperado
a partir de objetos (backing beans9), que geram os dados que
so apresentados na pgina.
Dispatcher View: utilizado para centralizar e controlar o tratamento de requisies HTTP. Possibilita que um processo de
negcio seja executado e o mesmo recupere o estado de um
objeto antes da pgina ser chamada.

Malks (2004).

B. Padres da camada de Negcio

A. Padres da camada de Apresentao

projeto da camada de negcio segundo Alur, Crupi e Malks
(2004).
Business Delegate: utilizado para encapsular o acesso a
componentes e servios de negcio, ocultando os detalhes de
implementao. Por exemplo, se um cliente precisar acessar
um componente de negcio, o Business Delegate quem faz a
comunicao entre o cliente e o componente de negcio, abstraindo qualquer complexidade de acesso, como detalhes de
comunicao remota.
Service Locator: utilizado para encapsular a pesquisa de
componentes e servios de negcio de maneira uniforme. Por
exemplo, o Service Locator que localiza e cria a instncia de
um componente EJB no servidor de aplicao, essa localizao
feita remotamente atravs de JNDI10.
Session Faade: utilizado para encapsular o acesso a componentes e servios de negcio, expondo remotamente suas
interfaces.
Application Service: utilizado para centralizar a lgica
que envolve vrios componentes e servios da camada de
negcio, de forma que fornea uma camada de servio mais
uniforme.
Business Object: utilizado para separar os dados e a lgica
de negcio de um objeto, por exemplo, em um cenrio onde um
objeto possui informaes de um cliente, tais como endereo.
Os dados do endereo so separados em outro objeto, de forma

jeto da camada de apresentao segundo Alur, Crupi e Malks

(2004).
Intercepting Filter: utilizado para interceptar e manipular
requisies HTTP7 de entrada, e respostas de sada atravs de
de um usurio.
Front Controller: utilizado para centralizar o controle do
gerenciamento das requisies HTTP. Por exemplo, pode-se
atravs do controle das requisies fazer chamada de servios
de segurana, autenticao, autorizao, tratamento de erros e
navegao de pginas.
Context Object: utilizado para encapsular informaes de
forma independente de protocolo de comunicao. Por exemplo, um objeto encapsular informaes obtidas da sesso de
um usurio (idioma, dados do usurio), e permitir que essas
informaes sejam acessadas por qualquer parte da camada de
aplicao, sem ter a necessidade de interagir com um protocolo
de comunicao, como por exemplo, o HTTP.
Application Controller: utilizado para recuperar e chamar
requisies HTTP, centralizando o processamento de compode navegao.
View Helper: utilizado para encapsular a formatao e o
processamento de exibio de dados em uma pgina web. Por
exemplo, possvel efetuar a formatao de dados de negcio,

cliente, que apenas tem em seu contexto o acesso ao objeto

endereo.
Composite Entity: utilizado para agregar um conjunto de
entidades em um objeto conceitual de negcio. Por exemplo,

atravs da utilizao de tag libs, tais como JSTL8.

Composite View: utilizado para criar vises agregadas de

lista de endereos, onde cliente e endereo so entidades que

no se relacionam.
Transfer Object: utilizado para transferir dados entre as
camadas de negcio, apresentao e integrao. Por exemplo,
caso seja necessrio transferir vrios dados de um componente
de negcio para a camada de apresentao, ento criado um
objeto de transferncia com os atributos e valores necessrios,
de forma que possa ser passado para camada de apresentao.

layout padro de uma pgina web, onde esse layout pode ser
composto dinamicamente por outros componentes, de forma
que crie uma nica viso.
Service to Worker: utilizado para iniciar o acesso a uma pgina web sem ter que passar pelo Front Controller. Pode execu-

mapeamento objeto relacional.

7. Hyper Text Transfer Protocol um protocolo de aplicao responsvel pelo
tratamento de pedidos e respostas entre cliente e servidor na web.
8. Java Server Pages Standard Tag Library, um componente da plataforma de

dades e mtodos que podem ser acoplados a componentes de interface.

10. Java Naming and Directory Interface uma API para acesso a servios de
diretrios. Ela permite que aplicaes cliente descubram e obtenham dados
ou objetos atravs de um nome.

uma biblioteca de tags para tarefas comuns, tais como processamento de dado.

11

T.I.S. 2012; 1 (1): 09-19

Leandro Lupianhez e Daniel Lucrdio

Transfer Object Assembler: utilizado para criar e centralizar

um modelo de aplicao composto por Transfer Object. Por
exemplo, precisam-se obter informaes de um cliente, e essas
informaes esto divididas em dois objetos de transferncia,
onde um objeto contm as informaes de contato do cliente
e o outro objeto contm as informaes pessoais do cliente. O
Transfer Object Assembler centraliza essas informaes em um
nico objeto, de modo que apenas um objeto esteja trafegando
pelas camadas de negcio e apresentao.
Value List Handler: utilizado para gerenciar o processamento e armazenamento em cache de consultas que retornam
uma grande quantidade de informaes. Por exemplo, uma
consulta que necessite de muito processamento e executada
vrias vezes pode gerar um alto trfego de rede, levando em
considerao que os dados da consulta estejam em um ambiente remoto. Armazenando esses dados em cache o cliente no
precisa refazer a consulta toda vez, tornando o processo mais
rpido, diminuindo o tempo de resposta e o trfego de rede.

tivao, aplicabilidade, estrutura, participantes, colaboradores,

conseqncias, implementao, exemplo de cdigo, usos conhecidos e padres relacionados. No trabalho de Pereira (2008) foram exploradas as caractersticas dos seguintes padres: Adapter,
Decorator, Proxy, Faade, Composite, Observer, State, Iterator,
Template Method, Singleton e Abastract Factory.
Na viso de Pereira (2008), os padres de projeto induzem
a uma melhor implementao, haja vista que so essenciais os
acoplamento entre os objetos de aplicao.
longo dos anos, padres passaram a ser utilizados como solues para problemas da engenharia de software, capturando solues que foram desenvolvidas anteriormente e aperfeioadas,
emergindo com a utilizao da orientao a objetos. Nesse
trabalho so abordados os padres GoF: de criao, estrutural e
comportamental. Tambm realizada uma abordagem dos padres GRASP (Padres Genricos de Software para Atribuio
de Responsabilidade). Ao longo de seu trabalho, foi apresentada a utilizao do padro GoF Iterator.
Valente (2003) aborda em seu trabalho desde o contexto
-

C. Padres da camada de Integrao

projeto da camada de integrao segundo Alur, Crupi e Malks

(2004).
Data Access Object: utilizado para encapsular e gerenciar
todo acesso a fontes de dados e suas persistncias. Por exemplo, para efetuar um cadastro de pessoas, criado um objeto

utilizada para registrar o conhecimento e a experincia dos modeladores mais experientes, para transmiti-los aos iniciantes e
como uma forma de documentao. Esse descreve o contexto
de um padro que ocorre em trs sistemas distintos para se ro-

por realizar todas as operaes de criao, leitura, alterao e

excluso dos dados.
Service Activator: utilizado para trocar mensagens JMS11,
chamando processos assncronos. Por exemplo, um sistema de
vendas que recebe pedidos de compra e executa o pedido sem
dido.
Domain Store: utilizado para separar o cdigo de persistncia do modelo de objetos. Por exemplo, esse padro muito
utilizado por frameworks de persistncia, tais como Hibernate,
TopLink, entre outros.
Web Service Broke: utilizado para acessar servios atravs
de XML e protocolos HTTP. Por exemplo, atravs desse padro que um componente de negcio pode prover, e pode ter
acesso, a um servio disponibilizado na web, conhecido mais
como Web Service.

componentes de um sistema de software.

que agrupe padres de projeto J2EE pode ser um diferencial
de produtividade para o desenvolvimento de solues emprees dos padres de projetos esto diretamente associados a
problemas comuns no desenvolvimento de um projeto, bem
como, o conhecimento de indivduos experientes a serem disseminados aos demais membros da equipe.
Pode-se observar que os padres de projetos tm sido amplamente utilizados no mercado de trabalho, tanto para proverem
recorrentes no desenvolvimento de aplicaes. Desta forma,
to organizacional em nvel de desenvolvimento, bem como de
manuteno, neste cenrio, o fator qualitativo, por certo, vem

IV. PESQUISAS ANTERIORES REALIZADAS SOBRE O ASSUNTO

tem solues para problemas encontrados por desenvolvedores
durante a fase de projeto de software. Por certo os padres
de projetos vo muito alm de facilitadores na resoluo de
-

V. ESTUDO DE CASO

dos sistemas.

Nessa seo abordado em um estudo de caso (sistema

GPDS), com emprego de alguns padres de projeto JEE.
O sistema GPDS foi elaborado e desenvolvido, visando dar
suporte a equipes envolvidas em projetos de desenvolvimento

11. Java Message Service uma API da linguagem Java para troca de mensagens
assncronas.

T.I.S. 2012; 1 (1): 09-19

12

Utilizando padres de Projeto JEE no desenvolvimento de aplicaes web: um estudo de caso

de software, automatizando o planejamento de atividades em

um controle de cronograma capaz de fornecer informaes que
auxiliem em tomadas de decises. Dessa forma, tem-se um
melhor controle sobre o andamento dos projetos, que permiti
to com antecedncia.
mitir o desenvolvimento da aplicao com baixo acoplamento e um alto nvel de modularidade, facilitando o processo de
manuteno e evoluo do sistema, garantindo que seus recursos fossem baseados em padres j estabelecidos e com ampla
aceitao no mercado.
Seguindo os padres de arquitetura JEE, o sistema GPDS
foi dividido em trs camadas. Sua implementao foi separada em dois projetos: GpdsApplication-ejb e GpdsAppli-

Por exemplo, no sistema GPDS, houve a necessidade de vesistema, para tanto se utilizou o conceito do padro de projeto
Intercepting Filter.
cidade do usurio antes que o servidor processasse a resposta
do cliente.
uma classe concreta que implementasse a interface javax.servlet.Filter
toda lgica de autenticao dos usurios, diminuindo a repetio de cdigos de validao nas pginas contidas nos mdulos
do sistema.
O Quadro 1 ilustra o fragmento do cdigo que representa

Apndice. Com isso foi possvel ter uma maior produtividade,

mento do sistema, permitindo separar as responsabilidades de
lgica de apresentao, lgica de negcio e lgica de integrao de dados.
mentao do sistema GPDS.
lizados alguns padres de projeto JEE no sistema GPDS.

doFilter vetenticado no sistema, o mesmo redirecionado para uma tela de

login, onde dever ser realizada a autenticao, caso contrrio o
Aps a criao da classe de Filtro, necessrio registr-la no
descritor de deploy
rao no arquivo web.xml da aplicao.
SecurityFilter,
no arquivo web.xml.
SecurityFilter; a tag

A. Validando restrio de acesso com Intercepting Filter

No desenvolvimento de aplicaes WEB, as aplicaes so
estruturadas em torno de solicitaes e respostas onde o cliente
envia alguma requisio para uma ao do servidor, e que aps
o processamento dessa ao espera-se o retorno de uma resposta para o cliente. Contudo, surge em alguns casos a necessidade de efetuar um pr-processamento das solicitaes, tanto no
cliente quanto no servidor, evitando-se assim processamentos
desnecessrios.

ser aplicado. No contexto deste sistema, toda pgina contida

A utilizao do padro Intercepting Filter no sistema GPDS
possibilitou a soluo do problema de autenticidade de usurios em determinados mdulos do sistema, garantindo a qualidade, integridade, reutilizao de cdigo e centralizao do
processo de autenticao.

Quadro 1. Exemplo da implementao de um Filtro

13

T.I.S. 2012; 1 (1): 09-19

Leandro Lupianhez e Daniel Lucrdio

e negcio. Para isso foi necessrio criar classes auxiliares que

manipulassem os detalhes de comunicao entre as camadas.
Delegate disponibiliza o acesso aos componentes de negcio
Remote, onde possvel consultar os status de projetos e os
percentuais de atividades, abstraindo a complexidade de comunicao.
O Quadro 4 ilustra o fragmento de cdigo que representa
ponsvel por criar a instncia de um componente de negcio
remotamente.

B. Delegando acesso a componentes de negcio com

Business Delegate
No desenvolvimento de aplicaes web utilizando tecnologia JEE, as aplicaes so estruturadas de modo que possam
ser disponibilizadas em ambientes distribudos.
O sistema GPDS foi estruturado e desenvolvido de modo
que, se necessrio, seja possvel a sua implantao em um ambiente distribudo. Com isso surgiu a necessidade de centralizar
os acessos remotos a componentes de negcio EJB. Para tanto
se utilizou os conceitos dos padres de projeto Business Delegate e Service Locator.
O Quadro 3 ilustra o fragmento de cdigo que demonstra a
implementao do padro de projeto Business Delegate.
Dessa forma foi possvel permitir o acesso lgica de negcio evitando o acoplamento entre as camadas de aplicao

o para cada componente EJB. A localizao desses compo-

Quadro 3. Classe de acesso servios de negcio

T.I.S. 2012; 1 (1): 09-19

14

Utilizando padres de Projeto JEE no desenvolvimento de aplicaes web: um estudo de caso

Quadro 4. Ilustrao de mtodo que cria uma instncia de um objeto remoto

nentes feita por meio de recursos disponibilizados pela API

JNDI.
O Quadro 5 ilustra o fragmento de cdigo que representa um

Conforme mostra a Figura 2 todo o acesso as interfaces do

acessar uma ou mais das vrias instncias do subsistema, bem
como, realizar possvel interao com estas instncias e retornar as respostas solicitadas pelo cliente.
No sistema GPDS, o acesso aos componentes EJB realizado por meio da interface Session Faade, respeitando o

projeto Service Locator.

cia do contexto do servidor de aplicao, e atravs dos endereos
de localizao retorna as instncias dos componentes EJB.
Com a utilizao do BusinessDelegate pode-se abstrair os
detalhes de implementao e complexidade no que se refere
ao acesso as chamadas ao servidor de aplicao, por exemplo a
implementao do padro ServiceLocator.

deste padro, alm de prover maior nvel de abstrao, d-se

mediante possveis alteraes no subsistema, evitando-se um
efeito cascata sobre as demais partes do sistema.

C. Encapsulando lgica de componentes de negcio com

Session Faade

D. Transferindo objetos entre camadas com Transfer Object

Em sistemas web que utilizam recursos distribudos tais
como EJB, algumas entidades podem conter dados que sempre
so utilizados em conjunto, podendo assim aumentar o trafego
dos dados, sobrecarregando o processamento do servidor, bem
como, ocasionar alto trafego de rede de forma desnecessria.
No sistema GPDS, toda transferncia de dados foi abstrada
fazendo-se uso de Transfer Object, assim diminuindo a sobre-

Em projetos que utilizam EJB, clientes EJB no devem acessar diretamente beans de entidade (Entity Beans), deste modo,
o padro Session Faade
acessa um conjunto de interfaces de um subsistema, tornan(KYLE, 2010). O uso do padro Session Faade pode ser veri-

Quadro 5. Ilustrao de mtodo de localizao de Objetos

15

T.I.S. 2012; 1 (1): 09-19

Leandro Lupianhez e Daniel Lucrdio

Figura 2. Estrutura do padro Session Faade (SUN MICROSYSTEMS, 2010).

possvel tambm agrupar informaes e facilitar a exibio das

mesmas, tornando assim a lgica de apresentao mais simples

ber os dados de transferncias. Esses dados de transferncia podem ser obtidos atravs do bean
bean
cess Object.
O Quadro 6 mostra o uso do padro Transfer Object em uma
das interfaces do sistema que acessada remotamente por um
cliente, no caso do sistema GPDS por um Business Delegate.

A Figura 3 ilustra um diagrama de classe do padro Transfer Object na sua forma mais simples no contexto de uma aplicao.
representa um usurio do sistema, onde por meio de uma soli-

Figura 3. Diagrama de classe do padro de projeto Transfer Object (SUN MICROSYSTEMS, 2010)

T.I.S. 2012; 1 (1): 09-19

16

Utilizando padres de Projeto JEE no desenvolvimento de aplicaes web: um estudo de caso

Quadro 6. Interface de implementao utilizando o padro Transfer Object.

Com a utilizao do padro Data Access Object no siste-

A utilizao do padro Transfer Object no sistema GPDS possibilitou a soluo de muitos problemas, tais como, organizao
de dados de transferncias entre camadas da aplicao, diminuio de trafego de rede nas chamadas remotas do sistema entre
outras.

persistncia e acesso a dados ao longo do desenvolvimento

do sistema.

E. Consultando dados com Data Access Object

VI. CONCLUSO
Um Data Access Object (Objeto de Acesso a Dados) usado
para abstrair a e encapsular todo o acesso a uma fonte de dados
(SUN MICROSYSTEMS, 2010). Desta forma o Princpio da
responsabilidade nica mostra-se preponderante aos padres
de desenvolvimento.
No sistema GPDS, todo acesso a fonte de dados foi abstrado fazendo-se uso de DAO`s. Assim toda operao de CRUD
(Create, Retrieve, Update e Delete) foi descrita e implementada por meio destes.
A Figura 4 demonstra, por meio do diagrama de classes,
como se d a interao dos DAO`s no contexto da aplicao:
Conforme pode ser observado na Figura 4, um DAO encapsula todo acesso a um DataSource, desagregando tal responsabilidade do componente de negcio (Business Object). Em
suas operaes o DAO pode utilizar ou criar Transfer Objects,
para retornar ao componente de negcio, bem como, receber os
mesmos do referido componente.
O Quadro 6 exibe a implementao de um mtodo contido
nos Data Access Objects da aplicao GPDS, para a recupera-

O presente artigo focou-se num estudo acerca da utilizao

dos padres de projeto no desenvolvimento de uma aplicao
denominada GPDS, sendo caracterizados os benefcios associados pelo uso destes. Fica explicito que os usos de padres
de projeto contribuem para resoluo de problemas normalmente encontrados durante o desenvolvimento de qualquer
aplicao.
No desenvolvimento da aplicao GPDS foi observado que
os padres de projeto possibilitaram um melhor reaproveitamento de cdigo, enfatizando o principio da responsabilidade
nica. Alem disso, possibilita maior clareza e permitir uma melhor manuteno. Observou-se tambm que o uso destes padres alm de contriburem em nvel de organizao de cdigo
possibilitou maior agilidade no, desenvolvimento, bem como,
dade de problemas comuns sanados pelo seu uso.
Neste trabalho procurou-se aprofundar na discusso dos seguintes padres: Intercepting Filter, Business Delegate, Session
Faade, Transfer Object e Data Access Object. A utilizao
desses padres permitiu a constituio de uma arquitetura junto
ao sistema, propiciando assim um fator comum de entendimento de comunicao entre as camadas do sistema, bem como, de
um melhor entendimento do sistema aos membros da equipe de
desenvolvimento e/ou aqueles que por ventura vierem a efetuar

deseja-se recuperar o objeto, a consulta ao banco de dados

da mesma, necessita-se dos dados recebidos como parmetro
no mtodo.

Figura 4. Mostra o diagrama de classes que representa a relao do padro Data Access Object
(SUN MICROSYSTEMS,2010).

17

T.I.S. 2012; 1 (1): 09-19

Leandro Lupianhez e Daniel Lucrdio

Quadro 7. Ilustra a implementao do mtodo que recupera os dados de uma entidade por sua chave primria

Este estudo abordou diversos benefcios propiciados pelos

padres de projeto. No entanto de imprescindvel importncia
o pleno entendimento da aplicao a ser desenvolvida de modo

KYLE BROWN. Rules and Patterns for Session Facades. Disponvel em: http://www.ibm.com/developerworks/websphere/library/techarticles/0106_brown/sessionfacades.html.
Acessado em: 25 de Agosto de 2010.
PEREIRA, ALINE DE SOUZA. Padres de Projeto: uma compilao dos mais utilizados em projetos de software. Faculdade
de Minas FAMINAS, Belo Horizonte MG, 2008. Disponvel em: http://www.ricardoterra.com.br/publications/students/ 2008_ pereira.pdf. Acessado em: 09 de Abril de 2010.
SORROCHE, ROGRIO; LOPES, MAURCIO CAPOBIANCO. Uso de Design Patterns e J2EE: um estudo de caso.
FURB, Universidade de Blumenau, Blumenau SC, 2003.
Disponvel em: http://www.inf.furb.br/seminco/2003/artigos/128-vf.pdf. Acessado em: 09 de Abril de 2010.
SUN MICROSYSTEMS. Sun Java Center J2EE Patterns. Disponvel em: http://java.sun.com/developer/technicaArticles/
J2EE/patterns/PatternsIntroduction.html. Acessado em: 09
de Abril de 2010.

aplicao. O principal objetivo dos padres oferecer soluo

a problemas comuns no contexto de desenvolvimento. Portanto, apenas fazer o uso de todos os padres em uma dada aplicao no pode ser traduzido como boa implementao haja vista
que a grandeza e complexidade da aplicao esto intimamente
associadas com a escolha dos mesmos.

REFERNCIAS BIBLIOGRFICAS
ALUR, DEEPAK; CRUPI, JOHN; MALKS, DAN. Core J2EE
patterns: as melhores prticas e estratgias de design. Rio
de Janeiro: Elsevier, 2004.
AZAMBUJA, ROGRIO XAVIER. Padres de Projeto de Softwares Orientados a Objetos. ULBRA, Santa Maria RS, 2008.
Disponvel em: http://www.ulbra.br/santamaria/eventos/jornada/2008/arquivos/Sis1223329207.pdf. Acessado em: 09
de Abril de 2010
GAMMA, ERICH; HELM, RICHARD; JOHNSON, RALPH;
VLISSIDES, JOHN. Padres de Projeto: solues reutilizveis de software orientado a objetos. Porto Alegre:
Bookman, 2000.

T.I.S. 2012; 1 (1): 09-19

EE 5 Tutorial. Disponvel em: http://download.oracle.com/

javaee/5/tutorial/doc/bnaay.html. Acessado em: 20 de Agosto
de 2010.
VALENTE, LUIS. Design Patterns Padres para Projeto.
Universidade Federal Fluminense, Niteri-RJ, 2003. Disponvel em: http://www.ic.uff.br/~lvalente/docs/DesignPatterns_Texto.pdf. Acessado em: 09 de Abril de 2010

18

Utilizando padres de Projeto JEE no desenvolvimento de aplicaes web: um estudo de caso

APNDICE - TABELAS

De Criao
Classe

Escopo
Objeto

Propsito
Comportamental

Estrutural
Factory Method

Adapter

Abstract Factory
Builder
Prototype
Singleton

Adapter
Bridge
Composite
Decorator
Faade
Flyweight
Proxy

Interpreter
Template Method
Chain of Responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor

Tabela 2. Catlogo de padres de projeto JEE

Apresentao
Intercepting Filter
Front Controller
Context Object
Application Controller

Negcio
Business Delegate
Service Locator
Session Faade
Application Service

View Helper

Business Object

Composite View

Composite Entity

Service to Worker
Dispatcher View

Transfer Object
Transfer Object Assembler
Value List Handler

Integrao
Data Access Object
Service Activator
Domain Store
Web Service Broker

Tabela 3. Projetos de implementao do sistema GPDS

Projeto
GpdsApplication-ejb
GpdsApplication-war

Projeto que contem a implementao da lgica de negcio e acesso a fonte de dados. Contempla
Projeto que contem a implementao da lgica de apresentao dos dados de negcio. Contempla

19

T.I.S. 2012; 1 (1): 09-19