IntegrandoDesignPatternsemArquiteturasde

Software

SérgioTeixeiradeCarvalho OrlandoGomesLoquesFi lho

sergiotc@ic.uff.br loques@ic.uff.br

ComputaçãoAplicadaeAutomação
InstitutodeComputação
UniversidadeFederalFluminense

Resumo

Acomposiçãodesistemaspartedadefinição deumaArquiteturade Software

que descreva seus componentes e o inter-relacionamento entre eles. O processo de
definiçãodaarquiteturaéchamadoConfiguração.

Design Patterns podem ser empregados quando da configuração de sistemas.

Designpatterns sãomeiosderepresentareregistrarassoluçõesdeprojetoe aexperiência
doprojetistaaodesenvolverestassoluções.

Nesterelatórioapresentamosumestudodecomoalguns designpatterns podem

ser empregados em conjunto com a configuração quando da elaboração e constru ção de
sistemasdistribuídos.Destacamos designpatterns consideradosdeinteraçãoentreobjetose
apresentamosexemplosdeimplementaçãoutilizandoconectoresR-RIO.
 IntegrandoDesignPatternsemArquiteturasde
Software
SérgioTeixeiradeCarvalho
sergiotc@ic.uff.br
ComputaçãoAplicadaeAutomação
InstitutodeComputação
UniversidadeFederalFluminense
1-Introdução
Aconcepçãodesoftwareconstitui-seuma
tarefa árdua em vários aspectos,
particularmentenotocanteàreutilização.
A reutilização de software é um aspecto
há muito tempo discutido. A dificuldade em
se consegui-la vem de décadas. A tentativa,
namaioriadoscasos,partiadareutilizaçãoda
fase de implementação, ou seja, apenas do
código fonte da aplicação através de rotinas
armazenadas em bibliotecas. Esta forma de
reutilização de software é plausível mas
insuficiente.
O desenvolvimento de sistemas por
composição e a separação de interesses
constituem-se em conceitos primordiais para
se alcançar a reutilização de software [4].
Construir sistemas por composição facilita a
reutilização pois permite que componentes
sejam adicionados ou removidos de forma
transparente. Quanto à separação de
interesses [2], esta distingue aspectos
funcionais de aspectos operacionais (não
funcionais) da aplicação. Como exemplo de
aspectos operacionais podemos citar
protocolos de comunicação entre
componentes em um sistema distribuído,
aspectosdetolerânciaafalhas,etc.
OrlandoGomesLoquesF ilho
loques@ic.uff.br
A composição de uma aplicação parte do
estabelecimentodoscomponentesenvolvidos
e das suas interações. A definição de um
sistema em termos dos componentes e das
interações entre estes componentes é
chamada Arquitetura de um Sistema de
Software [13]. A descrição de uma
arquitetura é feita através de uma ADL
(ArchitectureDescriptionLanguage ).
O projetista, ao utilizar uma ADL,
seleciona e especifica os componentes do
sistema e os conectores. Este processo é
chamado Programação da Configuração, ou
simplesmente,Configuração.
Os conectores têm um papel fundamental
na configuração: são responsáveis por
estabeleceraligaçãoentreoscomponentese
intermediar a interação entre os mesmos.
Além disso podem encapsular aspectos não
diretamenterelacionadosàfuncionalidadede
determinada aplicação, enquanto os
componentes realizam preferencialmente os
aspectosfuncionaisdamesmaaplicação.
Ainda com respeito à reutilização de
softwareexistea preocupação emrelação ao
reaproveitamento da “experiência” do
projetista. Durante o projeto de software,
objetosdevemser encontradosefatoradosem
classes, interfaces devem ser definidas,
2 de 16
hierarquias de herança precisam ser
estabelecidas,etc.Oconhecimentoacercado
projeto, associado aos seus problemas e
soluções, pode ser reaproveitado para
utilização emoutros projetos vindouros, seja
domesmoprojetistaouatémesmodeoutros.
A idéia é documentar de forma
padronizada problemas recorrentes
envolvendo classes e objetos em sistemas
orientados a objeto. Design patterns são
meios de representar e registrar as soluções
de projeto e a experiência do projetista ao
desenvolver estas soluções [1]. Catálogos de
design patterns podem ser criados e
consultadospordesenvolvedoresembuscada
resolução de determinados problemas. Com
isso, design patterns constituem-se em uma
forma padronizada de descrever problemas
reais, acompanhados de suas respectivas
soluções.
Neste relatório apresentamos um estudo
de como alguns design patterns podem ser
empregadosemconjuntocomaconfiguração
quando da elaboração e construção de
sistemas.Paraissodestacamosalguns design
patterns [1] considerados de interação entre
objetos. Além disso apresentamos exemplos
de como estes podem ser implementados
utilizando conectores R-RIO ( Reflective,
ReconfigurableInterconnectableObjects )[4]
atravésdalinguagemJava[5].
Este relatório está dividido em 6 seções.
Na seção 2 tratamos do processo de
configuraçãodesistemas edaabordagemR-
RIO para concepção de aplicações
distribuídas. Os design patterns são
caracterizados na seção 3. A seção 4
apresenta exemplos de implementação de
alguns designpatterns deinteraçãoutilizando
conectoresR-RIO.Conclusõesestãonaseção
5easeção6listaasreferências.
2–ConfiguraçãodeSistemas
A arquitetura de um sistema de software
define um sistema em termos dos
componentes e das interações entre estes
componentes [13]. Configurar um sistema é
utilizar uma ADL para descrever os
componenteseoselementosdeinterconexão
entreosmesmos,chamadosconectores.
O desenvolvimento de software baseado
emconfiguraçãodeslocaofocodoprojetista
paraaarquiteturadosistema,constituídados
componentes e suas interligações. A
visualização da arquitetura permite que
componentes sejam adicionados ou
removidos sem a preocupação com os
detalhesdeimplementaçãodecadaumdeles.
A configuração tem como base a
interligação de componentes através dos
conectores. Os conectores estabelecem a
interação entre os componentes e podem
realizar qualquer atividade inerente à
comunicaçãoentreestes.
2.1–R-RIO( Reflective,Reconfigurable
InterconnectableObjects )
A abordagem R-RIO ( Reflective,
ReconfigurableInterconnectableObjects )[3,
4] permite que se descreva a estrutura de
aplicaçõesapartirdeseuscomponentes,suas
interligaçõeseseusaspectosnãodiretamente
relacionados à sua funcionalidade, tais como
a distribuição, coordenação, protocolos de
comunicaçãoeoutros.
OmodelodeR-RIOestábaseadoemtrês
elementosbásicos[3,4]:
- Módulos: componentes de uma
aplicação que encapsulam sua
funcionalidade;
- Conectores: elementos de conexão
que implementam e gerenciam as
interaçõesentreosmódulos;
- Portas: pontos de acesso pelos quais
módulos e conectores oferecem ou
solicitamserviços.
A figura 1 mostra o inter-relacionamento
entreoselementosbásicosdeR-RIO.
Asclassesdemódulossãomapeadaspara
umaimplementação.Porexemplo,Módulo1
e Módulo 2 são instâncias de módulos
3 de 16
implementados em Java, C ou C++. Cada
módulo pode oferecer ou solicitar serviços
por meio de portas de entrada e portas de
saída respectivamente. Ao implementarmos
por exemplo um módulo como uma classe
Java, teríamos como portas de entrada a
declaraçãodosmétodosdaclasse.Quantoàs
portas de saída, estas seriam invocações de
método.
porta
Módulo1 Módulo2
Conector
Figura1. Módulo 1 interage com Módulo 2 através de
Conector.
Os conectores, ao interligarem módulos,
facilitam a separação de interesses,
permitindo a codificação de aspectos não
relacionados diretamente à funcionalidade
dosmódulosenvolvidos.Istoocorredevidoà
facilidade do mesmo em interceptar e
manipular requisições de e para os módulos.
Observamos com isso a capacidade de
reflexãodoconectorR-RIO.
A reflexão, quando empregada, trata o
sistema em dois níveis: nível base e meta-
nível. O primeiro é associado às
funcionalidades do sistema e o segundo é
associado aos aspectos não diretamente
relacionados às funções do mesmo sistema.
Operaçõesrealizadasnonívelbasepodemser
interceptadas e direcionadas para o meta-
nível. Este realiza o devido tratamento às
operações e as reencaminha, podendo
inclusivedesviá-lasdeseucursonormal.
A integração da configuração e reflexão
temsidoobjetodeestudo[4].
O sistema R-RIO [3] permite instanciar
módulos em um sistema, seja distribuído ou
não distribuído, ligar módulos através de
conectores, parar módulos em execução,
reiniciarestesmesmosmódulos,dentreoutras
funções.Paraocasodesistemasdistribuídos,
os módulos podem ser instanciados em
qualquer hostdosistema.
2.2–Exemplo
Como exemplo apresentamos um sistema
cliente-servidor simples. O módulo Cliente
possui uma porta de saída e o módulo
Servidor possui uma porta de entrada. A
arquiteturadestesistemaésimilaràfigura1,
na qual o Módulo 1 pode representar o
Cliente e o Módulo 2 pode representar o
Servidor.
A figura 2 apresenta a descrição da
arquitetura utilizando a ADL do R-RIO
chamada Babel ( Building Applications by
Evolution). A Babel permite a descrição, o
armazenamentoearecuperaçãodadescrição
de módulos, conectores e aplicações [4].
FundamentosdeBabelsãotratadosem[14].
Após a descrição da arquitetura faz-se
necessário codificar os módulos
correspondentes, instanciá-los e executá-los
nosistemaR-RIO.
Os dois módulos foram implementados
como classes Java. O módulo Cliente
simplesmente invoca um método do módulo
Servidor.AportadesaídadomóduloCliente
(figura 3) é indicada pela invocação do
método obtemMsg()dainstância srv.
A porta de entrada do módulo Servidor
(figura 4) é representada pela declaração do
método obtemMsg().
Importantenotarqueasclassesdasfiguras
3 e 4 herdam características da classe Thread
do Java. Isto ocorre pois os módulos são
executados em R-RIO como threads.
Detalhespodemserencontradosem[3].
Após a codificação das classes é o
momento de instanciá-las no sistema. Além
deinstanciá-lasem hostsdistintos,asligamos
através de um conector CORBA [6], já
codificadoepertencenteaorepositóriodeR-
RIO. Os comandos necessários para as
instanciaçõesealigaçãoaoconectorestãona
figura5.
4 de 16

