Captulo

Entendendo a Arquitetura
de Desenvolvimento
6
A

Introduo
- Reso de Arquitetura de Software

jCompany Developer Suite pode ser compreendido como uma soluo de reso em nvel

arquitetural. E no apenas para reso de camadas de base de arquitetura para as aplicaes

desenvolvidas, mas tambm para o ambiente de desenvolvimento (IDE) e de Testes de Unidade. Estas
solues arquiteturais de base so providas, respectivamente, pelos mdulos jCompany FS
Framework, jCompany IDE e jCompany Test for Developer.
Mas qual seria a diferena deste tipo de reso em comparao ao reso mais pontual, digamos, em nvel
de uma classe ou pequeno grupo de colaborao de classes?
O reso arquitetural possibilita reso de estratgias complexas englobando desde o reso de
colaboraes extensas de frameworks, somada produo assistida de especializaes preconizadas por
mtodos e padres delineados pela arquitetura. Este tipo de reso de mais alto nvel que os demais.
Digamos, uma integrao de vrias estratgias de reso pontuais, que produz um resultado de
valor visvel para o cliente (Ex.: um Caso de Uso potencial) e no solues parciais intermedirias.
Em outras palavras: muito embora sejam importantes as tticas de reso em nvel de classe ou via
padres de projeto (Design Patterns), o reso arquitetural de nvel mais estratgico,
fundamental para quem deseja ganhos de produtividade e qualidade em ambientes com
desenvolvimentos em larga escala. Estes ganhos equivalem aos que se consegue construindo
uma nova casa a partir de componentes maiores, pr-fabricados, em comparao a se comear
selecionando madeira para fabricar portas, por exemplo.
Apesar de no existir uma nica soluo de arquitetura perfeitamente adequada a todas as situaes, as
diversas dimenses de arquitetura pr-implementadas no jCompany so customizveis...
Para isso vingar na prtica, porm, torna-se necessrio um entendimento mais profundo das suas
implementaes, inclusive das motivaes fundamentais (Rationale) que guiaram a Powerlogic em sua
proposta. Este captulo inicia esta discusso.

Estudo de Evoluo de Arquiteturas de Software Java EE

- O que Arquitetura de Software?
J discutimos sobre a importncia da arquitetura no Capitulo 1, mas no pressupomos que todos tenham
conhecimentos balizados sobre o assunto. Por isso, vamos rever algumas definies fundamentais:
Uma Arquitetura de Software para um sistema a que define a estruturao deste sistema, que
compreende seus Elementos, a Relao entre eles e as Propriedades externamente visveis destes
Elementos e Relaes.
Ref. A6.1. [TS-4619 JavaOne 2006]

Arquitetura de Software a decomposio do problema de uma maneira que permita ao

desenvolvimento eficientemente resolv-lo, considerando restries (...)
Ref. A6.2. [John Klein- Architecture and Design]

A arquitetura de qualquer aplicao deve ao menos incluir (quando no se basear em)

consideraes de performance. A arquitetura de uma aplicao corporativa deve considerar os
Ciclos de Vida de Objetos, assim como a sua forma de uso
Ref. A6.3. [Haines, Steven 2006]

No h muita controvrsia sobre a importncia decisiva que uma boa Arquitetura de Software pode ter
em processo de desenvolvimento de software em geral. Tambm h um grande reconhecimento, por
parte de especialistas, com relao ao papel central que os frameworks assumem nesta questo. Porm,
muitas empresas no chegam a experimentar os resultados prometidos nesta rea.
Para no corrermos este risco e obtermos os melhores resultados, nossa proposta somar o reso de
uma arquitetura abrangente com padres de alto nvel e automao de atividades, orquestradas por
Cheat-Sheets do Eclipse.
Nossa arquitetura tambm ser ajustada para a eficincia de processamento, um outro ponto comumente
negligenciado. um erro imaginar a arquitetura apenas do ponto de vista estrutural e terico. A
arquitetura influi decisivamente em performance e devem ser considerados os comportamentos dinmico
e prtico da aplicao, alm dos fatores usabilidade, flexibilidade e outras dimenses concorrentes, em
nossa problemtica.
No se satisfaa com uma Arquitetura de Software rasa. Mesmo uma arquitetura incipiente poder
produzir um bocado de documentos e diagramas impressionantes, mas trar resultados medocres,
quando algum. Uma arquitetura para o perfil tpico de projetos corporativos, por exemplo, deve
definir, em detalhes, dependncias entre projetos e mdulos, pacotes dentro de projetos,
artefatos, eventos de programao de alto nvel e, finalmente, trazer um bom nmero de
generalizaes e padres que conduzam a um resultado visvel para o negcio, rapidamente.
Nos prximos tpicos, discutiremos nveis de maturidade de arquiteturas de software.

- Arquitetura de Software Invisvel

Em nossa experincia no incomum encontrar empresas desenvolvendo em Java EE em um estgio
onde ainda no h nenhuma arquitetura realmente visvel para os implementadores. Neste nvel
de maturidade, o que se chama de arquitetura so alguns documentos, traando diretrizes conceituais
para o uso de MVC, este ou aquele framework ou at determinados Design Patterns.
Este cenrio primitivo , claro, melhor que nada. Mas insuficiente para se perceber qualquer ganho
considervel nesta rea um estgio ao qual chamamos de Arquitetura de Software Invisvel,
ilustrado na Figura A6.1.

Figura A6.1. Arquitetura de software Invisvel.

Neste estgio, as lacunas esto vazias entre a plataforma de infra-estrutura Java EE (1) e as aplicaes
de negcio (5). Por este motivo, um enorme potencial para erros est espreita dos desenvolvedores,
que ficam s voltas com programaes repetitivas de cdigo, que deveriam estar fatoradas em
nvel arquitetural.
No h como evitar. Para uma arquitetura real, ser necessrio que os arquitetos passem do
domnio dos conceitos para a experincia de uso nas tecnologias, suas possveis combinaes,
deficincias e valores, alm de provveis variaes de uso.
Montar uma arquitetura madura demanda um tempo que no pode ser facilmente abreviado
especialmente uma que envolva altssimas taxas de reso, partindo de solues best-of-breed Java EE

Open Source. Nesta filosifia, que a adotada pelo jCompany, a recomendao escolher peas
melhores em seu segmento. Algumas dezenas de tecnologias, projetos e componentes OSS devero ser
entendidos, selecionados, especializados e integrados, muitos deles em reas de conhecimento com
razovel distino das demais.
Por exemplo, a camada Viso do MVC envolve a orquestrao de diversas tecnologias complexas, tais
como JSP/Facelets (XHTML)/HTML, Javascript, CSS, Ajax, tcnicas de gesto de leiautes, etc.,
nenhuma delas de domnio especfico do mundo Java ou OO, de domnio dos Arquitetos de
Software. O resultado, na prtica, uma quase ausncia de arquitetura para a camada Viso,
delegada para tratamento superficial pelos Web-Designers.
Refinar uma boa arquitetura para a camada Controle tambm tem seus desafios, j que esta bem
mais complexa, tecnologicamente, do que as camadas subsequentes de Modelo/Domnio ou Persistncia.
uma outra camada onde o nvel de solues de arquitetura costuma ser muito raso, basicamente
consistindo de homologao de algum framework de base "em seu estgio bruto".
As camadas de Modelo, Domnio e Persistncia, por serem mais puramente ligadas a linguagem Java
e s regras de negcio costumam receber 90% da ateno nos trabalhos tpicos de Arquitetura de
Software, ao menos em seu estgio inicial. Porm, ao longo do tempo se far necessrio um esforo
nas demais camadas, que exigiro um considervel aprofundamento tecnolgico.

- Arquitetura de Software Anmica

Em um estgio um pouco mais adiantado, o trabalho acima j ter se iniciado, de modo que a
arquitetura j pode ser vista na forma de software, concreta, como uma soluo de base
corporativa a ser reutilizada.
Esta soluo frequentemente composta de uma pilha (stack) de produtos e framework de base Open
Source integrados, normalmente definida aps alguns meses iniciais de prospeco, seleo e integrao
leve. Digamos, de uma dzia de produtos de base, complementados por documentos de guia em nvel
mais detalhado. Ela est representada pela camada (2) na figura A4.2.
Mas neste nvel de maturidade, como no anterior, ainda h uma grande migrao de problemas no
funcionais para a camada de Core Business (5) e programadores do negcio lidando indevidamente
com:
o

Cdigos MVC burros (de->para, fachadas artificiais);

Gerenciamento de transaes manuais;

Instanciaes de objetos manuais;

Cdigos Java para incluso, alterao, excluso (CRUD);

Elaborao de formulrios do zero;

Gesto de leiautes manual;

Etc.

H um avano perceptvel com relao arquitetura meramente conceitual do incio, mas neste nvel a
arquitetura ainda rasa ao ponto de no eliminar mesmo variabilidades bsicas indesejveis.
A distncia entre a realidade e a promessa de retorno de ambientes Orientados a Objeto continua imensa
- por isto batizamos a este estgio de Arquitetura de Software Anmica.
um estgio basicamente caracterizado por uma integrao pouco profunda e abrangente entre um
nmero tambm insuficiente de produtos Open Source de base, conforme ilustra a Figura A6.2. Note que
as camadas sob responsabilidade da empresa so representadas na mesma colorao da camada de core
business.

Figura A6.2. Arquitetura de Software Anmica.

- Arquitetura de Software Intermediria

Neste estgio de maturidade, j encontramos evidncia clara de uma primeira Arquitetura de Software
Corporativa em verso razovel, integrando um bom nmero de insumos (frameworks e utilitrios)
Open Source com um esforo suficiente na produo de padres de alto nvel, nas diversas camadas
MVC.

Figura A6.3. Arquitetura de Software Corporativa em nvel intermedirio.

Mas para ser de nvel intermedirio, realisticamente, esta arquitetura ir requerer uma comprovao de
uso satisfatrio em produo seguido das inevitveis refatoraes - por pelo menos dois anos. um
perodo mnimo, aps a construo da primeira verso, durante o qual uma equipe de perfil abrangente*
conseguir evoluir para este nvel de maturidade.

* Composta de Arquiteto de Software, Analistas de Negcio, Web-Designers, Peritos nas Tecnologias, Documentadores, Analistas de
Teste etc.

A partir deste ponto, no entanto, este modelo comea a apresentar suas limitaes, especialmente se a
implementao arquitetural for concebida e desenvolvida totalmente por equipe interna:
o

Desvio de Foco: Uma equipe de valor estar dedicando boa parte de seu tempo em atividades
totalmente fora do foco do negcio, j que grande parte da soluo arquitetural no diferencial
para seu negcio.

Aumento de Custo: Mesmo que haja uma contratao de terceiros para a manuteno desta
camada, perdem-se os ganhos de escala possveis a partir do reso da parcela commodity da
arquitetura.

