Integrando Design Patterns em Arquiteturas de Software

Transcrição

1 Integrando Design Patterns em Arquiteturas de Software Sérgio Teixeira de Carvalho Orlando Gomes Loques Fi lho Computação Aplicada e Automação Instituto de Computação Universidade Federal Fluminense Resumo A composição de sistemas parte da definição de uma Arquitetura de que descreva seus componentes e o inter-relacionamento entre eles. O definição da arquitetura é chamado Configuração. Software processo de Design Patterns podem ser empregados quando da configuração de sistemas. 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. Neste relatório apresentamos um estudo de como alguns design patterns podem ser empregados em conjunto com a configuração quando da elaboração e constru ção de sistemas distribuídos. Destacamos design patterns considerados de interação entre objetos e apresentamos exemplos de implementação utilizando conectores R-RIO.

2 Integrando Design Patterns em Arquiteturas de Software Sérgio Teixeira de Carvalho Orlando Gomes Loques F ilho sergiotc@ic.uff.br loques@ic.uff.br Computação Aplicada e Automação Instituto de Computação Universidade Federal Fluminense 1 - Introdução A concepção de software constitui-se uma tarefa árdua em vários aspectos, particularmente no tocante à 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, na maioria dos casos, partia da reutilização da 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, aspectos de tolerância a falhas, etc. A composição de uma aplicação parte do estabelecimento dos componentes envolvidos 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 (Architecture Description Language ). 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 estabelecer a ligação entre os componentes e intermediar a interação entre os mesmos. Além disso podem encapsular aspectos não diretamente relacionados à funcionalidade de determinada aplicação, enquanto os componentes realizam preferencialmente os aspectos funcionais da mesma aplicação. Ainda com respeito à reutilização de software existe a preocupação em relação ao reaproveitamento da experiência do projetista. Durante o projeto de software, objetos devem ser encontrados e fatorados em classes, interfaces devem ser definidas, 2 de 16

3 hierarquias de herança precisam ser estabelecidas, etc. O conhecimento a cerca do projeto, associado aos seus problemas e soluções, pode ser reaproveitado para utilização em outros projetos vindouros, seja do mesmo projetista ou até mesmo de outros. 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 consultados por desenvolvedores em busca da 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 empregados em conjunto com a configuração quando da elaboração e construção de sistemas. Para isso destacamos alguns 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, Reconfigurable Interconnectable Objects )[4] através da linguagem Java [5]. Este relatório está dividido em 6 seções. Na seção 2 tratamos do processo de configuração de sistemas e da abordagem R- 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 design patterns de interação utilizando conectores R-RIO. Conclusões estão na seção 5 e a seção 6 lista as referências. 2 Configuração de Sistemas 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 componentes e os elementos de interconexão entre os mesmos, chamados conectores. O desenvolvimento de software baseado em configuração desloca o foco do projetista para a arquitetura do sistema, constituída dos componentes e suas interligações. A visualização da arquitetura permite que componentes sejam adicionados ou removidos sem a preocupação com os detalhes de implementação de cada um deles. 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ção entre estes R-RIO ( Reflective, Reconfigurable Interconnectable Objects ) A abordagem R-RIO ( Reflective, Reconfigurable Interconnectable Objects ) [3, 4] permite que se descreva a estrutura de aplicações a partir de seus componentes, suas interligações e seus aspectos não diretamente relacionados à sua funcionalidade, tais como a distribuição, coordenação, protocolos de comunicação e outros. O modelo de R-RIO está baseado em três elementos bá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ções entre os módulos; - Portas: pontos de acesso pelos quais módulos e conectores oferecem ou solicitam serviços. A figura 1 mostra o inter-relacionamento entre os elementos básicos de R-RIO. As classes de módulos são mapeadas para uma implementação. Por exemplo, Módulo 1 e Módulo 2 são instâncias de módulos 3 de 16