module AplicacaoExemplo {
module ClienteType {
outport obtemMsgType obtemMsg;
map CODE Java “Cliente”;
} clnt;
module ServidorType {
inport obtemMsgType obtemMsg;
map CODE Java “Servidor”;
} serv;
conector CorbaC {
inport obtemMsgType;
outport obtemMsgType;
map CODE Java “Corba”;
} corba;
instantiate clnt at host1;
instantiate serv at host2;
link clnt to serv by cCorbaC;
} Exemplo;
start Exemplo;
Figura2. Arquitetura da Aplicação
public class Cliente extends Thread {
public Servidor srv;
public void run () {
System.out.println (srv.obtemMsg()) ;
}
}
Figura3. Código do Módulo Cliente.
public class Servidor extends Thread {
public void run (){
} Os design patterns são mecanismos de
public String obtemMsg () {
return “Mensagem do Servidor”;
} acompanhados de suas respectivas soluções
} [1]. Eles permitem o compartilhamento da
Figura4. Código do Módulo Servidor.
Os módulos Cliente e Servidor se
comunicam sem que tenham conhecimento
do mecanismo de comunicação empregado.
Tal mecanismo é responsabilidade do
conector. Mudar o estilo de comunicação
entreoClienteeoServidoréfácil,bastando
para isso utilizar o conector apropriado,
digamos SocketsaoinvésdeCORBA.
Protótipo do Sistema R-RIO – Versão 1.0
Entre com o comando no prompt
> instantiate Cliente as clnt at host1
Ok.
> instantiate Servidor as serv at host2
Ok.
> link clnt at host1 serv at host2 with conectores.Corba
Ok.
> start srv at host2
Ok.
> start clnt at host1
Ok.
Figura5. Comandos de Configuração.
Na próxima seção abordaremos conceitos
ecaracterísticasdos designpatterns afimde,
na parte 4, apresentarmos alguns deles
implementadosutilizandoconectoresR-RIO.
3– DesignPatterns
Durante o projeto de software, objetos
devem ser definidos e fatorados em classes,
interfaces devem ser criadas, hierarquias de
herançaprecisamserestabelecidas,etc.
Os projetistas, entretanto, podem
reaproveitar projetos já aplicados e que
tenham tido funcionalidade comprovada.
Projetistas experientes reutilizam soluções
quando estas são consideradas boas. Tais
soluçõessetornamentãopadrõesrecorrentes
de classes e objetos em muitos sistemas
orientados a objeto [1]. Tais padrões
resolvemproblemasdeprojetosespecíficose
os tornam mais flexíveis, elegantes e
reutilizáveis.
representação de problemas recorrentes
experiênciadeespecialistasdediversasáreas
econstituem-seemumamaneiradereutilizar
aexperiêncianoprojetodesoftware.
Design patterns apresentam-se como
descrições de soluções que tenham tido
sucesso em problemas de software [7]. A
idéia central é a possibilidade de se criar
handbooks que descrevam problemas
conhecidosesuassoluções.
5 de 16
 Importantesalientarentretantoque design