Problemas de Gesto: Normalmente, os problemas se agravam na medida em que comea a

existir uma base instalada da arquitetura em produo. Na fase de manuteno, requisitos
de Gerncia de Configurao passam a consumir uma grande parcela de esforo da
equipe interna para manter ramos de evoluo em paralelo com ramos compatveis. A
partir da, no incomum que o entusiasmo tcnico das primeiras fases d lugar a turn-overs ou
queda considervel de produtividade.

A percepo mais comum de que h uma dificuldade de ordem prtica para que esta soluo familiar
evolua para o prximo passo. Na medida em que as presses de negcio sobre aplicaes implantadas
prevalecem como prioridade, como haver de ser, h uma tendncia estagnao ou lentido para a
incorporao de inovaes, medo de reformulaes, etc.

- Arquitetura de Software Madura

Do nosso ponto de vista, uma primeira configurao de arquitetura rica e abrangente o suficiente para
oferecer os retornos esperados de um ambiente OO est ilustrada na Figura A6.4.

Figura A6.4. Arquitetura de Software Corporativa com alto nvel de maturidade.

Neste estgio, as preocupaes de nvel arquitetural que no sejam absolutamente dependentes do

contexto especfico da empresa so totalmente desacopladas de preocupaes de natureza comum ou
commodity.
Este o primeiro modelo que oferece um importante raciocnio de negcios: a potencial terceirizao
das camadas arquiteturais 2 e 3, horizontais, de forma a possibilitar a concentrao da
organizao nas camadas 4 e 5. De fato, somente as duas ltimas tm relevncia para o
ambiente especfico de TI e verticais de negcio.
Com esta possibilidade, aumenta-se no somente o foco no negcio. Diminui-se o custo e herda-se
qualidade e maturidade, abreviando-se longos anos e um grande nmero de problemas.

- Arquitetura de Software Provida pelo jCompany FS Framework

Se tomarmos como base somente a proposta do mdulo jCompany FS Framework, que prov uma
soluo arquitetural para as aplicaes desenvolvidas, veremos como ela pretende apoiar o modelo
anterior, oferecendo ganhos nas trs camadas arquiteturais:

Figura A6.5. Arquitetura em camadas de uma aplicao Java EE com o jCompany Full Stack Framework.

O apoio ao problema arquitetural do jCompany FS Framework se d de forma diferente, em cada

camada da arquitetura:
o

(2) Reduo do trabalho de integrao e pr-configurao da camada de reso Open

Source. Com isso, a empresa se liberta de manter partes de prospeco (P&D), integrao,
especializao, documentao de integrao, atualizao, controle de verses e gerncia de
configurao para estes insumos.

(3) Implementao completa e madura para a camada commodity, baseada em Design

Patterns de mercado. Com isso, a empresa se liberta de conceber, manter e evoluir a parcela
horizontal da arquitetura de software e de amadurec-la internamente.

(4) Soluo de base para a criao da camada especfica da empresa, chamada camada
Bridge. Deste modo, arquitetos da empresa podem imediatamente codificar suas generalidades e
especializaes de ltima milha, sobrepondo ou especializando artefatos da camada (c). Este
um espao concreto que possibilita a criatividade, customizao e generalizao que dependem
do contexto da empresa (segurana, web-design etc.)

- Outras Solues Arquiteturais do jCompany Developer Suite

Mas importante notar que, alm do jCompany FS Framework, os mdulos jCompany IDE e
jCompany Test for Developer tambm trazem solues arquiteturais para outras dimenses do
processo de desenvolvimento de software: ferramental/ambiente de apoio produtividade e solues de
base para Testes de Unidade, respectivamente.
Estas arquiteturas tambm podem ser expandidas e foram descritas no captulo 1, mas esto
reproduzidas nas Figura A6.6 e Figura A6.7, para convenincia:

Figura A6.6. Arquitetura de Software do Ambiente de Desenvolvimento (IDE).

Figura A6.7. Arquitetura de Software para desenvolvimento de Testes de Unidade.

- A Sndrome do NIH (Not Invented Here)

Apesar dos ganhos bvios advindos do reso de arquitetura, um entrave a esta inexorvel evoluo pode
estar no prprio corpo tcnico - por mais paradoxal que parea.
Um indivduo com interesse e formao em tecnologia, quando confrontado com um raciocnio de
negcios, pode falhar em identificar commodities de software, falhando em oportunidades de
terceirizao que so chaves para o negcio de sua empresa. Uma atitude sintomtica destes casos, por
parte de um arquiteto ou desenvolvedor, rotular arquiteturas (nunca as suas prprias!) de camisas de
fora, por exemplo*.
Todo reso exige esforo de compreenso e adeso ao que se deseja reutilizar, em um primeiro
momento, e deve possibilitar diferenciaes e flexibilidade para ganhos em nveis mais altos. Isso
vale para o reso de arquitetura, de objetos ou de componentes.

- Aprendendo a Reusar Arquitetura

Sendo, portanto, o reso em nvel de arquitetura a primeira arma de produtividade e qualidade de
ambientes Orientados a Objetos, ser essencial adquirirmos conhecimento nesta rea, para os prximos
nveis.

So o que Rod Johson, o criador do Spring, chama de Own Career Driven Architects [Johnson, Rod 2004] - indivduos que no
compreendem a importncia, para sua empresa, de orientarem a sua criatividadde para camadas de negcio. a insistncia em no
reusar, pelo desafio (ou interesse) pessoal de fazer.

Neste captulo, recapitularemos brevemente alguns fundamentos no campo da arquitetura de software

para nivelamento. No h pretenso e nem possibilidade de esgotarmos o assunto neste espao, mas os
pontos para discusso aqui selecionados procuram se concentrar em carncias frequentemente
encontradas em nosso mercado.

Reviso de Fundamentos
- Como Representaremos a Arquitetura?
Um sistema de software corporativo composto de muitas estruturas distintas, com relacionamentos
complexos. Portanto, so necessrias diversas vises para representar cada uma delas [TS-4619
JavaOne 2006]. Neste livro, iremos discutir as seguintes vises arquiteturais:
o

Viso Geral (General View): Utilizaremos a Viso Geral para uma primeira representao
(macro) das grandes camadas (Layers) e Blocos (Tiers) da arquitetura.

Viso de Mdulos (Module View): Utilizaremos a Viso de Mdulos para representar como
esto agrupados os conjuntos de artefatos em tempo de desenvolvimento e como eles se
relacionam entre si, em vrios nveis de detalhamento.

Viso Interna (Internal View): Utilizaremos a Viso Interna para representar como esto
organizados os projetos de desenvolvimento do ponto de vista de sua estruturao interna. um
tipo de viso de micro-arquitetura, considerando organizao dos pacotes e artefatos padres
definidos.

Viso Comportamental (Behavior View): Utilizaremos a Viso Comportamental para

representar como as categorias de classes colaboram entre si em algumas anatomias de
requisio MVC-P tpicas.

Viso de Execuo (Runtime View): Utilizaremos a Viso de Execuo para representar

como podemos embalar e liberar os conjuntos de componentes em tempo de execuo,
distribuindo-os ou mantendo-os em co-habitao, e como eles se relacionam nestas possveis
variaes de infra-estrutura. (Volume II)

Viso da Interface com o Usurio (GUI View): Utilizaremos a Viso de Interface com o
Usurio para representar os padres de leiautes, formulrios e componentes disponveis, como
esto organizados e interao entre si. Ela no contempla questes de usabilidade, discutidas
fora do mbito da arquitetura.

Alm das representaes principais para as vises acima, o detalhamento da arquitetura requer
documentos mais extensos que, por motivos didticos, no so disponibilizados neste livro. Eles esto
disponveis na documentao do mdulo jCompany Patterns & Methods, cedido com a licena
corporativa do jCompany.
Neste captulo, apresentaremos as trs primeiras vises: "Geral", "de Mdulos" e Interna. Com a
exceo da "Viso de Execuo", que somente ser abordada no Volume II desta srie, as demais sero
discutidas em captulos subsequentes.

- Arquitetura em Camadas (Layers)

O agrupamento de classes em mdulos, que por sua vez se organizam em camadas sobrepostas, um
sobre o outro, uma das metforas mais comuns em arquiteturas de software. A estes mdulos,
organizados rigorosamente desta forma, chamamos Layers (Camadas).
um paradigma que define dependncias de uma maneira simples (a camada de software de cima
depende da de baixo), mas que nos oferece um padro para realizar arranjos arquiteturais bastante
complexos, mas que ainda assim conseguimos compreender o que , alis, um dos grandes objetivos
de uma arquitetura OO.
O MVC, em si, uma arquitetura em camadas cujo intuito principal separar implementaes
relacionadas interao com o usurio (preocupaes da aplicao em si) das implementaes que
representam as regras de negcio fundamentais do negcio.
Para tanto, define uma camada controladora, que desacopla as camadas de Interface com o Usurio
(Viso) da de negcio (Modelo), e tambm encapsula algum tipo de implementao em seu nvel de
intermediao.
Na prtica, algumas dificuldades que percebemos no uso do MVC em Java EE so:
o

Erros fundamentais de acoplamentos indevidos entre as camadas;

Uso burocrtico, concebido para lidar com problemas intrnsecos do EJB 2.x, sem considerar
evolues tecnolgicas tais como o Java EE 5 e 6 e EJB 3.0 e 3.1;

Pouco investimento em generalizaes OO, levando ploriferao desnecessria de grande

quantidade de cdigo pr-forma (repetitivo), de comunicao entre as camadas.

Iremos discutir conceitos nestas trs reas, a comear pela questo das camadas:
o

Organizao com baixo acoplamento em Layer (Camadas Sobrepostas): Uma

organizao em Layer possui camadas sobrepostas uma sobre a outra, de modo que uma
camada somente dependa da imediatamente inferior. Por ter menos dependncias, cada
camada tende a ser mais estvel e flexvel. Esta organizao tambm conhecida didaticamente
como bolo de festa, em analogia s diferentes camadas de recheio que compem este tipo de
bolo:

Figura A6.8. Organizao em camadas.

Organizao em Referncia Circular: Muitas vezes uma representao errada ou pobremente

simplificada pode nos conduzir a concluses perigosas nesta rea. Por exemplo, a representao
esquerda da Figura A6.9 representa mdulos que no esto organizados em camadas, mas
que, devido omisso das setas de dependncia, sugere esta organizao.
Olhando a reviso direita, real, percebemos que se trata de uma arquitetura muito mais
complexa que a sugerida esquerda. Neste caso, inclusive mais instvel, pois sofre de um mal
conhecido como referncia circular. Este um problema que gera alto acoplamento e deve ser
evitado em todas as camadas de abstrao de um software.

Figura A6.9. Diagramao excessivamente simplificada de arquitetura.

Organizao de Tier (Blocos), com diagramao simplificada: Mas a organizao em

