de Desenvolvimento Capítulo Introdução Estudo de Evolução de Arquiteturas de Software Java EE - Reúso de Arquitetura de Software

Transcrição

1 A6Entendend a Arquitetura de Desenvlviment Capítul 4 Intrduçã - Reús de Arquitetura de Sftware O jcmpany Develper Suite pde ser cmpreendid cm uma sluçã de reús em nível arquitetural. E nã apenas para reús de camadas de base de arquitetura para as aplicações desenvlvidas, mas também para ambiente de desenvlviment (IDE) e de Testes de Unidade. Estas sluções arquiteturais de base sã prvidas, respectivamente, pels móduls jcmpany FS Framewrk, jcmpany IDE e jcmpany Test fr Develper. Mas qual seria a diferença deste tip de reús em cmparaçã a reús mais pntual, digams, em nível de uma classe u pequen grup de clabraçã de classes? O reús arquitetural pssibilita reús de estratégias cmplexas englband desde reús de clabrações extensas de framewrks, smada à prduçã assistida de especializações precnizadas pr métds e padrões delineads pela arquitetura. Este tip de reús é de mais alt nível que s demais. Digams, uma integraçã de várias estratégias de reús pntuais, que prduz um resultad de valr visível para cliente (Ex.: um Cas de Us ptencial) e nã sluções parciais intermediárias. Em utras palavras: muit embra sejam imprtantes as táticas de reús em nível de classe u via padrões de prjet (Design Patterns), reús arquitetural é de nível mais estratégic, fundamental para quem deseja ganhs de prdutividade e qualidade em ambientes cm desenvlviments em larga escala. Estes ganhs equivalem as que se cnsegue cnstruind uma nva casa a partir de cmpnentes maires, préfabricads, em cmparaçã a se cmeçar selecinand madeira para fabricar prtas, pr exempl. Apesar de nã existir uma única sluçã de arquitetura perfeitamente adequada a tdas as situações, as diversas dimensões de arquitetura pré-implementadas n jcmpany sã custmizáveis... Para iss vingar na prática, prém, trna-se necessári um entendiment mais prfund das suas implementações, inclusive das mtivações fundamentais (Ratinale) que guiaram a Pwerlgic em sua prpsta. Este capítul inicia esta discussã. Estud de Evluçã de Arquiteturas de Sftware Java EE - O que é Arquitetura de Sftware? Já discutims sbre a imprtância da arquitetura n Capitul 1, mas nã pressupms que tds tenham cnheciments balizads sbre assunt. Pr iss, vams rever algumas definições fundamentais: Uma Arquitetura de Sftware para um sistema é a que define a estruturaçã deste sistema, que cmpreende seus Elements, a Relaçã entre eles e as Prpriedades externamente visíveis destes Elements e Relações. Ref. A6.1. [TS-4619 JavaOne 2006] Arquitetura de Sftware é a decmpsiçã d prblema de uma maneira que permita a desenvlviment eficientemente reslvê-l, cnsiderand restrições (...) Ref. A6.2. [Jhn Klein- Architecture and Design ] A arquitetura de qualquer aplicaçã deve a mens incluir (quand nã se basear em) cnsiderações de perfrmance. A arquitetura de uma aplicaçã crprativa deve cnsiderar s Cicls de Vida de Objets, assim cm a sua frma de us Ref. A6.3. [Haines, Steven 2006] Nã há muita cntrvérsia sbre a imprtância decisiva que uma ba Arquitetura de Sftware pde ter em prcess de desenvlviment de sftware em geral. Também há um grande recnheciment, pr

2 Capítul A4 parte de especialistas, cm relaçã a papel central que s framewrks assumem nesta questã. Prém, muitas empresas nã chegam a experimentar s resultads prmetids nesta área. Para nã crrerms este risc e bterms s melhres resultads, nssa prpsta smará reús de uma arquitetura abrangente cm padrões de alt nível e autmaçã de atividades, rquestradas pr Cheat-Sheets d Eclipse. Nssa arquitetura também será ajustada para a eficiência de prcessament, um utr pnt cmumente negligenciad. É um err imaginar a arquitetura apenas d pnt de vista estrutural e teóric. A arquitetura influi decisivamente em perfrmance e devem ser cnsiderads s cmprtaments dinâmic e prátic da aplicaçã, além ds fatres usabilidade, flexibilidade e utras dimensões cncrrentes, em nssa prblemática. Nã se satisfaça cm uma Arquitetura de Sftware rasa. Mesm uma arquitetura incipiente pderá prduzir um bcad de dcuments e diagramas impressinantes, mas trará resultads medícres, quand algum. Uma arquitetura para perfil típic de prjets crprativs, pr exempl, deve definir, em detalhes, dependências entre prjets e móduls, pactes dentr de prjets, artefats, events de prgramaçã de alt nível e, finalmente, trazer um bm númer de generalizações e padrões que cnduzam a um resultad visível para negóci, rapidamente. Ns próxims tópics, discutirems níveis de maturidade de arquiteturas de sftware. - Arquitetura de Sftware Invisível Em nssa experiência nã é incmum encntrar empresas desenvlvend em Java EE em um estági nde ainda nã há nenhuma arquitetura realmente visível para s implementadres. Neste nível de maturidade, que se chama de arquitetura sã alguns dcuments, traçand diretrizes cnceituais para us de MVC, este u aquele framewrk u até determinads Design Patterns. Este cenári primitiv é, clar, melhr que nada. Mas insuficiente para se perceber qualquer ganh cnsiderável nesta área um estági a qual chamams de Arquitetura de Sftware Invisível, ilustrad na Figura A6.1. Figura A6.1. Arquitetura de sftware Invisível. Neste estági, as lacunas estã vazias entre a platafrma de infra-estrutura Java EE (1) e as aplicações de negóci (5). Pr este mtiv, um enrme ptencial para errs está à espreita ds desenvlvedres, que ficam às vltas cm prgramações repetitivas de códig, que deveriam estar fatradas em nível arquitetural. Nã há cm evitar. Para uma arquitetura real, será necessári que s arquitets passem d dmíni ds cnceits para a experiência de us nas tecnlgias, suas pssíveis cmbinações, deficiências e valres, além de prváveis variações de us. Mntar uma arquitetura madura demanda um temp que nã pde ser facilmente abreviad especialmente uma que envlva altíssimas taxas de reús, partind de sluções best-f-breed Java EE Open Surce. Nesta filsifia, que é a adtada pel jcmpany, a recmendaçã é esclher peças melhres em seu segment. Algumas dezenas de tecnlgias, prjets e cmpnentes OSS deverã ser