4 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ção dos métodos da classe. Quanto às portas de saída, estas seriam invocações de método. Conector porta Módulo 1 Módulo 2 Figura 1. 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 dos módulos envolvidos. Isto ocorre devido à facilidade do mesmo em interceptar e manipular requisições de e para os módulos. Observamos com isso a capacidade de reflexão do conector R-RIO. A reflexão, quando empregada, trata o sistema em dois níveis: nível base e metaní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ções realizadas no nível base podem ser interceptadas e direcionadas para o metanível. Este realiza o devido tratamento às operações e as reencaminha, podendo inclusive desviá-las de seu curso normal. A integração da configuração e reflexão tem sido objeto de estudo [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, reiniciar estes mesmos módulos, dentre outras funções. Para o caso de sistemas distribuídos, os módulos podem ser instanciados em qualquer host do sistema. 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 arquitetura deste sistema é similar à figura 1, 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 armazenamento e a recuperação da descrição de módulos, conectores e aplicações [4]. Fundamentos de Babel são tratados em [14]. Após a descrição da arquitetura faz-se necessário codificar os módulos correspondentes, instanciá-los e executá-los no sistema R-RIO. Os dois módulos foram implementados como classes Java. O módulo Cliente simplesmente invoca um método do módulo Servidor. A porta de saída do módulo Cliente (figura 3) é indicada pela invocação do método obtemmsg() da instância srv. A porta de entrada do módulo Servidor (figura 4) é representada pela declaração do método obtemmsg(). Importante notar que as classes das figuras 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. Detalhes podem ser encontrados em [3]. Após a codificação das classes é o momento de instanciá-las no sistema. Além de instanciá-las em hosts distintos, as ligamos através de um conector CORBA [6], já codificado e pertencente ao repositório de R- RIO. Os comandos necessários para as instanciações e a ligação ao conector estão na figura 5. 4 de 16

5 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; Figura 2. Arquitetura da Aplicação public class Cliente extends Thread { public Servidor srv; public void run () { System.out.println (srv.obtemmsg()) ; Figura 3. Código do Módulo Cliente. public class Servidor extends Thread { public void run (){ public String obtemmsg () { return Mensagem do Servidor ; Figura 4. 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 entre o Cliente e o Servidor é fácil, bastando para isso utilizar o conector apropriado, digamos Sockets ao invés de CORBA. 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. Figura 5. Comandos de Configuração. Na próxima seção abordaremos conceitos e características dos design patterns a fim de, na parte 4, apresentarmos alguns deles implementados utilizando conectores R-RIO. 3 Design Patterns Durante o projeto de software, objetos devem ser definidos e fatorados em classes, interfaces devem ser criadas, hierarquias de herança precisam ser estabelecidas, 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ções se tornam então padrões recorrentes de classes e objetos em muitos sistemas orientados a objeto [1]. Tais padrões resolvem problemas de projetos específicos e os tornam mais flexíveis, elegantes e reutilizáveis. Os design patterns são mecanismos de representação de problemas recorrentes acompanhados de suas respectivas soluções [1]. Eles permitem o compartilhamento da experiência de especialistas de diversas áreas e constituem-se em uma maneira de reutilizar a experiência no projeto de software. 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 conhecidos e suas soluções. 5 de 16

6 Importante salientar entretanto que 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 design pattern deve ter sido aplicada, no mínimo, três vezes [16]. Em outras palavras, não é feito o registro apenas de uma boa idéia, mas sim de uma solução aplicada em um cenário real. Outra característica importante dos 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 de programação [8]. Design patterns têm sido empregados no contexto de frameworks orientados a objetos. 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. Exemplos podem ser encontrados em [10] e [11]. Mais detalhes de como um framework é construído podem ser encontrados em [12]. 3.1 Descrição de um Design Pattern 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és de 4 (quatro) elementos essenciais [1, 8]. Nome: palavra ou frase que descreve o design pattern. Deve sintetizar o conceito que representa, minimizando os problemas de comunicação. O nome de um design pattern, 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 à tona o seu significado. Problema: este é o problema específico a ser resolvido. Descreve o objetivo do design pattern, quando aplicá-lo e o contexto ao qual aplicá-lo, ou seja, a configuração na qual o problema é encontrado. Solução: descrição da essência da solução, isto é, componentes envolvidos, 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. Um exemplo de implementação també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 custobenefício. Também são apresentados design patterns relacionados àquele em questão. Na próxima seção, apresentaremos alguns design patterns relacionados à interação entre objetos. Abordaremos a aplicação destes à configuração de sistemas distribuídos utilizando conectores R-RIO. 4 Configuração e Design Patterns O nível de reutilização que a configuraçã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 independentes e interagem uns com os outros através de conectores, responsáveis pela 6 de 16

7 interligação. Quanto aos design patterns, estes possibilitam a reutilização de software relacionada à expertise empregada. Em outras palavras, podemos reaproveitar o que outros projetistas já desenvolveram em termos de modelo e projeto. Esse reaproveitamento pode se dar por intermédio dos catá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ção de classes, hierarquias e interfaces. Este projeto poderia então ser reaproveitado através dos design patterns já existentes, elevando a reutilização de software como um 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 patterns de design patterns de interação, que uma vez implementados utilizando conectores, permitem a interligação dos módulos envolvidos na configuração. 4.1 Implementação de Design Patterns no 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 apresentados estão organizados em três tipos: 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ção de objetos; de estrutura tratam com a composição de classes ou objetos e os de comportamento caracterizam as formas nas quais os objetos ou classes interagem e distribuem responsabilidade. No contexto deste relatório, alguns design patterns são interessantes para aplicação em conectores, principalmente aqueles relacionados à interação entre objetos. Dentre estes destacamos 4 (quatro): - Chain of Responsibility (de comportamento); - Visitor (de comportamento); - Memento (de comportamento); - Proxy (de estrutura). A partir das próximas subseções apresentaremos uma descrição de cada um destes e um exemplo de implementação dos mesmos utilizando conectores. Uma citação a outros design patterns de interação que poderiam ser implementados utilizando conectores é feita no final desta seçã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 citados estão em [1] Chain of Responsibility Sempre que um objeto (emissor) invoca um método de outro objeto (receptor), o último responde logo em seguida, criando um acoplamento entre o emissor e o receptor. O objetivo deste design pattern é diminuir este acoplamento, permitindo que outros objetos possam tratar do pedido solicitado. 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 da cadeia possa tratá-lo. 7 de 16

8 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, se estes atenderão ao pedido ou não. Outro aspecto importante é a possibilidade de estabelecermos o conjunto de objetos componentes da cadeia de maneira dinâmica. O sistema poderia ter objetos anexados à cadeia ou removidos em tempo de execuçã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 tratamento ao pedido e cuidarão de conclui-lo junto ao servidor. A figura 6 retrata o cenário. Aspectos relevantes: - Cliente invoca método do servidor assincronamente, ou seja, não aguarda retorno do mesmo. - Qualquer dos objetos que compõem a 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 da cadeia. - Um objeto invoca um método do próximo objeto da cadeia assincronamente. - Tanto o cliente, o servidor, quanto os objetos encadeados podem estar em máquinas distintas em um ambiente distribuído. Cliente Servidor Figura 6. Exemplo do design pattern Chain of Responsibility. Podemos tratar a cadeia do exemplo dentro de um conector e usá-lo para interligar o cliente e o servidor. O conector implementa aspectos não diretamente ligados à funcionalidade da aplicação sem que o cliente ou o servidor tomem qualquer conhecimento disto. O conector chamado de ChainOfResp possui duas portas: uma interligada à porta de saída do módulo Cliente e outra interligada à porta de entrada do módulo Servidor (figura 7). Cliente ChainOfResp porta Servidor Figura 7. Design Pattern Chain of Responsibilit y implementado no conector. A configuração utilizando este conector é análoga à apresentada na figura 2, trocandose 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, neste contexto, fariam parte do nível base. Aspectos de Implementação O conector ChainOfResp é composto principalmente de 3 classes: StartChain, Handler e FinishChain. A instância da classe StartChain solicita ao primeiro objeto da cadeia que trate a invocação feita pelo Cliente (figura 3). A partir daí,cada objeto da cadeia invoca seu sucessor até que um deles possa executar a invocação solicitada pelo Cliente. Quando determinado objeto da cadeia precisa executar a invocação solicitada pelo Cliente, invoca assincronamente o construtor de FinishChain. Este encaminha finalmente o 8 de 16

9 pedido ao Servidor, também de forma assíncrona. A classe abstrata Handler é responsável por implementar a cadeia de responsabilidade. Cada objeto pertencente à cadeia é uma instância de uma classe herdada de Handler (figura 8). em máquinas distintas. Quando da configuração de módulos em máquinas distintas, este conector suporta comunicação via Sockets, CORBA ou RMI. Em nossos testes implementamos o conector ChainOfResp com comunicação via Sockets Visitor Handler forward ( ) handlerequest( ) sucessor Em determinados sistemas existem classes cujos métodos podem ser agregados com o objetivo de se realizar uma única operação. O design pattern Visitor possibilita a representação desta operação, e ainda que a mesma seja realizada em mais de um objeto. Classe 1 handlerequest( )... Classe n handlerequest( ) Figura 8. Classe Abstrata Handler. Classe 1, Classe 2... Classe n representam as classes que serão instanciadas como parte da cadeia. A figura 9 apresenta o código da classe abstrata Handler. Sempre que determinado objeto que compõe a cadeia quer repassar a responsabilidade a seu sucessor, invoca o método forward(). Como as classes envolvidas na cadeia sobrepõem o método handlerequest(), o objeto instanciado a partir desta classe pode executar suas atividades e, se conveniente, executar o método forward() para dar seguimento à cadeia. import rrio.suporte.*; { abstract class Handler { Handler sucessor = null; public void handlerrequest( ) { public void forward( ) { if ( this.sucessor!= null) Figura 9. this.sucessor.handlerequest( ); Código da classe abstrata Handler. O conector ChainOfResp interliga módulos em uma mesma máquina e módulos Como exemplo simples, imaginemos 2 (duas) classes representativas de 2 (dois) componentes de um microcomputador. As classes são HD (disco rígido) e Vídeo (monitor de vídeo). Estas classes possuem diversos métodos, dentre eles métodos com responsabilidade de calcular o preço de venda do componente. Diante deste cenário é possível que seja necessário obter o preço consolidado dos 2 (dois) componentes. Para isso métodos específicos para o cálculo de preço têm que ser executados em cada instância das respectivas classes. Em outras palavras, precisamos visitar cada instância e executar o(s) método(s) correspondente(s) ao cálculo do preço e obter o total. O design pattern Visitor trata de situações como esta. Uma estrutura para percorrer os objetos é estabelecida e cada objeto é visitado à procura de métodos que satisfaçam determinado requerimento. No exemplo acima, este requerimento traduz-se no preço dos equipamentos. A classe abstrata Visitor (figura 10) mantém uma interface com métodos capazes de agregar invocações aos métodos das classes envolvidas e que atendam ao requerimento. Por exemplo, os métodos visitvídeo e visithd, implementados na classe VisitorPreço, invocam métodos da classe Vídeo e da classe HD que possam calcular o preço do monitor de vídeo e do disco rígido respectivamente. Cada classe 9 de 16

10 concreta oriunda da classe abstrata Visitor representa um requerimento que deve ser satisfeito. A classe VisitorPreço é um exemplo de requerimento. Visitor visitvídeo (Vídeo) visithd (HD) 11), o conector monta o código correspondente ao método accept, associando o Visitor desejado (VisitorPreço) ao objeto que precisa ser visitado. Desta forma o conector pode encaminhar a requisição diretamente para a instâ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, dentro do conector. VisitorPreço visitvídeo (Vídeo) visithd (HD) Figura VisitorInventário visitvídeo (Vídeo) visithd (HD) Classe Abstrata Visitor. As classes Vídeo e HD originais, para serem utilizadas com o design pattern Visitor, 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, deve ter o seguinte código para seu método accept(visitor v): 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); Figura 11. Código do Módulo Cliente. 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 nos módulos envolvidos. Cliente Visitor HD Vídeo Aspectos de Implementação Vamos chamar de Cliente, o programa que precisa utilizar o VisitorPreço para calcular o preço dos equipamentos. A figura 11 apresenta seu có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 mostrado na figura 12. A classe abstrata da figura 10 é implementada dentro do conector. Ao receber a invocação do método h.accept(v) (figura Figura 12. Design Pattern Visitor implementado no conector. Aspectos relevantes da implementação do Visitor no conector: - Os módulos não têm a necessidade de 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

11 - A adição de novas operações, que dependem dos métodos existentes nos módulos é facilitada. Para isso basta adicionar nova classe ao conector Visitor. Por exemplo, a classe VisitorInventário foi adicionada à classe abstrata Visitor da figura 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 uma lista. - O conector não impede que o Cliente invoque diretamente os métodos dos objetos que participam de um Visitor. Por exemplo, o Cliente pode invocar o método que recupera características técnicas do monitor de vídeo: vid.caractecnicas( ); Assim como o conector ChainOfResp, o conector Visitor pode ser implementado 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, RMI ou CORBA Memento Em um sistema pode ser necessário manter o estado interno de determinados objetos participantes. O estado de um objeto é útil, por exemplo, para operações envolvendo 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 armazenar o estado do objeto envolvido para que, posteriormente, a recuperação do mesmo seja possí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 confiabilidade e a extensibilidade do modelo. O design pattern Memento resolve este problema mantendo um objeto que armazena um instantâneo ( snapshot) do estado interno de outro objeto. A figura 13 apresenta a estrutura do Memento. Figura 13. Originator setmemento (Memento m) creatememento ( ) ο state return new Memento (state) state = m.getstate( ) ο Memento getstate ( ) setstate ( ) state Design Pattern Memento. O objeto Originator torna disponível seu estado para o armazenamento em Memento. O objeto Memento armazena o estado interno do objeto Originator e somente pode ser acessado por este mesmo objeto. Quando qualquer operação que modifique o estado de Originator é acionada, o mé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. Aspectos de Implementação O design pattern Memento pode ser implementado através de conector como mostra a figura 14. Na implementação, o módulo Servidor possui uma interface com métodos inerentes à sua funcionalidade, mais os dois métodos responsáveis em tornar disponível seu estado ( setmemento( ) e creatememento( ) ). Portanto o módulo Servidor tem correspondência com o objeto Originator mostrado na figura 13, ou 11 de 16

12 seja, precisa manter um estado com objetivos de restauraçã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 última operação efetuada no Servidor. Cliente está invocando o método update(), o conector invoca creatememento() do módulo Servidor, o qual cria o Memento, salvando o estado do Servidor. Após este processamento a invocação ao método update() é retomada. public class Servidor extends Thread { int state = 0; Cliente Cliente Figura 14. Memento Servidor Design Pattern Memento implementado no conector. Memento creatememento() { Memento m = new Memento (state); return m; void setmemento (Memento m) { state = m.getstate(); O conector, graças à sua capacidade de reflexão, pode interceptar as invocações feitas 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 acesso aos mementos. Isto torna o código do módulo Servidor mais simples e dedicado aos seus aspectos funcionais. O módulo Cliente também tem vantagens com relação à implementação deste design pattern através do conector. O design pattern Memento apresentado em [1] assume que o objeto Caretaker (correspondente ao nosso módulo Cliente) deve invocar 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ção por parte do Cliente. O Cliente precisa apenas invocar os métodos inerentes à funcionalidade da aplicação e o conector invocará, no momento adequado, os métodos citados acima. Como exemplo apresentamos na figura 15 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 boolean update(int arg) { //... código para atualizar o estado state... 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. Figura 15. Código do Módulo Servidor. O Cliente, quando necessário, pode desfazer a última operação invocando o método undo(). Este é realizado no conector, o qual invoca o método setmemento() do Servidor 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 instantâneos ( snapshots) do módulo Servidor. Uma possibilidade seria, por exemplo, empilhar os instantâneos. O cliente poderia assim desfazer, por exemplo, 5 (cinco) operações realizadas. Este conector, como os demais, pode separar os módulos Cliente e Servidor em hosts distintos utilizando Sockets, RMI ou CORBA. 12 de 16

13 4.1.4 Proxy Os 3 (três) design patterns até agora apresentados ( Chain Of Responsibility, Visitor e Memento) são classificados por [1] em design patterns de comportamento. O Proxy, último ao qual apresentaremos um exemplo, é o único classificado como design pattern de estrutura. O Proxy oferece uma espécie de substituto para outro objeto com o objetivo de controlálo. Proxy é aplicável em situações nas quais é necessária uma referência mais versátil a um objeto. Por exemplo, proxies de proteção são úteis para verificar os direitos de acesso a determinado objeto. Antes que algum método deste objeto seja invocado, o objeto proxy verifica se o originário da mensagem tem permissão de acesso ao objeto destino. A estrutura do aparece na figura 16. design pattern Proxy O objeto Proxy possui a mesma interface do objeto destino. Desta forma este tem uma referência ao objeto destino e pode controlar o acesso ao mesmo. Aspectos de Implementação Como ilustração da potencialidade do conector na implementação do 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 é apresentada na figura 17. A capacidade de reflexão do conector simplifica de maneira considerável o problema proposto. O conector tem a capacidade de interceptar as invocações feitas 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 implementado no conector Proxy. Outro exemplo de Proxy seria a implementação de um conector distribuído com capacidade de codificação (criptografia). O conector ligaria o Cliente, localizado em um host, ao Servidor, localizado em outro host. A invocação por parte do Cliente seria interceptada e codificada para o envio até o módulo Servidor. RealSubject request( )... Figura 16. Cliente Cliente Figura 17. Subject request( )... realsubject Proxy request ( ) realsubject.request( )... Design Pattern Proxy. O objeto Proxy tem a mesma interface do objeto destino RealSubject. Proxy Servidor Design Pattern Proxy implementado no conector. 4.2 Outros Design Patterns Design patterns que envolvem a interaçã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. Todos eles têm características de interação entre objetos. O Observer define uma dependência um-para-muitos entre objetos tal que quando um objeto muda seu estado, todos ο 13 de 16

14 seus dependentes são notificados e atualizados automaticamente. Um exemplo de 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 ) no qual um jogador executa os lances e módulos Display recebem a atualização da situação do jogo. Estes módulos representam os observadores do jogo. 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 um objeto a outro. Ele é aplicado quando um 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és de um conector R-RIO interligando os objetos do conjunto por ele interligado. 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. Mais uma vez a estrutura de R-RIO facilita a implementação. No caso do State, o conector ficaria encarregado de manter este conjunto de subclasses, mantendo conseqüentemente os possíveis estados do objeto. Finalmente, o Iterator também pode ser tratado por R-RIO. Muitas vezes determinado 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. Uma lista por exemplo poderia ser percorrida utilizando múltiplos mecanismos, oferecidos pela classe do design pattern chamada ListIterator. Desta forma, a interface original do objeto Lista seria preservada. Iterator poderia ser encapsulado em um conector R- RIO o qual ligaria clientes de Lista ao objeto Lista e ainda estabeleceria a interface e mecanismos necessários para percorrê-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 é feita através de uma ADL. 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 possuem capacidade de reflexão, uma vez que têm facilidade em interceptar e manipular requisições de e para os módulos. Neste relatório apresentamos a implementação de design patterns no ambiente R-RIO, particularmente utilizandose 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, State e Iterator. Nossos estudos, implementações e testes comprovam que design patterns de interaçã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 que envolvem interação entre objetos. Além disso, conectores R-RIO tornam possível o tratamento de aspectos não relacionados diretamente à funcionalidade dos objetos envolvidos. Visitor, por exemplo, envolve a interação entre um módulo Cliente e um ou mais módulos que são visitados. 14 de 16

15 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 na realização de aspectos complementares da aplicação, não previstos ou encapsulados nos seus módulos básicos, quando de seu projeto. 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íamos assim uma espécie de repositório de design patterns implementados e prontos para se adequarem ao contexto de uma determinada aplicação. 6 Referências [1] Gamma, E., Helm, R., Johson, R., Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, EUA, [2] Sztajnberg, A. Flexibilidade e Separação de Interesses para Concepção e Evolução de Sistemas Distribuídos. Exame de Tese de Doutorado. COPPE- UFRJ, março, [3] Lobosco, M., Um Ambiente para Suporte à Construção e Evolução de Sistemas Distribuídos, dissertação de mestrado, IC/UFF, março, [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, novembro [5] Arnold, K., Gosling, J., The Java Programming Language, Second Edition, Sun Microsystems, Addison- Wesley, EUA, [6] OMG, The Common Object Request Brocker: Architecture and Specification, Revision 2.3, Dezembro, [7] Schmidt, D., C., Fayad, M., Johnson, R. Software Patterns, ACM Communications, vol. 39, n. 10, outubro [8] Rising, L. Patterns: A Way to Reuse Expertise. IEEE Communications, abril [9] Budd, T. On Introduction to Object- Oriented Programming Second Edition. Addison-Wesley, EUA, [10] Srinivasam, S. Design Patterns in Object-Oriented Frameworks. IEEE Computer, fevereiro [11] Suzuki, J., Yamamoto, Y. OpenWebServer: An Adaptative Web Server Using Software Patterns, IEEE Communications, abril [12] Adair, D. Building Object-Oriented Frameworks. AIXpert, fevereiro e março [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, Abril 1995, pp [14] Malucelli, V.V., Babel Construindo Aplicações por Evolução, dissertação de mestrado, DEE / PUC-RJ, Fevereiro [15] Sztajnberg, A., Lobosco, M., Loques, O. Configurando Protocolos de Interação na Abordagem R-RIO, SBES, Florianópolis, Santa Catarina, [16] Appleton, B. Patterns and Software:Essential Concepts and Terminology, disponível em 15 de 16

16 patterns-intro.html, [17] Booch, G., Rumbaugh J., Jacobson I., The Unified Modeling Language User Guide. Object Technology Series. Addison-Wesley, [18] Ambler, S. W., CRC Modeling: Bridging the Communication Gap Between Developers and Users. White Paper Ambysoft. Novembro, Disponível em html. [19] Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M., A System of Patterns-Pattern-Oriented Software Architecture. John Wiley & Sons, [20] Schmidt, D., Stal, M., Rohnert, H., Buschmann F. Pattern-Oriented Software Architecture-Patterns for Concurrent and Networked Objects, Volume 2. John Wiley & Sons, de 16