camadas no a nica utilizada em software e nem sempre a mais recomendvel. Pode-se
organizar uma aplicao em "blocos ou mdulos" (Tiers) que no so "isolantes" como as
camadas, mas ainda assim relacionam entre si de modo a manter baixas as dependncias.
Obs.: Mesmo nestes casos, muitas vezes a diagramao em camadas utilizada, para
simplificar o diagrama em si, ou enfatizar um comportamento. Por exemplo, a diagramao da
esquerda, na Figura A6.10, mais simples; mas quando exigido um rigor tcnico, pode dar
margem a confuso. Repare a verso mais exata direita, exibindo claramente que C
dependente diretamente de A e B.

Figura A6.10. Melhor diagramao de camadas.

Camadas paralelas e ortogonais: Como as organizaes de software so bem mais

complexas do que pode sustentar a metfora do bolo de festa, no mundo real ns iremos nos
deparar com combinaes mais sofisticadas das vrias abordagens possveis, ou vrias
dimenses de camadas.

Nas Figura A6.11 e Figura A6.12 vemos duas combinaes em camadas reais que produzem
arquiteturas estveis, corretamente diagramadas, e inclusive muito comuns em software.

Figura A6.11. Camadas paralelas.

Figura A6.12. Duas camadas transversais ou ortogonais.

Mesmo em uma arquitetura mais elaborada, como no caso da Figura A6.12, importante percebermos
que o raciocnio fundamental de minimizar dependncias atravs do uso de camadas continua presente.
Mas quais so os critrios para definirmos nossas camadas? O que cada camada ir conter e como
dependero umas das outras? Bom, estas respostas sero obtidas a partir de um raciocnio OO que
dever seguir inicialmente os velhos princpios de baixo acoplamento e alta coeso.

- Baixo Acoplamento (Menos dependncias, mais estabilidade)

O baixo acoplamento (ou diminuio das dependncias entre elementos) deve ser almejado em
estruturas de software em todos os seus nveis de abstrao:

Estruturas arquiteturais com o mnimo de dependncias

(Na prtica, com o maior uso possvel de camadas);

Aplicaes ou mdulos com o mnimo de dependncias (referncias externas)

(Na prtica, projetos com o menor tamanho possvel de Class Path);

Pacotes com o mnimo de referncias externas

(Na prtica, classes com o menor nmero possvel de imports);

Classes com menor nmero de referncias externas possveis

(Na prtica, pacotes com o mnimo de classes possvel).

Na implementao, classes que possuem menos dependncias tendem a ser mais simples de se
compreender e mais estveis, menos sensveis a turbulncias externas. Classes de camada Controle,
por exemplo, tendem a possuir mais dependncias, tais como interfaces de Servlet e de frameworks
como JSF ou Struts. Tendem, portanto, a ter mais imports que classes da camada Modelo ou
Domnio e a serem mais instveis (Por isso, dentre outros motivos, no so boas candidatas para
conterem implementaes importantes do negcio).
Mas como ser que isso se manifesta realmente, na prtica? Vamos ilustrar com o pequeno episdio real.
Certa vez, uma contribuio a um release menor do Tomcat 5.x introduziu a exigncia de
declarao implements Serializable para todos os objetos que fossem mantidos em sesso (a
inteno da equipe do Tomcat era atender a um aprimoramento de suporte a Clusters).
As nicas classes que realizavam registro em sesso eram, naturalmente, as que possuam acesso
(dependncia) a interfaces de Servlet. Apesar de ser uma mudana trivial nos objetos (uma
simples declarao), em vrias situaes de migrao para Tomcat 5.x, em todo o mundo, algumas
classes de controle escapavam reviso e cancelavam em produo, manifestando a
instabilidade provocada por esta dependncia.
um tpico problema produzido em camadas mais baixas da arquitetura que no acontece nas superiores
(de negcio, por exemplo), graas organizao em camadas do MVC.

- Alta Coeso (Melhor encapsulamento, maior reso)

Sob outro ngulo, queremos tambm que estruturas, nos seus diversos nveis de abstrao, se
mantenham especializadas, encapsulando implementaes de comportamentos de mesma afinidade e se
mantendo to simples quanto possvel em torno de um objetivo comum.
Em tempo de programao, mtodos que implementam mais de uma funcionalidade tendem a ser mais
confusos de se entender, manter e reutilizar. O mesmo ocorre com classes que agrupam blocos de
funcionalidade distintos, e assim por diante.
Pela nossa experincia, os maiores "crimes de baixa coeso ocorrem nos mtodos de partida,
que iniciam a resposta a um evento externo. Exemplos so o mtodo doGet de um Servlet ou o
contextInitialized em uma implementao de ServletContextListener, ou um execute de um DP
Command, utilizado em um framework qualquer. Nestes pontos da arquitetura, no difcil
encontrarmos verdadeiros programas COBOL, em sintaxe Java!

- Fatorao de Cdigo (Menos redundncias, mais eficcia)

A fatorao de cdigo consiste na identificao de cdigos redundantes ou muito similares em
diferentes artefatos, extrao da parte comum deste cdigo para um novo artefato independente, e
reviso dos originais para reusarem o cdigo extrado colocado em evidncia.
O objetivo do arquiteto, neste quesito, buscar por cdigos pr-forma (boiler plate) recorrentes,
vulgarmente conhecidos como cdigo burro e aplicar seus conhecimentos de arquitetura de software e
OO para elimin-los, possivelmente promovendo-os para frameworks ou utilitrios.
Fatorao de cdigo pr-forma , de longe, uma das questes da arquitetura que mais afetam a
produtividade e um dos objetivos principais de frameworks de integrao!
Uma arquitetura onde so admitidas grandes quantidades de cdigo burro, por limitaes de tempo ou
de conhecimentos mais aprofundados de OO e Java, fracassar ao menos parcialmente. Se no na
primeira verso da aplicao, nas fases seguintes, com as insustentveis manutenes.

- Refatorao de Cdigo (Fatorao contnua)

A melhor escrita a reescrita (...). Todo bom escritor sabe disto, e isto verdadeiro para software
tambm
Ref. A6.4. Paul Graham, citando E. B. White, em Hackers and Painters [Graham, Paul 2004]. Pg. 212

Mais recentemente, a fatorao de cdigo deu lugar a uma sucessora: a refatorao de cdigo
(Refactoring).
Bastante discutida por autores diversos com destaque para Kent Beck e Martin Fowler [Fowler, Martin
2004] e automatizada at certo ponto em IDEs tais como Eclipse, esta mudana de nfase para a
refatorao faz sentido na medida em que admitimos a dificuldade de se produzir cdigos bem fatorados,
de sada.
A verdade que hoje conhecemos que, ao contrrio do que alguns metodologistas eminentemente
tericos apregoam, dificilmente se obtm uma boa arquitetura na sua primeira verso.
Especialistas nas tecnologias e processos de Especificao (CASE UML, Ferramentas MDA etc.), mas que
pouco ou nada conhecem das tecnologias e processos de Construo, tero ainda mais dificuldade neste
objetivo. Portanto, ser prudente partir de preceitos arquiteturais que visem facilitar a refatorao ou
reformulao de cdigos de uma forma geral, com a produo do mnimo de instabilidade possvel.
Uma boa arquitetura obtida de exploraes prticas seguidas de refatoraes frequentes,
oportunidades que somente so bem aproveitadas por arquitetos de software hands-on, que se
atrevem a por a mo na massa.

- Arquitetura de Software proposta no jCompany

O estado atual da arquitetura proposta no jCompany fruto de uma boa amostra de projetos reais, com
fases de refatorao decisivas baseadas em problemas e sugestes reais de clientes. Apesar de no ser
perfeitamente ajustada para problemas de A at Z, contm solues para um mnimo denominador
comum que cobre um grande intervalo de problemas com solues generalizveis.
No estgio atual da arquitetura do jCompany, por exemplo, no mais requerida nem uma nica linha
de cdigo Java, em nenhuma das camadas do MVC, para se implementar Manutenes de Ciclo de Vida
de Objetos (incluir, alterar, excluir e consultar).
Mesmo quando lidamos com agregaes de objetos complexas, envolvendo cinco, dez ou at vinte
classes, o total de linhas de programao procedimental MVC para se obter um resultado com qualidade
de produo no jCompany tende a zero!
Manutenes de objetos em sua forma bsica so operaes commodity, candidatas primrias
fatorao de cdigo em qualquer linguagem de programao, especialmente em linguagens OO tais
como Java, e no deveriam ser resolvidas primariamente com gerao de cdigo - rapidez que
no se preserva nas manutenes.
Mas, indo alm destas operaes de manuteno de ciclo de vida, o jCompany generaliza por inteiro
dezenas de outras programaes sofisticadas e recorrentes em sistemas corporativos, tais como
clonagem de documentos, assistentes, leiaute dinmico para impresso, exploradores de dados
(treeview), exportao de dados, e muitas outras. Todas elas generalizaes que preveem espao para
especializaes em nvel corporativo ou em nvel de Caso de Uso, respeitando a arquitetura MVC.
Iremos experimentar estas promessas na prtica, no prximo mdulo. Neste captulo, vamos apresentar
a "Viso Geral", Viso de Mdulos e Viso Interna da arquitetura de software proposta pelo
jCompany.

Viso Geral - Grandes Camadas e Blocos da Arquitetura do Framework

- Viso Geral da Arquitetura do jCompany FS Framework
J apresentamos uma viso geral de toda a soluo jCompany Developer Suite, no captulo 1. Iremos,
na pauta atual, somente aprimorar a representao da arquitetura do framework jCompany FS
Framework, que representa a dimenso da soluo de maior interesse por parte de Arquitetos de
Software, j que inclui os componentes OO reutilizados e montados juntamente com as aplicaes.
A representao inicialmente apresentada no captulo 1 est repetida na Figura A6.13, para convenincia.
Os nmeros de 1 at 4 representam dependncias existentes para reso, desde a infra-estrutura,
passando pelos servios do Application Server, bibliotecas, frameworks de base, framework de integrao
e camada Bridge.

Figura A6.13. Viso Geral inicial da arquitetura do jCompany FS Framework.

Mas, mesmo sendo macro, esta representao muito simplria para estudos arquiteturais. Isto porque
nem a camada 3, do jCompany (Arquitetura Reutilizada), nem a camada 4, Bridge (Arquitetura
Especfica), funcionam como Layer, todo o tempo, como o diagrama pode sugerir.
Exceto nos percentuais de requisitos onde os Casos de Uso Padres so suficientes, o desenvolvedor
poder (e isto ser desejvel) acessar a camada 2 (JBoss Seam, Tiles/Facelets, JPA/Hibernate, etc.)
diretamente ou, mais raramente, a camada 1, em nvel do Application Server ou JVM.
Portanto, o diagrama abaixo mais realstico tecnicamente falando do que o anterior.

Figura A6.14. Viso Geral da Arquitetura do jCompany FS Framework - Aprimorada.