3 Entendend a Arquitetura de Desenvlviment entendids, selecinads, especializads e integrads, muits deles em áreas de cnheciment cm razável distinçã das demais. Pr exempl, a camada Visã d MVC envlve a rquestraçã de diversas tecnlgias cmplexas, tais cm Facelets (XHTML)/HTML, Javascript, CSS, Ajax, técnicas de gestã de leiautes, etc., nenhuma delas de dmíni específic d mund Java u OO, de dmíni ds Arquitets de Sftware. O resultad, na prática, é uma quase ausência de arquitetura para a camada Visã, delegada para tratament superficial pels Web-Designers. Refinar uma ba arquitetura para a camada Cntrller também tem seus desafis, já que esta é bem mais cmplexa, tecnlgicamente, d que as camadas subsequentes de Mdel/Dmíni u Persistence. É uma utra camada nde nível de sluções de arquitetura cstuma ser muit ras, basicamente cnsistind de hmlgaçã de algum framewrk de base "em seu estági brut". As camadas de Mdel, Dmíni e Persistence, pr serem mais puramente ligadas a linguagem Java e às regras de negóci cstumam receber 90% da atençã ns trabalhs típics de Arquitetura de Sftware, a mens em seu estági inicial. Prém, a lng d temp se fará necessári um esfrç nas demais camadas, que exigirã um cnsiderável aprfundament tecnlógic. - Arquitetura de Sftware Anêmica Em um estági um puc mais adiantad, trabalh acima já terá se iniciad, de md que a arquitetura já pde ser vista na frma de sftware, cncreta, cm uma sluçã de base crprativa a ser reutilizada. Esta sluçã é frequentemente cmpsta de uma pilha (stack) de prduts e framewrk de base Open Surce integrads, nrmalmente definida após alguns meses iniciais de prspecçã, seleçã e integraçã leve. Digams, de uma dúzia de prduts de base, cmplementads pr dcuments de guia em nível mais detalhad. Ela está representada pela camada (2) na figura A4.2. Mas neste nível de maturidade, cm n anterir, ainda há uma grande migraçã de prblemas nã funcinais para a camada de Cre Business (5) e prgramadres d negóci lidand indevidamente cm: Códigs MVC burrs (de->para, fachadas artificiais); Gerenciament de transações manuais; Instanciações de bjets manuais; Códigs Java para inclusã, alteraçã, exclusã (CRUD); Elabraçã de frmuláris d zer ; Gestã de leiautes manual; Etc. Há um avanç perceptível cm relaçã à arquitetura meramente cnceitual d iníci, mas neste nível a arquitetura ainda é rasa a pnt de nã eliminar mesm variabilidades básicas indesejáveis. A distância entre a realidade e a prmessa de retrn de ambientes Orientads a Objet cntinua imensa - pr ist batizams a este estági de Arquitetura de Sftware Anêmica. É um estági basicamente caracterizad pr uma integraçã puc prfunda e abrangente entre um númer também insuficiente de prduts Open Surce de base, cnfrme ilustra a Figura A6.2. Nte que as camadas sb respnsabilidade da empresa sã representadas na mesma clraçã da camada de cre business.

4 Capítul A4 Figura A6.2. Arquitetura de Sftware Anêmica. - Arquitetura de Sftware Intermediária Neste estági de maturidade, já encntrams evidência clara de uma primeira Arquitetura de Sftware Crprativa em versã razável, integrand um bm númer de insums (framewrks e utilitáris) Open Surce cm um esfrç suficiente na prduçã de padrões de alt nível, nas diversas camadas MVC. Figura A6.3. Arquitetura de Sftware Crprativa em nível intermediári. Mas para ser de nível intermediári, realisticamente, esta arquitetura irá requerer uma cmprvaçã de us satisfatóri em prduçã seguid das inevitáveis refatrações - pr pel mens dis ans. É um períd mínim, após a cnstruçã da primeira versã, durante qual uma equipe de perfil abrangente * cnseguirá evluir para este nível de maturidade. * Cmpsta de Arquitet de Sftware, Analistas de Negóci, Web-Designers, Perits nas Tecnlgias, Dcumentadres, Analistas de Teste etc.

5 Entendend a Arquitetura de Desenvlviment A partir deste pnt, n entant, este mdel cmeça a apresentar suas limitações, especialmente se a implementaçã arquitetural fr cncebida e desenvlvida ttalmente pr equipe interna: Desvi de Fc: Uma equipe de valr estará dedicand ba parte de seu temp em atividades ttalmente fra d fc d negóci, já que grande parte da sluçã arquitetural nã é diferencial para seu negóci. Aument de Cust: Mesm que haja uma cntrataçã de terceirs para a manutençã desta camada, perdem-se s ganhs de escala pssíveis a partir d reús da parcela cmmdity da arquitetura. Prblemas de Gestã: Nrmalmente, s prblemas se agravam na medida em que cmeça a existir uma base instalada da arquitetura em prduçã. Na fase de manutençã, requisits de Gerência de Cnfiguraçã passam a cnsumir uma grande parcela de esfrç da equipe interna para manter rams de evluçã em paralel cm rams cmpatíveis. A partir daí, nã é incmum que entusiasm técnic das primeiras fases dê lugar a turn-vers u queda cnsiderável de prdutividade. A percepçã mais cmum é de que há uma dificuldade de rdem prática para que esta sluçã familiar evlua para próxim pass. Na medida em que as pressões de negóci sbre aplicações implantadas prevalecem cm priridade, cm haverá de ser, há uma tendência à estagnaçã u lentidã para a incrpraçã de invações, med de refrmulações, etc. - Arquitetura de Sftware Madura D nss pnt de vista, uma primeira cnfiguraçã de arquitetura rica e abrangente suficiente para ferecer s retrns esperads de um ambiente OO está ilustrada na Figura A6.4. Figura A6.4. Arquitetura de Sftware Crprativa cm alt nível de maturidade. Neste estági, as precupações de nível arquitetural que nã sejam abslutamente dependentes d cntext específic da empresa sã ttalmente desacpladas de precupações de natureza cmum u cmmdity. Este é primeir mdel que ferece um imprtante racicíni de negócis: a ptencial terceirizaçã das camadas arquiteturais 2 e 3, hrizntais, de frma a pssibilitar a cncentraçã da rganizaçã nas camadas 4 e 5. De fat, smente as duas últimas têm relevância para ambiente específic de TI e verticais de negóci. Cm esta pssibilidade, aumenta-se nã smente fc n negóci. Diminui-se cust e herda-se qualidade e maturidade, abreviand-se lngs ans e um grande númer de prblemas. - Arquitetura de Sftware Prvida pel jcmpany FS Framewrk Se tmarms cm base smente a prpsta d módul jcmpany FS Framewrk, que prvê uma sluçã arquitetural para as aplicações desenvlvidas, verems cm ela pretende apiar mdel anterir, ferecend ganhs nas três camadas arquiteturais:

6 Capítul A4 Figura A6.5. Arquitetura em camadas de uma aplicaçã Java EE cm jcmpany Full Stack Framewrk. O api a prblema arquitetural d jcmpany FS Framewrk se dá de frma diferente, em cada camada da arquitetura: (2) Reduçã d trabalh de integraçã e pré-cnfiguraçã da camada de reús Open Surce. Cm iss, a empresa se liberta de manter partes de prspecçã (P&D), integraçã, especializaçã, dcumentaçã de integraçã, atualizaçã, cntrle de versões e gerência de cnfiguraçã para estes insums. (3) Implementaçã cmpleta e madura para a camada cmmdity, baseada em Design Patterns de mercad. Cm iss, a empresa se liberta de cnceber, manter e evluir a parcela hrizntal da arquitetura de sftware e de amadurecê-la internamente. (4) Sluçã de base para a criaçã da camada específica da empresa, chamada camada Bridge. Deste md, arquitets da empresa pdem imediatamente cdificar suas generalidades e especializações de última milha, sbrepnd u especializand artefats da camada (c). Este é um espaç cncret que pssibilita a criatividade, custmizaçã e generalizaçã que dependem d cntext da empresa (segurança, web-design etc.) - Outras Sluções Arquiteturais d jcmpany Develper Suite Mas é imprtante ntar que, além d jcmpany FS Framewrk, s móduls jcmpany IDE e jcmpany Test fr Develper também trazem sluções arquiteturais para utras dimensões d prcess de desenvlviment de sftware: ferramental/ambiente de api à prdutividade e sluções de base para Testes de Unidade, respectivamente. Estas arquiteturas também pdem ser expandidas e fram descritas n capítul 1, mas estã reprduzidas nas Figura A6.6 e Figura A6.7, para cnveniência:

