Arquitetura
Patrick H S Brito
patrickhenrique@gmail.com
————————————————————————————— Instituto de Computa¸c˜ao (IC)
Dimens˜
ao Arquitetural do Componente
• “Um componente como um elemento arquitetural. Este
componente deve oferecer e estar em conformidade com um conjunto de interfaces”;
• Normalmente representa um m´odulo ou um componente de alta granularidade do sistema;
• Um elemento arquitetural pode representar requisitos n˜ao-funcionais do sistema, como por exemplo:
– Distribui¸c˜ao, tolerˆancia a falhas, escalabilidade, desempenho.
• “Um componente como um elemento implementacional ´
acessado atrav´es de interfaces bem documentadas que podem ser descobertas em tempo de execu¸c˜ao”;
• Conhecidos como componentware;
• Essa ´e a dimens˜ao mais utilizada de um componente, mas n˜ao ´e a ´
unica;
• Se um componente possui a dimens˜ao implementacional, significa que ele est´a pronto para ser empacotado, implantado, instanciado e utilizado em um ambiente real:
Dimens˜
ao Implementacional-Arquitetural do
Componente
• “Um componente como um elemento implementacional mas que faz parte de um contexto arquitetural espec´ıfico”;
• Essa dimens˜ao mista de componentes facilita o mapeamento entre o c´odigo-fonte (dimens˜ao implementacional) e a arquitetura
software (dimens˜ao arquitetural);
• Um sistema constru´ıdo unicamente com componentes de dimens˜ao implementacional-arquitetural, ´e muito mais f´acil de evoluir:
– Melhor rastreabilidade entre requisitos, c´odigo e arquitetura de software.
Modelos de Componentes
• Um modelo de componentes define um conjunto de padr˜oes para implementa¸c˜ao, documenta¸c˜ao e implanta¸c˜ao de componentes; • Exemplos de modelos de componentes:
– Modelo EJB (Enterprise Java Beans); – Modelo COM+ (.NET);
– CCM (Corba Component Model); – COSMOS.
Elementos do Modelo de Componentes
O Modelo COSMOS (I)
• Modelo independente de plataforma;
• Consistˆencia entre arquitetura de software e c´odigo: – Rastreabilidade e facilidade de evolu¸c˜ao.
• Sub-modelo de especifica¸c˜ao (vis˜ao externa);
• Sub-modelo de implementa¸c˜ao (vis˜ao de implementa¸c˜ao); • Sub-modelo de conectores (vis˜ao de intera¸c˜ao).
O Modelo COSMOS (II)
O Modelo de Especifica¸c˜
ao
• Um componente possui interfaces providas e requeridas; • As interfaces s˜ao vis´ıveis externamente;
• A implementa¸c˜ao deve ser separada da especifica¸c˜ao; • Como utilizar um componente que s´o tem interfaces?
O Padr˜
ao Factory Method
• O padr˜ao factory method busca principalmente
ofere-cer um ponto ´unico para instancia¸c˜ao de objetos;
• Esse padr˜ao pode ser utilizado para implementar um
ponto de entrada para um m´odulo, atrav´es da instan-cia¸c˜ao de classes n˜ao vis´ıveis externamente.
Estrutura do Padr˜
ao Factory Method
Factory
+ createClass1 (.:.):Class1 + createClass2 (.:.):Class2
Class1
<< create >> −Class1 (.:.):Class1
Class2
Conseq¨
uˆ
encias
• Instancia¸c˜ao controlada por uma classe
es-pec´ıfica. O acesso centralizado possibilita um cont-role estrito sobre como e quando essas referˆencias s˜ao acessadas pelos clientes.
spec prov IManager req impl ComponentFactory + createInstance ():IManager Manager
O Padr˜
ao Fa¸cade
• O padr˜ao fa¸cade busca principalmente oferecer um
ponto ´unico de acesso a uma lista de servi¸cos;
• Esse padr˜ao pode ser utilizado para reduzir a
com-plexidade das classes que implementam as interfaces
de um m´odulo, uma vez que apesar de serem
re-spons´aveis pelos servi¸cos da interface, as fa¸cades ape-nas propagam as requisi¸c˜oes para outras classes inter-nas.
Interface1 + op1 ():void + op2 ():void + op3 ():void + op4 ():void << interface >> Interface2 + op5 ():void + op6 ():void Facade Controller1 Controller3 Controller2
Conseq¨
uˆ
encias
• Redu¸c˜ao da complexidade das classes controladoras,
que podem implementar apenas parte das opera¸c˜oes de uma interface, ao inv´es de “tudo ou nada”;
• Evolu¸c˜ao facilitada da implementa¸c˜ao das interfaces,
pois o fa¸cade nunca ser´a alterado e por essa raz˜ao as evolu¸c˜oes ser˜ao “transparentes” aos clientes.
spec prov IntProv1 IntProv2 req impl FacadeIntProv1 FacadeIntProv2 Class3 Class2 Class1 . . .
O Padr˜
ao Abstract Factory
• O padr˜ao abstract factory busca principalmente
ofer-ecer um ponto ´unico para instancia¸c˜ao dos objetos internos de um m´odulo.
AbstractClass1 ConcreteClass1−V1 ConcreteClass1−V2 ConcreteClass1−V1 AbstractClass1 ConcreteClass1−V2 ConcreteFactory−V1 AbstractFactory ConcreteFactory−V2
Conseq¨
uˆ
encias
• Facilidade de evolu¸c˜ao interna de um
m´odulo, o que acontece devido `a redu¸c˜ao da de-pendˆencia da classe propriamente dita.
• Melhoria da portabilidade do m´odulo, uma
vez que basta atualizar a f´abrica utilizada para alterar a plataforma de execu¸c˜ao.
spec prov
IntProv1 IntProv2
req
impl
FacadeIntProv1 FacadeIntProv2 Class3 Class2
Class1 ObjectFactory
Pode ser uma hierarquia
O Modelo de Implementa¸c˜
ao do COSMOS
operacoesSaque spec prov ITransferencia ISacar IManager req IConta_EBanking ILogging impl . Manager ComponentFactory FacadeTransferencia FacadeSacar ObjectFactory . ClasesDeImplementacao << component >> OperacoesSaque ISacar ITransferencia IConta_EBanking ILogging<< component >> OperacoesSaque operacoesSaque spec req IConta_EBanking ILogging ILogging ITransferencia ... conta_E−Banking_Mgr spec prov IConta_EBanking IManager Prov... Req... ... operacoesSaque−ContaEBanking impl . Manager FacadeConta_EBanking . ClasesDeImplementacao IManager << connector >> OperacoesSaque− ContaEBanking << component >> Conta_E−Banking_Mgr IConta_EBanking