#1. Nas parcelas de requisitos de Casos de Uso centrados em dados, tanto o jCompany FS
Framework quanto a complementao Bridge praticamente isolam a aplicao das camadas
de baixo, atuando como camadas (Layers). importante notar as setas tracejadas de
dependncia, indicando que estas "camadas" comunicam entre si para oferecer um resultado
MVC completamente generalizado.
#2. Em requisitos que fogem ou suplementam os suportados pelos padres, o acesso pode ser
direto camada de frameworks de base. Deste modo, a arquitetura no restringe; possibilita
ao desenvolvedor elaborar quaisquer solues que sejam convenientes, para cada caso.

Em quanto por cento dos casos o jCompany FS Framework e a Bridge funcionaro como camadas? Bom,
isso depende da natureza dos requisitos de cada projeto. Em um estudo de ROI (Retorno sobre o
Investimento) elaborado pela Powerlogic, a torta apresentada na Figura A6.15 tomada como base,
para um projeto corporativo tpico.

Figura A6.15. Segmentao tpica de requisitos de aplicao corporativa.

Assim, em 40% dos casos, em mdia, espera-se que o jCompany FS Framework atue como uma
camada, evitando contato direto de cdigos de negcio com frameworks de base.
Nos demais segmentos de requisitos, o framework ir contribuir provendo servios de IoC, DI, AOP para
gerncia de transaes, leiautes etc.; todos bastante teis, mas que no visam isolamento. Deste
modo mantm-se a liberdade para que o desenvolvedor acesse qualquer recurso de base, quando
necessrio for.
Veja a contribuio esperada (tambm em mdia, claro) para cada fatia de natureza de requisitos,
acima definida, na Figura A6.16.

Figura A6.16. Percentual de contribuio do jCompany FS Framework, por natureza de requisitos.

Quando funciona como camada, o nvel de contribuio do framework do jCompany no estudo foi
impressionante. Mas mesmo considerando-se o percentual de contribuio nas outras fatias,
devidamente ponderados, obtm-se ganhos expressivos!

"Viso de Mdulos - Dependncia entre os projetos gerados

- A arquitetura MVC no jCompany
Veja que, no tpico anterior, a representao de camadas utilizada ortogonal s camadas MVC. Neste
tpico, vamos "virar" em 90 graus o diagrama para analis-lo deste outro ponto de vista.
A arquitetura MVC sugerida pelo jCompany sustenta-se por cinco pilares principais:
1.

Adoo rigorosa da arquitetura MVC-2.

2.

Uso de camada de persistncia, subdivindo a de modelo, atravs do DP DAO (ao que chamamos,
resumidamente, de MVC2-P)

3.

Balanceamento entre melhores prticas Java EE e DDD.

4.

Refinamento do nvel de detalhe arquitetura, para dentro das camadas MVC2-P.

5.

Arquitetura rica, tambm para a camada Viso, com exclusivo IoC Universal, inclusive para esta
camada.

De uma forma um pouco mais detalhada:

1.

Primariamente, o jCompany resa o modelo MVC-2 clssico com separao rigorosa das suas
camadas utilizando o servlet de Front-Controller do JSF ou Struts (FacesServlet ou ActionServlet).
O uso deste DP Front-Controller o que distingue o MVC-2 do MVC-1, j que no segundo caso o
usurio acessa as JSPs diretamente.

2.

Em segundo lugar, o jCompany define uma nova camada para servios de persistncia,
subdiviso da camada Modelo, provendo contratos abstratos (Interface e DP Abstract
Factory), alm de implementaes concretas genricas e alternativas para Hibernate ou
JPA. A camada de Persistncia no uma sub-diviso clssica do MVC, mas como um layer
verdadeiro e muito comum no mercado, iremos enfatiz-lo com a sigla MVC2-P.

3.

Em terceiro lugar, a arquitetura se desenvolve com base em recomendaes da Sun,

assimilando melhores prticas do Core J2EE Patterns [Deepak Alur, John] atualizadas para
Java EE 6, balanceadas ainda com sugestes de Domain Driven-Design - DDD [Evans, Eric.
2004].
O DDD enfatiza uma organizao OO to pura quanto possvel para o modelo de Domnio, o que
concorre eventualmente com organizaes para cdigo distribudo do Java EE. Algumas vezes o Java
EE apresenta padres que apresentam pequenas otimizaes, de mais baixo nvel, mas que no so
to elegantes quanto um modelo rico de Domnio preconizado pelo DDD.
Mas, se por outro lado uma arquitetura que enfatize uma distribuio potencial de componentes,
como o Java EE, pode ser considerada overengineering [Johnson, Eric 2002], por outro pode ser
til em estratgias que pretendam maximizar o reso em runtime usando SOA, por exemplo.
A arquitetura sugerida no jCompany oferece um balano razovel entre estas duas escolas:
na prtica, isto significa que programaes de Domnio podem ser ricas e no anmicas
[Fowler, Martin 2004], refletindo uma linguagem de negcios, mas tambm publicveis ao
menor esforo e de forma eficiente atravs de um Web-Service ou servio EJB3 remoto - se,
quando e onde preciso for.

4.

Em quarto lugar, o jCompany refina a arquitetura para dentro de cada camada MVC2-P,
definindo uma organizao refinada de pacotes e novas categorias de classes internas tais como
Service e Helper, utilizadas com DP Composite [Freeman, Freeman 2004] para maximizar a coeso
e minimizar ainda mais o acoplamento.

5.

Finalmente, o jCompany possui uma arquitetura especialmente diferenciada na camada

Viso, provendo Inverso de Controle (IoC), tambm nesta camada, de modo a finalizar a
abrangncia de generalizao potencial da soluo.

Como vimos, esta uma camada especialmente mal resolvida em arquiteturas tpicas do mercado,
devido sua complexidade e diversidade de tecnologias (JSF, Tag-Files, JSTL, JSP, Tiles/Facelets,
Javascript, CSS, DHTML, Ajax/DOJO etc.). Para fazer frente a este desafio, o jCompany define leiautes
reutilizveis e controlados pelo framework (leiautes dinmicos com Tiles/Facelets), componentes visuais
especializados, solues para reso e especializao de peles, rotinas Javascript/Ajax etc., tudo isso com
DPs e conceitos OO aplicados, como nas demais camadas. Este assunto ser discutido de forma
especfica em captulo sobre customizao de Web-Design.

- Organizando Classes de Domnio

Uma das maiores discusses arquiteturais em MVC , frequentemente, como organizamos o nosso
modelo de Domnio?
O modelo de Domnio composto por aquela parcela de classes que representam entidades claramente
identificadas no negcio, persistentes, em sua maioria, contendo propriedades cujos valores devem ser
mantidos em bancos de dados.
Mas muito embora estas classes componham um ncleo importante das estruturas e regras de negcio,
existiro outras categorias importantes de classes tambm consideradas de negcio para encapsular
orquestraes de servios, clculos e procedimento de apoio.

- Arquitetura MVC-2 clssica do J2EE

Na viso original do J2EE, tais classes de domnio deveriam ser implementadas como Entity Beans e, pela
imposio de no poderem rodar fora de um container EJB (ao contrrio dos POJOs atuais), eram, de
forma obrigatria, localizadas em subcamada interna da camada Modelo.
At o aprimoramento recente do padro da especificao de Entity Beans para o EJB3, portanto, era
recomendado aos desenvolvedores J2EE trabalhar com classes artificiais de DTOs (Data Transfer

Objects), meros containers de informaes, para transportar dados de entidades da camada

Modelo/Persistncia para a camada Controle/Viso, conforme a Figura A6.17.

Figura A6.17. Arquitetura MVC preconizada no J2EE clssico (at EJB 2.1).

#1. Usurio aciona aplicao: No modelo MVC-2, um servlet recepciona todas as requisies do
usurio (e no os componentes de viso tais como JSP ou JSF, como no MVC-1)
#2. Camada controle chama servios de negcio: Um aparato de Design Patterns tais como
Business Delegate, Session Faade e outros so tipicamente utilizados para um maior
isolamento entre a camada da aplicao (Controle e Viso) e a camada de negcio (Modelo), e
tambm devido a uma pressuposio de remoting, ou seja, da potencial distribuio destas
camadas por mquinas distintas, em runtime. Classes remotas so, principalmente EJB Session
Beans 2.x.
#3. Todas as principais camadas compartilham utilitrios. Muito embora no sejam
representados com frequncia, componentes JAR contendo bibliotecas suplementares para
operaes com data, logging, numricas, tratamento de excees etc., so dispostas de forma
a estarem disponvel em todas as camadas.
#4. Uso de Entity Beans 2.x: A persistncia ideal do ponto de vista da especificao obtida
atravs de classes EJB Entity Beans e uso de linguagem EJB-QL.
#5. Uso de Session Beans (DAO): Alternativamente, classes de EJB Session Bean substituem
Entity Beans, devido a limitaes tecnolgicas ou de performance, requerendo codificao de
SQL diretamente nos cdigos Java.
#6. Acesso a servios de persistncia: Seja por responsabilidade do container EJB, no caso dos
Entity Beans ou do desenvolvedor nos DAOs, somente atravs de classes desta camada o
repositrio de armazenamento (Ex.: SGBD-R) acessado.
#7. Criao do meio de transporte: Aps a recuperao de informaes persistidas, seja por
que meio forem, a codificao da cpia dos dados de Entity Beans ou JDBC Result Sets para
DTOs (Data Transfer Objects) obrigatria.
#8. Controle de fluxo de navegao: No modelo MVC-2, as classes de Controle decidem para
que classes de visualizao iro delegar a finalizao da resposta ao usurio. Uma nova verso
de Interface com o Usurio ento selecionada em funo do estado atual da conversao.
#9. Despacho da visualizao: Classes representando tecnologias da camada Viso tais como
JSP, JSTL, Tiles, facelets ou JSF despacham algum formato de visualizao para dispositivos
de cliente, tais como HTML, XML, PDF, CSV, etc.
Perceba que, como a estrutura de dados dos formulrios de negcio composta em sua maior parte por
propriedades das entidades do negcio, a estrutura das classes de DTO terminava por ser 90% a 100%
redundante com a estrutura das classes Entity Bean. Por consequncia, a manuteno desta redundncia
exigia cdigos burros de transferncia de dados (de->para), instanciaes de classes desnecessrias
etc.