7 Entendend a Arquitetura de Desenvlviment Figura A6.6. Arquitetura de Sftware d Ambiente de Desenvlviment (IDE). Figura A6.7. Arquitetura de Sftware para desenvlviment de Testes de Unidade. - A Síndrme d NIH (Nt Invented Here) Apesar ds ganhs óbvis advinds d reús de arquitetura, um entrave a esta inexrável evluçã pde estar n própri crp técnic - pr mais paradxal que pareça. Um indivídu cm interesse e frmaçã em tecnlgia, quand cnfrntad cm um racicíni de negócis, pde falhar em identificar cmmdities de sftware, falhand em prtunidades de terceirizaçã que sã chaves para negóci de sua empresa. Uma atitude sintmática destes cass, pr parte de um arquitet u desenvlvedr, é rtular arquiteturas (nunca as suas próprias!) de camisas de frça, pr exempl *. Td reús exige esfrç de cmpreensã e adesã a que se deseja reutilizar, em um primeir mment, e deve pssibilitar diferenciações e flexibilidade para ganhs em níveis mais alts. Iss vale para reús de arquitetura, de bjets u de cmpnentes. - Aprendend a Reusar Arquitetura Send, prtant, reús em nível de arquitetura a primeira arma de prdutividade e qualidade de ambientes Orientads a Objets, será essencial adquirirms cnheciment nesta área, para s próxims níveis. * Sã que Rd Jhsn, criadr d Spring, chama de Own Career Driven Architects [Jhnsn, Rd 2004] - indivídus que nã cmpreendem a imprtância, para sua empresa, de rientarem a sua criatividadde para camadas de negóci. É a insistência em nã reusar, pel desafi (u interesse) pessal de fazer.

8 Capítul A4 Neste capítul, recapitularems brevemente alguns fundaments n camp da arquitetura de sftware para nivelament. Nã há pretensã e nem pssibilidade de esgtarms assunt neste espaç, mas s pnts para discussã aqui selecinads prcuram se cncentrar em carências frequentemente encntradas em nss mercad. Revisã de Fundaments - Cm Representarems a Arquitetura? Um sistema de sftware crprativ é cmpst de muitas estruturas distintas, cm relacinaments cmplexs. Prtant, sã necessárias diversas visões para representar cada uma delas [TS-4619 JavaOne 2006]. Neste livr, irems discutir as seguintes visões arquiteturais: Visã Geral (General View): Utilizarems a Visã Geral para uma primeira representaçã (macr) das grandes camadas (Layers) e Blcs (Tiers) da arquitetura. Visã de Móduls (Mdule View): Utilizarems a Visã de Móduls para representar cm estã agrupads s cnjunts de artefats em temp de desenvlviment e cm eles se relacinam entre si, em váris níveis de detalhament. Visã Interna (Internal View): Utilizarems a Visã Interna para representar cm estã rganizads s prjets de desenvlviment d pnt de vista de sua estruturaçã interna. É um tip de visã de micr-arquitetura, cnsiderand rganizaçã ds pactes e artefats padrões definids. Visã Cmprtamental (Behavir View): Utilizarems a Visã Cmprtamental para representar cm as categrias de classes clabram entre si em algumas anatmias de requisiçã MVC-P típicas. Visã de Execuçã (Runtime View): Utilizarems a Visã de Execuçã para representar cm pdems embalar e liberar s cnjunts de cmpnentes em temp de execuçã, distribuind-s u mantend-s em c-habitaçã, e cm eles se relacinam nestas pssíveis variações de infra-estrutura. Visã da Interface cm Usuári (GUI View): Utilizarems a Visã de Interface cm Usuári para representar s padrões de leiautes, frmuláris e cmpnentes dispníveis, cm estã rganizads e interaçã entre si. Ela nã cntempla questões de usabilidade, discutidas fra d âmbit da arquitetura. Além das representações principais para as visões acima, detalhament da arquitetura requer dcuments mais extenss que, pr mtivs didátics, nã sã dispnibilizads neste livr. Eles estã dispníveis na dcumentaçã d módul jcmpany Patterns & Methds, cedid cm a licença crprativa d jcmpany. Neste capítul, apresentarems as três primeiras visões: "Geral", "de Móduls" e Interna. - Arquitetura em Camadas (Layers) O agrupament de classes em móduls, que pr sua vez se rganizam em camadas sbrepstas, um sbre utr, é uma das metáfras mais cmuns em arquiteturas de sftware. A estes móduls, rganizads rigrsamente desta frma, chamams Layers (Camadas). É um paradigma que define dependências de uma maneira simples (a camada de sftware de cima depende da de baix ), mas que ns ferece um padrã para realizar arranjs arquiteturais bastante cmplexs, mas que ainda assim cnseguims cmpreender que é, aliás, um ds grandes bjetivs de uma arquitetura OO. O MVC, em si, é uma arquitetura em camadas cuj intuit principal é separar implementações relacinadas à interaçã cm usuári (precupações da aplicaçã em si) das implementações que representam as regras de negóci fundamentais d negóci. Para tant, define uma camada cntrladra, que desacpla as camadas de Interface cm Usuári (View) da de negóci (Mdel), e também encapsula algum tip de implementaçã em seu nível de intermediaçã. Na prática, algumas dificuldades que percebems n us d MVC em Java EE sã: Errs fundamentais de acplaments indevids entre as camadas; Us burcrátic, cncebid para lidar cm prblemas intrínsecs d EJB 2.x, sem cnsiderar evluções tecnlógicas tais cm Java EE 5 e 6 e EJB 3.0 e 3.1; Puc investiment em generalizações OO, levand à plriferaçã desnecessária de grande quantidade de códig pró-frma (repetitiv), de cmunicaçã entre as camadas. Irems discutir cnceits nestas três áreas, a cmeçar pela questã das camadas:

9 Entendend a Arquitetura de Desenvlviment Organizaçã cm baix acplament em Layer (Camadas Sbrepstas): Uma rganizaçã em Layer pssui camadas sbrepstas uma sbre a utra, de md que uma camada smente dependa da imediatamente inferir. Pr ter mens dependências, cada camada tende a ser mais estável e flexível. Esta rganizaçã é também cnhecida didaticamente cm bl de festa, em analgia às diferentes camadas de rechei que cmpõem este tip de bl: Figura A6.8. Organizaçã em camadas. Organizaçã em Referência Circular: Muitas vezes uma representaçã errada u pbremente simplificada pde ns cnduzir a cnclusões perigsas nesta área. Pr exempl, a representaçã à esquerda da Figura A6.9 representa móduls que nã estã rganizads em camadas, mas que, devid à missã das setas de dependência, sugere esta rganizaçã. Olhand a revisã à direita, real, percebems que se trata de uma arquitetura muit mais cmplexa que a sugerida à esquerda. Neste cas, inclusive mais instável, pis sfre de um mal cnhecid cm referência circular. Este é um prblema que gera alt acplament e deve ser evitad em tdas as camadas de abstraçã de um sftware. Figura A6.9. Diagramaçã excessivamente simplificada de arquitetura. Organizaçã de Tier (Blcs), cm diagramaçã simplificada: Mas a rganizaçã em camadas nã é a única utilizada em sftware e nem sempre é a mais recmendável. Pde-se rganizar uma aplicaçã em "blcs u móduls" (Tiers) que nã sã "islantes" cm as camadas, mas ainda assim relacinam entre si de md a manter baixas as dependências. Obs.: Mesm nestes cass, muitas vezes a diagramaçã em camadas é utilizada, para simplificar diagrama em si, u enfatizar um cmprtament. Pr exempl, a diagramaçã da esquerda, na Figura A6.10, é mais simples; mas quand é exigid um rigr técnic, pde dar margem a cnfusã. Repare a versã mais exata à direita, exibind claramente que C dependente diretamente de A e B.