patterns não são construções teóricas, mas
sim artefatos descobertos em múltiplos
sistemas [8]. Uma solução representada em
um designpattern deve ter sido aplicada,no
mínimo,três vezes [16].Emoutras palavras,
não é feito o registro apenas de uma boa
idéia, mas sim de uma solução aplicada em
umcenárioreal.
Outracaracterísticaimportantedos design
patterns é a sua independência de qualquer
linguagem de programação. As soluções
estão ligadas a aspectos inerentes à solução
em si. Portanto, eles podem ser aplicados a
qualquer domínio e em qualquer linguagem
deprogramação[8].
Design patterns têm sido empregados no
contextode frameworksorientadosaobjetos.
Um framework orientado a objeto é um
conjunto de classes que cooperam
mutuamente umas com as outras [9],
compondo a infra-estrutura necessária ao
desenvolvimento de uma aplicação
específica. Ao construir um framework, o
projetista deve definir classes e seus
relacionamentos, de tal forma que possa
atender aos requisitos de determinada
aplicação. Design patterns podem ser
empregados na fase de projeto de um
framework.Exemplospodemserencontrados
em [10] e [11]. Mais detalhes de como um
framework é construído podem ser
encontradosem[12].
3.1–Descriçãodeum DesignPattern
Um design pattern identifica as classes e
instâncias participantes, seus papéis e
colaborações, e a distribuição de
responsabilidades [1]. Sua descrição é feita
atravésde4(quatro)elementosessenciais[1,
8].
Nome: palavra ou frase que descreve o
designpattern .Devesintetizaroconceitoque
representa, minimizando os problemas de
comunicação.Onomedeum designpattern ,
assim como o nome de um algoritmo ou de
uma estrutura de dados, deve deixar clara a
informação à qual ele representa e deve ser
tratado como um poderoso mecanismo que
tragaàtonaoseusignificado.
Problema:esteéoproblemaespecíficoa
ser resolvido. Descreve o objetivo do design
pattern,quandoaplicá-loeocontextoaoqual
aplicá-lo, ou seja, a configuração na qual o
problemaéencontrado.
Solução: descrição da essência da
solução,istoé,componentesenvolvidos,seus
relacionamentos e responsabilidades. A
solução é dada em notação UML ( Unified
Modeling Language ) [17], descrição dos
participantes e diagramas de interação. Em
alguns patterns, esta seção traz cartões CRC
(Class-Responsibility-Collaborator) ou CRC
cards [18]. É importante salientar que este
elemento do design pattern não descreve a
implementação, mas sim as técnicas que
poderiam ser empregadas para implementá-
lo.Umexemplodeimplementaçãotambémé
apresentado.
Conseqüências: este elemento descreve
as conseqüências após a aplicação do design
pattern. Aqui são descritos os impactos para
o usuário decorrentes da sua aplicação,
através da especificação de vantagens e
desvantagens, além da relação custo-
benefício. Também são apresentados design
patternsrelacionadosàqueleemquestão.
Napróximaseção,apresentaremos alguns
designpatterns relacionadosàinteraçãoentre
objetos. Abordaremos a aplicação destes à
configuração de sistemas distribuídos
utilizandoconectoresR-RIO.
4–Configuraçãoe DesignPatterns
Oníveldereutilizaçãoqueaconfiguração
e os design patterns alcançam é diferente.
Utilizando uma ADL para descrever os
componentes e conectores, o projetista
consegue configurar aplicações com
características de reutilização. Isso ocorre
pois os componentes envolvidos são
independenteseinteragemunscomosoutros
através de conectores, responsáveis pela
6 de 16
interligação. Quanto aos design patterns ,
estes possibilitam a reutilização de software
relacionadaà expertiseempregada.Emoutras
palavras, podemos reaproveitar o que outros
projetistas já desenvolveram em termos de
modelo e projeto. Esse reaproveitamento
podesedarporintermédiodoscatálogos[1],
dos sistemas [19], ou das linguagens de
patterns[20] .
O emprego de design patterns na
configuração facilita a separação de
interesses. Aspectos não relacionados
diretamente à funcionalidade da aplicação
podem ser implementados preferencialmente
nos conectores e os aspectos funcionais
podem ser codificados nos módulos da
aplicação. O projeto de um conector nem
sempre é um processo trivial pois envolve a
definiçãodeclasses,hierarquias einterfaces.
Este projeto poderia então ser reaproveitado
através dos design patterns já existentes,
elevandoareutilizaçãodesoftwarecomoum
todo.
Nesta seção apresentamos como alguns
design patterns podem ser implementados
utilizando conectores na construção de
sistemas de software. O critério adotado na
escolha dos design patterns é o fato de
participarem como elementos de interação
entre objetos. Chamaremos tais design
patternsde designpatternsdeinteração ,que
uma vez implementados utilizando
conectores, permitem a interligação dos
módulosenvolvidosnaconfiguração.
4.1–Implementaçãode Design Patternsno
R-RIO
Um dos mais conhecidos catálogos é o
livro Design Patterns: Elements of Reusable
Object-Oriented Software [1]. Os autores
levantaram design patterns de uso geral sem
se aterem a nenhuma aplicação de domínio
específico.
No livro [1], os design patterns
apresentadosestãoorganizadosemtrêstipos:
de criação ( creational patterns) , de estrutura
(structural patterns ) e de comportamento
(behavioral patterns ). Design patterns de
criação estão associados ao processo de
criaçãodeobjetos;deestruturatratamcoma
composição de classes ou objetos e os de
comportamento caracterizam as formas nas
quais os objetos ou classes interagem e
distribuemresponsabilidade.
Nocontextodesterelatório,alguns design
patterns são interessantes para aplicação em
conectores, principalmente aqueles
relacionadosàinteraçãoentreobjetos.Dentre
estesdestacamos4(quatro):
- Chain of Responsibility (de
comportamento);
- Visitor(decomportamento);
- Memento(decomportamento);
- Proxy(deestrutura).
A partir das próximas subseções
apresentaremos uma descrição de cada um
destes e um exemplo de implementação dos
mesmosutilizandoconectores.Umacitaçãoa
outros design patterns de interação que
poderiam ser implementados utilizando
conectoreséfeitanofinaldestaseção.
Todos os exemplos de implementação
foram criados no ambiente R-RIO [4]
utilizando a linguagem Java. Detalhes a
respeito de cada um dos design patterns
citadosestãoem[1].
4.1.1– ChainofResponsibility
Sempre que um objeto (emissor) invoca
um método de outro objeto (receptor), o
últimorespondelogoemseguida,criandoum
acoplamento entre o emissor e o receptor. O
objetivo deste design pattern é diminuir este
acoplamento, permitindo que outros objetos
possamtratardopedidosolicitado.
Para que isto seja possível, objetos
“candidatos” a tratar o pedido formam uma
cadeia de objetos receptores. Desta forma o
pedido é retransmitido até que algum objeto
dacadeiapossatratá-lo.
7 de 16
 Um ponto interessante neste design