Os outros graves problemas desta especificao Entity Bean (at a verso 2.x), tais como srias
restries da linguagem de persistncia EJB-QL, limitao ao uso de herana etc., findavam por
configurar um verdadeiro desastre em termos de produtividade - e Orientao a Objetos.
Na prtica, muitos resolviam este problema simplesmente desistindo dos Entity Beans 2.x (de fato, quase
inutilizveis). Mas quem no os substitua por algum framework de mapeamento Objeto-Relacional tal
como o Hibernate, passava a programar JDBC em EJB Session Beans, como exemplificado em (E), com
manipulao direta de result sets e cpias de/para DTOs (ou VOs), caindo em nveis de produtividade
de tcnicas de programao da gerao COBOL. Na verdade, em nveis piores devido s deficincias
intrusivas da gerao EJB 2.x, como visto.
Felizmente, os Entity Beans 2.x so agora legado, substitudos na verso EJB 3.0 por POJOs (Plain Old
Java Objects) que corrigem, da gua para o vinho, todas as limitaes clssicas.
Uma sequela disso que os Entity Beans 3.0 foram inteiramente reconcebidos a partir do padro Java EE
5 e o ramo 2.x no sofrer mais evolues. Ruim para quem acreditou cegamente neste tipo de padro
forado de comit; bom para o restante do mercado, que j havia trocado o uso de Entity Beans 2.x por
alternativas que agora se tornaram o padro de-facto, como o Hibernate/JPA*.
Padres de facto do mercado Open Source, via de regra, superam os de comit. Somente nos
ltimos anos, os condutores estratgicos do Java EE 5 e Java EE 6, especialmente a SUN, focou
nos anseios dos desenvolvedores e no somente dos fabricantes de Application Server. Esta
tendncia tem levado quase eliminao de padres artificais concebidos sem explorao tcnica.

- Camada de Domnio Ortogonal em Java EE 6

Por tudo isso, em sua verso 3.x os Entity Beans voltam a ser a implementao ideal para Entidades de
Domnio. Os EJBs 2.x no eram recomendados para este fim pelos principais autores e adeptos do DDD,
tais como Martin Fowler e Eric Evans.
Dentre outras vantagens, os EJBs 3.x podem agora dispensar os DTOs na maior parte do tempo, pois so
destacveis e podem ser expostos para todas as camadas do MVC2-P em um esquema conhecido como
atach-detach. Deste modo, servem tanto para persistncia transparente quanto para encapsularem
regras de sua alada e transportarem seus prprios dados.
Com esta evoluo, uma melhor organizao para entidades de Domnio coloc-las em uma nova
camada, ortogonal camada central do MVC [POJOs in Action] [Spring MVC], conforme ilustrado na
Figura A6.18.

O criador da Hibernate, Gavin King, foi um dos lderes da especificao EJB3, especialmente da parte de Entity Beans, que foi
redefinida dentro do padro JPA (Java Persistance Architecture). Por isso, o JPA hoje 90% similar arquiteturalmente ao que j se
usava na Hibernate.

Figura A6.18. Arquitetura MVC com camada ortogonal de Domnio.

#1. Camada comuns engloba utilitrios e DTOs eventuais: As classes utilitrias comuns a
todas as camadas MVC principais, bem como eventuais DTOs que ainda sejam necessrios so
encapsulados na viso Comuns.
#2. Camada de persistncia mais leve, utilizando JPA-QL: A camada de persistncia agora
pode dispensar codificao de incluses, alteraes, excluses e de tratamentos de
concorrncia, gerao de identificadores automticos, dentre outros trabalhos realizados de
forma transparente pelo JPA. Alm disso, a linguagem JPA-QL retorna grafos de entidades de
domnio prontamente disponveis para uso pelas demais camadas de forma OO, e no mais
result sets JDBC, relacionais.
#3. Camada ortogonal para Entidades de Domnio: A camada de domnio agora representa
um objeto clssico de OO, com propriedades e responsabilidades (mtodos) do negcio, alm
de poderem ser utilizadas em qualquer camada MVC2-P. importante notar que agora as
nobres classes desta camada so as mais estveis da arquitetura, no dependendo de servios
de nenhuma outra, nem de persistncia, por exemplo (a camada de Persistncia recupera
dados e disponibiliza para a de Domnio).
Na camada simplificada como Comuns (1) esto includas classes de utilitrios comuns de base OSS
(Apache Commons, Apache Log4j etc.), do jCompany (classes sufixadas com Helper ou Util), os DTOs
restantes e, ainda, os contratos (as Interfaces, somente) de fachada, entre as camadas.
A Figura A6.19 mostra uma radiografia um pouco mais detalhada da Arquitetura de Software MVC2-P*
proposta para Java EE 6 pelo jCompany, exibindo tambm algumas dependncias especificas de cada
camada, ao centro (Mat. Prima OSS, Service, Helper):

Neste livro, utilizaremos MVC2-P quando quisermos enfatizar uma arquitetura MVC do tipo 2, com subcamada de Persistncia bem
definida.

Figura A6.19. Arquitetura MVC2-P com dependncias ortogonais globais e internas das camadas.

#1. DP Faade: Apesar de representarmos, didaticamente, uma seta com dependncia entre
Controle e Modelo (do Controle para a subcamada de implementao de Fachada), o DP Faade
utilizado nesta interao, de modo que h um acomplamento leve, facilitando
reimplementaes de servios, se/quando necessrio.
#2. Transporte DTO e Context: Quando um Caso de Uso apresenta formulrio com estrutura
bastante distinta das Entidades, pode-se lanar como recurso de transporte os tradicionais
DTOs (Data Transfer Objects), como exceo, no mais como regra! Alm disso, um POJO com
DP Context Object utilizado pelo jCompany para transportar, genericamente, informaes de
contexto da camada Controle para Modelo, que podem ser teis (perfil do usurio autenticado,
metadados de colaborao etc.).
#3. Utilitrios Globais: Classes do jCompany com sufixo Helper trazem funes diversas,
complementares a funes de utilitrios de mercado, de interesse de todas as camadas.
#4. Matria-Prima OSS Global: Representam dependncias externas (JAR) de utilitrios,
tambm comuns a todas as camadas MVC2-P, tais como Log4j, Commons, CGLib (AOP) etc.
#5. Servios e utilitrios Especficos: Dentro de cada grande camada MVC2-P, h subdivises
de pacotes segmentando e encapsulando servios e utilitrios internos do jCompany,
especficos para a camada.
#6. Matria-Prima OSS Especfica: Cada camada MVC2-P possui um conjunto agrupado de
dependncias externas de interesse seu apenas (definido tanto no Maven quanto em User
Libraries do Eclipse). Este agrupamento simplifica a gesto de dependncias, evitando falhas
bsicas de arquitetura produzida por desenvolvedores. Ex.: Importaes de servios de
persistncia na camada Controle.
importante observarmos algumas dependncias acima indicadas:
o

H uma dependncia ortogonal, por parte de todas as camadas MVC2-P, com a camada de
Domnio, alm de utilitrios comuns, resqucios de DTO e contratos de fachada (somente as
Interfaces).

A camada de Domnio, por sua vez, desconhece e independe de quaisquer das camadas MVC2-P.
Ela se torna assim, como de se esperar, a parte mais estvel da arquitetura, funcionando
com um layer ortogonal. O conceito da ortogonalidade pode ser melhor visualizado pelo
rearranjo didtico da Figura A6.20.

Figura A6.20. Rearranjo para visualizao mais didtica da camada Ortogonal - layer.

Algumas outras observaes importantes:

o

O M do MVC2-P, a camada Modelo, agora decomposta em Implementaes de Contratos de

Fachada e Servios de Negcio. No detm mais os direitos exclusivos de acesso s
Entidade de Domnio, que por sua vez tambm encapsulam regras de negcio de sua
responsabilidade e no somente dados.

Em uma eventual disponibilizao de forma distribuda, os mdulos que compem as camadas

ortogonais so embalados em ambos os executveis: o da aplicao e o do servio. Ou seja,
em lugar dos DTOs artificiais (somente alguns contratos especiais permanecem), so
as prprias Entidades que agora servem de transporte entre as aplicaes
distribudas.

Entidades no podem acessar DAOs (Data Access Objects) para obter dados. Elas devem
receber dados recuperados por classes de servio da camada Modelo (Manager/Business
Objects-BO ou Application Services-AS) para realizar seus processamentos, tipicamente
regras de negcio.

Os termos entre parnteses sugerem sufixos padres para classes em cada camada, mas podem
ser customizados em nvel corporativo atravs de configuraes nos metadados do jCompany.
Assim, classes de servio da camada Modelo podem ter sufixo padro BO, Manager, Mgr ou
Service, conforme desejado.

- Organizao de Projetos de Desenvolvimento

Os trs projetos Eclipse gerados no captulo anterior suportam a arquitetura MVC2-P, no ambiente de
desenvolvimento, da seguite forma:

Figura A6.21. Projetos de desenvolvimento x arquitetura de camadas MVC-P.

#1. Projeto Eclipse rhtutorial: Engloba a chamada de camada da Aplicao [Richardson,

Chris 2006], ou seja, as camadas Viso e Controle (Controlador) do MVC. Naturalmente,
artefatos de viso so segmentados dos de controle em pacotes distintos.
#2. Projeto Eclipse rhtutorial_modelo: Engloba a camada de Modelo, incluindo a
subsegmentao de persistncia em pacote distinto. Tambm neste caso, pacotes distintos
segmentam servios de negcio e de persistncia.
#3. Projeto Eclipse rhtutorial_comuns: Engloba a camada de utilitrios e outras classes de
interesse comum das demais camadas e tambm a camada de Domnio, segmentada em
pacote especfico.
Obs.: Um quarto projeto pode ter sido gerado apenas para facilidade de gerao de arquivos EAR via
Maven.
Na organizao da Figura A6.21, importante notar que no h uma relao um para um entre uma
camada da arquitetura e um projeto de desenvolvimento na IDE, j que a proliferao de projetos de
desenvolvimento tambm prejudicial, aumentando a complexidade muitas vezes sem
vantagens prticas.
Por outro lado, agrupar todas as camadas em um nico projeto costuma tambm ser uma
simplificao exagerada na medida em que facilita a quebra de arquitetura MVC*.
O jCompany sugere um agrupamento considerado bom para a mdia dos projetos corporativos, em seus
templates INI, mas deve-se realizar ajustes, customizando-se estes templates para algumas situaes.
Alguns bons exemplos so:
o

Caso a aplicao pretendesse renderizar objetos para mais de uma tecnologia de Viso (Ex.:
HTML e tambm XML/XSLT ou WML), ento seria uma boa escolha separar os pacotes de Viso,
presentes no projeto rhtutorial, em outro projeto independente. Deste modo, poder-se-ia ter
dois projetos para esta camada Viso bem desacoplados.

O mesmo raciocnio valeria, caso a pretenso fosse utilizar duas implementaes de persistncia.
Se fosse o caso, compensaria fatorar o(s) pacote(s) de persistencia do rhtutorial_modelo para
um projeto prprio de persistncia.

Isso porque facilita aos desenvolvedores eventualmente instanciarem dependncias de outras camadas, disponveis globalmente em
um nico Class Path.

Note que, desde que classes de uma camada MVC2-P estejam segmentadas, pelo menos, por pacotes com baixo acomplamento,
reorganizar os projetos no seria uma tarefa complexa. E como veremos, esta uma preocupao do jCompany, que descreveremos
na Viso Interna da arquitetura proposta.

