Entendendo a Arquitetura de Desenvolvimento

4
Capítulo
Entendendo a Arquitetura
de Desenvolvimento
6
A
Introdução
- Reúso de Arquitetura de Software
O
jCompany Developer Suite pode ser compreendido como uma solução de reúso em nível
arquitetural. E não apenas para reúso de camadas de base de arquitetura para as aplicações
desenvolvidas, mas também para o ambiente de desenvolvimento (IDE) e de Testes de Unidade. Estas
soluções arquiteturais de base são providas, respectivamente, pelos módulos jCompany FS
Framework, jCompany IDE e jCompany Test for Developer.
Mas qual seria a diferença deste tipo de reúso em comparação ao reúso mais pontual, digamos, em nível
de uma classe ou pequeno grupo de colaboração de classes?
O reúso arquitetural possibilita reúso de estratégias complexas englobando desde o reúso de
colaborações extensas de frameworks, somada à produção assistida de especializações preconizadas por
métodos e padrões delineados pela arquitetura. Este tipo de reúso é de mais alto nível que os demais.
Digamos, uma integração de várias estratégias de reúso pontuais, que produz um resultado de
valor visível para o cliente (Ex.: um Caso de Uso potencial) e não soluções parciais intermediárias.
Em outras palavras: muito embora sejam importantes as táticas de reúso em nível de classe ou via padrões de
projeto (Design Patterns), o reúso arquitetural é de nível mais estratégico, 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 comparação a se começar selecionando madeira para fabricar portas, por exemplo .
Apesar de não existir uma única solução de arquitetura perfeitamente adequada a todas as situações, as
diversas dimensões de arquitetura pré-implementadas no jCompany são customizáveis...
Para isso vingar na prática, porém, torna -se necessário um entendimento mais profundo das suas
implementações, inclusive das motivações fundamentais (Rationale) que guiaram a Powerlogic em sua
proposta. Este capítulo inicia esta discussão.
Estudo de Evolução de Arquiteturas de Software Java EE
- O que é Arquitetura de Software?
Já discutimos sobre a importância da arquitetura no Capitulo 1, mas não pressupomos que todos tenham
conhecimentos balizados sobre o assunto. Por isso, vamos rever algumas definições fundamentais:
“Uma Arquitetura de Software para um sistema é a que define a estruturação deste sistema, que compreende
seus Elementos, a Relação entre eles e as Propriedades externamente visíveis destes Elementos e Relações.”
Ref . A 6.1. [TS-4619 JavaOne 2006]
“Arquitetura de Software é a decomposição do problema de uma maneira que permita ao desenvolvimento
eficientemente resolvê-lo, considerando restrições (...)”
Ref . A 6.2. [John Klein- “A rchitecture and Design”]
“A arquitetura de qualquer aplicação deve ao menos incluir (quando não se basear em) considerações de
performance. A arquitetura de uma aplicação corporativa deve considerar os Ciclos de Vida de Objetos, assim
como a sua forma de uso”
Ref . A 6.3. [Haines, Steven 2006]
Não há muita controvérsia sobre a importância decisiva que uma boa Arquitetura de Software pode ter
em processo de desenvolvimento de software em geral. Também há um grande reconhecimento, por
Capítulo A4
parte de especialistas, com relação ao papel central que os frameworks assumem nesta questão. Porém,
muitas empresas não chegam a experimentar os re sultados prometidos nesta área.
Para não corrermos este risco e obtermos os melhores resultados, nossa proposta somará o reúso de
uma arquitetura abrangente com padrões de alto nível e automação de atividades, orquestradas p or
Cheat-Sheets do Eclipse.
Nossa arquitetura também será ajustada para a eficiência de processamento, outro ponto comumente
negligenciado. É um erro imaginar a arquitetura apenas do ponto de vista estrutural e t eórico. A
arquitetura influi decisivamente em performance e devem ser considerados os comportamentos dinâmico
e prático da aplicação, além dos fatores usabilidade, flexibilidade e outras dimensões concorrentes, em
nossa problemática.
Não se satisfaça com uma Arquitetura de Software rasa. Mesmo uma arquitetura incipiente poderá produzir um
bocado de documentos e diagramas impressionantes, mas trará resultados medíocres, quando algum. Uma
arquitetura para o perfil típico de projetos corporativos, por exemplo, deve definir, em detalhes, dependências
entre projetos e módulos, pacotes dentro de projetos, artefatos, eventos de programação de alto nível e,
finalmente, trazer um bom número de generalizações e padrões que conduzam a um resultado visível para o
negócio, rapidamente.
Nos próximos tópicos, discutiremos níveis de maturidade de arquiteturas de software.
- Arquitetura de Software “Invisível”
Em nossa experiência não é incomum encontrar empresas desenvolvendo em Java EE em um estágio
onde ainda não há nenhuma arquitetura realmente visível para os implementadores. Neste nível
de maturidade, o que se chama de arquitetura são alguns “documentos”, traçando diretrizes conceituais
para o uso de MVC, este ou aquele framework ou até determinados Design Patterns.
Este cenário primitivo é, claro, melhor que nada. Mas insuficiente para se perceber qualquer ganho
considerável nesta área – um estágio ao qual chamamos de “Arquitetura de Software Invisível”,
ilustrado na Figura A6.1.
Figura A 6.1. A rquitet ura de sof tware “Invisível”.
Neste estágio, as lacunas estão vazias entre a plataforma de infraestrutura Java EE (1) e as aplicações de
negócio (5). Por este motivo, um enorme potencial para erros está à espreita dos desenvolvedores, que
ficam às voltas com programações repetitivas de código, que deveriam estar fatoradas em
nível arquitetural.
Não há como evitar. Para uma arquitetura real, será necessário que os arquitetos passem do domínio dos
conceitos para a “experiência de uso nas tecnologias, suas possíveis combinações, deficiências e valores, além
de prováveis variações de uso”.
Montar uma arquitetura madura demanda um tempo que não pode ser facilmente abreviado –
especialmente uma que envolva altíssimas taxas de reúso, partindo de soluções “best-of-breed” Java EE
Open Source. Nesta filosofia, que é a adotada pelo jCompany, a recomendação é escolher peças
“melhores em seu segmento”. Algumas dezenas de tecnologias, projetos e componentes OSS deverão ser
Entendendo a Arquitetura de Desenvolvimento
entendidos, selecionados, especializados e integrados, muitos deles em áreas de conhecimento com
razoável distinção das demais.
Por exemplo, a camada Visão do MVC envolve a orquestração de diversas tecnologias complexas, tais
como Facelets (XHTML)/HTML, Javascript, CSS, Ajax, técnicas de gestão de leiautes, etc.,
nenhuma delas de domínio específico do mundo Java ou OO, de domínio dos Arquitetos de
Software. O resultado, na prática, é uma quase ausência de arquitetura para a camada Visão,
delegada para tratamento superficial pelos Web Designers.
Refinar uma boa arquitetura para a camada Controller também tem seus desafios, já que esta é bem
mais complexa, tecnologicamente, do que as camadas subsequentes de Model/Domínio ou Persistence. É
uma outra camada onde o nível de soluções de arquitetura costuma ser muito raso, basicamente
consistindo de homologação de algum framework de base "em seu estágio bruto".
As camadas de Model, Domínio e Persistence, por serem mais puramente ligadas a linguagem Java e
às regras de negócio costumam receber 90% da atenção nos trabalhos típicos de Arquitetura de
Software, ao menos em seu estágio inicial. Porém, ao longo do tempo se fará necessário um esforço
nas demais camadas, que exigirão um considerável aprofundamento tecnológico.
- Arquitetura de Software “Anêmica”
Em um estágio 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 “solução de base
corporativa a ser reutilizada”.
Esta solução é frequentemente composta de uma pilha (stack) de produtos e framework de base Open
Source integrados, normalmente definida após alguns meses iniciais de prospecção, seleção e integração
“leve”. Digamos, de uma dúzia de produtos de base, complementados por documentos de guia em nível
mais detalhado. Ela está representada pela camada (2) na figura A4.2.
Mas neste nível de maturidade, como no anterior, ainda há uma grande migração de problemas “não
funcionais” para a camada de Core Business (5) e programadores “do negócio” lidando indevidamente
com:
o
Códigos MVC “burros” (de->para, fachadas artificiais);
o
Gerenciamento de transações manuais;
o
Instanciações de objetos manuais;
o
Códigos Java para inclusão, alteração, exclusão (CRUD);
o
Elaboração de formulários “do zero”;
o
Gestão de leiautes manual;
o
Etc.
Há um avanço perceptível com relação à arquitetura “meramente conceitual” do início , mas neste nível a
arquitetura ainda é rasa ao ponto de não eliminar mesmo variabilidades básicas indesejáveis.
A distância entre a realidade e a promessa de retorno de ambientes Orientados a Objeto continua imensa
- por isto batizamos a este estágio de “Arquitetura de Software Anêmica”.
É um estágio basicamente caracterizado por uma integração pouco profunda e abrangente entre um
número também insuficiente de produtos Open Source de base, conforme ilustra a Figura A6.2. Note que
as camadas sob responsabilidade da empresa são representadas na mesma coloração da camada de core
business.
Capítulo A4
Figura A 6.2. A rquitet ura de Sof tware “A nêmica”.
- Arquitetura de Software Intermediária
Neste estágio de maturidade, já encontramos evidência clara de uma primeira “Arquitetura de Software
Corporativa” em versão razoável, integrando um bom número de insumos (frameworks e utilitários)
Open Source com um esforço suficiente na produção de padrões de alto nível, nas diversas camadas
MVC.
Figura A 6.3. A rquitet ura de Sof tware Corporativa em nível intermediário.
Mas para ser de “nível intermediário”, realisticamente, esta arquitetura irá requerer uma compro vação de
uso satisfatório em produção – seguido das inevitáveis refatorações - por pelo menos dois anos. É um
período mínimo, após a construção da primeira versão, durante o qual uma equipe de perfil abrangente *
conseguirá evoluir para este nível de maturidade.
* C ompos ta de A rquiteto de Software, A nalistas de N egócio, Web - D esigners, P eritos nas T ecnologias, D oc umentadores, A nalistas de
T es te etc.
Entendendo a Arquitetura de Desenvolvimento
A partir deste ponto, no entanto, este modelo começa a apresentar suas limitações, especialmente se a
implementação 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 negócio, já que grande parte da solução arquitetural não é diferencial
para seu negócio.
o
Aumento de Custo: Mesmo que haja uma contratação de terceiros para a manutenção desta
camada, perdem-se os ganhos de escala possíveis a partir do reúso da parcela “commodity” da
arquitetura.
o
Problemas de Gestão: Normalmente, os problemas se agravam na medida em que começa a
existir uma “base instalada” da arquitetura em produção. Na fase de manutenção, requisitos
de Gerência de Configuração passam a consumir uma grande parcela de esforço da
equipe interna para manter ramos “de evolução” em paralelo com ramos “compatíveis”. A
partir daí, não é incomum que o entusiasmo técnico das primeiras fases dê lugar a turn-overs ou
queda considerável de produtividade.
A percepção mais comum é de que há uma dificuldade de ordem prática para que esta solução “familiar”
evolua para o próximo passo. Na medida em que as pressões de negócio sobre aplicações implantadas
prevalecem como prioridade, como haverá de ser, há uma tendência à estagnação ou lentidão para a
incorporação de inovações, medo de reformulações, etc.
- Arquitetura de Software Madura
Do nosso ponto de vista, uma primeira configuração de arquitetura rica e abrangente o suficiente para
oferecer os retornos esperados de um ambiente OO está ilustrada na Figura A6.4.
Figura A 6.4. A rquitet ura de Sof tware Corporativa com alto nível de maturidade.
Neste estágio, as preocupações de nível arquitetural que não sejam absolutamente dependentes do
contexto específico da empresa são totalmente desacopladas de preocupações de natureza comum ou
commodity.
Este é o primeiro modelo que oferece um importante raciocínio de negócios: a potencial terceirização
das camadas arquiteturais “2” e “3”, horizontais, de forma a possibilitar a concentração da
organização nas camadas “4” e “5”. De fato, somente as duas últimas têm relevância para o
ambiente específico de TI e verticais de negócio.
Com esta possibilidade, aumenta-se não somente o foco no negócio. Diminui-se o custo e herda-se
qualidade e maturidade, abreviando-se longos anos e um grande número de problemas.
- Arquitetura de Software Provida pelo jCompany FS Framework
Se tomarmos como base somente a proposta do módulo jCompany FS Framework, que provê uma
solução arquitetural para as aplicações desenvolvidas, veremos como ela pretende apoiar o modelo
anterior, oferecendo ganhos nas três camadas arquiteturais:
Capítulo A4
Figura A 6.5. A rquitet ura em camadas de uma aplicação 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) Redução do trabalho de integração e pré-configuração da camada de reúso Open
Source. Com isso, a empresa se liberta de manter partes de prospecção (P&D), integração,
especialização, documentação de integração, atualização, controle de versões e gerência de
configuração para estes insumos.
o
(3) Implementação 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.
o
(4) Solução de base para a criação da camada específica da empresa, chamada camada
Bridge. Deste modo, arquitetos da empresa podem imediatamente codificar suas generalidades e
especializações de “última milha”, sobrepondo ou especializando artefatos da camada (c). Este é
um espaço concreto que possibilita a criatividade, customização e generalização que dependem
do contexto da empresa (segurança, web-design etc.)
- Outras Soluções Arquiteturais do jCompany Developer Suite
Mas é importante notar que, além do jCompany FS Framework, os módulos jCompany IDE e
jCompany Test for Developer também trazem soluções arquiteturais para outras dimensões do
processo de desenvolvimento de software: ferramental/ambiente de apoio à produtividade e soluções de
base para Testes de Unidade, respectivamente.
Estas arquiteturas também podem ser expandidas e foram descritas no capítulo 1, mas estão
reproduzidas nas Figura A6.6 e Figura A6.7, para conveniência:
Entendendo a Arquitetura de Desenvolvimento
Figura A 6.6. A rquitet ura de Sof tware do A mbiente de Desenvolvimento (IDE).
Figura A 6.7. A rquitet ura de Sof tware para desenvolvimento de Testes de Unidade.
- A Síndrome do NIH (Not Invented Here)
Apesar dos ganhos óbvios advindos do reúso de arquitetura, um entrave a esta inexorável evolução pode
estar no próprio corpo técnico - por mais paradoxal que pareça.
Um indivíduo com interesse e formação em tecnologia, quando confrontado com um raciocínio de
negócios, pode falhar em identificar commodities de software, falhando em oportunidades de
terceirização que são chaves para o negócio de sua empresa. Uma atitude sintomática destes casos, por
parte de um arquiteto ou desenvolvedor, é rotular arquiteturas (nunca as suas próprias!) de “camisas de
força”, por exemplo *.
Todo reúso exige esforço de compreensão e adesão ao que se deseja reutilizar, em um primeiro momento, e
deve possibilitar diferenciações e flexibilidade para ganhos em níveis mais altos. Isso vale para o reúso de
arquitetura, de objetos ou de componentes.
- Aprendendo a Reusar Arquitetura
Sendo, portanto, o reúso em nível de arquitetura a primeira arma de produtividade e qualidade de
ambientes Orientados a Objetos, será essencial adquirirmos conhecimento nesta área, para os próximos
níveis.
*
São o que Rod J ohs on, o c riador do Spring , c hama de “O wn C areer D riven A rchitects” [J ohnson, Rod 2 0 04] - indivíduos que não
c ompreendem a importância, para s ua empres a, de orientarem a s ua “c riatividade” para c amadas de negóc io. É a ins is tência em não
reus ar, pelo des afio (ou interesse) pessoal de fazer.
Capítulo A4
Neste capítulo, recapitularemos brevemente alguns fundamentos no campo da arquitetura de software
para nivelamento. Não há pretensão e nem possibilidade de esgotarmos o assunto neste espaço, mas os
pontos para discussão aqui selecionados procuram se concentrar em carências frequentemente
encontradas em nosso mercado.
Revisão de Fundamentos
- Como Representaremos a Arquitetura?
Um sistema de software corporativo é composto de muitas estruturas distintas, com relacionamentos
complexos. Portanto, são necessárias diversas visões para representar cada uma delas [TS-4619
JavaOne 2006]. Neste livro, iremos discutir as seguintes visões arqu iteturais:
o
“Visão Geral” (General View): Utilizaremos a Visão Geral para uma primeira representação
(macro) das grandes camadas (Layers) e Blocos (Tiers) da arquitetura.
o
“Visão de Módulos” (Module View): Utilizaremos a Visão de Módulos para representar como
estão agrupados os conjuntos de artefatos em tempo de desenvolvimento e como eles se
relacionam entre si, em vários níveis de detalhamento.
o
“Visão Interna” (Interna View): Utilizaremos a Visão Interna para representar como estão
organizados os projetos de desenvolvimento do ponto de vista de sua estruturação interna. É um
tipo de visão de “micro-arquitetura”, considerando organização dos pacotes e artefatos padrões
definidos.
o
“Visão Comportamental” (Beauvoir View): Utilizaremos a Visão Comportamental para
representar como as categorias de classes colaboram entre si em algumas anatomias de
requisição MVC-P típicas.
o
“Visão de Execução” (Runtime View): Utilizaremos a Visão de Execução para representar
como podemos embalar e liberar os conjuntos de componentes em tempo de execução,
distribuindo-os ou mantendo-os em co-habitação, e como eles se relacionam nestas possíveis
variações de infra-estrutura.
o
“Visão da Interface com o Usuário” (GUI View): Utilizaremos a Visão de Interface com o
Usuário para representar os padrões de leiautes, formulários e componentes disponíveis, como
estão organizados e interação entre si. Ela não contempla questões de usabilidade, discutidas
fora do âmbito da arquitetura.
Além das representações principais para as visões acima, o detalhamento da arquitetura requer
documentos mais extensos que, por motivos didáticos, não são disponibilizados neste livro. Eles estão
disponíveis na documentação do módulo “jCompany Patterns & Methods”, cedido com a licença
corporativa do jCompany.
Neste capítulo, apresentaremos as três primeiras visões: "Geral", "de Módulos" e “Interna”.
- Arquitetura em Camadas (Layers)
O agrupamento de classes em módulos, que por sua vez se organizam em camadas sobrepostas, um
sobre o outro, é uma das metáforas mais comuns em arquiteturas de software. A estes módulos,
organizados rigorosamente desta forma, chamamos Layers (Camadas).
É um paradigma que define dependências de uma maneira simples (a camada de software “de cima”
depende da “de baixo”), mas que nos oferece um padrão para realizar arranjos arquiteturais bastante
complexos, mas que ainda assim conseguimos compreender – o que é, aliás, um dos grandes objetivos
de uma arquitetura OO.
O MVC, em si, é uma arquitetura em camadas cujo intuito principal é separar implementações
relacionadas à interação com o usuário (preocupações da aplicação em si) das implementações que
representam as regras de negócio fundamentais do negócio.
Para tanto, define uma camada “controladora”, que desacopla as camadas de Interface com o Usuário
(View ) da de negócio (Model), e também encapsula algum tipo de implementação em seu nível de
intermediação.
Na prática, algumas dificuldades que percebemos no uso do MVC em Java EE são:
o
Erros fundamentais de acoplamentos indevidos entre as camadas;
o
Uso burocrático, concebido para lidar com problemas intrínsecos do EJB 2.x, sem considerar
evoluções tecnológicas tais como o Java EE 5 e 6 e EJB 3.0 e 3.1;
o
Pouco investimento em generalizações OO, levando à proliferação desnecessária de grande
quantidade de código “pró-forma” (repetitivo), de comunicação entre as camadas.
Iremos discutir conceitos nestas três áreas, a começar pela questão das camadas:
Entendendo a Arquitetura de Desenvolvimento
o
Organização com baixo acoplamento em Layer (Camadas Sobrepostas): Uma
organização em Layer possui camadas sobrepostas “uma sobre a outra”, de modo que uma
camada somente dependa da imediatamente inferior. Por ter menos dependências, cada
camada tende a ser mais estável e flexível. Esta organização é também conhecida didaticamente
como “bolo de festa”, em analogia às diferentes camadas de recheio que compõem este tipo de
bolo:
Figura A 6.8. Organização em camadas.
o
Organização em Referência Circular: Muitas vezes uma representação errada ou pobremente
simplificada pode nos conduzir a conclusões perigosas nesta área. Por exemplo, a representação
à esquerda da Figura A6.9 representa módulos que não estão organizados em camadas, mas
que, devido à omissão das setas de dependência, sugere esta organização.
Olhando a revisão à direita, real, percebemos que se trata de uma arquitetura muito mais
complexa que a sugerida à esquerda. Neste caso, inclusive mais instável, pois sofre de um mal
conhecido como “referência circular”. Este é um problema que gera alto acoplamento e deve ser
evitado em todas as camadas de abstração de um software.
Figura A 6.9. Diagramação excessivamente simplif icada de arquitet ura.
o
Organização de Tier (Blocos), com diagramação simplificada: Mas a organização em
camadas não é a única utilizada em software e nem sempre é a mais recomendável. Pode-se
organizar uma aplicação em "blocos ou módulos" (Tiers) que não são "isolantes" como as
camadas, mas ainda assim relacionam entre si de modo a manter baixas as dependências.
Obs.: Mesmo nestes casos, muitas vezes a diagramação em camadas é utilizada, para
simplificar o diagrama em si, ou enfatizar um comportamento. Por exemplo, a diagramação da
esquerda, na Figura A6.10, é mais simples; mas quando é exigido um rigor técnico, pode dar
margem a confusão. Repare a versão mais exata à direita, exibindo claramente que C
dependente diretamente de A e B.
Capítulo A4
Figura A 6.10. Melhor diagramação de camadas.
o
Camadas paralelas e ortogonais: Como as organizações de software são bem mais
complexas do que pode sustentar a metáfora do “bolo de festa”, no mundo real nós iremos nos
deparar com combinações mais sofisticadas das várias abordagens possíveis, ou várias
“dimensões de camadas”.
Nas Figura A6.11 e Figura A6.12 vemos duas combinações em camadas “reais” que produzem arquiteturas
estáveis, corretamente diagramadas, e inclusive muito comuns em software.
Figura A 6.11. Camadas paralelas.
Figura A 6.12. Duas camadas transversais ou ortogonais.
Mesmo em uma arquitetura mais elaborada, como no caso da Figura A6.12, é importante percebermos
que o raciocínio fundamental de “minimizar dependências através do us o de camadas” continua presente.
Mas quais são os critérios para definirmos nossas camadas ? O que cada camada irá conter e como
dependerão umas das outras? Bom, estas respostas serão obtidas a partir de um raciocínio OO que
deverá seguir inicialmente os velhos princípios de baixo acoplamento e alta coesão.
- Baixo Acoplamento (Menos dependências, mais estabilidade)
O baixo acoplamento (ou diminuição das dependências entre elementos) deve ser almejado em
estruturas de software em todos os seus níveis de abstração:
Entendendo a Arquitetura de Desenvolvimento
o
Estruturas arquiteturais com o mínimo de dependências
(Na prática, com o maior uso possível de “camadas”);
o
Aplicações ou módulos com o mínimo de dependências (referências externas)
(Na prática, projetos com o menor tamanho possível de “Class Path”);
o
Pacotes com o mínimo de referências externas
(Na prática, classes com o menor número possível de “imports”);
o
Classes com menor número de referências externas possíveis
(Na prática, pacotes com o mínimo de classes possível).
Na implementação, classes que possuem menos dependências tendem a ser mais simples de se
compreender e mais “estáveis”, menos sensíveis a “turbulências” externas. Classes de camada
Controller, por exemplo, tendem a possuir mais dependências, tais como interfaces de Servlet e de
frameworks como o JSF. Tendem, portanto, a ter mais “imports” que classes da camada “Model” ou
“Domínio” e a serem mais instáveis (Por isso, dentre outros motivos, não são boas candidatas para
conterem implementações importantes do negócio ).
Mas como será que isso se manifesta realmente, na prática? Vamos ilustrar com o pequeno episódio real.
C erta vez, uma contribuição a um release menor do Tomcat 5.x introduziu a exigência de declaração
“implements Serializable” para todos os objetos que fossem mantidos em sessão (a intenção da equipe do
Tomcat era atender a um aprimoramento de suporte a Clusters).
As únicas classes que realizavam registro em sessão eram, naturalmente, as que possuíam acesso
(dependência) a interfaces de Servlet. Apesar de ser uma mudança trivial nos objetos (uma simples
declaração), em várias situações de migração para Tomcat 5.x, em todo o mundo, algumas classes de controle
“escapavam” à revisão e cancelavam em produção, manifestando a “instabilidade” provocada por esta
dependência.
É um típico problema produzido em camadas mais baixas da arquitetura que não acontece nas superiores
(de negócio, por exemplo), graças à organização em camadas do MVC.
- Alta Coesão (Melhor encapsulamento, maior reúso)
Sob outro ângulo, queremos também que estruturas, nos seus diversos níveis de abstração, se
mantenham especializadas, encapsulando implementações de comportamentos de mesma afinidade e se
mantendo tão simples quanto possível em torno de um objetivo comum.
Em tempo de programação, métodos 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 experiência, os maiores "crimes de baixa coesão” ocorrem nos métodos “de partida” , que iniciam a
resposta a um evento externo. Exemplos são o método “doGet” de um Servlet ou o “contextInitialized” em uma
implementação de ServletContextListener, ou um “execute” de um DP Command, utilizado em um framew ork
qualquer. Nestes pontos da arquitetura, não é difícil encontrarmos verdadeiros programas “COBOL”, em sintaxe
Java!
- Fatoração de Código (Menos redundâncias, mais eficácia)
A “fatoração de código” consiste na identificação de códigos redundantes ou muito similares em
diferentes artefatos, extração da parte comum deste código para um novo artefato independente, e
revisão dos originais para reusarem o código extraído “colocado em evidência”.
O objetivo do arquiteto, neste quesito, é buscar por códigos “pró -forma” (boiler plate) recorrentes,
vulgarmente conhecidos como “código burro” e aplicar seus conhecimentos de arquitetura de software e
OO para eliminá-los, possivelmente promovendo-os para frameworks ou utilitários.
Fatoração de código “pró-forma” é, de longe, uma das questões da arquitetura que mais afetam a
produtividade e um dos objetivos principais de frameworks de integração!
Uma arquitetura onde são admitidas grandes quantidades de “código burro”, por limitações de tempo ou
de conhecimentos mais aprofundados de OO e Java, fracassará ao menos parcialmente. Se não na
primeira versão da aplicação, nas fases seguintes, com as insustentáveis manutenções.
- Refatoração de Código (Fatoração contínua)
“A melhor escrita é a reescrita (...). Todo bom escritor sabe disto, e isto é verdadeiro para software também”
Ref . A 6.4. Paul Graham, citando E. B. White, em Hackers and Painters [Graham, Paul 2004]. Pág. 212
Mais recentemente, a “fatoração de código” deu lugar a uma sucessora: a “refatoração de código”
(Refactoring).
Capítulo A4
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 mudança de ênfase para a
refatoração faz sentido na medida em que admitimos a dificuldade de se produzir códigos bem fatorados,
“de saída”.
A verdade que hoje conhecemos é que, ao contrário do que alguns metodologistas eminentemente
teóricos apregoam, dificilmente se obtém uma boa arquitetura na sua primeira versão.
Especialistas nas tecnologias e processos de Especificação (CASE UML, Ferramentas MDA etc.), mas que
pouco ou nada conhecem das tecnologias e processos de Construção, terão ainda mais dificuldade neste
objetivo. Portanto, será prudente partir de preceitos arquiteturais que visem facilitar a “refatoração ou
reformulação de códigos” de uma forma geral, com a produção do mínimo de instabilidade possível.
Uma boa arquitetura é obtida de explorações práticas seguidas de refatorações freq uentes, oportunidades que
somente são bem aproveitadas por arquitetos de software hands-on, que se atrevem a “por a mão 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 refatoração decisivas baseadas em problemas e sugestões reais de clientes. Apesar de não ser
perfeitamente ajustada para problemas de A até Z, contém soluções para um “mínimo denominador
comum” que cobre um grande intervalo de problemas com soluções generalizáveis.
No estágio atual da arquitetura do jCompany, por exemplo, não é mais requerida nem uma única linha
de código Java, em nenhuma das camadas do MVC, para se implementar “Manutenções de Ciclo de Vida
de Objetos” (incluir, alterar, excluir e consultar).
Mesmo quando lidamos com agregações de objetos complexas, envolvendo cinco, dez ou até vinte
classes, o total de linhas de programação procedimental MVC para se obter um resultado com qualidade
de produção no jCompany tende a “zero”!
Manutenções de objetos em sua forma básica são operações commodity, candidatas primárias à fatoração de
código em qualquer linguagem de programação, especialmente em linguagens OO tais como Java, e não
deveriam ser resolvidas primariamente com geração de código - “rapidez” que não se preserva nas
manutenções.
Mas, indo além destas operações de manutenção de ciclo de vida, o jCompany generaliza por inteiro
dezenas de outras programações sofisticadas e recorrentes em sistemas corporativos, tais como
“clonagem de documentos”, “assistentes”, “leiaute dinâmico para impressão”, “exploradores de dados
(treeview)”, “exportação de dados”, e muitas outras. Todas elas generalizações que preveem espaço para
especializações em nível corporativo ou em nível de Caso de Uso, respeitando a arquitetura MVC.
Iremos experimentar estas promessas na prática, no próximo módulo. Neste capítulo, vamos apresentar
a "Visão Geral", “Visão de Módulos” e “Visão Interna” da arquitetura de software proposta pelo
jCompany.
“Visão Geral” - Grandes Camadas e Blocos da Arquitetura do Framework
- Visão Geral da Arquitetura do jCompany FS Framework
Já apresentamos uma visão geral de toda a solução jCompany Developer Suite, no capítulo 1. Iremos,
na pauta atual, somente aprimorar a representação da arquitetura do framework jCompany FS
Framework, que representa a dimensão da solução de maior interesse por parte de Arq uitetos de
Software, já que inclui os componentes OO reutilizados e montados juntamente com as aplicações.
A representação inicialmente apresentada no capítulo 1 está repetida na Figura A6.13, para conveniência.
Os números de 1 até 4 representam dependências existentes para reúso, desde a infra-estrutura,
passando pelos serviços do Application Server, bibliotecas, frameworks de base, framework de integração
e camada Bridge.
Entendendo a Arquitetura de Desenvolvimento
Figura A 6.13. Visão Geral inicial da arquitet ura do jCompany FS Framework.
Mas, mesmo sendo macro, esta representação é muito simplória para estudos arquiteturais. Isto porque
nem a camada “3”, do jCompany (Arquitetura Reutilizada), nem a camada “4, Bridge (Arquitetura
Específica), funcionam como Layer, todo o tempo, como o diagrama pode sugerir.
Exceto nos percentuais de requisitos onde os Casos de Uso Padrões são suficientes, o desenvolvedor
poderá (e isto será desejável) acessar a camada “2” (JBoss Seam, Tiles/Facelets, JPA/Hibernate, etc.)
diretamente ou, mais raramente, a camada “1”, em nível do Application Server ou JVM.
Portanto, o diagrama abaixo é mais realístico tecnicamente falando do que o anterior.
Figura A 6.14. Visão Geral da A rquitet ura do jCompany FS Framework - A primorada.
#1.
Nas parcelas de requisitos de Casos de Uso centrados em dados, tanto o jCompany FS Framework
quanto a complementação Bridge praticamente isolam a aplicação das camadas de baixo, atuando como
camadas (Layers). É importante notar as setas tracejadas de dependência, indicando que estas "camadas"
comunicam entre si para oferecer um resultado MVC completamente generalizado.
#2.
Em requisitos que fogem ou suplementam os suportados pelos padrões, o acesso pode ser direto à camada
de frameworks de base. Deste modo, a arquitetura não restringe; possibilita ao desenvolvedor elaborar
quaisquer soluções que sejam convenientes, para cada caso.
Em quanto por cento dos casos o jCompany FS Framework e a Bridge funcionarão como camadas? Bom,
isso depende da natureza dos requisitos de cada projeto. Em um estudo de ROI (Retorno sobre o
Capítulo A4
Investimento) elaborado pela Powerlogic, a torta apresentada na Figura A6.15 é tomada como base,
para um projeto corporativo típico.
Figura A 6.15. Segmentação típica de requisitos de aplicação corporativa.
Assim, em 40% dos casos, em média, espera -se que o jCompany FS Framework atue como uma
camada, evitando contato direto de códigos de negócio com frameworks de base.
Nos demais segmentos de requisitos, o framework irá contribuir provendo serviços de IoC, DI, AOP para
gerência de transações, leiautes etc.; todos bastante úteis, mas que não visam isolamento. Deste
modo mantém-se a liberdade para que o desenvolvedor acesse qualquer recurso de base, quando
necessário for.
Veja a contribuição esperada (também em média, é claro) para cada fatia de natureza de requisitos,
acima definida, na Figura A6.16.
Figura A 6.16. Percentual de contribuição do jCompany FS Framework, por natureza de requisitos.
Quando funciona como camada, o nível de contribuiçã o do framework do jCompany no estudo foi
impressionante. Mas mesmo considerando-se o percentual de contribuição nas outras fatias,
devidamente ponderados, obtém-se ganhos expressivos!
"Visão de Módulos” - Dependência entre os projetos gerados
- A arquitetura MVC no jCompany
Veja que, no tópico anterior, a representação de camadas utilizada é ortogonal às camadas MVC. Neste
tópico, 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.
Adoção rigorosa da arquitetura MVC-2.
2.
Uso de camada de Persistence, subdivindo a de modelo, através do DP DAO (ao que chamamos, resumidamente,
de MVC2-P)
3.
Balanceamento entre “melhores práticas” Java EE e DDD.
4.
Refinamento do nível de detalhe arquitetura, para dentro das camadas MVC2-P.
5.
Arquitetura rica, também para a camada Visão, com exclusivo “IoC Universal”, inclusive para esta camada.
De uma forma um pouco mais detalhada:
1.
Primariamente, o jCompany reúsa o modelo MVC-2 clássico com separação rigorosa das suas camadas
utilizando o servlet de “Front-Controller” do JSF (FacesServlet). O uso deste DP Front-Controller é o que distingue
o MVC-2 do MVC-1, já que no segundo caso o usuário acessa as JSPs diretamente.
Entendendo a Arquitetura de Desenvolvimento
2.
Em segundo lugar, o jCompany define uma nova camada para serviços de Persistence, subdivisão da
camada Model, provendo contratos abstratos (Interface e DP Abstract Factory), além de
implementações concretas genéricas e alternativas para Hibernate ou JPA. A camada de Persistence não
é uma sub-divisão “clássica” 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 recomendações da Sun, assimilando “melhores
práticas” do Core J2EE Patterns [Deepak Alur, John] atualizadas para Java EE 6, balanceadas ainda com
sugestões de Domain Driven-Design - DDD [Evans, Eric. 2004].
O DDD enfatiza uma organização OO tão pura quanto possível para o modelo de Domínio, o que concorre
eventualmente com organizações para código distribuído do Java EE. Algumas vezes o Java EE apresenta padrões
que apresentam pequenas otimizações, de mais baixo nível, mas que não são tão elegantes quanto um modelo
rico de Domínio preconizado pelo DDD.
Mas, se por outro lado uma arquitetura que enfatize uma “distribuição potencial” de componentes, como o Java
EE, pode ser considerada “overengineering” [Johnson, Eric 2002], por outro pode ser útil em e stratégias que
pretendam maximizar o reúso em runtime usando SOA, por exemplo.
A arquitetura sugerida no jCompany oferece um balanço razoável entre estas duas escolas : na prática,
isto significa que programações de Domínio podem ser ricas e “não anêmicas” [Fowler, Martin 2004],
refletindo uma linguagem de negócios, mas também publicáveis ao menor esforço e de forma eficiente
através de um WebService ou serviço 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
organização refinada de pacotes e novas categorias de classes internas tais como Service e Helper, utilizadas com
DP C omposite [Freeman, Freeman 2004] para maximizar a coesão e minimizar ainda mais o acoplamento.
5.
Finalmente, o jCompany possui uma arquitetura especialmente diferenciada na camada Visão, provendo
Inversão de Controle (IoC), também nesta camada, de modo a finalizar a abrangência de generalização potencial
da solução.
Como vimos, esta é uma camada especialmente mal resolvida em arquiteturas típicas 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
reutilizáveis e controlados pelo framework (leiautes dinâmicos com Tiles /Facelets), componentes visuais
especializados, soluções para reúso e especialização de peles, rotinas Javascript/Ajax etc., tudo isso com
DPs e conceitos OO aplicados, como nas demais camadas. Este assunto será discutido de forma
específica em capítulo sobre customização de Web-Design.
- Organizando Classes de Domínio
Uma das maiores discussões arquiteturais em MVC é, frequentemente, “como organizamos o nosso
modelo de Domínio”?
O modelo de Domínio é composto por aquela parcela de classes que representam entidades claramente
identificadas no negócio, persistentes, em sua maioria, contendo propriedades cujos valores devem ser
mantidos em bancos de dados.
Mas muito embora estas classes componham um núcleo importante das estruturas e regras de negócio,
existirão outras categorias importantes de classes também consideradas “de negócio” para encapsular
orquestrações de serviços, cálculos e procedimento de apoio.
- Arquitetura MVC-2 clássica do J2EE
Na visão original do J2EE, tais classes de domínio deveriam ser implementadas como Entity Beans e, pela
imposição de não poderem rodar fora de um container EJB (ao contrário dos POJOs atuais), eram, de
forma obrigatória, localizadas em subcamada interna da camada Model.
Até o aprimoramento recente do padrão da especificação de Entity Beans para o EJB3, portanto, era
recomendado aos desenvolvedores J2EE trabalhar com cla sses artificiais de DTOs (Data Transfer
Objects), meros containers de informações, para transportar dados de entidades da camada
Modelo/Persistence para a camada Controller/View, conforme a Figura A6.17.
Capítulo A4
Figura A 6.17. A rquitet ura MVC preconizada no J2EE clássico (até EJB 2.1).
#1.
Usuário aciona aplicação: No modelo MVC-2, um servlet recepciona todas as requisições do usuário (e
não os componentes de visão tais como JSF, no MVC-1)
#2.
Camada controller chama “serviços” de negócio: Um aparato de Design Patterns tais como Business
Delegate, Session Façade e outros são tipicamente utilizados para um maior isolamento entre a camada da
aplicação (Controle e Visão) e a camada de negócio (Model), e também devido a uma pressuposição de
“remoting”, ou seja, da potencial distribuição destas camadas por máquinas distintas, em runtime. Classes
remotas são, principalmente EJB Session Beans 2.x.
#3.
Todas as principais camadas compartilham utilitários. Muito embora não sejam representados com
frequência, componentes JAR contendo bibliotecas suplementares para operações com data, logging,
numéricas, tratamento de exceções etc., são dispostas de forma a estarem disponível em todas as
camadas.
#4.
Uso de Entity Beans 2.x: A Persistence ideal do ponto de vista da especificação é obtida através 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 limitações tecnológicas ou de performance, requerendo codificação de SQL diretamente nos
códigos Java.
#6.
Acesso a serviços de Persistence: Seja por responsabilidade do container EJB, no caso dos Entity Beans
ou do desenvolvedor nos DAOs, somente através de classes desta camada o repositório de armazenamento
(Ex.: SGBD-R) é acessado.
#7.
Criação do meio de transporte: Após a recuperação de informações persistidas, seja por que meio
forem, a codificação da cópia dos dados de Entity Beans ou JDBC Result Sets para DTOs (Data Transfer
Objects) é obrigatória.
#8.
Controle de fluxo de navegação: No modelo MVC-2, as classes de Controle decidem para que classes de
visualização irão delegar a finalização da resposta ao usuário. Uma nova versão de Interface com o Usuário
é então selecionada em função do estado atual da conversação.
#9.
Despacho da visualização: Classes representando tecnologias da camada Visão tais como facelets ou
JSF despacham algum formato de visualização para dispositivos de cliente, tais como HTML, XML, PDF, CSV,
etc.
Perceba que, como a estrutura de dados dos formulários de negócio é composta em sua maior parte por
propriedades das entidades do negócio, a estrutura das classes de DTO terminava por ser 90% a 100%
redundante com a estrutura das classes Entity Bean. Por conseq uência, a manutenção desta redundância
exigia códigos “burros” de transferência de dados (de ->para), instanciações de classes desnecessárias
etc.
Os outros graves problemas desta especificação Entity Bean (até a versão 2.x), tais como sérias
restrições da linguagem de Persistence EJB-QL, limitação ao uso de herança etc., findavam por
configurar um verdadeiro desastre em termos de produtividade - e Orientação a Objetos.
Na prática, muitos resolviam este problema simplesmente desistindo dos Entity Beans 2.x (de fato, quase
inutilizáveis). Mas quem não os substituía por algum framework de mapeamento Objeto-Relacional tal
Entendendo a Arquitetura de Desenvolvimento
como o Hibernate, passava a programar JDBC em EJB Session Beans, como exemplificado em (E), com
manipulação direta de “result sets” e cópias de/para DTOs (ou VOs), caindo em níveis de produtividade
de técnicas de programação da geração “COBOL”. Na verdade, em níveis piores devido às deficiências
intrusivas da geração EJB 2.x, como visto.
Felizmente, os Entity Beans 2.x são agora “legado”, s ubstituídos na versão EJB 3.0 por POJOs (Plain Old
Java Objects) que corrigem, da “água para o vinho”, todas as limitações clássicas.
Uma sequela disso é que os Entity Beans 3.0 foram inteiramente reconcebidos a partir do padrão Java EE
5 e o ramo 2.x não sofrerá mais evoluções. Ruim para quem acreditou cegamente neste tipo de “padrão
forçado 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 “padrão de -facto”, como o Hibernate/JPA*.
Padrões “de facto” do mercado Open Source, via de regra, superam os “de comitê”. Somente nos últimos anos,
os condutores estratégicos do Java EE 5 e Java EE 6, especialmente a SUN, focou nos anseios dos
desenvolvedores e não somente dos fabricantes de Application Server . Esta tendência tem levado à quase
eliminação de padrões artificais concebidos sem exploração técnica.
- Camada de Domínio Ortogonal em Java EE 6
Por tudo isso, em sua versão 3.x os Entity Beans voltam a ser a implementação ideal para Entidades de
Domínio. Os EJBs 2.x não 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 são
“destacáveis” e podem ser expostos para todas as camadas do MVC2 -P em um esquema conhecido como
“atach-detach”. Deste modo, servem tanto para Persistence transparente quanto para encapsularem
regras de sua alçada e transportarem seus próprios dados.
Com esta evolução, uma melhor organização para entidades de Domínio é colocá -las em uma nova
camada, ortogonal à camada central do MVC [POJOs in Action] [Spring MVC], conforme ilustrado na
Figura A6.18.
Figura A 6.18. A rquitet ura MVC com camada ortogonal de Domínio.
#1.
*
Camada commons engloba utilitários e DTOs eventuais: As classes utilitárias comuns a todas as
camadas MVC principais, bem como eventuais DTOs que ainda sejam necessários são encapsulados na
visão “Commons”.
O c riador da Hibernate, G avin King, foi um dos líderes da es pecificação EJB3, es pec ialmente da parte de Entity Beans, que foi
redefinida dentro do padrão JPA (Java Persistance A rchitecture). P or is so, o J P A é hoje 9 0 % s imilar arquiteturalmente ao que já s e
us ava na H ibernate.
Capítulo A4
#2.
Camada de Persistence mais “leve”, utilizando JPA-QL: A camada de Persistence agora pode
dispensar codificação de inclusões, alterações, exclusões e de tratamentos de concorrência, geração de
identificadores automáticos, dentre outros trabalhos realizados de forma transparente pelo JPA. Além disso,
a linguagem JPA-QL retorna grafos de entidades de domínio prontamente disponíveis para uso pelas demais
camadas de forma OO, e não mais “result sets” JDBC, relacionais.
#3.
Camada ortogonal para Entidades de Domínio: A camada de domínio agora representa um objeto
clássico de OO, com propriedades e responsabilidades (métodos) do negócio, além de poderem ser
utilizadas em qualquer camada MVC2-P. É importante notar que agora as nobres classes desta camada são
as mais estáveis da arquitetura, não dependendo de serviços de nenhuma outra, nem de Persistence, por
exemplo (a camada de Persistence recupera dados e disponibiliza para a de Domínio).
Na camada simplificada como “Commons” (1) estão incluídas classes de utilitários 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 também algumas dependências especificas de cada
camada, ao centro (Mat. Prima OSS, Service, Helper):
Figura A 6.19. A rquitet ura MVC2-P com dependências ortogonais globais e internas das camadas.
*
#1.
DP Façade: Apesar de representarmos, didaticamente, uma seta com dependência entre Controller e
Model (do Controller para a subcamada de implementação de Fachada), o DP Façade é utilizado nesta
interação, de modo que há um acoplamento leve, facilitando reimplementações de serviços, se/quando
necessário.
#2.
Transporte DTO e Context: Quando um Caso de Uso apresenta formulário com estrutura bastante
distinta das Entidades, pode-se lançar como recurso de transporte os tradicionais DTOs (Data Transfer
Objects), como exceção, não mais como regra! Além disso, um POJO com DP Context Object é utilizado
pelo jCompany para transportar, genericamente, informações de contexto da camada Controle para
Modelo, que podem ser úteis (perfil do usuário autenticado, metadados de colaboração etc.).
#3.
Utilitários Globais: Classes do jCompany com sufixo Helper trazem funções diversas, complementares a
funções de utilitários de mercado, de interesse de todas as camadas.
#4.
Matéria-Prima OSS Global: Representam dependências externas (JAR) de utilitários, também comuns a
todas as camadas MVC2-P, tais como Log4j, Commons, CGLib (AOP) etc.
N es te livro, utilizaremos M VC2-P quando quisermos enfatizar uma arquitetura MVC do tipo 2 , c om s ubc amada de P ersistência bem
definida.
Entendendo a Arquitetura de Desenvolvimento
#5.
Serviços e utilitários Específicos: Dentro de cada grande camada MVC2-P, há subdivisões de pacotes
segmentando e encapsulando serviços e utilitários internos do jCompany, específicos para a camada.
#6.
Matéria-Prima OSS Específica: Cada camada MVC2-P possui um conjunto agrupado de dependências
externas de interesse seu apenas (definido tanto no Maven quanto em User Libraries do Eclipse). Este
agrupamento simplifica a gestão de dependências, evitando falhas básicas de arquitetura produzida por
desenvolvedores. Ex.: Importações de serviços de Persistence na camada Controller.
É importante observarmos algumas dependências acima indicadas:
o
Há uma dependência ortogonal, por parte de todas as camadas MVC2-P, com a camada de
Domínio, além de utilitários comuns, resquícios de DTO e contratos de fachada (somente as
Interfaces).
o
A camada de Domínio, por sua vez, desconhece e independe de quaisquer das camadas MVC2-P.
Ela se torna assim, como é de se esperar, a parte mais estável da arquitetura, funcionando
com um “layer ortogonal”. O conceito da ortogonalidade pode ser melhor visualizado pelo
rearranjo didático da Figura A6.20.
Figura A 6.20. Rearranjo para visualização mais didática da camada Ortogonal - "layer".
Algumas outras observações importantes:
o
O M do MVC2-P, a camada Model, é agora decomposta em “Implementações de Contratos de
Fachada” e “Serviços de Negócio”. Não detém mais os direitos exclusivos de acesso às
Entidade de Domínio, que por sua vez também encapsulam “regras de negócio de sua
responsabilidade” e não somente dados.
o
Em uma eventual disponibilização de forma distribuída, os módulos que compõem as camadas
ortogonais são embalados em ambos os executáveis: o da aplicação e o do serviço. Ou seja,
em lugar dos DTOs artificiais (somente alguns contratos especiais permanecem), são
as próprias Entidades que agora servem de transporte entre as aplicações
distribuídas.
o
Entidades não podem acessar DAOs (Data Access Objects) para obter dados. Elas devem
receber dados recuperados por classes de serviço da camada Model (Manager/Business
Objects-BO ou Application Services-AS) para realizar seus processamentos, tipicamente
regras de negócio.
o
Os termos entre parênteses sugerem sufixos padrões para classes em cada camada, mas podem
ser customizados em nível corporativo através de configurações nos metadados do jCompany.
Assim, classes de serviço da camada Modelo podem ter sufixo padrão BO, Manager, Mgr ou
Service, conforme desejado.
- Organização de Projetos de Desenvolvimento
Os três projetos Eclipse gerados no capítulo anterior suportam a arquitetura MVC2-P, no ambiente de
desenvolvimento, da seguinte forma:
Capítulo A4
Figura A 6.21. Projet os de desenvolvimento x arquitet ura de camadas MVC-P.
#1.
Projeto Eclipse “rhtutorial”*: Engloba a chamada de “camada da Aplicação” [Richardson, Chris 2006], ou
seja, as camadas Visão e Controle (Controlador) do MVC. Naturalmente, artefatos de visão são
segmentados dos de controle em pacotes distintos.
#2.
Projeto Eclipse “rhtutorial_model”: Engloba a camada de Model, incluindo a subsegmentação de
Persistence em pacote distinto. Também neste caso, pacotes distintos segmentam serviços de negócio e de
Persistence.
#3.
Projeto Eclipse “rhtutorial_commons”: Engloba a camada de utilitários e outras classes de interesse
comum das demais camadas e também a camada de Domínio, segmentada em pacote específico.
Na organização da Figura A6.21, é importante notar que não há uma relação “um para um” entre uma
camada da arquitetura e um projeto de desenvolvimento na IDE, já que a proliferação de projetos de
desenvolvimento é também prejudicial, aumentando a complexidade muitas vezes sem
vantagens práticas.
Por outro lado, agrupar todas as camadas em um único projeto costuma também ser uma
simplificação exagerada na medida em que facilita a quebra de arquitetura MVC †.
O jCompany sugere um agrupamento considerado bom para a média dos projetos corporativos, em seus
templates INI, mas deve-se realizar ajustes, customizando-se estes templates para algumas situações.
Alguns bons exemplos são:
o
Caso a aplicação pretendesse renderizar objetos para mais de uma tecnologia de Visão (Ex.:
HTML e também XML/XSLT ou WML), então seria uma boa escolha separar os pacotes de Visão,
presentes no projeto “rhtutorial”, em outro projeto independente. Deste modo, poder-se-ia ter
dois projetos para esta camada Visão bem desacoplados.
o
O mesmo raciocínio valeria, caso a pretensão fosse utilizar duas implementações de Persistence.
Se fosse o caso, compensaria fatorar o(s) pacote(s) de persistencia do “rhtutorial_modelo” para
um projeto próprio de Persistence‡.
*
N a vers ão 6 .0 do J A GUAR os projetos M VC s ão gerados s ob um projeto pai nomeado c omo "[nomeapp]_parent". E ssa nova estrutura
fornec e maior dinamis mo para o maven e não interfere em nenhum artefato M VC.
†
I s s o porque fac ilita aos des envolvedores eventualmente instanciarem dependência s de outras c amadas, dis poníveis globalmente em
um únic o C lass P ath.
‡
N ote que, des de que c las ses de uma c amada M VC2-P estejam s egmentadas, pelo menos , por pac otes c om baixo acoplamento,
reorganizar os projetos não s eria uma tarefa c omplexa. E c omo veremo s, es ta é uma preoc upação do jCompany, que des c reveremos
na “V is ão I nterna” da arquitetura proposta.
Entendendo a Arquitetura de Desenvolvimento
Figura A 6.22. Principais pacotes que segmentam internamente as camadas, dentro de projet os.
Devido à organização acima representada, chega -se ao seguinte esquema de dependência entre os
projetos gerados (gerada desta forma pelo jCompany, automaticamente, tanto no Eclipse quanto no
Maven):
Figura A 6.23. Diagrama de dependência de módulos em linguagem UML.
Nos exemplos em Figura A6.24, Figura A6.25 e Figura A6.26, vemos os arquivos Maven e configurações
no Eclipse envolvidos. Os módulos Maven (Projetos que serão alterados e construídos pelo
desenvolvedor) são definidos no arquivo "pom.xml" do projeto Parent e as dependências Maven nos
arquivos "pom.xml" de cada projeto. A sincronia entre esta definição e o Build Path do Eclipse é
automaticamente realizada pelo plugin M2Eclipse. Notar que este plugin importa "módulos Maven" como
"Projetos Eclipse" e, como veremos mais adiante, outras dependências (JAR) como Libraries Externas,
como deve ser feito:
Capítulo A4
Figura A 6.24. Projet o "principal": Módulos expressos no "pom.xml"
Figura A 6.25. Projet o "principal": Dependências de módulos expressas no "pom.xml" e sincronizadas no Eclipse.
Figura A 6.26. Projet o "modelo": Dependências de módulos expressas no "pom.xml" e sincronizadas no Eclipse.
O projeto "commons" não possui dependência dos demais, sendo portanto considerado mais "estável", do
ponto de vista arquitetural.
- Dependências com o jCompany
A Figura A6.27 exibe novamente um Diagrama de Componentes da UML para nosso projeto “rhtutorial”,
desta vez expandido para conter dependências do jCompany em tempo de desenvolvimento (no
Eclipse).
Figura A 6.27. Dependências entre projet os gerados e jCompany, em tempo de desenvolvimento.
O projeto do jCompany para camada de Visão, “jcompany_view” não esta incluído como dependência
porque não contém classes necessárias em tempo de desenvolvimento. Mas caso o desenvolvedor
Entendendo a Arquitetura de Desenvolvimento
necessitasse especializar algum componente ele teria que acrescentar uma camada “Bridge”
especializada ao projeto.
- Dependências com o jCompany “em tempo de desenvolvimento”
Como implementamos as dependências da Figura A6.27, no ambiente do Eclipse?
Além dos módulos supra-citados, o plugin M2Eclipse sincroniza as dependências simples, que não são
expressas como "módulos" nos arquivos "pom.xml"(do projetos MVC e do projeto Parent) ,como
"External Libraries" no Eclipse, automaticamente. Deste modo, dispensa o desenvolvedor de configurar
de forma redundante estas dependências. Ver Figura A6.28.
Figura A 6.28. Dependências automaticamente geradas no Eclipse, a partir do M2Eclipse
#1.
Projetos Rhtutorial, que por ser um projeto jCompany tem dependências gerenciadas pelo M2Eclipse.
#2.
JARs definidos nos arquivos "pom.xml" e disponíveis no repositório Maven local, agrupados em "Maven
Dependencies".
- Dependências com o jCompany “em tempo de execução”
Em uma visão de dependência “em tempo de execução”, o projeto da camada Visão, “jcompany_visao”
devem aparecer, pois reúne artefatos "não Java", com conteúdo em formatos como XHTML (leiautes
genéricos de formulário), CSS, Javascript (Widgets, utilitários, ...), dentre outros artefatos reutilizados
somente em tempo de execução. Isto é exemplificado na Figura A6.29.
Figura A 6.29. Dependências entre projet os gerados e jCompany em tempo de execução.
Obs. 1: Para dependências somente em “tempo de execução”, é necessário o devido registro das
dependências nos arquivos “pom.xml” do Maven, mas não necessariamente no Eclipse! O M2Eclipse já
cuida deste tipo de configuração automaticamente.
Obs. 2: Os projetos da camada visão do jCompany são disponibilizados como “WAR” para o Maven, que
os expande e mescla com o WAR da aplicação (ou EAR) em tempo de montagem para funcionamento em
execução. Este formato é modelado como "PSEUDO-WAR" para distingui-lo de um "WAR" final,
executável.
Capítulo A4
- Dependências com a camada de reúso Open Source (OSS)
Além da dependência entre os projetos Eclipse e o jCompany, precisaremos analisar e implementar
ainda as dependências de todos estes projetos com os frameworks de base e bibliotecas de utilitários
homologados no solução, aos quais chamamos de “Matéria -Prima Open Source”.
As dependências das camadas de reúso Open-Source também são importadas como "External Libraries"
no Eclipse pelo M2Eclipse, não havendo distinção com relação aos JARs do jCompany, por exemplo.
Figura A 6.30. Libraries contendo jCompany e componentes reutilizados (em destaque), gerados pelo M2Eclipse.
“Visão Interna” - Estrutura e artefatos dos projetos gerados
- Introdução
Nesta visão, vamos entender como os três projetos gerados no cap ítulo anterior estão organizados do
ponto de vista de sua estrutura interna. Esta visão engloba a organização de diretórios e de artefatos
sugeridos pela arquitetura.
A organização inicial de diretórios adotada pelo jCompany segue convenções recomendadas pela
ferramenta Apache Maven, resultado de anos de prática em organização de projetos colaborativos e
mundiais do grupo Apache. A organização “opinativa” do Maven, como gostam de frisar os seus autores,
é mais rigorosa, porém permite a esta ferramenta compreender mais a fundo o projeto (onde estão suas
classes de teste, artefatos de configuração da aplicação etc.) e, por consequência, contribuir mais.
Seguir o padrão de pacotes do Maven nos ajudará na atualização de versões, geração de
rotinas de montagem, compilação e liberação de executáveis. Além disso, plugins Maven poderão
gerar métricas interessantes e um Web-Site em nível 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
exigências arquiteturais e irá cobrar um maior investimento inicial quando comparado, por exemplo, ao Apache
Ant, mas trará mais retorno, no médio prazo.
- Aprendendo mais sobre o Apache Maven
Não iremos redundar neste livro toda a explicação de base disponível nos manuais do “Maven 3”, 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 disponíveis na Web,
facilmente desvendáveis através de consulta “maven 3 articles” no Google.
Em nossa pauta, iremos discutir os refinamentos realizados pelo jCompany sobre essa estrutura padrão
de forma detalhada.
- O projeto principal (Controller e View)
O projeto “principal” contém basicamente pacotes para programações da camada Controller
do MVC, bem como arquivos de configuração e artefatos de camada Visão. É a seguinte a sua
organização interna padrão, conforme definida no template INI (e, portanto, utilizada para novos
projetos):
Entendendo a Arquitetura de Desenvolvimento
Figura A 6.31. Organização interna do projet o principal “rhtutorial”.
Organização Interna do Projet o Principal (Ex.: rhtutorial)
P ac ote P adrão
(D iretrizes M aven)
O bjetivo
1 . s rc /main/java
(Sourc e Folder)
C ontém arquivos c om c ódigo-fonte em linguagem J ava para
c las ses da c amada “C ontroller” da arquitetura M VC, organizados
c om o s eguinte padrão:
[br.]c om.[empres a].[projeto].controller.[js f]
onde
[br.] é um prefixo opc ional, uma vez que o res tante do pac ote
c os tuma s er s uficiente para evitar c olisões de nomes .
[empres a] nome da organizaç ão
[projeto] nome do projeto
[js f| lis tener] s ão originalmente s ubdivididas c om base em
*
dependênc ias de tec nologias típicas da c amada c ontrol ler :
o
js f: P acote que c ontém c lasses com dependência de tecnologia J SF
o
lis tener: Pacote que c ontém classes dependência da tecnologia de
Servlet, especificamente c onhecidas como “listeners”.
A lém dis so, o pac ote raiz pode c onter c lasses alternativas de
s erviço da c amada c ontroller, que não s ejam ac opladas
es pec ialmente a nenhuma das tec nologias ac ima.
2 . s rc /test/java
(Sourc e Folder)
C ontém arquivos c om c ódigo-fonte em linguagem J ava para
c las ses de T este da aplicação, inc luindo tes tes de unidade para
c amada “C ontroller” da arquitetura MVC (c lasses locais do
projeto), e tes tes func ionais da aplicação em geral.
A es trutura interna possui um pac ote “es pelho” ao pac ote
princ ipal, de modo que uma determinada c lasse de tes te
*
A organizaç ão bas eada em dependências de tecnologias visa aumentar a “es tabilidade” de c ada pac ote, mantendo -os c om o mínimo
pos s ível de ac oplamentos (‘imports’). São pos s íveis s ubdivisões em pac otes “func ionais” abaixo do pac ote de tec nologia (ex: por C asos
de U s o), ou mes mo alteração desta ênfase, c olocando -se pacotes “func ionais” antec edendo os pacotes de tec nologia, s e des ejado.
Capítulo A4
c ompartilhe visibilidade de mes mo “package” da c lasse testada.
O bs .: T écnicas de T este de U nidade e Func ional (es ta última
utilizando o produto jCompany Q A ), bem c omo a organizaç ão de
diretórios detalhada, s erão dis cutidos em c apítulo dedicado.
3 . s rc /test/resources
(P s eudo Source- Folder)
C onfigurado c omo Source
folder no E c lipse para melhorar
vis ualização no P ackage
E xplorer, muito embora não
c ontenha c lasses J ava.
C ontém arquivos de rec ursos utilizados em T estes Funcionais,
E s táticos e de C arga/Stress.
4 . s rc /main/config
(Sourc e Folder)
C ontém arquivos c om anotações J ava que representam
“metadados ” do jCompany para a aplic ação, es pecíficos para a
c amada “C ontrole” da arquitetura MVC, organizados c om o
s eguinte padrão:
O bs .: E s tes arquivos também s erão c ompreendidos em c a pítulo
es pec íficos s obre automação de tes tes em geral.
c om.powerlogic.jc ompany.c onfig.[emp|appl*URLs*]
onde
[emp] c ontém arquivo “pac kage -info.java”, que pos sui anotações
em nível da organizaç ão e , portanto, gerais para todos os
projetos . N ormalmente, em ins talações c orporativas, deve s er
utilizado s omente em projetos da c amada Bridge e,
eventualmente, utilizados s omente para s obreposições de
anotaç ões específicas.
[app] c ontém arquivo “pac kage -info.java”, que pos sui anotações
em nível da aplic ação e , portanto, gerais para o projeto c orrente.
[* U RL s*] s ubdiretórios que s erão c riados pelos plugins do
jCompany na medida em que U RL s que repres entem
c olaborações padrões sejam geradas. C ada diretório tem uma
c orres pondência “um para um” c om uma U RL que s iga um padrão
do jCompany, e c onterá um arquivo “pac kage-info.java” c om
“metadados ”. E xemplo:
o
o
c om.powerlogic. jc ompany.config.funcionarioman\
pac kage-info.java: anotações para URL ‘/funcionarioman’
c om.powerlogic. jc ompany.config.funcionariosel\
pac kage-info.java: anotações para URL ‘/funcionariosel’
O bs .: U m maior entendimento sobre “metadados” do jCompany
s erá obtido no des enrolar dos tutoriais, nos próximos c apítulos.
5 . s rc /main/resources
(P s eudo Source- Folder)
C onfigurado c omo Source
folder no E c lipse para melhorar
vis ualização no P ackage
E xplorer, muito embora não
c ontenha c lasses J ava.
Segundo o padrão M aven, es te diretório deve c onter arquivos de
c onfiguração que s erão disponibilizados no “C lass P ath” de
exec utáveis. N a prática, c opiados para o diretório /WE B I N F/classes, em tempo de montagem do arquivo WA R.
6 . s rc /main/webapp
(P s eudo Source- Folder)
C onfigurado c omo Source
folder no E c lipse para melhorar
vis ualização no P ackage
E xplorer, muito embora não
c ontenha c lasses J ava.
C ontém arquivos J ava E E “não J ava”, típicos da c amada
“C ontroller” e “V iew” da arquitetura MVC, podendo ter os
s eguintes formatos:
7 . (raiz) arquivos P O M
o
A rquivos XML de c onfiguração diversos, ta nto para atendimento à
es pecificação Servlet, quando J SF ou Struts e T iles.
o
A rquivos PROPERTIES (texto c ontendo valores no formato
“c have=valor”) de c onfiguração de mensagens e rótulos da
aplicação, para internacionalização (I18n), quanto para
c onfigurações do log4j e jBoss Seam.
o
A rquivos JAVASCRIPT que representam lógicas J avascript/Ajax,
para execução local nas máquinas dos c lientes.
o
A rquivos CSS que representam as peles, que dão aparência (cor,
fontes, etc.) à aplicação.
o
A rquivos de mídia (.GIF, .JPG, .PNG, etc.), utilizados para
dec oração geral da aplicação.
N a raiz do projeto s e enc ontram dois arquivos de c onfiguração
M aven fundamentais para a “c ompilação e c onstrução” de arquivos
WA R, J A R ou E AR:
o
pom.xml: arquivo de c onfiguração de módulo, existente para cada
projeto Eclipse com dependências de c ompilação direta do módulo.
O “pseudo source-folder webapp” merece um maior detalhamento, já que contém diversos diretórios
padrão Java EE e arquivos de configuração padrões:
Entendendo a Arquitetura de Desenvolvimento
Figura A 6.32. Organização do f older “webapp” do projet o principal “rhtutorial”.
Organização Interna do Folder webapp (Ex.: rhtutorial/src/mai n/we ba pp)
P ac ote P adrão
(D iretrizes J ava EE)
O bjetivo
1 . /M E TA -INF
É um folder padrão J ava, que deve c ons tar exatamente c om es te
nome e em maiús c ulas. C ontém os s eguintes arquivos:
o
2 . /res /c ss
*
M ANIFEST.MF: arquivo de configuração padrão J ava para possíveis
dec larações c om relação a um módulo executável (WAR, EAR ou JAR).
N ão é utilizado pelo jCompany, mas incluído s omente para
c onformidade com padrão.
É um folder padrão do jCompany (todos os prefixos e s ufixos ‘plc ’
indic am origem no jCompany) para c onter os s eguintes arquivos:
o
app.geral.css: Arquivo de CSS de arquitetura vazio, específico da
A plicação, devendo s er utilizado para sobreposições de estilos (lookand- feel) corporativos, preferencialmente definidos em arquivos CSS
em nível da empresa (Bridge).
o
app.c omuns.css: Arquivo auxiliar que c ontém a relação de arquivos
C SS necessários para Widgets e Plugins jQ uery em geral, de modo a
evitar que excesso de downloads HTTP. Este arquivo é melhor
explicado no capítulo 22, que fala sobre recursos de RIA.
P ode c onter também arquivos de mídia (.gif,.jpg,.png) que irão variar
em funç ão da “pele” escolhida (arquivos de mídia invariantes devem
fic ar em /plc/midia)
N ota: Aqui pressupomos que o desenvolvedor irá implementar
diversos projetos para uma empresa, reutilizando a mesma “pele”
(C SS) e “layout” (Facelets). Assim, definir estes arquivos inteiramente
em c ada aplicação seria redundância indesejável
3 . /res /midia***
É um folder padrão do jCompany para c onter os s eguintes arquivos:
o
*
A rquivos de mídia (.gif,.jpg,.png) que não variam em função da “pele”
es colhida (arquivos de mídia variantes devem ficar nos diretórios CSS,
tais c omo /plc/css/[pele])
É importante perc eber que o agrupamento de todos es tes recursos abaixo da pas ta “plc ” é propos ital e exc epcionalmente importante
para a performanc e das aplicações, já que todos es tes são recursos passiveis de s erem mantidos em c aching, no c liente (nos
N avegadores). P ara ac ionar es te excepcional rec urso de performanc e, o jCompany já traz pré- c onfigurado o filtro P lcClienteFilter no
web.xml, mapeado para todos os arquivos abaixo de “/plc ”. E s te é mais outro motivo para reforçar o us o des ta c onvenção, e agr upar
rec urs os desta mesma natureza, abaixo deste diretório.
Capítulo A4
E xemplos: logo e rodapés da empresa e imagens de destaque
N ota 1: O jCompany traz algumas imagens utilizadas na página de
login (login-logo-empresa.png). T odas devem s er modificadas (ou
s implesmente s obrepostas).
N ota 2: O logo da empresa, para login, topo e janela sobre, pode s er
mantida na camada “Bridge” para não ficar redundado em cada
projeto, em uma arquitetura mais c orporativa.
4 . /WE B - I NF/
É um folder padrão J ava E E, que deve c o ns tar exatamente c om es te
nome e em maiús c ulas, e deve c onter, em s ua raiz, arquivos de
c onfiguração diversos.
O template I NI padrão traz os s eguintes arquivos pré -configurados:
5 . /WE B - I NF/fcls
o
fac es-config.xml: Arquivo XML de c onfiguração do J ava Server Faces,
que c ontém regras de navegação (inter-URLs) e outras c onfigurações
de c ontrole.
o
beans.xml: Arquivo XML de configuração diversas da aplicação.
o
T rinidad-config.xml: Arquivo XML c om configurações para o Trinidad.
o
web.xml: Arquivo XML de configuração padrão J ava E E, que define
diversos parâmetros globais para a aplicação, de suma importância.
E s te arquivo s erá melhor discutido em tópico à parte.
É um folder padrão M VC, s ugerido para c onter páginas Facelets da
aplic ação que não devem s er ac essadas di retamente (fragmentos
inc ompletos de Facelets, utilizados nos leiautes).
Será princ ipalmente utilizado para c onter páginas de formulários do
negóc io, mas o template I NI traz algumas s ugestões:
6 . (raiz)
o
geralAcoesComplemento.xhtml: Página vazia de arquitetura,
dis ponível para c onter eventual novos botões de ação que aparecem
ao lado dos botões padrões do jCompany
o
geralRodapeComplemento.xhtml: P ágina vazia de arquitetura,
dis ponível para c onter eventual c omplementos à barra de rodapé
aparecendo ao lado das opções genericamente disponíveis no
jCompany.
o
geralMenu.xhtml: Arquivo X HML que define a estrutura de menu
es pecífica da aplicação de modo neutro e que portanto pode s er
renderizado de diversas formas (muitas já automatizadas pelo
jCompany)
C ontém a página Fac elets configurada no web.xml c om “inic ial” da
aplic ação, para a qual o us uário é redirec ionado após c hamar a
aplic ação s em explicitar uma U RL interna es pecífica (E x.:
http://loc alhost:8080/rhtutorial ”).
As classes Java definidas no projeto template padrão têm o seguinte propósito:
Classes Java da A rquitet ura pré-def inidas no projet o principal
C lasse
O bjetivo
1 . /js f/A ppMB
C lasse de arquitetura vazia para c onter possíveis
programaç ões genéricas de c ontrole, para toda
a aplic ação.
2 . /js f/A ppPhaseListener
C lasse de arquitetura vazia para c onter possíveis
programaç ões ativadas em eventos J SF
divers os. A pesar do s ufixo “L istener”, não é um
L is tener padrão Servlet 2 .5.
3 . /lis tener/AppHttpSessionListener
C lasse de arquitetura vazia para c onter possíveis
programaç ões ativadas no momento da c riaç ão
e/ou remoç ão de s essões HTTP no s ervidor
(importante notar que uma s es são é c riada “ao
primeiro c ontato de um novo us uário”, e não
após a s ua autentic ação).
4 . /lis tener/AppServletContextListener
C lasse de arquitetura vazia para c onter possíveis
programaç ões ativadas no momento da
inic ialização e/ou finalização da aplicação pelo
A pplication Server.
6 . /A ppU suarioPerfilService
C lasse de arquitetura vazia para c onter possíveis
programaç ões ativadas no momento “após
autentic ação” de us uários, c onhecidas c omo
Entendendo a Arquitetura de Desenvolvimento
lógic as de “us er profiling” (E x.: regis tros
es pec iais de s egurança em c aching de s essão,
rec uperação de dados de us uários utilizados na
aplic ação tais c omo email, nome c ompleto etc.)
Pela descrição que vimos até aqui, já devemos ter percebido que as classes incluídas nos projetos
gerados não contêm código procedimental em Java. Os poucos artefatos com conteúdo gerados são
alguns arquivos XHTML e mídias de exemplo para permitirem uma apresentação inicial de Web-Design
para a aplicação, a ser modificada para o contexto de cada empresa/aplicação.
Os verdadeiros propósitos do plugin de criação de projetos, e de outros que compõem o jCompany
Artifact Generator, são reforçar:
o
Gerência de Configuração: Pré-configuração da grande diversidade de frameworks, tecnologia
Java EE e bibliotecas utilizados, em uma linha de base íntegra e homologada no jCompany.
o
Padrões de Arquitetura: Pré-definição de locais apropriados para implementações específicas
(CSS, Javascript, botões de ação complementares, rodapé etc.), o que faz parte do trabalho de
definição de uma arquitetura extensível. Não fosse assim, ficar-se-ia ao sabor de preferências
momentâneas do implementador, o que dificultaria sobremaneira as manutenções e economia
de escala.
As classes Java presentes nos templates INI, portanto, estão vazias, visando apenas promover o uso de
padrões de programação da arquitetura.
Nota: Além disso, estas classes não são instanciadas pelo desenvolvedor, mas por algum esquema de
“Inversão de Controle” (IoC). O jCompany faz IoC através do padrão CDI (jCompany 6.x) ou via jBoss
Seam complementado por técnicas próprias (em versões 5.5.x ou inferiores). Além disso, reutiliza IoC
clássico para APIs como Listener e Filter, utilizando o web.xml para declarar estas implementações (até
que o uso de conteiners no padrão Java EE 6 se popularizem, de modo a possibilitar o uso de anotações).
Os diversos mecanismos de IoC utilizados ou implementados pelo jCompany serão discutidos em
detalhe nos capítulos de programação de regras de negócio , no módulo E.
- O projeto “model” (Serviços de Negócio e Persistência)
O projeto “model” contém pacotes para programações da camada Model do MVC2-P, incluindo
segmentação por pacotes de classes de implementações de Fachada (DP Faça de) e de classes da camada
de Persistence (assim como o projeto principal “rhtutorial” segmenta internamente as camadas Controller
e View ).
Do ponto de vista da “Visão Interna”, é a seguinte a organização padrão do projeto “rhtutorial_model”,
conforme definida no template INI:
Figura A 6.33. Organização interna do projet o model ”rhtutorial_model”.
Organização Interna do Projet o Model (Ex.: rhtutorial_model)
P ac ote P adrão
O bjetivo
1 . s rc /main/java
(Sourc e Folder)
C ontém arquivos c om c ódigo-fonte em linguagem J ava para c lasses
da c amada “M odel” da arquitetura MVC, organizados c om o s eguinte
padrão:
[br.]c om.[empres a].[projeto].modelo.[facade| model|persistence]
onde
[br.] é um prefixo opc ional, uma vez que o res tante do pac ote
c os tuma s er s uficiente para evitar c olisões de nomes .
Capítulo A4
[empres a] nome da organizaç ão
[projeto] nome do projeto
[fac ade| model|persistence] s ão originalmente s ubdivididos c om base
em s ubc amadas dentro do projeto:
2 . s rc /main/config
(Sourc e Folder)
o
fac ade: Pacote que encapsula classes de I mplementação dos
C ontratos de Fachada (DP Façade). As interfaces ficam no projeto
“c ommons”.
o
model: Pacote que encapsula classes de s erviço (Casos de Uso) da
aplicação.
o
pers istence: P acote que contém c lasses que acessam repositórios de
dados, tipicamente SGBD-Rs. Subdivide-se, em c onformidade c om a
tec nologia de implementação em “jpa”.
C ontém arquivos c om anotações J ava que representam “metadados”
do jCompany para a aplic ação, es pecificas para a c amada “M odel”
da arquitetura M VC, organizados c om o s eguinte padrão:
c om.powerlogic. jc ompany.config.[model| persistence].[app|xxx]
onde
[model| persistence] s egmenta metadados de c amada uma das
res pec tivas c amadas:
o
model: contém arquivo “package-info.java”, c om anotações de
c onfiguração para a c amada model.
o
pers istence: c ontém arquivo “package-info.java”, reunindo anotações
de c onfiguração para a c amada persistence.
[app| xxx] é uma s igla de três letras (app é padrão), que define um
módulo, des te modo diferenc iando anotações da c amada modelo
para o módulo princ ipal (app) e outros pos síveis (“pes” para módulo
P es soa etc .).
3 . s rc /main/resources
(P s eudo Source Folder)
C onfigurado c omo Source
folder no E c lipse para
melhorar vis ualização no
P ac kage E xplorer, muito
embora não c ontenha
c las ses J ava.
C ontém diretório padrão M ETA-INF para J ARs, nes te c aso c om
c onfigurações (opcionais) para E J Bs.
4 . s rc /test/java
(Sourc e Folder)
C ontém arquivos c om c ódigo-fonte em linguagem J ava para c lasses
de T es te do módulo, inc luindo testes de unidade para c amada
“M odel” da arquitetura M VC (c lasses loc ais do projeto).
A es trutura interna possui um pac ote “es pelho” ao pac ote principal
do módulo, de modo que uma determinada c lasse de tes te
c ompartilhe de visibilidade de mes mo “pac kage” da c lasse testada.
5 . (raiz) pom.xml
N a raiz do módulo s e enc ontra o arquivo M aven de c onfiguração para
“c ompilação e c onstrução” do arquivo J AR c orrespondente:
pom.xml: arquivo de c onfiguração de módulo, existente para c ada
projeto E c lipse, e c ontendo as dependências de c ompilação direta do
módulo.
As classes Java definidas no template INI para projetos “model” têm o seguinte propósito:
Classes Java da A rquitet ura pré-def inidas no projet o “model”
C lasse
O bjetivo
1 . /fac ade/AppFacadeImpl
C lasse de arquitetura vazia para c onter possíveis
es pec ializações de implementação ao c ontrato de
“M anutenç ão de C iclo de V ida e M anipulação de
A gregações”, mantido pelo jCompany.
- O projeto “commons” (Entidades e Contratos)
O projeto “commons” contém pacotes para programações das Entidades de Domínio e
Interfaces de Fachada (DP Façade), que definem contratos entre aplicações (Controller) e serviços
(Model). Além disso, pode conter classes de utilitários comuns que sejam necessárias em todas as
camadas MVC-P, deste modo evitando-se redundá-las.
Na “Visão de Módulos” veremos que as Entidades devem ser expostas a todas as camadas MVC -P mas
não podem depender de nenhuma delas. Deste modo, passam a configurar uma camada ortogonal e se
tornam a parte mais estável da arquitetura.
Entendendo a Arquitetura de Desenvolvimento
Por hora, vamos nos concentrar no entendimento da arquitetura interna deste projeto, conforme definido
no template INI:
Figura A 6.34 Organização interna do projet o modelo ”rhtutorial_commons”.
Organização Interna do Projet o Commons (Ex.: rhtutorial_commons)
P ac ote P adrão
O bjetivo
1 . s rc /main/java
(Sourc e Folder)
C ontém arquivos c om c ódigo-fonte em linguagem J ava para c lasses da
c amada “D omínio e C ontratos”, ortogonal a todas as c amadas da
arquitetura M VC e que c ontém artefatos c omuns a todas elas. O s
arquivos s ão organizados c om o s eguinte padrão:
[br.]c om.[empres a].[projeto].[entity |facade|commons]
onde
[br.] é um prefixo opc ional, uma vez que o res tante do pac ote c ostuma
s er s ufic iente para evitar c olisões de nomes .
[empres a] nome da organizaç ão
[projeto] nome do projeto
[entity | fac ade| c ommons] s egmentas os s eguintes tipos de c lasses:
2 . s rc /main/config
o
entity: Pacote que encapsula classes que representam conceitos de
negócio, chamadas “E ntidades de D omínio”
o
fac ade: Pacote que encapsula interfaces que definem o contrato de
fac hada (DP Façade). As classes de implementação ficam no projeto
“M odel”.
o
c ommons: Pacote que pode encapsular classes utilitárias de uso c omum
em todas as camadas MVC-P, para a aplicação (utilitários de interesse
inter-aplicações devem s er disponibilizados em módulo à parte).
C ontém arquivos c om anotações J ava que representam “metadados” do
jCompany para a aplic ação, es pecificas para a c amada “C ommons” da
arquitetura M VC, organizados c om o s eguinte padrão:
c om.powerlogic.jc ompany.c onfig.[domain|commons].[app| emp]
onde
[domain| c ommons] s egmenta metadados de c amada uma das
res pec tivas c amadas:
o
domain: contém arquivo “package-info.java”, c om anotações de
c onfiguração de domínio para a c amada commons.
o
pers istence: c ontém arquivo “package-info.java”, reunindo anotações de
c onfiguração para a c amada Persistence.
[app| xxx] é uma s igla de três letras (app é padrão), que define um
módulo, des te modo diferenc iando anotações da c amada model para o
módulo princ ipal (app) e outros pos síveis (“pes ” para módulo P essoa
etc .).
3 . s rc /main/resources
(P s eudo Source Folder)
C onfigurado c omo
Sourc e folder no E c lipse
para melhorar
C ontém diretório padrão M ETA-INF para J ARs, nes te c aso c om
c onfigurações de P ersistence J PA (pers istence.xml), e também o arquiv o
hibernate.c fg.xml.
E s tas declarações de P ersistence s ão idealmente mantidas no mes mo
Capítulo A4
vis ualização no P ackage
E xplorer, muito embora
não c ontenha c lasses
Java.
projeto das E ntidades, para maior c oesão, e não implic am em
dependênc ias ou ac oplamentos por s erem apenas c onfigurações
(metadados ).
4 . s rc /test/java
(Sourc e Folder)
C ontém arquivos c om c ódigo-fonte em linguagem J ava para c lasses de
T es te do módulo, c onsistindo de testes de unidade para c amada
“E ntidades, C ontratos e U tilitários C omuns” da arquitetura MVC (c lasses
pres entes locais do projeto).
A es trutura interna possui um pac ote “es pelho” ao pac ote principal do
módulo, de modo que uma determinada c lasse de tes te c ompartilhe de
vis ibilidade de mes mo “pac kage” da c lasse testada.
5 . (raiz) pom.xml
N a raiz do módulo s e enc ontra o arquivo M aven de c onfiguração para
“c ompilação e c onstrução” do arquivo J AR c orrespondente:
o
pom.xml: arquivo de c onfiguração de módulo, existente para cada projeto
E c lipse, e c ontendo as dependências de compilação direta do módulo.
As classes Java definidas no projeto template default para “commons” têm o seguinte propósito:
Classes Java da A rquitet ura pré-def inidas no projet o “commons”
C lasse
O bjetivo
1 . /c ommons /AppBaseContextVO
C lasse de arquitetura vazia para c onter possíveis
es pec ializações de valores de c ontexto da
aplic ação que prec isem s er transportados para a
c amada M odel (D P C ontext).
2 . / c ommons /A ppConstants
C lasse de arquitetura vazia para c onter possíveis
c ons tantes que tenham es copo c omum e m
várias c amadas MVC.
3 . / c ommons /A ppException
C lasse de arquitetura vazia para c onter possíveis
es pec ializações de P lcException, que é a exc eção
“mes tra” que enc aps ula (“wrapper”), exc eç ões
es pec íficas do negócio ou ines peradas.
4 . / c ommons /A ppUserProfileVO
C lasse de arquitetura vazia para c onter possíveis
atributos ac erca do perfil do us uário c orrente
(dados mantido em s es são pelo jCompany),
des te modo enc apsulando dados relacionados ao
us uário (c riado através do s erviço
A ppU suarioPerfilService).
N ota: E s tá no c ommons, obviamente, porque é
trans portada para c amada M odel, nos c ontratos
padrões do jCompany, para que lógic as de
negóc io “c onheçam” es tes dados.
5 . /entity/AppBaseEntity
C lasse de arquitetura vazia para c onter possíveis
anotaç ões de P ersistence c omuns a todas as
“E ntidades” no es c opo da aplicação. E la, por s ua
vez, herda propriedades c omuns de auditoria
“pauta mínima” (us uário e data/hora da última
alteraç ão), e vers ão (tratamento de c oncorrência
otimis ta), s ugeridas pela metodologia.
E ntidades devem herdar des ta c lasse, s e
des ejarem reus ar as definições ac ima.
6 . /fac ade/IAppFacade
I nterfac e de arquitetura vazia para c onter
pos s íveis cláusulas de es pecializações do
c ontrato de “M anutenção do C iclo de V i da e
M anipulação de A gregações” do jCompany.
N ota: N ão deve s er utilizada para definição de
c ontratos de negóc io es pecíficos que não tenham
relaç ão c om o c ontrato “mantido” pelo
jCompany. P ara tanto, deve- se c riar PO JI (P lan
O ld J ava I nterfaces) independe ntes.
U m aprendizado detalhado s obre elaboração de
c ontratos Façade do negóc io s erá obtido em
c apítulos s obre “P rogramação de Regras de
N egóc io no jCompany”.
Entendendo a Arquitetura de Desenvolvimento
Sumário
Neste capítulo, fizemos uma breve revisão sobre preceitos da Arquitetura de Software e discutimos a
“Visão Interna” e “Visão de Módulos” da arquitetura incorporada e proposta pelo jCompany, tomando
como base os três projetos gerados no capítulo anterior.
Ao expormos os critérios (“Rationale”) utilizados pela Po werlogic para absorção e concepção da
arquitetura sugerida, provemos as condições necessárias para ajustes específicos e especializações
corporativas que se façam necessários.
No próximo capítulo iremos sair da Arquitetura de Software para ingressar na Metodologia de Construção
Java EE incorporada no jCompany, começando por entender seus Casos de Uso Padrão e a aplicação
que iremos desenvolver mais em detalhes.
O retorno a este capítulo, após uma maior experimentação prática no jCompany, é altamente
recomendável.