pattern é sua capacidade de isolar o emissor
das possíveis manipulações que podem
ocorrer na cadeia. O cliente (emissor) nada
sabe sobre o comportamento dos objetos na
cadeia,seestesatenderãoaopedidoounão.
Outroaspectoimportanteéapossibilidade
de estabelecermos o conjunto de objetos
componentesdacadeiademaneiradinâmica.
O sistema poderia ter objetos anexados à
cadeiaouremovidosemtempodeexecução.
Como exemplo imaginemos a seguinte
situação: um cliente precisa invocar um
método de um objeto por ele instanciado
(servidor) e, durante a invocação, outros
objetos interceptarão o pedido, farão um
tratamentoaopedidoecuidarãodeconclui-lo
juntoaoservidor.Afigura6retrataocenário.
Aspectosrelevantes:
- Cliente invoca método do servidor
assincronamente,ouseja,nãoaguarda
retornodomesmo.
- Qualquerdosobjetos quecompõema
cadeia pode concluir o pedido do
cliente ao servidor (na figura 6, o
último objeto da cadeia conclui o
pedido).
- Se determinado objeto da cadeia não
pode concluir o pedido ao servidor,
encaminha o pedido para o próximo
dacadeia.
- Um objeto invoca um método do
próximo objeto da cadeia
assincronamente.
- Tantoocliente,o servidor, quanto os
objetos encadeados podem estar em
máquinas distintas em um ambiente
distribuído.
Cliente Servidor
Figura6. Exemplo do design pattern Chain of
Responsibility.
Podemos tratar a cadeia do exemplo
dentrodeumconectoreusá-loparainterligar
oclienteeoservidor.Oconectorimplementa
aspectos não diretamente ligados à
funcionalidadedaaplicaçãosemqueocliente
ou o servidor tomemqualquer conhecimento
disto.
O conector chamado de ChainOfResp
possuiduasportas:umainterligadaàportade
saídadomóduloClienteeoutrainterligadaà
porta de entrada do módulo Servidor (figura
7).
porta
Cliente
Servidor
ChainOfResp
Figura7. Design Pattern Chain of Responsibilit y
implementado no conector.
Aconfiguraçãoutilizando esteconector é
análoga à apresentada na figura 2, trocando-
se o conector CORBA pelo conector
ChainOfResp.
O design pattern em questão, quando
implementado utilizando conector, ratifica a
capacidade de reflexão dos conectores R-
RIO. A cadeia de objetos realiza atividades
não relacionadas diretamente à
funcionalidade do sistema. Esta é então
implementada no meta-nível utilizando-se o
conector. Os módulos Cliente e Servidor,
nestecontexto,fariampartedonívelbase.
AspectosdeImplementação
O conector ChainOfResp é composto
principalmente de 3 classes: StartChain,
Handlere FinishChain.Ainstânciadaclasse
StartChain solicita ao primeiro objeto da
cadeiaquetrateainvocaçãofeitapeloCliente
(figura3).Apartirdaí,cadaobjetodacadeia
invoca seu sucessor até que um deles possa
executar a invocação solicitada pelo Cliente.
Quandodeterminadoobjetodacadeiaprecisa
executar a invocação solicitada pelo Cliente,
invoca assincronamente o construtor de
FinishChain. Este encaminha finalmente o
8 de 16
pedido ao Servidor, também de forma em máquinas distintas. Quando da
assíncrona. configuração de módulos em máquinas
distintas, este conector suporta comunicação
A classe abstrata Handler é responsável via Sockets, CORBA ou RMI. Em nossos
por implementar a cadeia de testes implementamos o conector
responsabilidade. Cada objeto pertencente à ChainOfRespcomcomunicaçãovia Sockets.
cadeiaéumainstânciadeumaclasseherdada
de Handler(figura8). 4.1.2– Visitor