Figura A6.22. Principais pacotes que segmentam internamente as camadas, dentro de projetos.

Devido organizao acima representada, chega-se ao seguinte esquema de dependncia entre os

projetos gerados (gerada desta forma pelo jCompany, automaticamente, tanto no Eclipse quanto no
Maven):

Figura A6.23. Diagrama de dependncia de mdulos em linguagem UML.

Nos exemplos em Figura A6.24, Figura A6.25 e Figura A6.26, vemos os arquivos Maven e configuraes
no Eclipse envolvidos. Os mdulos Maven (Projetos que sero alterados e construdos pelo
desenvolvedor) so definidos no arquivo "projeto-pom.xml" e as dependncias Maven nos arquivos
"pom.xml" de cada projeto. A sincronia entre esta definio e o Build Path do Ecilpse automaticamente
realizada pelo plugin M2Eclipse. Notar que este plugin importa "modulos Maven" como "Projetos Eclipse"
e, como veremos mais adiante, outras dependncias (JAR) como Libraries Externas, como deve ser feito:

Figura A6.24. Projeto "principal": Mdulos expressos no "projeto-pom.xml"

Figura A6.25. Projeto "principal": Dependncias de mdulos expressas no "pom.xml" e sincronizadas no Eclipse.

Figura A6.26. Projeto "modelo": Dependncias de mdulos expressas no "pom.xml" e sincronizadas no Eclipse.

O projeto "comuns" no possui dependncia dos demais, sendo portanto considerado mais "estvel", do
ponto de vista arquitetural.

- Dependncias com o jCompany

A Figura A6.27 exibe novamente um Diagrama de Componentes da UML para nosso projeto rhtutorial,
desta vez expandido para conter dependncias do jCompany em tempo de desenvolvimento (no
Eclipse).

Figura A6.27. Dependncias entre projetos gerados e jCompany, em tempo de desenvolvimento.

Os projetos do jCompany para camada de Viso, jcompany_visao e jcompany_visao_jsf, no

esto includos como dependncias porque no contm classes necessrias em tempo de
desenvolvimento. Mas caso o desenvolvedor necessitasse especializar algum componente JSF, por
exemplo, ele teria que acrescentar o jcompany_visao_jsf.

- Dependncias com o jCompany em tempo de desenvolvimento

Como implementamos as dependncias da Figura A6.27, no ambiente do Eclipse?
Alm dos mdulos supra-citados, o plugin M2Eclipse sincroniza as dependncias simples, que no so
expressas como "mdulos" nos arquivos "pom.xml" e "projeto-pom.xml", como "External Libraries" no

Eclipse, automaticamente. Deste modo, dispensa o desenvolvedor de configurar de forma redudante

estas dependncias. Ver Figura A6.28.

Figura A6.28. Dependncias automaticamente geradas no Eclipse, a partir do M2Eclipse

#1. Projetos com marca "M", que caracterizam o gerenciamento pelo M2Eclipse.
#2. JARs definidos nos arquivos "pom.xml" e disponveis no repositrio Maven local, agrupados em
"Maven Dependencies".

- Dependncias com o jCompany em tempo de execuo

Em uma viso de dependncia em tempo de execuo, os projetos da camada Viso,
jcompany_visao, jcompany_visao_jsf e jcompany_visao_jsfw2 devem aparecer, pois renem
artefatos "no Java", com contedo em formatos como XHTML (leiautes genricos de formulrio), CSS,
Javascript (Widgets, utilitrios, ...), dentre outros artefatos reutilizados somente em tempo de execuo.
Isto exemplificado na Figura A6.29.

Figura A6.29. Dependncias entre projetos gerados e jCompany em tempo de execuo.

Obs. 1: Para dependncias somente em tempo de execuo, necessrio o devido registro das
dependncias nos arquivos pom.xml do Maven, mas no necessariamente no Eclipse! O M2Eclipse j
cuida deste tipo de configurao automaticamente.
Obs. 2: Os projetos da camada viso do jCompany so disponibilizados como WAR para o Maven, que
os expande e mescla com o WAR da aplicao (ou EAR) em tempo de montagem para funcionamento em

execuo. Este formato modelado como "PSEUDO-WAR" para distingui-lo de um "WAR" final,
executvel.

- Dependncias com a camada de reso Open Source (OSS)

Alm da dependncia entre os projetos Eclipse e o jCompany, precisaremos analisar e implementar
ainda as dependncias de todos estes projetos com os frameworks de base e bibliotecas de utilitrios
homologados no soluo, aos quais chamamos de Matria-Prima Open Source.
A Figura A6.30 exibe o Modelo de Componentes final para nossa aplicao exemplo, sem incluir
sofisticaes tais como mdulos reutilizveis do negcio e camada Bridge corporativa, que no sero
discutidos neste livro por falta de espao.

Figura A6.30. Modelo de Componentes completo (em nvel macro) para o projeto RH que ser desenvolvido.

As dependncias das camadas de reso Open-Source tambm so importadas como "External Libraries"
no Eclipse pelo M2Eclipse, no havendo distino com relao aos JARs do jCompany, por exemplo.

Figura A6.31. Libraries contendo jCompany e componentes reutilizados (em destaque), gerados pelo M2Eclipse.

Viso Interna - Estrutura e artefatos dos projetos gerados

- Introduo
Nesta viso, vamos entender como os trs projetos gerados no captulo anterior esto organizados do
ponto de vista de sua estrutura interna. Esta viso engloba a organizao de diretrios e de artefatos
sugeridos pela arquitetura.
A organizao inicial de diretrios adotada pelo jCompany segue convenes recomendadas pela
ferramenta Apache Maven, resultado de anos de prtica em organizao de projetos colaborativos e
mundiais do grupo Apache. A organizao opinativa do Maven, como gostam de frisar os seus autores,

 mais rigorosa, porm permite a esta ferramenta compreender mais a fundo o projeto (onde esto suas
classes de teste, artefatos de configurao da aplicao etc.) e, por consequncia, contribuir mais.
Seguir o padro de pacotes do Maven nos ajudar na atualizao de verses, gerao de
rotinas de montagem, compilao e liberao de executveis. Alm disso, plugins Maven podero
gerar mtricas interessantes e um Web-Site em nvel bem adiantado de acabamento para nossos
projetos, uma vez que utilizemos a sua arquitetura sugerida.
A postura opinativa do Maven similar adotada pela Powerlogic no jCompany. O Maven
aprofunda as exigncias arquiteturais e ir cobrar um maior investimento inicial quando
comparado, por exemplo, ao Apache Ant, mas trar mais retorno, no mdio prazo.

- Aprendendo mais sobre o Apache Maven

No iremos redundar neste livro toda a explicao de base disponvel nos manuais do Maven 2, sobre
as vantagens da estrutura de pacotes sugerida adotada pelo jCompany. Para isso, sugerimos estudo dos
tutoriais do produto em www.maven.apache.org/guides ou dos diversos artigos disponveis na Web,
facilmente desvendveis atravs de consulta maven 2 articles no Google.
Em nossa pauta, iremos discutir os refinamentos realizados pelo jCompany sobre essa estrutura padro
de forma detalhada.

- O projeto principal (Controle e Viso)

O projeto principal contm basicamente pacotes para programaes da camada Controle do
MVC, bem como arquivos de configurao e artefatos de camada Viso. a seguinte a sua organizao
interna padro, conforme definida no template INI (e, portanto, utilizada para novos projetos):

Figura A6.32. Organizao interna do projeto principal rhtutorial.

Organizao Interna do Projeto Principal (Ex.: rhtutorial)

Pacote Padro
(Diretrizes Maven)

Objetivo

1. src/main/java
(Source Folder)

Contm arquivos com cdigo-fonte em linguagem Java para

classes da camada Controle da arquitetura MVC, organizados
com o seguinte padro:
[br.]com.[empresa].[projeto].controle.[jsf|listener|tiles]
onde
[br.] um prefixo opcional, uma vez que o restante do pacote
costuma ser suficiente para evitar colises de nomes.
[empresa] nome da organizao
[projeto] nome do projeto
[jsf|listener|tiles] so originalmente subdivididas com base em

dependncias de tecnologias tpicas da camada controle :

o

jsf: Pacote que contm classes com dependncia de tecnologia JSF

listener: Pacote que contm classes dependncia da tecnologia de

Servlet, especificamente conhecidas como listeners.

tiles: Pacote que contm classes com dependncia de tecnologia

Tiles.

Alm disso, o pacote raiz pode conter classes alternativas de

servio da camada controle, que no sejam acopladas
especialmente a nenhuma das tecnologias acima.
2. src/test/java
(Source Folder)

Contm arquivos com cdigo-fonte em linguagem Java para

classes de Teste da aplicao, incluindo testes de unidade para
camada Controle da arquitetura MVC (classes locais do projeto),
e testes funcionais da aplicao em geral.
A estrutura interna possui um pacote espelho ao pacote
principal, de modo que uma determinada classe de teste
compartilhe visibilidade de mesmo package da classe testada.
Obs.: Tcnicas de Teste de Unidade e Funcional (esta ltima
utilizando o produto jCompany QA), bem como a organizao de
diretrios detalhada, sero discutidos em captulo dedicado.

3. src/test/resources
(Pseudo Source-Folder)
Configurado como Source
folder no Eclipse para melhorar
visualizao no Package
Explorer, muito embora no
contenha classes Java.

Contm arquivos de recursos utilizados em Testes Funcionais,

Estticos e de Carga/Stress.

4. src/main/config
(Source Folder)

Contm arquivos com anotaes Java que representam

metadados do jCompany para a aplicao, especificos para a
camada Controle da arquitetura MVC, organizados com o
seguinte padro:

Obs.: Estes arquivos tambm sero compreendidos em captulo

especficos sobre automao de testes em geral.

com.powerlogic.jcompany.config.[emp|appl*URLs*]
onde
[emp] contm arquivo package-info.java, que possui anotaes
em nvel da organizao e, portanto, gerais para todos os
projetos. Normalmente, em instalaes corporativas, deve ser
utilizado somente em projetos da camada Bridge e,
eventualmente, utilizados somente para sobreposies de
anotaes especficas.
[app] contm arquivo package-info.java, que possui anotaes
em nvel da aplicao e, portanto, gerais para o projeto corrente.
[*URLs*] subdiretrios que sero criados pelos plugins do
jCompany na medida em que URLs que representem
colaboraes padres sejam geradas. Cada diretrio tem uma
correspondncia um para um com uma URL que siga um padro
do jCompany, e conter um arquivo package-info.java com
metadados. Exemplo:
o

com.powerlogic. jcompany.config.funcionarioman\
package-info.java: anotaes para URL /funcionarioman
com.powerlogic. jcompany.config.funcionariosel\
package-info.java: anotaes para URL /funcionariosel