10 Capítul A4 Figura A6.10. Melhr diagramaçã de camadas. Camadas paralelas e rtgnais: Cm as rganizações de sftware sã bem mais cmplexas d que pde sustentar a metáfra d bl de festa, n mund real nós irems ns deparar cm cmbinações mais sfisticadas das várias abrdagens pssíveis, u várias dimensões de camadas. Nas Figura A6.11 e Figura A6.12 vems duas cmbinações em camadas reais que prduzem arquiteturas estáveis, crretamente diagramadas, e inclusive muit cmuns em sftware. Figura A6.11. Camadas paralelas. Figura A6.12. Duas camadas transversais u rtgnais. Mesm em uma arquitetura mais elabrada, cm n cas da Figura A6.12, é imprtante perceberms que racicíni fundamental de minimizar dependências através d us de camadas cntinua presente. Mas quais sã s critéris para definirms nssas camadas? O que cada camada irá cnter e cm dependerã umas das utras? Bm, estas respstas serã btidas a partir de um racicíni OO que deverá seguir inicialmente s velhs princípis de baix acplament e alta cesã. - Baix Acplament (Mens dependências, mais estabilidade) O baix acplament (u diminuiçã das dependências entre elements) deve ser almejad em estruturas de sftware em tds s seus níveis de abstraçã:

11 Entendend a Arquitetura de Desenvlviment Estruturas arquiteturais cm mínim de dependências (Na prática, cm mair us pssível de camadas ); Aplicações u móduls cm mínim de dependências (referências externas) (Na prática, prjets cm menr tamanh pssível de Class Path ); Pactes cm mínim de referências externas (Na prática, classes cm menr númer pssível de imprts ); Classes cm menr númer de referências externas pssíveis (Na prática, pactes cm mínim de classes pssível). Na implementaçã, classes que pssuem mens dependências tendem a ser mais simples de se cmpreender e mais estáveis, mens sensíveis a turbulências externas. Classes de camada Cntrller, pr exempl, tendem a pssuir mais dependências, tais cm interfaces de Servlet e de framewrks cm JSF. Tendem, prtant, a ter mais imprts que classes da camada Mdel u Dmíni e a serem mais instáveis (Pr iss, dentre utrs mtivs, nã sã bas candidatas para cnterem implementações imprtantes d negóci). Mas cm será que iss se manifesta realmente, na prática? Vams ilustrar cm pequen episódi real. Certa vez, uma cntribuiçã a um release menr d Tmcat 5.x intrduziu a exigência de declaraçã implements Serializable para tds s bjets que fssem mantids em sessã (a intençã da equipe d Tmcat era atender a um aprimrament de suprte a Clusters). As únicas classes que realizavam registr em sessã eram, naturalmente, as que pssuíam acess (dependência) a interfaces de Servlet. Apesar de ser uma mudança trivial ns bjets (uma simples declaraçã), em várias situações de migraçã para Tmcat 5.x, em td mund, algumas classes de cntrle escapavam à revisã e cancelavam em prduçã, manifestand a instabilidade prvcada pr esta dependência. É um típic prblema prduzid em camadas mais baixas da arquitetura que nã acntece nas superires (de negóci, pr exempl), graças à rganizaçã em camadas d MVC. - Alta Cesã (Melhr encapsulament, mair reús) Sb utr ângul, querems também que estruturas, ns seus diverss níveis de abstraçã, se mantenham especializadas, encapsuland implementações de cmprtaments de mesma afinidade e se mantend tã simples quant pssível em trn de um bjetiv cmum. Em temp de prgramaçã, métds que implementam mais de uma funcinalidade tendem a ser mais cnfuss de se entender, manter e reutilizar. O mesm crre cm classes que agrupam blcs de funcinalidade distints, e assim pr diante. Pela nssa experiência, s maires "crimes de baixa cesã crrem ns métds de partida, que iniciam a respsta a um event extern. Exempls sã métd dget de um Servlet u cntextinitialized em uma implementaçã de ServletCntextListener, u um execute de um DP Cmmand, utilizad em um framewrk qualquer. Nestes pnts da arquitetura, nã é difícil encntrarms verdadeirs prgramas COBOL, em sintaxe Java! - Fatraçã de Códig (Mens redundâncias, mais eficácia) A fatraçã de códig cnsiste na identificaçã de códigs redundantes u muit similares em diferentes artefats, extraçã da parte cmum deste códig para um nv artefat independente, e revisã ds riginais para reusarem códig extraíd clcad em evidência. O bjetiv d arquitet, neste quesit, é buscar pr códigs pró-frma (biler plate) recrrentes, vulgarmente cnhecids cm códig burr e aplicar seus cnheciments de arquitetura de sftware e OO para eliminá-ls, pssivelmente prmvend-s para framewrks u utilitáris. Fatraçã de códig pró-frma é, de lnge, uma das questões da arquitetura que mais afetam a prdutividade e um ds bjetivs principais de framewrks de integraçã! Uma arquitetura nde sã admitidas grandes quantidades de códig burr, pr limitações de temp u de cnheciments mais aprfundads de OO e Java, fracassará a mens parcialmente. Se nã na primeira versã da aplicaçã, nas fases seguintes, cm as insustentáveis manutenções. - Refatraçã de Códig (Fatraçã cntínua) A melhr escrita é a reescrita (...). Td bm escritr sabe dist, e ist é verdadeir para sftware também Ref. A6.4. Paul Graham, citand E. B. White, em Hackers and Painters [Graham, Paul 2004]. Pág. 212 Mais recentemente, a fatraçã de códig deu lugar a uma sucessra: a refatraçã de códig (Refactring).

12 Capítul A4 Bastante discutida pr autres diverss cm destaque para Kent Beck e Martin Fwler [Fwler, Martin 2004] e autmatizada até cert pnt em IDEs tais cm Eclipse, esta mudança de ênfase para a refatraçã faz sentid na medida em que admitims a dificuldade de se prduzir códigs bem fatrads, de saída. A verdade que hje cnhecems é que, a cntrári d que alguns metdlgistas eminentemente teórics apregam, dificilmente se btém uma ba arquitetura na sua primeira versã. Especialistas nas tecnlgias e prcesss de Especificaçã (CASE UML, Ferramentas MDA etc.), mas que puc u nada cnhecem das tecnlgias e prcesss de Cnstruçã, terã ainda mais dificuldade neste bjetiv. Prtant, será prudente partir de preceits arquiteturais que visem facilitar a refatraçã u refrmulaçã de códigs de uma frma geral, cm a prduçã d mínim de instabilidade pssível. Uma ba arquitetura é btida de explrações práticas seguidas de refatrações frequentes, prtunidades que smente sã bem aprveitadas pr arquitets de sftware hands-n, que se atrevem a pr a mã na massa. - Arquitetura de Sftware prpsta n jcmpany O estad atual da arquitetura prpsta n jcmpany é frut de uma ba amstra de prjets reais, cm fases de refatraçã decisivas baseadas em prblemas e sugestões reais de clientes. Apesar de nã ser perfeitamente ajustada para prblemas de A até Z, cntém sluções para um mínim denminadr cmum que cbre um grande interval de prblemas cm sluções generalizáveis. N estági atual da arquitetura d jcmpany, pr exempl, nã é mais requerida nem uma única linha de códig Java, em nenhuma das camadas d MVC, para se implementar Manutenções de Cicl de Vida de Objets (incluir, alterar, excluir e cnsultar). Mesm quand lidams cm agregações de bjets cmplexas, envlvend cinc, dez u até vinte classes, ttal de linhas de prgramaçã prcedimental MVC para se bter um resultad cm qualidade de prduçã n jcmpany tende a zer! Manutenções de bjets em sua frma básica sã perações cmmdity, candidatas primárias à fatraçã de códig em qualquer linguagem de prgramaçã, especialmente em linguagens OO tais cm Java, e nã deveriam ser reslvidas primariamente cm geraçã de códig - rapidez que nã se preserva nas manutenções. Mas, ind além destas perações de manutençã de cicl de vida, jcmpany generaliza pr inteir dezenas de utras prgramações sfisticadas e recrrentes em sistemas crprativs, tais cm clnagem de dcuments, assistentes, leiaute dinâmic para impressã, explradres de dads (treeview), exprtaçã de dads, e muitas utras. Tdas elas generalizações que preveem espaç para especializações em nível crprativ u em nível de Cas de Us, respeitand a arquitetura MVC. Irems experimentar estas prmessas na prática, n próxim módul. Neste capítul, vams apresentar a "Visã Geral", Visã de Móduls e Visã Interna da arquitetura de sftware prpsta pel jcmpany. Visã Geral - Grandes Camadas e Blcs da Arquitetura d Framewrk - Visã Geral da Arquitetura d jcmpany FS Framewrk Já apresentams uma visã geral de tda a sluçã jcmpany Develper Suite, n capítul 1. Irems, na pauta atual, smente aprimrar a representaçã da arquitetura d framewrk jcmpany FS Framewrk, que representa a dimensã da sluçã de mair interesse pr parte de Arquitets de Sftware, já que inclui s cmpnentes OO reutilizads e mntads juntamente cm as aplicações. A representaçã inicialmente apresentada n capítul 1 está repetida na Figura A6.13, para cnveniência. Os númers de 1 até 4 representam dependências existentes para reús, desde a infra-estrutura, passand pels serviçs d Applicatin Server, biblitecas, framewrks de base, framewrk de integraçã e camada Bridge.