Emdeterminadossistemasexistemclasses
sucessor
Handler cujos métodos podem ser agregados com o
objetivodeserealizarumaúnicaoperação.O
forward ( ) design pattern Visitor possibilita a
handleRequest( )
representação desta operação, e ainda que a
mesmasejarealizadaemmaisdeumobjeto.

Como exemplo simples, imaginemos 2

Classe1 Classen (duas) classes representativas de 2 (dois)
handleRequest( )
... handleRequest( )
componentes de um microcomputador. As
classes são HD (disco rígido) e Vídeo
(monitor de vídeo). Estas classes possuem
Figura8. Classe Abstrata Handler. Classe 1, Classe 2 ... diversos métodos, dentre eles métodos com
Classe n representam as classes que serão
instanciadas como parte da cadeia. responsabilidadedecalcularopreçodevenda
do componente. Diante deste cenário é
possível que seja necessário obter o preço
A figura 9 apresenta o código da classe consolidado dos 2 (dois) componentes. Para
abstrata Handler. isso métodos específicos para o cálculo de
preço têm que ser executados em cada
Sempre que determinado objeto que instância das respectivas classes. Em outras
compõe a cadeia quer repassar a palavras, precisamos “visitar” cada instância
responsabilidade a seu sucessor, invoca o e executar o(s) método(s) correspondente(s)
método forward(). Como as classes aocálculodopreçoeobterototal.
envolvidas na cadeia sobrepõem o método
handleRequest(), oobjetoinstanciadoapartir O designpatternVisitor tratadesituações
desta classe pode executar suas atividades e, como esta. Uma estrutura para percorrer os
seconveniente,executar ométodo forward() objetoséestabelecidaecadaobjetoévisitado
paradarseguimentoàcadeia. à procura de métodos que satisfaçam
determinado requerimento. No exemplo
acima, este requerimento traduz-se no preço
import rrio.suporte.*; { dosequipamentos.
abstract class Handler {
Handler sucessor = null;
public void handlerRequest( ) { A classe abstrata Visitor (figura 10)
} mantémuma interfacecommétodos capazes
public void forward( ) {
if (this.sucessor != null) de agregar invocações aos métodos das
classes envolvidas e que atendam ao
this.sucessor.handleRequest( ); requerimento. Por exemplo, os métodos
}
} visitVídeo e visitHD, implementados na
Figura9. Código da classe abstrata Handler.
classe VisitorPreço, invocam métodos da
classe Vídeo e da classe HD que possam
O conector ChainOfResp interliga calcular o preço do monitor de vídeo e do
módulosemumamesmamáquinaemódulos disco rígido respectivamente. Cada classe

9 de 16
concreta oriunda da classe abstrata Visitor
representa um requerimento que deve ser
satisfeito. A classe VisitorPreço é um
exemploderequerimento.
Visitor
visitVídeo (Vídeo)
visitHD (HD)
VisitorPreço VisitorInventário
visitVídeo (Vídeo) ... visitVídeo (Vídeo)
visitHD (HD) visitHD (HD)
Figura10. Classe Abstrata Visitor.
As classes Vídeo e HD originais, para
seremutilizadascomo designpatternVisitor ,
precisam de apenas uma modificação: a
adição do método accept(Visitor v) ao seu
conjunto de métodos. A classe HD, por
exemplo,deveteroseguintecódigoparaseu
método accept(Visitor v):
v.visitHD (this);
visitHD por sua vez invoca os métodos da
classe HD correspondentes ao Visitor
desejado (no exemplo VisitorPreço). Como
veremos, a implementação do Visitor como
conector torna desnecessária esta declaração
nosmódulosenvolvidos.
AspectosdeImplementação
VamoschamardeCliente,oprogramaque
precisautilizaroVisitorPreçoparacalcularo
preço dos equipamentos. A figura 11
apresentaseucódigo.
Um conector correspondente ao design
pattern Visitor pode ser construído
interligando o módulo Cliente com os
módulos que se deseja visitar, conforme
mostradonafigura12.
A classe abstrata da figura 10 é
implementadadentrodoconector.Aoreceber
a invocação do método h.accept(v) (figura
11), o conector monta o código
correspondenteaométodo accept, associando
o Visitor desejado (VisitorPreço) ao objeto
que precisa ser visitado. Desta forma o
conector pode encaminhar a requisição
diretamentepara ainstância do módulo (HD
ou Vídeo), através da porta de entrada do
mesmo módulo. A totalização do preço de
cada equipamento é feita na classe
VisitorPreço,dentrodoconector.
public class Cliente extends Thread {
public HD h;
public Video vid;
VisitorPreco v;
double precoHD;
double precoVideo;
public void run ( ) {
precoHD = h.accept (v);
precoVideo = vid.accept (v);
}
}
Figura11. Código do Módulo Cliente.
HD
Visitor
Cliente
Cliente
Vídeo
Figura12. Design Pattern Visitor implementado no
conector.
Aspectos relevantesdaimplementação do
Visitornoconector:
- Osmódulosnãotêmanecessidadede
declarar o método accept dentre as
demais operações. Isto ocorre pois o
conector tem condições de descobrir,
durante a execução, o Visitor
requerido e o módulo envolvido,
através de reflexão. Desta forma os
módulos obtêm transparência em
relação ao processo realizado pelo
Visitor.
10 de 16
 - A adição de novas operações, que
dependemdosmétodosexistentesnos
módulos é facilitada. Para isso basta
adicionar nova classe ao conector
Visitor. Por exemplo, a classe
VisitorInventário foi adicionada à
classeabstrataVisitordafigura10.
- O Cliente apresentado na figura 11 é
simples e realiza a visita aos objetos
”h” e “vid”. Entretanto, é possível
estabelecer uma estrutura de objetos
mais complexa, como por exemplo
umalista.
- O conector nãoimpede que o Cliente
invoque diretamente os métodos dos
objetosqueparticipamdeum Visitor.
Porexemplo,oClientepodeinvocaro
método que recupera características
técnicasdomonitordevídeo:
vid.caracTecnicas( );
Assim como o conector ChainOfResp, o
conector Visitor podeserimplementado com
características distribuídas. Os módulos
Cliente, HD e Vídeo, por exemplo, podem
estar em hosts diferentes, sendo a
comunicação realizada pelo conector,
utilizando Sockets,RMIouCORBA.
4.1.3– Memento
Em um sistema pode ser necessário
manter o estado interno de determinados
objetosparticipantes.Oestadodeumobjetoé
útil,porexemplo,paraoperaçõesenvolvendo
checkpoints ou undo. Tais mecanismos são
requeridos quando se deseja desfazer uma
operação realizada ou recuperar-se de erros.
Para se desfazer uma operação é necessário
armazenaroestadodoobjetoenvolvidopara
que,posteriormente,arecuperaçãodomesmo
sejapossível.
Entretanto objetos mantêm seus estados
encapsulados, tornando-os inacessíveis a
outros objetos do sistema. A exposição dos
estados violaria o encapsulamento, ferindo a
confiabilidadeeaextensibilidadedomodelo.
O design pattern Memento resolve este
problemamantendoumobjetoquearmazena
um instantâneo ( snapshot) do estado interno
deoutroobjeto.
A figura 13 apresenta a estrutura do
Memento.
Originator
setMemento (Memento m) ο
createMemento ( ) ο
state
return new Memento (state)
Memento
getState ( )
setState ( )
state = m.getState( )
state
Figura13. DesignPattern Memento. O objeto Originator
torna disponível seu estado para o
armazenamento em Memento.
O objeto Memento armazena o estado
internodoobjeto Originatoresomentepode
seracessadoporestemesmoobjeto.
Quandoqualqueroperaçãoquemodifique
oestadode Originatoréacionada,ométodo
createMemento( ) deve ser invocado para que o
estado torne-se disponível. Por outro lado,
quando da operação de undo (desfazer a
última operação), o método
setMemento(Memento m) deve ser acionado para
buscar o estado anterior armazenado em
Memento.
AspectosdeImplementação
O design pattern Memento pode ser
implementado através de conector como
mostraafigura14.
Na implementação, o módulo Servidor
possuiumainterfacecommétodosinerentesà
sua funcionalidade, mais os dois métodos
responsáveisemtornardisponívelseuestado
( setMemento( ) e createMemento( ) ). Portanto o
móduloServidortemcorrespondênciacomo
objeto Originator mostrado na figura 13, ou
11 de 16
seja,precisamanterumestadocomobjetivos
derestauração.
Quanto ao Cliente, este apenas invoca
métodos do módulo Servidor, provocando
mudanças no estado deste último. Além
disso, o Cliente pode, a qualquer instante,
solicitar a operação de undo para desfazer a
últimaoperaçãoefetuadanoServidor.
Cliente
Cliente Servidor
Servidor
Memento
Figura14. Design Pattern Memento implementado no
conector.
O conector, graças à sua capacidade de
reflexão,podeinterceptarasinvocaçõesfeitas
pelo Cliente ao Servidor. As interceptações
permitem ao conector gerenciar e controlar
vários mementos criados pelo módulo
Servidor, além de tornar transparente a este
mesmo módulo o momento da criação e
acessoaosmementos.Istotornaocódigodo
móduloServidormaissimplesededicadoaos
seusaspectosfuncionais.
O módulo Clientetambémtemvantagens
com relação à implementação deste design
patternatravésdoconector.O designpattern
Memento apresentado em [1] assume que o
objeto Caretaker (correspondente ao nosso
móduloCliente) deveinvocar explicitamente
os métodos createMemento( ) e setMemento( ) para
permitir ao Originator salvar seu estado e
recuperá-lo, respectivamente. A nossa
implementação não exige esta invocaçãopor
parte do Cliente. O Cliente precisa apenas
invocar os métodos inerentes à instantâneos( snapshots)domóduloServidor.
funcionalidade da aplicação e o conector
invocará,nomomentoadequado,osmétodos
citadosacima.
Comoexemploapresentamosnafigura15
uma possível interface para o módulo
Servidor.
Quando o módulo Cliente invoca o
método update() de Servidor, o conector
intercepta a invocação. Ao descobrir que o
Cliente está invocando o método update(), o
conector invoca createMemento() do módulo
Servidor,oqualcriaoMemento,salvandoo
estadodoServidor.Apósesteprocessamento
ainvocaçãoaométodo update() éretomada.
public class Servidor extends Thread {
int state = 0;
Memento createMemento() {
Memento m = new Memento (state);
return m;
}
void setMemento (Memento m) {
state = m.getState();
}
boolean update(int arg) {
// ... código para atualizar o estadostate...
}
boolean undo() {
// ... apenas o código funcional relacionado
// ... à operação undo(). A execução do
// ... undo() não precisa ser feita aqui.
// ... Ela é executada no conector.
}
}
Figura15. Código do Módulo Servidor.
O Cliente, quando necessário, pode
desfazer a última operação invocando o
método undo(). Esteérealizadonoconector,o
qualinvocaométodo setMemento() doServidor
para restauração do estado. Se alguma
funcionalidade precisa ser executada após a
operação undo(), esta pode ser codificada no
módulo Servidor (figura 15). Outro ponto
interessante desta solução é a possibilidade
do conector gerenciar e controlar vários
Uma possibilidade seria, por exemplo,
empilhar os instantâneos. O cliente poderia
assim desfazer, por exemplo, 5 (cinco)
operaçõesrealizadas.
Este conector, como os demais, pode
separar os módulos Cliente e Servidor em
hosts distintos utilizando Sockets, RMI ou
CORBA.
12 de 16
 4.1.4– Proxy comcapacidadedecodificação(criptografia).
O conector ligaria o Cliente, localizado em
Os 3 (três) design patterns até agora um host, ao Servidor, localizado em outro
apresentados ( Chain Of Responsibility , host. A invocação por parte do Cliente seria
Visitor e Memento) são classificados por [1] interceptada e codificada para o envio até o
em design patterns de comportamento. O móduloServidor.
Proxy, último ao qual apresentaremos um
exemplo,éoúnicoclassificadocomo design
pattern deestrutura. Subject
request( )
...
O Proxyofereceumaespéciedesubstituto
paraoutroobjetocomoobjetivodecontrolá-
lo. Proxyéaplicávelemsituaçõesnasquaisé
necessáriaumareferênciamaisversátil aum
RealSubject realSubject Proxy
objeto.Porexemplo, proxiesdeproteçãosão
request( ) request ( ) ο
úteis para verificar os direitos de acesso a ... ...
determinadoobjeto.Antesquealgummétodo
deste objeto seja invocado, o objeto proxy
verifica se o originário da mensagem tem
permissãodeacessoaoobjetodestino. ...
realSubject.request( )
...
A estrutura do design pattern Proxy
aparecenafigura16. Figura16. Design Pattern Proxy. O objeto Proxy tem a
mesma interface do objeto destino
RealSubject.
O objeto Proxy possui a mesma interface
doobjetodestino.Destaformaestetemuma
referênciaaoobjeto destinoe pode controlar
oacessoaomesmo.
Cliente
Cliente Servidor
Servidor
AspectosdeImplementação
Proxy

Como ilustração da potencialidade do Figura17. Design Pattern Proxy implementado no

conectornaimplementaçãodo design pattern
Proxy, implementamos um conector que
verifica se um objeto Cliente possui
permissão para invocar métodos do objeto
Servidor. A configuração do sistema é
apresentadanafigura17.
A capacidade de reflexão do conector
simplifica de maneira considerável o
problema proposto. O conector tem a
capacidadedeinterceptarasinvocaçõesfeitas
pelo Cliente e realizar qualquer verificação
necessária. Os módulos Cliente e Servidor
não têm conhecimento da presença do
mecanismo de verificação de permissão
implementadonoconector Proxy.
Outro exemplo de Proxy seria a
implementação de um conector distribuído
conector.
4.2–Outros DesignPatterns
Design patternsqueenvolvemainteração
entre objetos são candidatos em potencial à
implementação utilizando R-RIO. Outros
citados em [1] e que poderiam ser
implementados utilizando conectores R-RIO
são:
- Observer
- Mediator
- State
- Iterator.
Todoselestêmcaracterísticasdeinteração
entre objetos. O Observer define uma
dependênciaum-para-muitosentreobjetostal
quequandoumobjetomudaseuestado,todos

13 de 16
seus dependentes são notificados e
atualizadosautomaticamente.Umexemplode
implementação do design pattern Observer
utilizando conectores R-RIO pode ser
encontrado em [15]. O exemplo é uma
aplicação do jogo TicTacToe (“jogo da
velha”)noqualumjogadorexecutaoslances
e módulos Display recebem a atualização da
situaçãodojogo.Estes módulosrepresentam
osobservadoresdojogo.
O Mediator define um objeto que
encapsula como um conjunto de objetos
interage, evitando que os objetos deste
conjunto referenciem-se explicitamente. Este
design pattern age como um elemento
centralizador, “roteando” as mensagens de
umobjetoaoutro.Eleéaplicadoquandoum
conjunto de objetos se comunica de forma
bem estruturada entretanto complexa,
tornando dificultada a reutilização de um
objeto. O Mediator poderia ser construído
atravésdeumconectorR-RIOinterligandoos
objetosdoconjuntoporeleinterligado.
Objetos mantêm estados internos e estes
podem se alterar conforme execução do
sistema. O design pattern State permite que
um objeto altere seu comportamento quando
da alteração de seu estado. Um conjunto de
subclasses é estabelecido para tratar cada
possível estado do objeto, particionando o
comportamento para os diferentes estados.
MaisumavezaestruturadeR-RIOfacilitaa
implementação.Nocasodo State,oconector
ficaria encarregado de manter este conjunto
de subclasses, mantendo conseqüentemente
ospossíveisestadosdoobjeto.
Finalmente, o Iterator também pode ser
tratadoporR-RIO.Muitasvezesdeterminado
objeto representa seqüências, nas quais os
elementos devem ser acessados. Este design
pattern permite este acesso sem que a
representação do objeto precise ser exposta.
Umalistaporexemplopoderiaserpercorrida
utilizando múltiplos mecanismos, oferecidos
pela classe do design pattern chamada
ListIterator.Destaforma,ainterfaceoriginal
do objeto Lista seria preservada. Iterator
poderia ser encapsulado em um conector R-
RIOoqualligariaclientesdeListaaoobjeto
Lista e ainda estabeleceria a interface e
mecanismosnecessáriosparapercorrê-la.
5–Conclusão
A concepção de sistemas de software
passa pela arquitetura de software. Esta
representa os componentes definidos e a
inter-relação entre eles. A definição de uma
arquiteturaéfeitaatravésdeumaADL.
A utilização de uma ADL possibilita a
seleção e especificação dos componentes do
sistema e conectores. Em R-RIO os
conectores interligam módulos (nome dado
por R-RIO a componentes), facilitando a
separação de interesses. Conectores R-RIO
possuemcapacidadedereflexão,umavezque
têm facilidade em interceptar e manipular
requisiçõesdeeparaosmódulos.
Neste relatório apresentamos a
implementação de design patterns no
ambiente R-RIO, particularmente utilizando-
se conectores. Analisamos design patterns
relacionados à interação entre objetos e, a
partir do catálogo [1], destacamos quatro
deles para implementação e testes no
ambiente R-RIO: Chain of Responsibility ,
Visitor, Memento e Proxy. Implementamos
estes quatro utilizando conectores R-RIO e
citamos outros, também relacionados à
interação, que podem ser implementados:
Observer, Mediator, Statee Iterator.
Nossos estudos, implementações e testes
comprovamque designpatterns deinteração,
de forma geral, podem ser implementados
com a utilização de conectores R-RIO. O
ambiente R-RIO, dadas suas características
de distribuição e separação de interesses,
facilita a implementação de design patterns
queenvolveminteraçãoentreobjetos.
Além disso, conectores R-RIO tornam
possível o tratamento de aspectos não
relacionados diretamente à funcionalidade
dosobjetosenvolvidos. Visitor,porexemplo,
envolveainteraçãoentreummóduloCliente
e um ou mais módulos que são “visitados”.
14 de 16
As instâncias destes módulos e do módulo
Cliente interagem de forma transparente,
ignorando o conector. O conector, neste
contexto, faz o papel de um Visitor atuando
narealizaçãodeaspectoscomplementaresda
aplicação,nãoprevistosouencapsuladosnos
seusmódulosbásicos,quandodeseuprojeto.
Os design patterns de interação citados
foram implementados e testados utilizando
conectores R-RIO. A partir do estudo
apresentado neste relatório, investigaremos a
possibilidade de se implementar design
patterns no R-RIO de tal forma que estes
possam se adequar às aplicações de forma
transparente.Teríamosassimumaespéciede
repositóriode designpatterns implementados
e prontos para se adequarem ao contexto de
umadeterminadaaplicação.
6–Referências
[1] Gamma, E., Helm, R., Johson, R.,
Vlissides,J. “Design Patterns: Elements
of Reusable Object-Oriented Software”,
Addison-Wesley,EUA,1995.
[2] Sztajnberg, A. “Flexibilidade e
SeparaçãodeInteresses paraConcepção
e Evolução de Sistemas Distribuídos”.
Exame de Tese de Doutorado. COPPE-
UFRJ,março,1999.
[3] Lobosco, M., “Um Ambiente para
Suporte à Construção e Evolução de
Sistemas Distribuídos”, dissertação de
mestrado,IC/UFF,março,1999.
[4] Loques, O., Leite, J., Lobosco, M.,
Sztajnberg, A., “Integrating Meta-Level
Programming and Configuration
Programming”, Workshop on Object
Oriented Reflection and Software
Engineering, OOPSLA’99, Denver,
Colorado,novembro1999.
[5] Arnold, K., Gosling, J., “The Java
Programming Language”, Second
Edition, Sun Microsystems, Addison-
Wesley,EUA,1998.
[6] OMG, “The Common Object Request
Brocker: Architecture and
Specification”, Revision 2.3, Dezembro,
1998.
[7] Schmidt,D.,C.,Fayad,M.,Johnson,R.
“Software Patterns”, ACM
Communications,vol.39,n.10,outubro
1996.
[8] Rising, L. “Patterns: A Way to Reuse
Expertise”.IEEECommunications,abril
1999.
[9] Budd, T. “On Introduction to Object-
Oriented Programming” – Second
Edition.Addison-Wesley,EUA,1996.
[10] Srinivasam, S. “Design Patterns in
Object-Oriented Frameworks”. IEEE
Computer,fevereiro1999.
[11] Suzuki, J., Yamamoto, Y.
“OpenWebServer: An Adaptative Web
Server Using Software Patterns”, IEEE
Communications,abril1999.
[12] Adair, D. “Building Object-Oriented
Frameworks”. AIXpert, fevereiro e
março1995.
[13] Shaw M., DeLine, R., Klein, D., Ross,
T., Young, D., Zelesnik G.,
“Abstractions for Software Architecture
and Tools to Support Then”, IEEE
Transactions on Software Engineering,
Vol.21,No.4,Abril1995,pp.314-335.
[14] Malucelli, V.V., “Babel – Construindo
Aplicações por Evolução”, dissertação
de mestrado, DEE / PUC-RJ, Fevereiro
1996.
[15] Sztajnberg,A.,Lobosco,M.,Loques,O.
“Configurando Protocolos de Interação
na Abordagem R-RIO”, SBES,
Florianópolis,SantaCatarina,1999.
[16] Appleton, B. “Patterns and
Software:Essential Concepts and
Terminology”, disponível em
15 de 16
 http://www.enteract.com/~bradapp/docs/
patterns-intro.html,2000.

[17] Booch, G., Rumbaugh J., Jacobson I.,

“The Unified Modeling Language User
Guide”. Object Technology Series.
Addison-Wesley,1999.

[18] Ambler, S. W., “CRC Modeling:

Bridging the Communication Gap
Between Developers and Users.” White
PaperAmbysoft.Novembro,1998.
Disponívelem
http://www.ambysoft.com/crcModeling.
html.

[19] Buschmann, F., Meunier, R., Rohnert,

H.,Sommerlad,P.,Stal,M.,“A System
of Patterns-Pattern-Oriented Software
Architecture”.JohnWiley&Sons,1996.

[20] Schmidt, D., Stal, M., Rohnert, H.,

Buschmann F. “Pattern-Oriented
Software Architecture-Patterns for
Concurrent and Networked Objects”,
Volume2.JohnWiley&Sons,2000.

16 de 16