Obs.: Um maior entendimento sobre metadados do jCompany

ser obtido no desenrolar dos tutoriais, nos prximos captulos.
5. src/main/resources
(Pseudo Source-Folder)
Configurado como Source
folder no Eclipse para melhorar
visualizao no Package

Segundo o padro Maven, este diretrio deve conter arquivos de

configurao que sero disponibilizados no Class Path de
executveis. Na prtica, copiados para o diretrio /WEBINF/classes, em tempo de montagem do arquivo WAR.

A organizao baseada em dependncias de tecnologias visa aumentar a estabilidade de cada pacote, mantendo-os com o mnimo
possvel de acoplamentos (imports). So possveis subdivises em pacotes funcionais abaixo do pacote de tecnologia (ex: por Casos
de Uso), ou mesmo alterao desta nfase, colocando-se pacotes funcionais antecedendo os pacotes de tecnologia, se desejado.

Explorer, muito embora no

contenha classes Java.
6. src/main/webapp
(Pseudo Source-Folder)
Configurado como Source
folder no Eclipse para melhorar
visualizao no Package
Explorer, muito embora no
contenha classes Java.

7. (raiz) arquivos POM

Contm arquivos Java EE no Java, tpicos da camada Controle

e Viso da arquitetura MVC, podendo ter os seguintes formatos:
o

Arquivos XML de configurao diversos, tanto para atendimento

especificao Servlet, quando JSF ou Struts e Tiles.

Arquivos PROPERTIES (texto contendo valores no formato

chave=valor) de configurao de mensagens e rtulos da
aplicao, para internacionalizao (I18n), quanto para
configuraes do log4j e jBoss Seam.

Arquivos JSP que representam fragmentos de interfaces com o

usurio, principalmente de formulrios, utilizados na leiautes Tiles.

Arquivos JAVASCRIPT que representam lgicas Javascript/Ajax,

para execuo local nas mquinas dos clientes.

Arquivos CSS que representam as peles, que do aparncia (cor,

fontes, etc.) aplicao.

Arquivos de mdia (.GIF, .JPG, .PNG, etc.), utilizados para

decorao geral da aplicao.

Na raiz do projeto se encontram dois arquivos de configurao

Maven fundamentais para a compilao e construo de arquivos
WAR, JAR ou EAR:
o

pom.xml: arquivo de configurao de mdulo, existente para cada

projeto Eclipse, e contendo as dependncias de compilao direta
do mdulo.

projeto-pom.xml: arquivo de configurao de projeto, existente

para cada projeto principal no Eclipse, mas no para cada mdulo.
Contm os mdulos que compem e so montados em um projeto.

O pseudo source-folder webapp merece um maior detalhamento, j que contm diversos diretrios
padro Java EE e arquivos de configurao padres:

Figura A6.33. Organizao do folder webapp do projeto principal rhtutorial.

Organizao Interna do Folder webapp (Ex.: rhtutorial/src/main/webapp)

Pacote Padro
(Diretrizes Java EE)

Objetivo

1. /plc/midia*

um folder padro do jCompany para conter os seguintes arquivos:

o

Arquivos de mdia (.gif,.jpg,.png) que no variam em funo da pele

escolhida (arquivos de mdia variantes devem ficar nos diretrios CSS,
tais como /plc/css/[pele])
Exemplos: logo e rodaps da empresa e imagens de destaque
Nota 1: O jCompany traz algumas imagens utilizadas na pgina de
login (login-logo-empresa.png). Todas devem ser modificadas (ou
simplesmente sobrepostas).
Nota 2: O logo da empresa, para login, topo e janela sobre, pode ser

mantida na camada Bridge para no ficar rendundado em cada

projeto, em uma arquitetura mais corporativa.
2. /plc/css

um folder padro do jCompany (todos os prefixos e sufixos plc

indicam origem no jCompany) para conter os seguintes arquivos:
o

app.geral.css: Arquivo de CSS de arquitetura vazio, especfico da

Aplicao, devendo ser utilizado para sobreposies de estilos (lookand-feel) corporativos, preferencialmente definidos em arquivos CSS
em nvel da empresa (Bridge).
Pode conter tambm arquivos de mdia (.gif,.jpg,.png) que iro variar
em funo da pele escolhida (arquivos de mdia invariantes devem
ficar em /plc/midia)
Nota: Aqui pressupomos que o desenvolvedor ir implementar
diversos projetos para uma empresa, reutilizando a mesma pele
(CSS) e layout (Facelets). Assim, definir estes arquivos inteiramente
em cada aplicao seria redundncia indesejvel

3. /META-INF

um folder padro Java, que deve constar exatamente com este

nome e em maisculas. Contm os seguintes arquivos:
o

4. /WEB-INF/fcls

MANIFEST.MF: arquivo de configurao padro Java para possveis

declaraes com relao a um mdulo executvel (WAR, EAR ou JAR).
No utilizado pelo jCompany, mas includo somente para
conformidade com padro.

um folder padro MVC, sugerido para conter pginas Facelets da

aplicao que no devem ser acessadas diretamente (fragmentos
incompletos de Facelets, utilizados nos leiautes).
Ser principalmente utilizado para conter pginas de formulrios do
negcio, mas o template INI traz algumas sugestes:

5. /WEB-INF/

geralAcoesComplemento.xhtml: Pgina vazia de arquitetura,

disponvel para conter eventual novos botes de ao que aparecem
ao lado dos botes padres do jCompany

geralRodapeComplemento.xhtml: Pgina vazia de arquitetura,

disponvel para conter eventual complementos barra de rodap
aparecendo ao lado das opes genericamente disponveis no
jCompany.

geralMenu.xhtml: Arquivo XHML que define a estrutura de menu

especfica da aplicao de modo neutro e que portanto pode ser
renderizado de diversas formas (muitas j automatizadas pelo
jCompany)

um folder padro Java EE, que deve constar exatamente com este
nome e em maisculas, e deve conter, em sua raiz, arquivos de
configurao diversos.
O template INI padro traz os seguintes arquivos pr-configurados:

components.xml: Arquivo XML de configurao do jBoss Seam, que

pode ser utilizado para configuraes externas de componentes e
ativao de opes diversas (logging, etc.).

faces-config.xml: Arquivo XML de configurao do Java Server Faces,

que contm regras de navegao (inter-URLs) e outras configuraes
de controle.

jboss-web.xml: Arquivo XML de configurao da aplicao para

liberao em Application Server JBoss.

plcf.tld: Arquivo XML de configurao de Tag-Libs JSF, mantidas de

forma redundada nos projetos devido a limitao dos plugins Red Hat
Studio, que no oferecem completion (control+space para ver
opes, em JSPs) para estas Tag-Libs, caso no existam no projeto
corrente. (O arquivo oficial fica no projeto jcompany_visao_jsf)

web.xml: Arquivo XML de configurao padro Java EE, que define

diversos parmetros globais para a aplicao, de suma importncia.

importante perceber que o agrupamento de todos estes recursos abaixo da pasta plc proposital e excepcionalmente importante
para a performance das aplicaes, j que todos estes so recursos passiveis de serem mantidos em caching, no cliente (nos
Navegadores). Para acionar este excepcional recurso de performance, o jCompany j traz pr-configurado o filtro PlcClienteFilter no
web.xml, mapeado para todos os arquivos abaixo de /plc. Este mais outro motivo para reforar o uso desta conveno, e agrupar
recursos desta mesma natureza, abaixo deste diretrio.

Este arquivo ser melhor discutido em tpico parte.

6. (raiz)

Contm a pgina Facelets configurada no web.xml com inicial da