13 Entendend a Arquitetura de Desenvlviment Figura A6.13. Visã Geral inicial da arquitetura d jcmpany FS Framewrk. Mas, mesm send macr, esta representaçã é muit simplória para estuds arquiteturais. Ist prque nem a camada 3, d jcmpany (Arquitetura Reutilizada), nem a camada 4, Bridge (Arquitetura Específica), funcinam cm Layer, td temp, cm diagrama pde sugerir. Excet ns percentuais de requisits nde s Cass de Us Padrões sã suficientes, desenvlvedr pderá (e ist será desejável) acessar a camada 2 (JBss Seam, Tiles/Facelets, JPA/Hibernate, etc.) diretamente u, mais raramente, a camada 1, em nível d Applicatin Server u JVM. Prtant, diagrama abaix é mais realístic tecnicamente faland d que anterir. Figura A6.14. Visã Geral da Arquitetura d jcmpany FS Framewrk - Aprimrada. #1. Nas parcelas de requisits de Cass de Us centrads em dads, tant jcmpany FS Framewrk quant a cmplementaçã Bridge praticamente islam a aplicaçã das camadas de baix, atuand cm camadas (Layers). É imprtante ntar as setas tracejadas de dependência, indicand que estas "camadas" cmunicam entre si para ferecer um resultad MVC cmpletamente generalizad. #2. Em requisits que fgem u suplementam s suprtads pels padrões, acess pde ser diret à camada de framewrks de base. Deste md, a arquitetura nã restringe; pssibilita a desenvlvedr elabrar quaisquer sluções que sejam cnvenientes, para cada cas. Em quant pr cent ds cass jcmpany FS Framewrk e a Bridge funcinarã cm camadas? Bm, iss depende da natureza ds requisits de cada prjet. Em um estud de ROI (Retrn sbre

14 Capítul A4 Investiment) elabrad pela Pwerlgic, a trta apresentada na Figura A6.15 é tmada cm base, para um prjet crprativ típic. Figura A6.15. Segmentaçã típica de requisits de aplicaçã crprativa. Assim, em 40% ds cass, em média, espera-se que jcmpany FS Framewrk atue cm uma camada, evitand cntat diret de códigs de negóci cm framewrks de base. Ns demais segments de requisits, framewrk irá cntribuir prvend serviçs de IC, DI, AOP para gerência de transações, leiautes etc.; tds bastante úteis, mas que nã visam islament. Deste md mantém-se a liberdade para que desenvlvedr acesse qualquer recurs de base, quand necessári fr. Veja a cntribuiçã esperada (também em média, é clar) para cada fatia de natureza de requisits, acima definida, na Figura A6.16. Figura A6.16. Percentual de cntribuiçã d jcmpany FS Framewrk, pr natureza de requisits. Quand funcina cm camada, nível de cntribuiçã d framewrk d jcmpany n estud fi impressinante. Mas mesm cnsiderand-se percentual de cntribuiçã nas utras fatias, devidamente pnderads, btém-se ganhs expressivs! "Visã de Móduls - Dependência entre s prjets gerads - A arquitetura MVC n jcmpany Veja que, n tópic anterir, a representaçã de camadas utilizada é rtgnal às camadas MVC. Neste tópic, vams "virar" em 90 graus diagrama para analisá-l deste utr pnt de vista. A arquitetura MVC sugerida pel jcmpany sustenta-se pr cinc pilares principais: 1. Adçã rigrsa da arquitetura MVC Us de camada de Persistence, subdivind a de mdel, através d DP DAO (a que chamams, resumidamente, de MVC2-P) 3. Balanceament entre melhres práticas Java EE e DDD. 4. Refinament d nível de detalhe arquitetura, para dentr das camadas MVC2-P. 5. Arquitetura rica, também para a camada Visã, cm exclusiv IC Universal, inclusive para esta camada. De uma frma um puc mais detalhada: 1. Primariamente, jcmpany reúsa mdel MVC-2 clássic cm separaçã rigrsa das suas camadas utilizand servlet de Frnt-Cntrller d JSF (FacesServlet). O us deste DP Frnt-Cntrller é que distingue MVC-2 d MVC-1, já que n segund cas usuári acessa as JSPs diretamente.

15 Entendend a Arquitetura de Desenvlviment 2. Em segund lugar, jcmpany define uma nva camada para serviçs de Persistence, subdivisã da camada Mdel, prvend cntrats abstrats (Interface e DP Abstract Factry), além de implementações cncretas genéricas e alternativas para Hibernate u JPA. A camada de Persistence nã é uma sub-divisã clássica d MVC, mas cm é um layer verdadeir e muit cmum n mercad, irems enfatizá-l cm a sigla MVC2-P. 3. Em terceir lugar, a arquitetura se desenvlve cm base em recmendações da Sun, assimiland melhres práticas d Cre J2EE Patterns [Deepak Alur, Jhn] atualizadas para Java EE 6, balanceadas ainda cm sugestões de Dmain Driven-Design - DDD [Evans, Eric. 2004]. O DDD enfatiza uma rganizaçã OO tã pura quant pssível para mdel de Dmíni, que cncrre eventualmente cm rganizações para códig distribuíd d Java EE. Algumas vezes Java EE apresenta padrões que apresentam pequenas timizações, de mais baix nível, mas que nã sã tã elegantes quant um mdel ric de Dmíni precnizad pel DDD. Mas, se pr utr lad uma arquitetura que enfatize uma distribuiçã ptencial de cmpnentes, cm Java EE, pde ser cnsiderada verengineering [Jhnsn, Eric 2002], pr utr pde ser útil em estratégias que pretendam maximizar reús em runtime usand SOA, pr exempl. A arquitetura sugerida n jcmpany ferece um balanç razável entre estas duas esclas: na prática, ist significa que prgramações de Dmíni pdem ser ricas e nã anêmicas [Fwler, Martin 2004], refletind uma linguagem de negócis, mas também publicáveis a menr esfrç e de frma eficiente através de um Web-Service u serviç EJB3 remt - se, quand e nde precis fr. 4. Em quart lugar, jcmpany refina a arquitetura para dentr de cada camada MVC2-P, definind uma rganizaçã refinada de pactes e nvas categrias de classes internas tais cm Service e Helper, utilizadas cm DP Cmpsite [Freeman, Freeman 2004] para maximizar a cesã e minimizar ainda mais acplament. 5. Finalmente, jcmpany pssui uma arquitetura especialmente diferenciada na camada Visã, prvend Inversã de Cntrle (IC), também nesta camada, de md a finalizar a abrangência de generalizaçã ptencial da sluçã. Cm vims, esta é uma camada especialmente mal reslvida em arquiteturas típicas d mercad, devid à sua cmplexidade e diversidade de tecnlgias (JSF, Tag-Files, JSTL, JSP, Tiles/Facelets, Javascript, CSS, DHTML, Ajax/DOJO etc.). Para fazer frente a este desafi, jcmpany define leiautes reutilizáveis e cntrlads pel framewrk (leiautes dinâmics cm Tiles/Facelets), cmpnentes visuais especializads, sluções para reús e especializaçã de peles, rtinas Javascript/Ajax etc., tud iss cm DPs e cnceits OO aplicads, cm nas demais camadas. Este assunt será discutid de frma específica em capítul sbre custmizaçã de Web-Design. - Organizand Classes de Dmíni Uma das maires discussões arquiteturais em MVC é, frequentemente, cm rganizams nss mdel de Dmíni? O mdel de Dmíni é cmpst pr aquela parcela de classes que representam entidades claramente identificadas n negóci, persistentes, em sua mairia, cntend prpriedades cujs valres devem ser mantids em bancs de dads. Mas muit embra estas classes cmpnham um núcle imprtante das estruturas e regras de negóci, existirã utras categrias imprtantes de classes também cnsideradas de negóci para encapsular rquestrações de serviçs, cálculs e prcediment de api. - Arquitetura MVC-2 clássica d J2EE Na visã riginal d J2EE, tais classes de dmíni deveriam ser implementadas cm Entity Beans e, pela impsiçã de nã pderem rdar fra de um cntainer EJB (a cntrári ds POJOs atuais), eram, de frma brigatória, lcalizadas em subcamada interna da camada Mdel. Até aprimrament recente d padrã da especificaçã de Entity Beans para EJB3, prtant, era recmendad as desenvlvedres J2EE trabalhar cm classes artificiais de DTOs (Data Transfer Objects), mers cntainers de infrmações, para transprtar dads de entidades da camada Mdel/Persistence para a camada Cntrller/View, cnfrme a Figura A6.17.

