Padres de arquitetura modular

Por Kirk Knoernschild

SOBRE OS PADRES DE MODULARIDADE
Quadros mdulo esto ganhando fora na plataforma Java. Emora modularidade no
! um conceito novo" que promete mudar a forma como o desenvolvimento de
aplicaes de soft#are. $oc% s vai ser capa& de perceer os enef'cios da
modularidade se voc% entender como pro(etar sistemas de soft#are mais modulares.
)s padres de modularidade estaelecer as ases necess*rias para incorporar o
pensamento de design modular em suas iniciativas de desenvolvimento. +o ,mito
do mdulo ! necess*rio para usar esses padres" e voc% (* tem muitas das
ferramentas que voc% precisa para pro(etar soft#are modular. Este refcard fornece
uma refer%ncia r*pida para os -. padres de modularidade discutidos no livro Java
Application Architecture: Padres de modularidade com Exemplos Usando OSGi.
Os padres de modularidade no so especfcos para a plataforma Java.Eles podem ser
aplicados em qualquer plataforma tratando a unidade de autorizao e a implantao do
mdulo.Cada padro inclui um diagrama (exceto para os padres de base), descrio e
orientao de implementao.
Padres de Base: conceitos de design modular fundamental sore o qual e/istem v*rios
outros padres.
Padres de dependncia: 0sado para a(udar voc% a gerenciar as depend%ncias entre os
mdulos.
Padres de Usabilidade: 0sado para a(udar voc% a criar mdulos que so f*ceis de usar.
Padres de extensibilidade: 0sado para a(udar voc% a criar mdulos 1e/'veis que podem
ser estendidas com novas funcionalidades.
Padres de utilidade: 0sado como ferramentas para au/iliar o desenvolvimento modular.
Pr!et L"#ic $s Mdular
Quase todos os princ'pios e padres em conhecidos que o soft#are de design pro(eto
lgico endereo de a(uda. 2denti3car os m!todos de uma classe" as relaes entre as
classes" e estrutura de pacotes do sistema so todas as questes de design lgicas. 4
grande maioria das equipes de desenvolvimento de gastar seu tempo lidando com
questes de design lgicas. 0m pro(eto lgico 1e/'vel facilita a manuteno e
aumenta a e/tensiilidade.
Pro(eto lgico ! apenas uma parte do soft#are de design e arquitectura desa3o" no
entanto. ) outro ! o pro(eto modular" que incide sore as entidades f'sicas e as
relaes entre eles. 2denti3car as entidades contendo as construes de seu design
lgico e gerenciamento de depend%ncias entre as unidades de implantao so
e/emplos de design modular. 5em design modular" voc% pode no perceer os
enef'cios que voc% espera do seu pro(eto lgico. )s padres de modularidade a(ud*6
lo7
5oft#are de design que ! e/tens'vel" reutili&*vel" sustent*vel e adapt*vel.
8esign de soft#are modular" ho(e" em antecipao de plataforma de apoio futuro
para modularidade.
Quere grandes sistemas de soft#are em um composto 1e/'vel de colaorar
mdulos.
Entender onde colocar o seu foco arquitet9nico
:igrar aplicaes monol'ticas em grande escala para aplicaes com uma
arquitetura modular.
As duas %acetas de &dularidade
E/istem duas facetas da modularidade.
) modelo de e/ecuo se concentra em como gerenciar sistemas de soft#are em
tempo de e/ecuo. 0m sistema de mdulos" tais como )5;i" ! necess*ria para tirar
vantagem do modelo de e/ecuo.
) modelo de desenvolvimento trata de como os desenvolvedores a criar soft#are
modular. ) modelo de desenvolvimento pode ser dividido em duas sucategorias. )
modelo de programao ! a forma como voc% interage com uma estrutura de mdulo
para aproveitar os enef'cios de e/ecuo de modularidade. ) paradigma do pro(eto !
o con(unto de padres que se aplicam a pro(etar grandes mdulos.
4 estrutura do mdulo d* suporte runtime e um modelo de programao para a
modularidade. :as um quadro mdulo no vai a(ud*6lo a pro(etar grandes mdulos de
soft#are. )s padres neste endereo refcard o paradigma do pro(eto e a(udar voc% a
criar soft#are modular.
M"dul de'nid
0m mdulo de soft#are ! um gerenci*vel nativamente reutili&*vel comin*veis
unidade destac*vel""""" ap*trida de soft#are que fornece uma interface concisa para
os consumidores. +a plataforma Java" um mdulo ! um arquivo J4<" como mostrado
no diagrama. )s padres neste refcard a(udar voc% a criar soft#are modular e
perceer os enef'cios da modularidade.
PADRES DE BASE
)s padres *sicos so os elementos fundamentais sore os quais e/istem outros
padres. Eles estaelecem o processo de pensamento consciente que vai para
pro(etar sistemas com uma arquitetura modular. Eles se concentram em mdulos
como a unidade de reutili&ao" gerenciamento de depend%ncia e de coeso.
(erenciar Relacina&ents
Pro(eto relacionamentos mdulo.
Descri)*
0ma relao entre dois mdulos quando e/iste uma classe dentro de um mdulo de
importao" pelo menos uma classe =nica dentro de um outro mdulo. Por outras
palavras7
5e a alterao do conte=do de um mdulo" :>" pode impactar o conte=do de um
outro mdulo" :-" podemos di&er que :- tem uma depend%ncia f'sica em :>.
8epend%ncias e/cessivas far* seus mdulos mais dif'cil de manter" reutili&ar e teste.
(uia de I&ple&enta)*
Evite mdulos com depend%ncias de entrada e sa'da e/cessivos.
:dulos com muitas depend%ncias de entrada deve ser est*vel. 2sto !" eles
devem mudar raramente
0se depend%ncias do mdulo como um sistema de freios e contrapesos. Por
e/emplo" impor os relacionamentos entre as camadas de soft#are usando
modularidade ?ver camadas f'sicas@.
M"dul Reuse
Enfati&am a reutili&ao no n'vel de mdulo.
Descri)*
0m enef'cio muito citado de desenvolvimento orientado a o(eto ! a
reutili&ao. 2nfeli&mente" o(etos ?ou classes@ no so uma construo reutili&ao
adequada. 4 reutili&ao de Aanamento Princ'pio da Equival%ncia e/plica o porqu%.
4 unidade de reuso ! a unidade de lierao.
)s mdulos so uma unidade de liertao e" portanto" um e/celente candidato como
unidade de reutili&ao.
(uia de I&ple&enta)*
:dulos hori&ontais separados ?aqueles que arangem dom'nios de negcios@ de
mdulos verticais ?aquelas espec'3cas para um dom'nio de negcio@.
:dulo de granularidade e peso desempenhar um papel signi3cativo na
reutili&ao. Bonsiderar cuidadosamente cada um.
:dulos de granulao 3na com con3gurao e/terna v%m com uma maior
proailidade de reutili&ao. :as cuidado" estes mdulos podem ser mais dif'ceis
de usar.
M"duls cesas
Bomportamento mdulo deve servir a um propsito singular.
Descri)*
Boeso ! uma medida de quo intimamente relacionada e focada as diferentes
responsailidades de um mdulo so. )s mdulos que carecem de coeso so mais
dif'ceis de manter.
(uia de I&ple&enta)*
Preste ateno em como voc% atriuir aulas aos seus respectivos mdulos.
Blasses mudando C mesma ta/a e" normalmente reutili&ado (untos" pertencem ao
mesmo mdulo.
Blasses mudando em ritmos diferentes e normalmente no ! reutili&ado em
con(unto pertencem em mdulos separados.
PADRES DE DEPE+D,+-IA
)s padres de depend%ncia foco na gesto das relaes entre os mdulos.Eles
fornecem orientao sore a gesto de acoplamento que aumentam a proailidade
de mdulo de reutili&ao.
Relacina&ents ac.clics
<elaes mdulo deve ser ac'clico.
Descri)*
<elaes c'clicas complicar a estrutura do mdulo. 4plicar a regra a seguir para
identi3car as relaes c'clicas.
5e comear com o mdulo 4" voc% pode seguir as relaes de depend%ncia entre o
con(unto de mdulos que 4 ! diretamente ou indiretamente dependente e voc%
encontrar qualquer depend%ncia do mdulo 4 dentro desse con(unto" ento e/iste
uma depend%ncia c'clica entre sua estrutura de mdulo.
$oc% deve evitar depend%ncias c'clicas.
(uia de I&ple&enta)*
Escalonamento quera ciclos movendo a causa da depend%ncia c'clica a um
mdulo de gesto de um n'vel superior.
<eai/amento quera ciclos movendo a causa da depend%ncia c'clica a um
mdulo de n'vel inferior.
Ballacks querar um ciclo atrav!s da de3nio de uma astrao que ! in(etado
no mdulo dependente. Esta implementao se assemelha ao padro )server
D;)EF.
Le$eli/e Mdules
<elaes mdulo deve ser nivelado.
Descri)*
Aeveli&ation ! semelhante ao de camadas" mas ! uma forma mais re3nado para
gerenciar relacionamentos ac'clicos entre os mdulos. Bom leveli&ation" uma =nica
camada pode conter v*rios n'veis do mdulo. Para leveli&e mdulos" faa o seguinte7
4triuir mdulos e/ternos de n'vel G. :dulos dependente apenas no n'vel G mdulos
so n'vel - atriu'do. :dulos dependentes do n'vel - ! atriu'do o n'vel >. :dulos
dependente do n'vel n so n'vel n H - atriu'do.
(uia de I&ple&enta)*
)s n'veis so mais granular do que as camadas em seu sistema. 0tili&e os n'veis
para gerir as relaes dentro de camadas.
Aeveli&ation e/ige relaes mdulo ser ac'clico. +o ! poss'vel uma estrutura de
mdulo leveli&e com ciclos.
0m esquema leveli&ation rigoroso" onde os mdulos so dependentes apenas do
n'vel imediatamente aai/o" ! conceitualmente ideal" mas pragmaticamente dif'cil.
-a&adas %.sicas
<elaes mdulo no deve violar as camadas conceituais.
Descri)*
Bamadas de um sistema de a(uda a facilitar a manuteno ea testailidade da
aplicao. Bamadas mais comuns incluem a apresentao ?ou se(a" a interface de
usu*rio@" dom'nio ?ou se(a" o negcio@" e acesso a dados.Qualquer sistema de
soft#are em camadas pode conceptualmente ser dividido em mdulos que
correspondem a estas camadas conceptuais. Bamadas f'sicas a(uda a aumentar a
reutili&ao porque cada camada ! uma unidade implement*vel.
(uia de I&ple&enta)*
Bomece criando um =nico mdulo de granulao grossa para cada camada.
Ea&er cumprir as camadas usando Aeveli&e compilao.
Quere cada camada em mdulos mais coesos e usar mdulos Aeveli&e de
compreender e gerir as relaes dentro da camada.
I om se os mdulos dentro de uma camada de ter relacionamentos entre
eles. Estes mdulos sero em diferentes n'veis.
-ntainer Independncia
)s mdulos devem ser independentes do recipiente runtime.
Descri)*
:dulos pesados so dependentes de um amiente de e/ecuo espec'3ca e so
dif'ceis de reutili&ar em conte/tos. 8epend%ncias amientais tam!m afetam
negativamente a sua capacidade de testar mdulos. :dulos independentes do
recipiente de e/ecuo so mais propensos reutili&ados" e so mais facilmente
mantidos e test*veis.
(uia de I&ple&enta)*
Evitar a importao de pacotes dependentes de cont%ineres no cdigo do mdulo.
0tili&e con3gurao e/terna para con3gurar um mdulo de modo a que ele possa
operar em diferentes amientes de e/ecuo.
0sar in(eo de depend%ncia para as depend%ncias astratas de cont%ineres.
I&planta)* independente
)s mdulos devem ser unidades independentes implement*veis.
Descri)*
As dependncias menos sada de um mdulo tem, mais fcil o mdulo reutilizar.Um mdulo
sem dependncias de sada independente destacvel e pode ser reutilizado sem a
preocupao de identifcar o que pode ser necessrio mdulos adicionais.Mdulos de nvel
inferior inerentemente tm menos dependncias de sada e aumentar a oportunidade de
reutilizao.
(uia de I&ple&enta)*
+em todos os mdulos podem ser independentemente implement*vel. 4lgumas
depend%ncias do mdulo so sempre necess*rios.
Em adicional para redu&ir as depend%ncias de sa'da" depend%ncias recipiente
tam!m deve ser minimi&ado para os mdulos que so independentemente
implement*vel.
:dulos altamente coesos so mais f*ceis de fa&er unidades independentemente
implement*veis.
PADRES DE USABILIDADE
Queremos mdulos que outros desenvolvedores acham f*cil de interagir. )s padres
de usailidade a(udar mdulos de design que so f*ceis de entender e usar.
Inter%ace publicada
4dicione interface pulicada de um mdulo em conhecida.
Descri)*
)s mdulos devem encapsular detalhes de implementao" para que outros mdulos
no precisa entender a aplicao para utili&ar o mdulo. 2nterface pulicada de um
mdulo e/pe os recursos que voc% dese(a disponiili&ar para outros
desenvolvedores.
4 interface pulicada consiste nos m!todos p=licos" dentro das classes p=licas
dentro dos pacotes Je/portadosJ que outros mdulos so capa&es de invocar.
+o padro Java" no h* nenhuma maneira de declarar e/plicitamente que empacota
um mdulo e/portaes" por isso ! dif'cil de aplicar uma interface pulicado. Quadros
mdulo" como )5;i" rilhar nesta situao.
(uia de I&ple&enta)*
+o padro Java" documentar a interface pulicada voc% espera outros clientes
para invocar.
+o padro Java" e/por a interface pulicado via astraes e desencora(ar outros
desenvolvedores usando as classes concretas.
Quadros mdulo" como )5;i" permitem e/portar pacotes e permitir que voc% mais
facilmente impor uma interface pulicada.
-n'#ura)* externa
)s mdulos devem ser con3gur*veis e/ternamente.
Descri)*
2niciali&ao do mdulo normalmente requer a con3gurao do mdulo para o seu
conte/to amiental. E/ternali&ao da con3gurao diminui as depend%ncias de
conte/to e permite que voc% use o mdulo atrav!s de uma ampla gama de
amientes. Bon3gurao e/terna aumenta a reutili&ao de um mdulo" mas torna
mais dif'cil de usar" porque os desenvolvedores devem entender como con3gurar o
mdulo.
(uia de I&ple&enta)*
0tili&e con3gurao e/terna para eliminar depend%ncias amientais de um
mdulo.
2ncluir um 3cheiro de con3gurao dentro do mdulo que de3ne uma con3gurao
padro" fa&endo com que o mdulo mais f*cil de usar.
Permanecem" portanto" cientes de tradeoK entre o aumento da reutili&ao e
reduo da usailidade. Em outras palavras" ma/imi&ando a reutili&ao complica
a utili&ao.
I&ple&enta)* padr*
Eornecer mdulos com uma implementao padro.
Descri)*
Para ma/imi&ar a reutili&ao" um mdulo deve ser su3cientemente 1e/'vel de modo
que possa funcionar em uma grande variedade de amientes operativos
diferentes. +o entanto" fa&endo um mdulo mais f*cil de usar nos leva a incorporar
mais funcionalidade em um mdulo de modo promotores so origados a fa&er
menos quando se utili&a o mdulo. 4 implementao padro com pontos de e/tenso
em de3nidos a(uda a resolver esta tenso.
(uia de I&ple&enta)*
4o de3nir uma implementao padro" depende dos elementos astratos de um
mdulo ?ver mdulos astratas ou astraes separadas@.
2ncluir uma con3gurao padro no mdulo" mas fa&er o mdulo con3gur*vel
e/ternamente tam!m.
5empre criar um mdulo de teste para testar a implementao do padro.
M"dul 0ac1ada
Briar uma fachada servindo como um ponto de entrada de granulao grossa a
implementao su(acente do outro mdulo 3negrained.
Descri)*
:dulos de gro 3no e leve so inerentemente mais reutili&*vel. :as mdulos
re3nadas so tam!m tipicamente dependente de v*rios outros mdulos. 4 Eachada
:odule de3ne uma 4P2 de n'vel superior que coordena o traalho de um con(unto de
mdulos de granulao 3na. 4 fachada enfati&a a facilidade de uso" enquanto os
mdulos mais granulari&adas enfati&ar reutili&ao.
(uia de I&ple&enta)*
+o enfati&am a reutili&ao da fachada. 0se6o para unir e con3gurar v*rios
mdulos de granulao 3na.
Boloque o conte/to e as depend%ncias amientais na fachada.
0se a fachada como um ponto de entrada para os testes de integrao.
PADRES DE E23E+SIBILIDADE
Queremos soft#are que ! f*cil de estender" sem modi3car a ase de cdigo
e/istente. +s tam!m queremos implantar esta nova funcionalidade sem afetar
outras *reas do sistema. )s padres de e/tensiilidade nos a(udar a alcanar este
o(etivo.
Resu& Mdules
8ependem dos elementos astratos de um mdulo.
Descri)*
8ependendo dos elementos astratos de um mdulo d*6lhe mais oportunidades para
ampliar o sistema atrav!s da de3nio de novos mdulos com classes que
implementam ou estender a astrao. Qualquer cliente do mdulo tam!m tem a
capacidade de de3nir suas prprias implementaes e lig*6los no mdulo.
(uia de I&ple&enta)*
0se uma implementao de f*rica para criar a implementao su(acente de um
mdulo.
0so astrato mdulos quando voc% tem muitas depend%ncias de mdulos de
entrada e voc% quer a 1e/iilidade de trocar implementaes su(acentes.
Esforce6se para fa&er a astrao dentro de um mdulo to est*vel quanto
poss'vel. 2sto !" evitar mudanas" uma ve& que ter* muitos muitos outros mdulos
esto dependentes dela.
I&planta)* de %4brica
0se f*ricas para criar classes de implementao de um mdulo.
Descri)*
Qualquer mdulo cu(as aulas depender* dos elementos astratos de um outro mdulo
deve evitar fa&er refer%ncia a qualquer classe de implementao. 5e o 3&er" ir*
comprometer seu pro(eto de mdulo. Bonsidere a seguinte regra.
5e uma classe dependendo de uma astrao deve ser alterada" a 3m de instanciar
uma nova implementao da astrao" o pro(eto ! falho.
4l!m disso" se um mdulo deve ser alterado para acomodar a instanciao" o design
do mdulo est* comprometida.
(uia de I&ple&enta)*
4 f*rica tem de ser separado a partir do mdulo que cont!m as inst,ncias de
classe que cria" assim como o mdulo dependentes as astraces.
E/teriori&ar a criao da implementao de um mdulo para um arquivo de
con3gurao.
Bonsidere o uso de um frame#ork de in(eo de depend%ncia como 5pring" )5;i
Llueprint" ou 5ervios declarativos )5;i. Estes serviro como sua f*rica para unir
as implementaes apropriadas em tempo de e/ecuo.
Abstra)es separadas
Boloque astraes e as classes que implementam6los em mdulos separados.
Descri)*
5eparando astraes a partir de sua implementao oferece a maior 1e/iilidade
para fornecer novas implementaes que sustituem completamente as
implementaes e/istentes. Bom 4straes separados" voc% pode de3nir um novo
comportamento e lig*6lo em seu sistema" sem afetar os mdulos do sistema em
vigor. 4straes separadas pode ser usado para desenvolver uma arquitetura plug6
in. Bomo orientao geral" aplicar a regra a seguir.
:antenha a astrao mais pr/imo das classes que dependem dele e mais longe das
classes que estendem ou implement*6lo.
(uia de I&ple&enta)*
5e todas as classes que dependem de uma astrao viver em um =nico mdulo"
em seguida" coloque as classes ea astrao no mesmo mdulo.
5e as classes dependentes de uma astrao viver em mdulos separados"
coloque a astrao em um mdulo separado das classes que dependem dele.
5eparando astraes d* a 1e/iilidade" 3nalmente" para estender seu sistema"
mas tam!m aumenta a sua comple/idade.
PADRES DE SER5I6OS P7BLI-OS
)s modelos de utilidade so ferramentas e t!cnicas adicionais que o desenvolvimento
modular a(uda. Eles a(ud*6lo a cumprir o seu design modular e garantir a qualidade.
-lcate Exce)es
E/cees devem estar perto da classe ou interface que os (oga.
Descri)*
4locao de e/cees para os mdulos tem implicaes sore as depend%ncias do
mdulo. Bolocando e/cees perto das classes que peg*6los cria uma depend%ncia do
mdulo que gera a e/ceo para o mdulo que cont!m a e/ceo. Porque chamar um
m!todo pode introdu&ir uma depend%ncia do mdulo" as e/cees devem estar no
mesmo mdulo que a classe que cont!m o m!todo que gera a e/ceo.
(uia de I&ple&enta)*
Aanar a e/ceo na interface ou classe astrata voc% ! origado a e coloque6a
e/ceo no mesmo mdulo como a interface ou classe astrata.
5e astraes atrav!s de v*rios mdulos a mesma e/ceo" reai/ar a e/ceo de
um mdulo completamente separado em um n'vel inferior.
Le$eli/e -nstruir
E/ecutar a construo de acordo com o mdulo leveli&ation.
Descri)*
2mpondo relaes mdulo ! dif'cil. Emora conceitualmente voc% pode acreditar que
voc% tem uma estrutura de mdulo ac'clico e compreender plenamente as relaes
do mdulo" um =nico construir alvo com tudo no classpath permite ciclos indese(*veis
e depend%ncias para raste(ar em 4 construo nivelado a(uda voc% a cumprir suas
depend%ncias de mdulo.Quaisquer depend%ncias que violam a sua estrutura de
mdulo de3nido ir* resultar em uma falha de construo.
(uia de I&ple&enta)*
Evite a construo classpath completo" onde todas as classes so constru'dos
utili&ando um =nico alvo de compilao.
8e3nir metas para separar construir mdulos em diferentes n'veis. +'vel mdulos
- pode ser constru'do com apenas o n'vel e/terno G mdulos. 4 n'veis mais
elevados" incluem apenas os mdulos de n'veis mais ai/os que so necess*rios
para uma construo em sucedida.
8e3nio de novas depend%ncias de mdulo ser* necess*rio modi3car a
construo para esse mdulo. Esta no ! necessariamente indese(*vel.
M"dul de teste
Bada mdulo deve ter um mdulo de teste correspondente.
Descri)*
:dulos de teste cont%m todos os testes para as classes em um mdulo
espec'3co. Eles permitem que voc% teste implementao su(acente de um
mdulo. 0m mdulo de teste pode conter testes de unidade que testam as classes de
um mdulo" em como testes de integrao que testam a funcionalidade de todo o
mdulo.
(uia de I&ple&enta)*
8ependendo 4stracto :dulos torn*6lo mais f*cil de3nir as simulaes e topos
para testar um mdulo independente.
Para maiores testes suites" ou situaes onde o desempenho ! primordial"
diferentes tipos diferentes de testes ?ie" testes unit*rios" testes de integrao"
testes de desempenho" etc@ para fora em mdulos de teste separadas.
2dealmente" voc% s vai incluir o mdulo de teste e do mdulo em teste no
classpath durante a e/ecuo dos testes. Pragmaticamente" alguns mdulos
podem e/igir outros mdulos dependentes.