aplicao, para a qual o usurio redirecionado aps chamar a
aplicao sem explicitar uma URL interna especfica (Ex.:
http://localhost/rhtutorial).

As classes Java definidas no projeto template padro tm o seguinte propsito:

Classes Java da Arquitetura pr-definidas no projeto principal
Classe

Objetivo

1. /jsf/AppAction

Classe de arquitetura vazia para conter possveis

programaes genricas de controle, para toda
a aplicao.

2. /jsf/AppPhaseListener

Classe de arquitetura vazia para conter possveis

programaes ativadas em eventos JSF
diversos. Apesar do sufixo Listener, no um
Listener padro Servlet 2.5.

3. /listener/AppHttpSessionListener

Classe de arquitetura vazia para conter possveis

programaes ativadas no momento da criao
e/ou remoo de sesses HTTP no servidor
(importante notar que uma sesso criada ao
primeiro contato de um novo usurio, e no
aps a sua autenticao).

4. /listener/AppServletContextListener

Classe de arquitetura vazia para conter possveis

programaes ativadas no momento da
inicializao e/ou finalizao da aplicao pelo
Application Server.

5. /tiles/AppMenuItemController

Classe de arquitetura vazia para conter possveis

programaes que permitam manipulaes
dinmicas de itens de menu Tiles definidos no
app-tiles-menu.xml.

6. /AppUsuarioPerfilService

Classe de arquitetura vazia para conter possveis

programaes ativadas no momento aps
autenticao de usurios, conhecidas como
lgicas de user profiling (Ex.: registros
especiais de segurana em caching de sesso,
recuperao de dados de usurios utilizados na
aplicao tais como email, nome completo etc.)

Pela descrio que vimos at aqui, j devemos ter percebido que as classes includas nos projetos
gerados no contm cdigo procedimental em Java. Os poucos artefatos com contedo gerados so
alguns arquivos de JSP e mdias de exemplo para permitirem uma apresentao inicial de Web-Design
para a aplicao, a ser modificada para o contexto de cada empresa/aplicao.
Os verdadeiros propsitos do plugin de criao de projetos, e de outros que compem o jCompany
Artifact Generator, so reforar:
o

Gerncia de Configurao: Pr-configurao da grande diversidade de frameworks, tecnologia

Java EE e bibliotecas utilizados, em uma linha de base ntegra e homologada no jCompany.

Padres de Arquitetura: Pr-definio de locais apropriados para implementaes especficas

(CSS, Javascript, botes de ao complementares, rodap etc.), o que faz parte do trabalho de
definio de uma arquitetura extensvel. No fosse assim, ficar-se-ia ao sabor de preferncias
momentneas do implementador, o que dificultaria sobremaneira as manutenes e economia
de escala.

As classes Java presentes nos templates INI, portanto, esto vazias, visando apenas promover o uso de
padres de programao da arquitetura.
Nota: Alm disso, estas classes no so instanciadas pelo desenvolvedor, mas por algum esquema de
Inverso de Controle (IoC). O jCompany faz IoC atravs do padro CDI (jCompany 6.x) ou via jBoss
Seam complementado por tcnicas prprias (em verses 5.5.x ou inferiores). Alm disso, reutiliza IoC
clssico para APIs como Listener e Filter, utilizando o web.xml para declarar estas implementaes (at
que o uso de conteiners no padro Java EE 6 se popularizem, de modo a possibilitar o uso de anotaes).
Os diversos mecanismos de IoC utilizados ou implementados pelo jCompany sero discutidos em
detalhe nos captulos de programao de regras de negcio, no mdulo E.

- O projeto modelo (Servios de Negcio e Persistncia)

O projeto modelo contm pacotes para programaes da camada Modelo do MVC2-P,
incluindo segmentao por pacotes de classes de implementaes de Fachada (DP Faade) e de classes
da camada de Persistncia (assim como o projeto principal rhtutorial segmenta internamente as
camadas de Controle e Viso).
Do ponto de vista da Viso Interna, a seguinte a organizao padro do projeto rhtutorial_modelo,
conforme definida no template INI:

Figura A6.34. Organizao interna do projeto modelo rhtutorial_modelo.

Organizao Interna do Projeto Modelo (Ex.: rhtutorial_modelo)

Pacote Padro

Objetivo

1. src/main/java
(Source Folder)

Contm arquivos com cdigo-fonte em linguagem Java para classes

da camada Modelo da arquitetura MVC, organizados com o
seguinte padro:
[br.]com.[empresa].[projeto].modelo.[facade|modelo|persistencia]
onde
[br.] um prefixo opcional, uma vez que o restante do pacote
costuma ser suficiente para evitar colises de nomes.
[empresa] nome da organizao
[projeto] nome do projeto
[facade|modelo|persistencia] so originalmente subdivididos com
base em subcamadas dentro do projeto:

2. src/main/config
(Source Folder)

facade: Pacote que encapsula classes de Implementao dos

Contratos de Fachada (DP Faade). As interfaces ficam no projeto
comuns.

modelo: Pacote que encapsula classes de servio (Casos de Uso) da

aplicao.

persistencia: Pacote que contm classes que acessam repositrios de

dados, tipicamente SGBD-Rs. Subdivide-se, em conformidade com a
tecnologia de implementao, em hibernate ou jpa.

Contm arquivos com anotaes Java que representam metadados

do jCompany para a aplicao, especificas para a camada Modelo
da arquitetura MVC, organizados com o seguinte padro:
com.powerlogic. jcompany.config.[modelo|persistencia].[app|xxx]
onde
[modelo|persistencia] segmenta metadados de camada uma das
respectivas camadas:
o

modelo: contm arquivo package-info.java, com anotaes de

configurao para a camada modelo.

persistencia: contm arquivo package-info.java, reunindo anotaes

de configurao para a camada persistncia.

[app|xxx] uma sigla de trs letras (app padro), que define um

mdulo, deste modo diferenciando anotaes da camada modelo

para o mdulo principal (app) e outros possveis (pes para mdulo
Pessoa etc.).
3. src/main/resources
(Pseudo Source Folder)
Configurado como Source
folder no Eclipse para
melhorar visualizao no
Package Explorer, muito
embora no contenha
classes Java.

Contm diretrio padro META-INF para JARs, neste caso com

configuraes (opcionais) para EJBs.

4. src/test/java
(Source Folder)

Contm arquivos com cdigo-fonte em linguagem Java para classes

de Teste do mdulo, incluindo testes de unidade para camada
Modelo da arquitetura MVC (classes locais do projeto).
A estrutura interna possui um pacote espelho ao pacote principal
do mdulo, de modo que uma determinada classe de teste
compartilhe de visibilidade de mesmo package da classe testada.

5. (raiz) pom.xml

Na raiz do mdulo se encontra o arquivo Maven de configurao para

compilao e construo do arquivo JAR correspondente:
pom.xml: arquivo de configurao de mdulo, existente para cada
projeto Eclipse, e contendo as dependncias de compilao direta do
mdulo.

As classes Java definidas no template INI para projetos modelo tm o seguinte propsito:
Classes Java da Arquitetura pr-definidas no projeto modelo
Classe

Objetivo

1. /facade/AppFacadeImpl

Classe de arquitetura vazia para conter possveis

especializaes de implementao ao contrato de
Manuteno de Ciclo de Vida e Manipulao de
Agregaes, mantido pelo jCompany.

2. /modelo/AppManager

Classe de arquitetura vazia para conter possveis

programaes genricas para todos os servios de
modelo (Business Object ou Application Services). mais
raramente utilizada.

- O projeto comuns (Entidades e Contratos)

O projeto comuns contm pacotes para programaes das Entidades de Domnio e
Interfaces de Fachada (DP Faade), que definem contratos entre aplicaes (Controle) e servios
(Modelo). Alm disso, pode conter classes de utilitrios comuns que sejam necessrias em todas as
camadas MVC-P, deste modo evitando-se redund-las.
Na Viso de Mdulos veremos que as Entidades devem ser expostas a todas as camadas MVC-P mas
no podem depender de nenhuma delas. Deste modo, passam a configurar uma camada ortogonal e se
tornam a parte mais estvel da arquitetura.
Por hora, vamos nos concentrar no entendimento da arquitetura interna deste projeto, conforme definido
no template INI:

Figura A6.35 Organizao interna do projeto modelo rhtutorial_comuns.

Organizao Interna do Projeto Comuns (Ex.: rhtutorial_comuns)

Pacote Padro

Objetivo

1. src/main/java
(Source Folder)

Contm arquivos com cdigo-fonte em linguagem Java para classes da

camada Domnio e Contratos, ortogonal a todas as camadas da
arquitetura MVC e que contm artefatos comuns a todas elas. Os
arquivos so organizados com o seguinte padro:
[br.]com.[empresa].[projeto].[entidade|facade|comuns]
onde
[br.] um prefixo opcional, uma vez que o restante do pacote costuma
ser suficiente para evitar colises de nomes.
[empresa] nome da organizao
[projeto] nome do projeto
[entidade|facade|comuns] segmentas os seguintes tipos de classes:
o

entidade: Pacote que encapsula classes que representam conceitos de

negcio, chamadas Entidades de Domnio

facade: Pacote que encapsula interfaces que definem o contrato de

fachada (DP Faade). As classes de implementao ficam no projeto
Modelo.

comuns: Pacote que pode encapsular classes utilitrias de uso comum em

todas as camadas MVC-P, para a aplicao (utilitrios de interesse interaplicaes devem ser disponibilizados em mdulo parte).

2. src/main/resources
(Pseudo Source Folder)
Configurado como
Source folder no Eclipse
para melhorar
visualizao no Package
Explorer, muito embora
no contenha classes
Java.

Contm diretrio padro META-INF para JARs, neste caso com

configuraes de persistncia JPA (persistence.xml), e tambm o
arquivo hibernate.cfg.xml.

3. src/test/java
(Source Folder)

Contm arquivos com cdigo-fonte em linguagem Java para classes de

Teste do mdulo, consistindo de testes de unidade para camada
Entidades, Contratos e Utilitrios Comuns da arquitetura MVC (classes
presentes locais do projeto).

Estas declaraes de persistncia so idealmente mantidas no mesmo

projeto das Entidades, para maior coeso, e no implicam em
dependncias ou acoplamentos por serem apenas configuraes
(metadados).

A estrutura interna possui um pacote espelho ao pacote principal do

mdulo, de modo que uma determinada classe de teste compartilhe de
visibilidade de mesmo package da classe testada.
4. (raiz) pom.xml

Na raiz do mdulo se encontra o arquivo Maven de configurao para

compilao e construo do arquivo JAR correspondente:
o

pom.xml: arquivo de configurao de mdulo, existente para cada projeto

Eclipse, e contendo as dependncias de compilao direta do mdulo.

As classes Java definidas no projeto template default para comuns tm o seguinte propsito:
Classes Java da Arquitetura pr-definidas no projeto comuns
Classe

Objetivo

1. /comuns/AppBaseContextVO

Classe de arquitetura vazia para conter possveis

especializaes de valores de contexto da
aplicao que precisem ser transportados para a
camada Modelo (DP Context).

2. /comuns/AppConstantesComuns

Classe de arquitetura vazia para conter possveis

constantes que tenham escopo comum em
vrias camadas MVC.

3. /comuns/AppException

Classe de arquitetura vazia para conter possveis

especializaes de PlcException, que a exceo
mestra que encapsula (wrapper), excees
especficas do negcio ou inesperadas.

4. /comuns/AppUsuarioPerfilVO

Classe de arquitetura vazia para conter possveis

atributos acerca do perfil do usurio corrente
(dados mantido em sesso pelo jCompany),
deste modo encapsulando dados relacionados ao
usurio (criado atravs do servio

AppUsuarioPerfilService).
Nota: Est no comuns, obviamente, porque
transportada para camada Modelo, nos contratos
padres do jCompany, para que lgicas de
negcio conheam estes dados.
5. /entidade/AppBaseEntity

Classe de arquitetura vazia para conter possveis

anotaes de persistncia comuns a todas as
Entidades no escopo da aplicao. Ela, por sua
vez, herda propriedades comuns de auditoria
pauta mnima (usurio e data/hora da ltima
alterao), e verso (tratamento de concorrncia
otimista), sugeridas pela metodologia.
Entidades devem herdar desta classe, se
desejarem reusar as definies acima.

6. /facade/IAppFacade

Interface de arquitetura vazia para conter

possveis clusulas de especializaes do
contrato de Manuteno do Ciclo de Vida e
Manipulao de Agregaes do jCompany.
Nota: No deve ser utilizada para definio de
contratos de negcio especficos que no tenham
relao com o contrato mantido pelo
jCompany. Para tanto, deve-se criar POJI (Plan
Old Java Interfaces) independentes.
Um aprendizado detalhado sobre elaborao de
contratos Faade do negcio ser obtido em
captulos sobre Programao de Regras de
Negcio no jCompany.

7. /facade/IAppFacadeRemote

Interface de arquitetura vazia que especializa a

interface acima para dot-la de anotaes para
funcionamento remoto (@Remote), quando se
deseja utilizar EJB 3.0 em ambientes
distribudos.
Deste modo, o jCompany conseguir comutar
automaticamente entre uma verso local (com
ou sem EJBs) e remota (com EJBs efetivamente
acionados via RMI/IIOP).

Sumrio
Neste captulo, fizemos uma breve reviso sobre preceitos da Arquitetura de Software e discutimos a
Viso Interna e Viso de Mdulos da arquitetura incorporada e proposta pelo jCompany, tomando
como base os trs projetos gerados no captulo anterior.
Ao expormos os critrios (Rationale) utilizados pela Powerlogic para absoro e concepo da
arquitetura sugerida, provemos as condies necessrias para ajustes especficos e especializaes
corporativas que se faam necessrios.
No prximo captulo iremos sair da Arquitetura de Software para ingressar na Metodologia de Construo
Java EE incorporada no jCompany, comeando por entender seus Casos de Uso Padro e a aplicao
que iremos desenvolver mais em detalhes.
O retorno a este captulo, aps uma maior experimentao prtica no jCompany, altamente
recomendvel.