16 Capítul A4 Figura A6.17. Arquitetura MVC precnizada n J2EE clássic (até EJB 2.1). #1. Usuári acina aplicaçã: N mdel MVC-2, um servlet recepcina tdas as requisições d usuári (e nã s cmpnentes de visã tais cm JSF, n MVC-1) #2. Camada cntrller chama serviçs de negóci: Um aparat de Design Patterns tais cm Business Delegate, Sessin Façade e utrs sã tipicamente utilizads para um mair islament entre a camada da aplicaçã (Cntrle e Visã) e a camada de negóci (Mdel), e também devid a uma pressupsiçã de remting, u seja, da ptencial distribuiçã destas camadas pr máquinas distintas, em runtime. Classes remtas sã, principalmente EJB Sessin Beans 2.x. #3. Tdas as principais camadas cmpartilham utilitáris. Muit embra nã sejam representads cm frequência, cmpnentes JAR cntend biblitecas suplementares para perações cm data, lgging, numéricas, tratament de exceções etc., sã dispstas de frma a estarem dispnível em tdas as camadas. #4. Us de Entity Beans 2.x: A Persistence ideal d pnt de vista da especificaçã é btida através de classes EJB Entity Beans e us de linguagem EJB-QL. #5. Us de Sessin Beans (DAO): Alternativamente, classes de EJB Sessin Bean substituem Entity Beans, devid a limitações tecnlógicas u de perfrmance, requerend cdificaçã de SQL diretamente ns códigs Java. #6. Acess a serviçs de Persistence: Seja pr respnsabilidade d cntainer EJB, n cas ds Entity Beans u d desenvlvedr ns DAOs, smente através de classes desta camada repsitóri de armazenament (Ex.: SGBD-R) é acessad. #7. Criaçã d mei de transprte: Após a recuperaçã de infrmações persistidas, seja pr que mei frem, a cdificaçã da cópia ds dads de Entity Beans u JDBC Result Sets para DTOs (Data Transfer Objects) é brigatória. #8. Cntrle de flux de navegaçã: N mdel MVC-2, as classes de Cntrle decidem para que classes de visualizaçã irã delegar a finalizaçã da respsta a usuári. Uma nva versã de Interface cm Usuári é entã selecinada em funçã d estad atual da cnversaçã. #9. Despach da visualizaçã: Classes representand tecnlgias da camada Visã tais cm facelets u JSF despacham algum frmat de visualizaçã para dispsitivs de cliente, tais cm HTML, XML, PDF, CSV, etc. Perceba que, cm a estrutura de dads ds frmuláris de negóci é cmpsta em sua mair parte pr prpriedades das entidades d negóci, a estrutura das classes de DTO terminava pr ser 90% a 100% redundante cm a estrutura das classes Entity Bean. Pr cnsequência, a manutençã desta redundância exigia códigs burrs de transferência de dads (de->para), instanciações de classes desnecessárias etc. Os utrs graves prblemas desta especificaçã Entity Bean (até a versã 2.x), tais cm sérias restrições da linguagem de Persistence EJB-QL, limitaçã a us de herança etc., findavam pr cnfigurar um verdadeir desastre em terms de prdutividade - e Orientaçã a Objets. Na prática, muits reslviam este prblema simplesmente desistind ds Entity Beans 2.x (de fat, quase inutilizáveis). Mas quem nã s substituía pr algum framewrk de mapeament Objet-Relacinal tal

17 Entendend a Arquitetura de Desenvlviment cm Hibernate, passava a prgramar JDBC em EJB Sessin Beans, cm exemplificad em (E), cm manipulaçã direta de result sets e cópias de/para DTOs (u VOs), caind em níveis de prdutividade de técnicas de prgramaçã da geraçã COBOL. Na verdade, em níveis pires devid às deficiências intrusivas da geraçã EJB 2.x, cm vist. Felizmente, s Entity Beans 2.x sã agra legad, substituíds na versã EJB 3.0 pr POJOs (Plain Old Java Objects) que crrigem, da água para vinh, tdas as limitações clássicas. Uma sequela diss é que s Entity Beans 3.0 fram inteiramente recncebids a partir d padrã Java EE 5 e ram 2.x nã sfrerá mais evluções. Ruim para quem acreditu cegamente neste tip de padrã frçad de cmitê ; bm para restante d mercad, que já havia trcad us de Entity Beans 2.x pr alternativas que agra se trnaram padrã de-fact, cm Hibernate/JPA *. Padrões de fact d mercad Open Surce, via de regra, superam s de cmitê. Smente ns últims ans, s cndutres estratégics d Java EE 5 e Java EE 6, especialmente a SUN, fcu ns anseis ds desenvlvedres e nã smente ds fabricantes de Applicatin Server. Esta tendência tem levad à quase eliminaçã de padrões artificais cncebids sem explraçã técnica. - Camada de Dmíni Ortgnal em Java EE 6 Pr tud iss, em sua versã 3.x s Entity Beans vltam a ser a implementaçã ideal para Entidades de Dmíni. Os EJBs 2.x nã eram recmendads para este fim pels principais autres e adepts d DDD, tais cm Martin Fwler e Eric Evans. Dentre utras vantagens, s EJBs 3.x pdem agra dispensar s DTOs na mair parte d temp, pis sã destacáveis e pdem ser expsts para tdas as camadas d MVC2-P em um esquema cnhecid cm atach-detach. Deste md, servem tant para Persistence transparente quant para encapsularem regras de sua alçada e transprtarem seus própris dads. Cm esta evluçã, uma melhr rganizaçã para entidades de Dmíni é clcá-las em uma nva camada, rtgnal à camada central d MVC [POJOs in Actin] [Spring MVC], cnfrme ilustrad na Figura A6.18. Figura A6.18. Arquitetura MVC cm camada rtgnal de Dmíni. #1. Camada cmmns englba utilitáris e DTOs eventuais: As classes utilitárias cmuns a tdas as camadas MVC principais, bem cm eventuais DTOs que ainda sejam necessáris sã encapsulads na visã Cmmns. * O criadr da Hibernate, Gavin King, fi um ds líderes da especificaçã EJB3, especialmente da parte de Entity Beans, que fi redefinida dentr d padrã JPA (Java Persistance Architecture). Pr iss, JPA é hje 90% similar arquiteturalmente a que já se usava na Hibernate.

18 Capítul A4 #2. Camada de Persistence mais leve, utilizand JPA-QL: A camada de Persistence agra pde dispensar cdificaçã de inclusões, alterações, exclusões e de trataments de cncrrência, geraçã de identificadres autmátics, dentre utrs trabalhs realizads de frma transparente pel JPA. Além diss, a linguagem JPA-QL retrna grafs de entidades de dmíni prntamente dispníveis para us pelas demais camadas de frma OO, e nã mais result sets JDBC, relacinais. #3. Camada rtgnal para Entidades de Dmíni: A camada de dmíni agra representa um bjet clássic de OO, cm prpriedades e respnsabilidades (métds) d negóci, além de pderem ser utilizadas em qualquer camada MVC2-P. É imprtante ntar que agra as nbres classes desta camada sã as mais estáveis da arquitetura, nã dependend de serviçs de nenhuma utra, nem de Persistence, pr exempl (a camada de Persistence recupera dads e dispnibiliza para a de Dmíni). Na camada simplificada cm Cmmns (1) estã incluídas classes de utilitáris cmuns de base OSS (Apache Cmmns, Apache Lg4j etc.), d jcmpany (classes sufixadas cm Helper u Util), s DTOs restantes e, ainda, s cntrats (as Interfaces, smente) de fachada, entre as camadas. A Figura A6.19 mstra uma radigrafia um puc mais detalhada da Arquitetura de Sftware MVC2-P * prpsta para Java EE 6 pel jcmpany, exibind também algumas dependências especificas de cada camada, a centr (Mat. Prima OSS, Service, Helper): Figura A6.19. Arquitetura MVC2-P cm dependências rtgnais glbais e internas das camadas. #1. DP Façade: Apesar de representarms, didaticamente, uma seta cm dependência entre Cntrller e Mdel (d Cntrller para a subcamada de implementaçã de Fachada), DP Façade é utilizad nesta interaçã, de md que há um acmplament leve, facilitand reimplementações de serviçs, se/quand necessári. #2. Transprte DTO e Cntext: Quand um Cas de Us apresenta frmulári cm estrutura bastante distinta das Entidades, pde-se lançar cm recurs de transprte s tradicinais DTOs (Data Transfer Objects), cm exceçã, nã mais cm regra! Além diss, um POJO cm DP Cntext Object é utilizad pel jcmpany para transprtar, genericamente, infrmações de cntext da camada Cntrle para Mdel, que pdem ser úteis (perfil d usuári autenticad, metadads de clabraçã etc.). #3. Utilitáris Glbais: Classes d jcmpany cm sufix Helper trazem funções diversas, cmplementares a funções de utilitáris de mercad, de interesse de tdas as camadas. #4. Matéria-Prima OSS Glbal: Representam dependências externas (JAR) de utilitáris, também cmuns a tdas as camadas MVC2-P, tais cm Lg4j, Cmmns, CGLib (AOP) etc. * Neste livr, utilizarems MVC2-P quand quiserms enfatizar uma arquitetura MVC d tip 2, cm subcamada de Persistência bem definida.

19 Entendend a Arquitetura de Desenvlviment #5. Serviçs e utilitáris Específics: Dentr de cada grande camada MVC2-P, há subdivisões de pactes segmentand e encapsuland serviçs e utilitáris interns d jcmpany, específics para a camada. #6. Matéria-Prima OSS Específica: Cada camada MVC2-P pssui um cnjunt agrupad de dependências externas de interesse seu apenas (definid tant n Maven quant em User Libraries d Eclipse). Este agrupament simplifica a gestã de dependências, evitand falhas básicas de arquitetura prduzida pr desenvlvedres. Ex.: Imprtações de serviçs de Persistence na camada Cntrller. É imprtante bservarms algumas dependências acima indicadas: Há uma dependência rtgnal, pr parte de tdas as camadas MVC2-P, cm a camada de Dmíni, além de utilitáris cmuns, resquícis de DTO e cntrats de fachada (smente as Interfaces). A camada de Dmíni, pr sua vez, descnhece e independe de quaisquer das camadas MVC2-P. Ela se trna assim, cm é de se esperar, a parte mais estável da arquitetura, funcinand cm um layer rtgnal. O cnceit da rtgnalidade pde ser melhr visualizad pel rearranj didátic da Figura A6.20. Figura A6.20. Rearranj para visualizaçã mais didática da camada Ortgnal - "layer". Algumas utras bservações imprtantes: O M d MVC2-P, a camada Mdel, é agra decmpsta em Implementações de Cntrats de Fachada e Serviçs de Negóci. Nã detém mais s direits exclusivs de acess às Entidade de Dmíni, que pr sua vez também encapsulam regras de negóci de sua respnsabilidade e nã smente dads. Em uma eventual dispnibilizaçã de frma distribuída, s móduls que cmpõem as camadas rtgnais sã embalads em ambs s executáveis: da aplicaçã e d serviç. Ou seja, em lugar ds DTOs artificiais (smente alguns cntrats especiais permanecem), sã as próprias Entidades que agra servem de transprte entre as aplicações distribuídas. Entidades nã pdem acessar DAOs (Data Access Objects) para bter dads. Elas devem receber dads recuperads pr classes de serviç da camada Mdel (Manager/Business Objects-BO u Applicatin Services-AS) para realizar seus prcessaments, tipicamente regras de negóci. Os terms entre parênteses sugerem sufixs padrões para classes em cada camada, mas pdem ser custmizads em nível crprativ através de cnfigurações ns metadads d jcmpany. Assim, classes de serviç da camada Mdel pdem ter sufix padrã BO, Manager, Mgr u Service, cnfrme desejad. - Organizaçã de Prjets de Desenvlviment Os três prjets Eclipse gerads n capítul anterir suprtam a arquitetura MVC2-P, n ambiente de desenvlviment, da seguite frma:

20 Capítul A4 Figura A6.21. Prjets de desenvlviment x arquitetura de camadas MVC-P. #1. Prjet Eclipse rhtutrial * : Englba a chamada de camada da Aplicaçã [Richardsn, Chris 2006], u seja, as camadas Visã e Cntrle (Cntrladr) d MVC. Naturalmente, artefats de visã sã segmentads ds de cntrle em pactes distints. #2. Prjet Eclipse rhtutrial_mdel : Englba a camada de Mdel, incluind a subsegmentaçã de Persistence em pacte distint. Também neste cas, pactes distints segmentam serviçs de negóci e de Persistence. #3. Prjet Eclipse rhtutrial_cmmns : Englba a camada de utilitáris e utras classes de interesse cmum das demais camadas e também a camada de Dmíni, segmentada em pacte específic. Na rganizaçã da Figura A6.21, é imprtante ntar que nã há uma relaçã um para um entre uma camada da arquitetura e um prjet de desenvlviment na IDE, já que a prliferaçã de prjets de desenvlviment é também prejudicial, aumentand a cmplexidade muitas vezes sem vantagens práticas. Pr utr lad, agrupar tdas as camadas em um únic prjet cstuma também ser uma simplificaçã exagerada na medida em que facilita a quebra de arquitetura MVC. O jcmpany sugere um agrupament cnsiderad bm para a média ds prjets crprativs, em seus templates INI, mas deve-se realizar ajustes, custmizand-se estes templates para algumas situações. Alguns bns exempls sã: Cas a aplicaçã pretendesse renderizar bjets para mais de uma tecnlgia de Visã (Ex.: HTML e também XML/XSLT u WML), entã seria uma ba esclha separar s pactes de Visã, presentes n prjet rhtutrial, em utr prjet independente. Deste md, pder-se-ia ter dis prjets para esta camada Visã bem desacplads. O mesm racicíni valeria, cas a pretensã fsse utilizar duas implementações de Persistence. Se fsse cas, cmpensaria fatrar (s) pacte(s) de persistencia d rhtutrial_mdel para um prjet própri de Persistence. * Na versã 6.0 d JAGUAR s prjets MVC sã gerads sb um prjet pai nmead cm "[nmeapp]_parent". Essa nva estrutura frnece mair dinamism para maven e nã interfere em nenhum artefat MVC. Iss prque facilita as desenvlvedres eventualmente instanciarem dependências de utras camadas, dispníveis glbalmente em um únic Class Path. Nte que, desde que classes de uma camada MVC2-P estejam segmentadas, pel mens, pr pactes cm baix acmplament, rerganizar s prjets nã seria uma tarefa cmplexa. E cm verems, esta é uma precupaçã d jcmpany, que descreverems na Visã Interna da arquitetura prpsta.

21 Entendend a Arquitetura de Desenvlviment Figura A6.22. Principais pactes que segmentam internamente as camadas, dentr de prjets. Devid à rganizaçã acima representada, chega-se a seguinte esquema de dependência entre s prjets gerads (gerada desta frma pel jcmpany, autmaticamente, tant n Eclipse quant n Maven): Figura A6.23. Diagrama de dependência de móduls em linguagem UML. Ns exempls em Figura A6.24, Figura A6.25 e Figura A6.26, vems s arquivs Maven e cnfigurações n Eclipse envlvids. Os móduls Maven (Prjets que serã alterads e cnstruíds pel desenvlvedr) sã definids n arquiv "pm.xml" d prjet Parent e as dependências Maven ns arquivs "pm.xml" de cada prjet. A sincrnia entre esta definiçã e Build Path d Ecilpse é autmaticamente realizada pel plugin M2Eclipse. Ntar que este plugin imprta "mduls Maven" cm "Prjets Eclipse" e, cm verems mais adiante, utras dependências (JAR) cm Libraries Externas, cm deve ser feit:

22 Capítul A4 Figura A6.24. Prjet "principal": Móduls expresss n "pm.xml" Figura A6.25. Prjet "principal": Dependências de móduls expressas n "pm.xml" e sincrnizadas n Eclipse. Figura A6.26. Prjet "mdel": Dependências de móduls expressas n "pm.xml" e sincrnizadas n Eclipse. O prjet "cmmns" nã pssui dependência ds demais, send prtant cnsiderad mais "estável", d pnt de vista arquitetural. - Dependências cm jcmpany A Figura A6.27 exibe nvamente um Diagrama de Cmpnentes da UML para nss prjet rhtutrial, desta vez expandid para cnter dependências d jcmpany em temp de desenvlviment (n Eclipse). Figura A6.27. Dependências entre prjets gerads e jcmpany, em temp de desenvlviment. O prjet d jcmpany para camada de Visã, jcmpany_view nã esta incluíd cm dependência prque nã cntém classes necessárias em temp de desenvlviment. Mas cas desenvlvedr

23 Entendend a Arquitetura de Desenvlviment necessitasse especializar algum cmpnente ele teria que acrescentar uma camada Bridge especializada a prjet. - Dependências cm jcmpany em temp de desenvlviment Cm implementams as dependências da Figura A6.27, n ambiente d Eclipse? Além ds móduls supra-citads, plugin M2Eclipse sincrniza as dependências simples, que nã sã expressas cm "móduls" ns arquivs "pm.xml"(d prjets MVC e d prjet Parent),cm "External Libraries" n Eclipse, autmaticamente. Deste md, dispensa desenvlvedr de cnfigurar de frma redudante estas dependências. Ver Figura A6.28. Figura A6.28. Dependências autmaticamente geradas n Eclipse, a partir d M2Eclipse #1. Prjets Rhtutrial, que pr ser um prjet jcmpany tem dependências gerenciadas pel M2Eclipse. #2. JARs definids ns arquivs "pm.xml" e dispníveis n repsitóri Maven lcal, agrupads em "Maven Dependencies". - Dependências cm jcmpany em temp de execuçã Em uma visã de dependência em temp de execuçã, prjet da camada Visã, jcmpany_visa devem aparecer, pis reúne artefats "nã Java", cm cnteúd em frmats cm XHTML (leiautes genérics de frmulári), CSS, Javascript (Widgets, utilitáris,...), dentre utrs artefats reutilizads smente em temp de execuçã. Ist é exemplificad na Figura A6.29. Figura A6.29. Dependências entre prjets gerads e jcmpany em temp de execuçã. Obs. 1: Para dependências smente em temp de execuçã, é necessári devid registr das dependências ns arquivs pm.xml d Maven, mas nã necessariamente n Eclipse! O M2Eclipse já cuida deste tip de cnfiguraçã autmaticamente. Obs. 2: Os prjets da camada visã d jcmpany sã dispnibilizads cm WAR para Maven, que s expande e mescla cm WAR da aplicaçã (u EAR) em temp de mntagem para funcinament em execuçã. Este frmat é mdelad cm "PSEUDO-WAR" para distingui-l de um "WAR" final, executável.

24 Capítul A4 - Dependências cm a camada de reús Open Surce (OSS) Além da dependência entre s prjets Eclipse e jcmpany, precisarems analisar e implementar ainda as dependências de tds estes prjets cm s framewrks de base e biblitecas de utilitáris hmlgads n sluçã, as quais chamams de Matéria-Prima Open Surce. As dependências das camadas de reús Open-Surce também sã imprtadas cm "External Libraries" n Eclipse pel M2Eclipse, nã havend distinçã cm relaçã as JARs d jcmpany, pr exempl. Figura A6.30. Libraries cntend jcmpany e cmpnentes reutilizads (em destaque), gerads pel M2Eclipse. Visã Interna - Estrutura e artefats ds prjets gerads - Intrduçã Nesta visã, vams entender cm s três prjets gerads n capítul anterir estã rganizads d pnt de vista de sua estrutura interna. Esta visã englba a rganizaçã de diretóris e de artefats sugerids pela arquitetura. A rganizaçã inicial de diretóris adtada pel jcmpany segue cnvenções recmendadas pela ferramenta Apache Maven, resultad de ans de prática em rganizaçã de prjets clabrativs e mundiais d grup Apache. A rganizaçã pinativa d Maven, cm gstam de frisar s seus autres, é mais rigrsa, prém permite a esta ferramenta cmpreender mais a fund prjet (nde estã suas classes de teste, artefats de cnfiguraçã da aplicaçã etc.) e, pr cnsequência, cntribuir mais. Seguir padrã de pactes d Maven ns ajudará na atualizaçã de versões, geraçã de rtinas de mntagem, cmpilaçã e liberaçã de executáveis. Além diss, plugins Maven pderã gerar métricas interessantes e um Web-Site em nível bem adiantad de acabament para nsss prjets, uma vez que utilizems a sua arquitetura sugerida. A pstura pinativa d Maven é similar à adtada pela Pwerlgic n jcmpany. O Maven aprfunda as exigências arquiteturais e irá cbrar um mair investiment inicial quand cmparad, pr exempl, a Apache Ant, mas trará mais retrn, n médi praz. - Aprendend mais sbre Apache Maven Nã irems redundar neste livr tda a explicaçã de base dispnível ns manuais d Maven 3, sbre as vantagens da estrutura de pactes sugerida adtada pel jcmpany. Para iss, sugerims estud ds tutriais d prdut em u ds diverss artigs dispníveis na Web, facilmente desvendáveis através de cnsulta maven 3 articles n Ggle. Em nssa pauta, irems discutir s refinaments realizads pel jcmpany sbre essa estrutura padrã de frma detalhada. - O prjet principal (Cntrller e View) O prjet principal cntém basicamente pactes para prgramações da camada Cntrller d MVC, bem cm arquivs de cnfiguraçã e artefats de camada Visã. É a seguinte a sua rganizaçã interna padrã, cnfrme definida n template INI (e, prtant, utilizada para nvs prjets):