Reuso da Implementação Orientada a Aspectos do Padrão de Projeto Camada de Persistência

Reuso da Implementação Orientada a Aspectos do Padrão de Projeto Camada de Persistência Ricardo Argenton Ramos, 1, Valter Vieira de Camargo, 2 Rosângela Penteado, Paulo Cesar Masiero Universidade Federal de São Carlos - Departamento de Computação Universidade de São Paulo - Instituto de Ciências Matemáticas e de Computação {rar, rosangel}@dc.ufscar.br, {valter, masiero}@icmc.usp.br Abstract This paper relates a reuse experience of the aspect-oriented implementation of the Persistence Layer pattern in an inventory system that was used as case study. This implementation was developed in the AspectJ language in a previous work, aiming to separate the functional code from persistency code. The case study system is implemented in the object-oriented paradigm, in Java, and uses the Persistence Layer pattern. To reuse the aspect-oriented implementation was necessary to identify and to remove the objectoriented code of the pattern, what was done by means of regular expressions. It was noticed that the aspect-oriented reuse process is simpler than the object-oriented and benefits are perceived in the target system. Keywords: Aspect-Oriented Reuse, Design Patterns, Persistence Layer. Resumo Este artigo relata uma experiência de reuso da implementação orientada a aspectos do padrão Camada de Persistência em um sistema de controle de estoque utilizado como estudo de caso. Essa implementação foi desenvolvida, anteriormente, na linguagem AspectJ com o objetivo de separar o código funcional do código de persistência. O sistema utilizado como estudo de caso está implementado no paradigma orientado a objetos, com Java, e possui o padrão Camada de Persistência. Para que a implementação orientada a aspectos do padrão pudesse ser reusada foi necessário identificar e retirar o código orientado a objetos do padrão, o que foi feito por meio de expressões regulares. Observouse que o processo de reuso orientado a aspectos é mais simples do que o orientado a objetos e benefícios são notados no sistema resultante. Palavras chave: Reuso Orientado a Aspectos, Padrão de Projeto, Camada de Persistência. 1 Apoio Financeiro do CNPq 2 Apoio Financeiro da CAPES

1. Introdução Padrões de Projeto são soluções de projeto já testadas e aprovadas. O reuso dessas soluções implica em softwares mais manuteníveis e de mais fácil desenvolvimento [5]. Porém, alguns autores comentam que embora o projeto desses padrões possa ser reutilizado facilmente, o mesmo não ocorre com a sua implementação, quando ela é Orientada a Objetos (OO) [6][9]. Da mesma forma, a implementação de requisitos não funcionais também causa problemas quando é utilizada uma linguagem OO. Como essas linguagens de programação fornecem mecanismos pouco adequados à implementação de padrões de projeto e de requisitos não-funcionais [9], permitindo que o código do padrão/requisito nãofuncional permaneça espalhado e entrelaçado com os módulos funcionais da aplicação. Assim, têm-se problemas de manutenção, evolução e reuso. Quando ocorre entrelaçamento/espalhamento, uma possível solução é utilizar a programação orientada a aspectos (POA). Foi proposta em 1997 por Kiczales [7] e visa fornecer construtores lingüísticos mais adequados para separar os requisitos funcionais dos não-funcionais, do que as linguagens OO. Embora padrões de projeto não sejam considerados como requisitos não-funcionais, sua aplicação muitas vezes faz com que o seu código também se encontre espalhado/entrelaçado pela aplicação, podendo ser caracterizados como passíveis de serem implementados com aspectos. Alguns autores têm utilizado a POA na implementação de padrões de projeto, separando o código do padrão do código funcional [6]. Algumas experiências com o reuso da implementação OO do padrão Camada de Persistência (Persistence Layer) foram realizadas em trabalhos anteriores [1] [3] [4]. Esse padrão encapsula o requisito não-funcional de persistência em algumas classes e interfaces para manter a independência da aplicação. O processo de reuso da implementação OO não apresenta muitas dificuldades, porém o código que implementa o padrão fica espalhado/entrelaçado com o código da aplicação, causando os problemas citados anteriormente. A implementação desse padrão com a linguagem AspectJ foi realizada por estes autores [3], e neste artigo será mostrado o processo de reutilização de sua implementação em um sistema de controle de estoque implementado em Java [4]. Dessa forma, infere-se que há benefícios quando se utiliza o processo de reuso da implementação OA em relação ao OO. Como o estudo de caso aqui apresentado já continha o padrão Camada de Persistência implementado de forma OO, expressões regulares foram utilizadas para identificar e remover o código de persistência [10]. Na Seção 2 encontram-se alguns trabalhos sobre a Programação Orientada a Aspectos e Padrões de Projeto; na Seção 3 é apresentado o projeto baseado em aspectos do padrão Camada de Persistência; na Seção 4 são mostrados os detalhes do processo de reuso realizado e na Seção 5 as considerações finais são apresentadas. 2. Programação Orientada a Aspectos e Padrões de Projeto Segundo Kiczales e outros [7], a programação orientada a aspectos consiste na separação dos interesses de um sistema em unidades modulares e posterior composição (weaving) desses módulos em um sistema completo. Esses interesses podem variar de noções de alto nível, como segurança e qualidade de serviço, a noções de baixo nível, como sincronização 2

e manipulação de buffers de memória. Eles podem ser tanto funcionais, como características ou regras de negócio, quanto não-funcionais, como gerenciamento de transação e persistência. Aspect/J é uma extensão da linguagem Java, de propósito geral, orientada a aspectos, em que a principal unidade modular é o aspecto (aspect) [7]. Um aspecto pode possuir atributos e métodos e participar de uma hierarquia de aspectos por meio da definição de aspectos especializados. Aspect/J possibilita nomear um conjunto de pontos de junção e associar uma determinada implementação a eles, que pode ser executada antes, após ou apropriar-se do fluxo de execução dos eventos relacionados a esses pontos. Os seguintes conceitos são usados em AspectJ: Pontos de junção (joinpoints): são métodos bem definidos na execução do fluxo do programa que compõem pontos de corte. Pontos de corte (pointcuts): identificam coleções de pontos de junção no fluxo do programa. Sugestões (advices): são construções semelhantes a métodos, que definem comportamentos adicionais aos pontos de junção. São executadas quando pontos de junção são alcançados [7]. AspectJ tem três tipos diferentes de sugestões: i) Pré-sugestão (before): é executada quando um ponto de junção é alcançado e antes da computação ser realizada. ii) Pós-sugestão (after): é executada quando um ponto de junção é alcançado e após a computação ser realizada. iii) Sugestão substitutiva (around): é executada quando o ponto de junção é alcançado e tem o controle explícito da computação, podendo alternar a execução com o método alcançado pelo ponto de junção. A modularização de interesses de entrecorte é realizada usando pontos de junção (join points) e sugestões (advices). Segundo Noda e Kishi [9], as técnicas atuais de programação não são adequadas para a utilização dos padrões de projeto, pois tornam a aplicação dependente deles, o que diminui as chances de reuso da parte funcional da aplicação. Eles realizaram a implementação de duas versões de um mesmo sistema utilizando o conceito da separação avançada de interesses (Advanced Separation of Concern - ASOC) em Aspet/J e Hyper/J, utilizando o padrão de projeto Observer [5]. Nas duas versões do sistema os autores separam o código da aplicação do código do padrão, os quais foram tratados como interesses separados. O interesse que trata da aplicação contém apenas suas funções específicas, as quais são independentes do padrão, possibilitando o reuso desse interesse. O interesse que trata do padrão descreve a estrutura e o comportamento abstratos do padrão e é independente da aplicação. Assim como Noda e Kishi [9], Hannemann e Kiczales [6] comentam que a técnica de implementação orientada a objetos não é adequada à implementação de padrões de projeto. Para testar essa hipótese, realizaram um experimento com programação orientada a aspectos no qual os vinte e três padrões de projeto propostos por Gamma e outros [5] foram implementados em Java e em Aspect/J. Os benefícios obtidos em dezessete dos vinte e três padrões implementados com orientação a aspectos foram: melhor localidade de código, maior reusabilidade, facilidade de composição e de (desc)conectividade entre classes do padrão e da aplicação. Segundo os autores, alguns padrões possuem estrutura que entrecorta 3

o relacionamento entre os papéis impostos pelo padrão e as classes de aplicação que assumem esses papéis. Os três tipos de estruturas identificadas foram as estruturas: de papéis definidos, de papéis sobrepostos e mista. No primeiro tipo de estrutura o papel é bem definido, isto é, as classes participantes não têm funcionalidade além daquela fornecida pelo padrão. Nesses casos a implementação com Aspect/J não apresentou benefícios. No segundo tipo, os papéis são sobrepostos, isto é, eles são atribuídos a classes que têm funcionalidade além daquela fornecida pelo padrão. Esse tipo de estrutura foi a que obteve maiores benefícios, já que a programação orientada a aspectos possui construtores específicos para tratar relacionamentos de entrecorte. O terceiro tipo de estrutura possui tanto papéis definidos quanto sobrepostos e também obteve benefícios, porém menores do que o segundo tipo. As melhorias obtidas com o uso do Aspect/J são inicialmente devidas à inversão das dependências. O código do padrão depende dos participantes e não ao contrário, como ocorre na implementação Orientada a Objetos. Isso possui um impacto direto na localidade de código, pois todas as dependências entre os padrões e a aplicação são localizadas no código do padrão. Visando a necessidade de obtenção de melhorias na localidade do código Orientado a Objetos, Ramos [10] propõe uma abordagem para migrar sistemas Orientados a Objetos para sistemas Orientados a Aspectos. Essa abordagem fornece diretrizes e indícios (alguns no formato de expressões regulares) para a localização, modelagem e implementação de seis tipos de interesses na linguagem AspectJ. Com base nos trabalhos apresentados nesta seção nota-se que embora os padrões não sejam tratados como requisitos não funcionais, sua implementação espalha-se pelo código funcional, causando problemas de reuso, manutenção e evolução. Com base nessa motivação, o padrão Camada de Persistência [11] foi implementado com aspectos [3] e essa implementação é apresentada com maiores detalhes na próxima Seção. 3. Projeto Baseado em Aspectos do Padrão Camada de Persistência O padrão de projeto Camada de Persistência permite minimizar a incompatibilidade existente entre o paradigma orientado a objetos e a persistência de dados em um banco relacional [11]. Ele consiste em uma camada que cuida da interface entre objetos de aplicação e tabelas de banco de dados relacional. Possui um conjunto de dez sub-padrões que podem ser utilizados para a implementação dessa camada de persistência: Camada Persistente (Persistent Layer), CRUD (Criação (Create), Leitura (Read), Atualização (Update) e Remoção (Delete)), Descrição de Código SQL (SQL Code Description), Gerenciador de Tabelas (Table Manager), Métodos de Mapeamento de Atributos (Atributte Mapping Methods), Conversão de Tipos (Type Conversion), Gerenciador de Mudanças (Change Manager), Gerenciador de Identificadores Únicos (OID Manager), Gerenciador de Conexão (Connection Manager) e Gerenciador de Transação (Transaction Manager). Cada um deles possui uma funcionalidade bem definida e enquanto alguns são obrigatórios, outros são opcionais. Por exemplo, o padrão CRUD é essencial, para a realização das operações básicas de persistência, já o padrão Conversão de Tipos é útil, mas não essencial, podendo não ser utilizado. O padrão Camada de Persistência possui três formas de uso, segundo Cagnin [1] a terceira forma é a que permite mais facilmente reutilizar o Gerenciador de Tabelas (Table 4

Manager), pois não há preocupação com a persistência de qualquer tipo de objeto no banco de dados, necessitando apenas conhecer os parâmetros dos métodos das classes. Além disso, o sistema implementado utilizando-a é o mais manutenível. Embora a classe TableManager seja reusável, o mesmo não ocorre com as classes da aplicação, devido à dependência do padrão, que ocorre porque essas classes invocam métodos existentes nas classes que implementam o padrão. Camargo e outros [3] fornecem uma alternativa de projeto baseado em aspectos para este padrão que pode ser reutilizada em aplicações específicas. O objetivo foi desenvolver uma estrutura que mantivesse separado o código de persistência do código funcional, facilitando dessa forma o entendimento do padrão e melhorando sua reusabilidade. Para isso, um estudo de caso com um sistema de oficina eletrônica implementado em Java e reimplementado em AspectJ foi utilizado para comparar as duas alternativas de implementação. A versão do padrão com aspectos manteve o código de persistência completamente separado do código funcional, facilitando o entendimento e, conseqüentemente, a sua manutenibilidade e o reuso. Neste artigo é mostrada a experiência em reutilizar o código do padrão Camada de Persistência baseado em aspectos em um sistema de controle de estoque. A Figura 1 mostra uma instanciação genérica do projeto baseado em aspectos do padrão Camada de Persistência [3], sendo que na parte superior encontra-se a camada de persistência e na inferior, a camada de aplicação. Ressalta-se que o termo instanciação está sendo usado para evidenciar que algumas partes do projeto baseado em aspectos do padrão precisam ser modificadas de acordo com a aplicação na qual ele será acoplado. Contudo, há consciência de que esse projeto não é um framework. Outro ponto que merece destaque é que a notação usada neste diagrama para representar os conceitos da POA é a proposta por Camargo e Masiero [2], que evoluiu a partir da necessidade de se representar os conceitos básicos da POA e também de frameworks orientados a aspectos. O aspecto abstrato AbstractAspectConnection encapsula o comportamento genérico de conexão com o banco de dados e deve ser especializado por um aspecto concreto que especifica detalhes específicos da aplicação. Esses detalhes consistem na sobreposição de alguns métodos abstratos e também na especificação de dois pontos de corte abstratos, que podem ser identificados pelos estereótipos <<pointcut-hook>> em itálico. A identificação dos pontos de instanciação é feita por meio da existência do conceito de gancho (hook). Por exemplo, o ponto de corte openconnection é um gancho e precisa ser redefinido no aspecto especializado. Da mesma forma, os métodos com estereótipo <<hook>> também são pontos de instanciação que precisam ser redefinidos. A sobreposição dos métodos é feita para informar detalhes da conexão, enquanto que a especificação do ponto de corte concreto é feita para indicar em que ponto da aplicação a conexão deve ser feita. Note-se que a existência dos pontos de corte é o que determina a independência da aplicação em relação ao código não-funcional, pois na implementação OO, o ponto da aplicação onde a conexão deve ser aberta contém uma chamada a algum método da camada de persistência. Na implementação OA o que ocorre é o contrário, a camada de persistência tem consciência dos locais onde a conexão deve ser aberta. Essa inversão de dependência é o ponto fundamental que mantém a aplicação livre do código não-funcional. 5

AbstractAspectConnection <<pointcut-hook>> closeconnection <<pointcut-hook>> openconnection <<after>> closeconnection <<after>> openconnection <<hook>> setjdbc <<hook>> execute <<hook>> executequery <<hook>> conectdb <<hook>> closedb TableManager <<introduction>> {method = findall, getlast, findlike, delete} {attribute = tablename, keyname, colnames, colvalues, cols} AspectStructure AspectConnection AspectClasseApp <<pointcut>> openconnection <<pointcut>> closeconnection <<after>> changesconstructor <<after>> changesemptyconstructor Camada de Persistência Camada de Aplicação <<crosscutting>> {joinpoint =?ClasseAplicacao(..)} {PCDescriptor = changesconstructor} <<crosscutting>> <<introduction>> {joinpoint =? ClasseAplicacao} {method = save, getprimarykeyclause {PCDescriptor = changesemptyconstructor} getprimarykeyvalue} ClasseAplicacao Figura 1 Projeto Baseado em Aspectos do Padrão Camada de Persistência. Na Figura 1, os dois pontos de corte abstratos do aspecto AbstractAspectConnection e também os métodos abstratos são redefinidos no aspecto concreto AspectConnection, porém apenas o ponto de corte concreto openconnection e closeconnection está sendo exibido. A classe TableManager não foi transformada em aspectos porque seu comportamento já estava bem encapsulado e ela não influenciava nenhuma das classes de aplicação. Sendo assim, optou-se por não transformá-la em aspecto. O aspecto AspectStructure é responsável por introduzir nas classes de aplicação alguns atributos e métodos de persistência independentes de qualquer aplicação. Embora não seja explícito no diagrama, o ponto de instanciação nesse aspecto consiste em informar em quais classes de aplicação esses atributos e métodos devem ser inseridos. Na Figura 1, isso é representado por meio de um relacionamento de introdução, representado com o estereótipo <<introduction>>. Os atributos e métodos de persistência que serão inseridos na classe de aplicação ClasseAplicacao podem ser vistos por meio das etiquetas valoras (tag values) attribute e method, respectivamente. Na implementação OO, esses atributos e métodos estão presentes e repetidos em todas as classes de aplicação. O aspecto AspectClassApp é um tipo de aspecto dependente de uma determinada classe persistente de aplicação. Ele é responsável tanto por inserir alguns métodos nessa 6

classe, quanto por interceptar as execuções do construtor para modificar seu comportamento. Por exemplo, os métodos getprimarykeyclause, getprimarykeyvalue e o save, vistos por meio da etiqueta method do relacionamento de introdução entre o aspecto AspectClassApp e a classe ClasseAplicacao, possuem informações dependentes dessa classe, que devem ser informadas dentro do aspecto. Além disso, deve-se notar também dois relacionamentos de interceptação (crosscutting) desse aspecto com essa classe. O primeiro utiliza o ponto de corte changesconstructor para interceptar as execuções do construtor normal da classe ClasseAplicacao. Essas informações podem ser obtidas analisando-se as etiquetas PCDescriptor e joinpoint do relacionamento de interceptação em questão. O segundo relacionamento de interceptação utiliza o ponto de corte changesemptyconstructor para interceptar as execuções do construtor vazio dessa mesma classe. Após essas interceptações, as sugestões existentes nesse aspecto informam detalhes específicos da aplicação. A Seção seguinte apresenta o estudo de caso realizado para avaliar o reuso da implementação do padrão de projeto Camada de Persistência implementado com aspectos. 4. Estudo de Caso O estudo de caso consiste em um sistema de controle de estoque implementado na linguagem Java que utiliza o banco de dados relacional SyBase e HTML para as interfaces. O padrão Camada de Persistência está implementado no paradigma Orientado a Objetos (OO) para separar o código da aplicação do código da persistência. A comunicação entre o banco de dados e as interfaces foi implementada por meio de servlets [4]. A função principal do sistema é cadastrar materiais, fornecedores, contas, previsão de compras e alguns documentos, como por exemplo, requisição de material, solicitação de material, comunicado de recebimento, devolução de materiais ao fornecedor, correção de estoque físico, etc. Como o padrão foi implementado utilizando o paradigma OO, todas as classes persistentes da aplicação contêm o código de persistência entrelaçado e espalhado pelos módulos funcionais. A Figura 2 mostra esquematicamente as atividades realizadas. A Atividade I é apoiada por expressões regulares, que fornecem os indícios para o engenheiro de software encontrar o interesse de persistência [10], e tem como entrada o código fonte do sistema de controle de estoque implementado no paradigma OO. O código fonte marcado com comentários, quando o interesse é localizado, e a implementação em aspectos do padrão de projeto Camada de Persistência [3], são as entrada para a Atividade II. A seguir são descritas as atividades que foram realizadas. 7

Código fonte OO do sistema de Controle de Estoque Atividade I Identificar o código que implementa o padrão Camada de Persistência. Expressões Regulares Código fonte OA do Padrão Camada de Persistência Código fonte OO do sistema de Controle de Estoque com os trechos de código marcados. Atividade II Reutilizar a porção de código genérica e adaptar a porção de código especifica do padrão. Código fonte OA do sistema de Controle de Estoque Figura 2 - Atividades do processo de reuso do padrão Camada de Persistência. 4.1. Atividade I: Identificar o Código Fonte que Implementa o Padrão Camada de Persistência Essa atividade utiliza as expressões regulares criadas na abordagem Aspecting [10] para identificar interesses existentes no código fonte OO. A Figura 3 mostra a expressão regular referente ao interesse de Persistência que está presente no código fonte do sistema de Controle de Estoque. Todo trecho de código reconhecido por essa expressão regular deve ser considerado como sendo do interesse de persistência e deve-se adicionar, ao final de cada linha, comentários que indiquem que esta linha pertence ao interesse. Esse recurso de comentários também proposto na abordagem Aspecting. <i.persistencia.bd> = Connection <statements> Connection <statements> <SQL> <SQL> <statements> Connection PreparedStatement <statements> PreparedStatement <statements> <SQL> <SQL> <statements> PreparedStatement ResultSet <statements> ResultSet <statements> <SQL> <SQL> <statements> ResultSet Figura 3 - Expressão regular que auxilia a identificar os indícios do interesse de Persistência [10]. As expressões regulares existentes para reconhecer os indícios de Persistência não foram elaboradas considerando a utilização do padrão Persistence Layer. Assim, no trecho de código da classe Conta, apresentado na Figura 4, somente a parte marcada com (a) é que foi reconhecida como de Persistência. Os outros trechos de código, (b) e (c), foram reconhecidos pelo engenheiro de software como parte do padrão. Para isso há necessidade do conhecimento da granularidade 3 do padrão Camada de Persistência. 3 O quanto e como está espalhada pelas classes a implementação do padrão. 8

MesAt quantidadenaoat setobje setdbtoobj 1 AnoAt quantidadenaoat setobje setdbtoobj Movime t quantidade quantidad S valoren valors me MovimentoMesesAn setobje setdbtoobj Localiza deposi pratelei repartic bo setobje setdbtoobj Estoq estoq almoxarif Materi codig class descric unida maxm maxi mini qtdestoq precome sald valorultimaco valorcompr C compraunitariaforn dataultimomovi datacada setobje setdbtoobj Cont descric debito credito debitom credito conta conta conta public class Conta implements PersistentObject {... private TableManager tablemanager; private String tablename;... colnames.addelement ("codigo"); colnames.addelement ("descrição");... public boolean save { ResultSet rs; // Persistência Vector clause = new Vector; Vector parameter = new Vector;... } (a) (b) (c) Atributos não localizados pela expressão regular, porém que fazem parte do interesse de Persistência. Linha de código reconhecida pela expressão regular como sendo do Interesse de Persistência Figura 4 - Trecho de código da classe Conta. 4.2. Atividade II: Reutilizar a Porção de Código Genérica e Adaptar a Porção de Código Especifica do Padrão A Figura 5 mostra as três etapas para a execução dessa atividade: (1) análise e adaptação para o reuso dos aspectos AbstractAcpectConnection, AspectConnection que implementam o sub padrão Gerenciador de Conexão; (2) análise e adaptação para o reuso do aspecto AspectStructure que implementa parte dos sub padrões Gerenciador de Tabelas, CRUD e Objeto Persistente; e (3) análise e adaptação/criação para o reuso dos aspectos que implementam atributos específicos de persistência para cada classe de aplicação. Os aspectos dessa última etapa implementam o sub padrão Métodos de Mapeamento de Atributos e a parte restante dos sub padrões CRUD e Objeto Persistente. Nessa etapa é reutilizada a implementação da classe TableManeger. Após a aplicação das três etapas a camada de persistência reusada, Figura 5 (a), intercepta a camada de aplicação do sistema de Controle de Estoque, Figura 5 (b). AbstractAspectConnection <<pointcut-hook>> closeconnection <<pointcut-hook>> openconnection <<after>> closeconnection <<after>> openconnection <<hook>> setjdbc <<hook>> execute <<hook>> executequery <<hook>> conectdb <<hook>> closedb (1) (a) Camada de Persistência Reusada AbstractAspectConnection <<pointcut-hook>> closeconnection <<pointcut-hook>> openconnection <<after>> closeconnection <<after>> openconnection <<hook>> setjdbc <<hook>> execute <<hook>> executequery <<hook>> conectdb <<hook>> closedb <<pointcut>> openconnection <<pointcut>> closeconnection (b) Camada de Aplicação do Sistema de Controle de Estoque <<pointcut>> openconnection <<pointcut>> closeconnection AspectStructure (2) AspectStructure TableManager TableManager AspectClasseApp (3) AspectClasseApp <<after>> changesconstructor <<after>> changesemptyconstructor <<after>> changesconstructor <<after>> changesemptyconstructor Figura 5 - Etapas realizadas no processo de reuso do padrão de projeto Camada de Persistência. 9

Na etapa (1), apenas o aspecto AbstractAspectConnection, mostrado na Figura 6, é reusado completamente sem adaptações para o sistema de controle de estoque. Ele possui um ponto de corte abstrato denominado openconnection, cujo ponto de junção deve ser fornecido pelo aspecto, mostrado na Figura 7, AspectConnection que é o aspecto concreto que o especializa. public abstract aspect AbstractAspectConnection { public static Connection con; public static Statement stmt;... abstract pointcut openconnection; after : openconnection {... ConnectDB; }... public void setjdbc(...) {...} protected static void ConnectDB {...} private static void CloseDB {...} public static void execute {...} public static ResultSet executequery {...} } Figura 6 - Aspecto de Conexão Abstrato. Para o AspectConnection é necessário que se defina o ponto de junção concreto, que indica o método que deve ser interceptado para realizar a conexão, e também os parâmetros de configuração dessa conexão na Sugestão before. A parte (a) na Figura 7 mostra que o ponto de junção concreto são chamadas do método init, pois é nesse local do código da implementação orientada a objetos que havia uma chamada ao método responsável pela conexão com o banco de dados. Além disso, na Sugestão before desse aspecto, o método setjdbc deve ser invocado do aspecto abstrato passando alguns parâmetros de configuração necessários à conexão, conforme apresentado na parte destacada com a letra (b) dessa mesma figura. Portanto para a adaptação desse aspecto em (a) indicou-se o método que era chamado na versão OO, após a conexão com o banco de dados. Em (b) foram adicionados o nome do banco de dados, nome do usuário desse banco e a senha. Foram retirados das classes de aplicação, todos os métodos referentes a conexão que estavam marcados como sendo do padrão. public aspect AspectConnection extends AbstractAspectConnection { pointcut doconnection: call (void init(..)); (a) Ponto de junção fornecido } before : doconnection { super.setjdbc("jdbc:odbc:estoque", "DBA", "sql",...); } (b) Parâmetros de configuração Figura 7 - Aspecto de Conexão Concreto. Na etapa (2), o AspectStructure, mostrado na Figura 8, é adaptado para poder ser reutilizado. Esse aspecto por meio do conceito de Introduções, insere os atributos de persistência tablename, keyname, colnames, colvalues, colnamesexception e cols em todas as classes de aplicação, pois são atributos provenientes do sub-padrão Gerenciador de 10

Tabelas. O mesmo ocorre com os métodos findall e findlike, que foram reusados do sub-padrão Objeto Persistente e, delete que foi reusado tanto do Objeto Persistente quanto do CRUD. Portanto para a adaptação desse aspecto para o reuso foi necessário adicionar o nome de todas as classes de aplicação do sistema de Controle de Estoque juntamente com os métodos e atributos descritos a cima. A Figura 8 ilustra em negrito, alguns trechos dessa adaptação para a classe Conta. Foram retirados das classes de aplicação todos os métodos e atributos marcados como sendo do padrão que estavam relacionados no aspecto AspectStructure. public aspect AspectStructure { private String Conta.tableName;... private String Conta.keyName;... private String Conta.colNames = new Vector;... private String Conta.colNamesException = new Vector;... métodos sets e gets public ResultSet Conta.findall { return TableManager.findallDB(this.getTableName); } public ResultSet Conta.findlike {...}... public boolean Conta.delete {...} }... } Figura 8 - Aspecto AspectStructure. A etapa (3) consiste em criar um aspecto para cada classe persistente de aplicação. A Figura 9 apresenta o aspecto AspectConta, que possui comportamento específico para a classe Conta, pois deve definir valores de persistência para essa classe, tais como: nome da tabela, nome das colunas da tabela, nome da chave primária e número de colunas, como mostrado parcialmente na parte destacada com a letra (a). A parte destacada com a letra (b) mostra a atribuição dos valores para os atributos definidos anteriormente. Como esse tipo de aspecto possui características específicas de cada classe de persistência, foi criado um aspecto como esse para cada uma delas. O ponto de corte changesconstructor desse aspecto possui como tarefa interceptar chamadas do construtor da classe Conta e definir valores para os atributos de persistência dessa classe. Foram retirados das classes de aplicação todos os métodos e atributos marcados como sendo do padrão que estavam relacionados aos aspectos específicos. public aspect AspectConta { pointcut changesconstructor(conta c): target (c) && execution (Conta.new(int, String, String, String, String, String, String)); after (Conta c): changesconstructor(c) } {c.settablename("conta"); c.setkeyname("codigo");... id = new Integer(c.getCodigo); c.setcolvalues(id); c.setcolvalues(c.getdescricao);...} public boolean Conta.save {... } public Conta Conta.SetObject (ResultSet rs) {... } private Conta Conta.SetDBToObject(ResultSet rs) {... } (a) (b) Figura 9 - Aspecto AspectConta. 11

A Tabela 1 apresenta para cada aspecto reusado, quais foram as ações efetuadas para reusar o código na versão Orientada a Aspectos (OA) e quais seriam as ações necessárias para reusar a porção de código equivalente na versão Orientada a Objetos (OO). Tabela 1 - Comparação das adaptações para o reuso nas versões OO e OA. Aspectos Reusados AbstractAspectConnection e AspectConnection AspectStructure Aspectos específicos e a classe TableManeger Ações necessárias para reusar na versão orientada a aspectos 1 - especificar um ponto de corte no AspectConnection 2 - sobrepor o método setjdbc inserindo as informações especificas sobre a conexão. 1 - alterar o aspecto AspectStructure colocando o nome das classes que fazem a persistência. 1 - criar um aspecto para cada classe de persistência da aplicação. 2 - utilizar o conceito de introdução e adicionar três métodos que pertencem ao padrão nas classes que fazem a persistência. 3 - criar dois pontos de corte e duas sugestões (advices) que modificam os construtores 4 - reutilizar a classe TableManeger sem modifica-la. Ações necessárias para reusar na versão orientada a objetos 1 - sobrepor as informações específicas sobre a conexão na classe ConnectionManneger. 2 - procurar por todos os pontos da aplicação que fazem a conexão com o banco de dados. 1 - procurar por todas as classes que fazem a persistência e adicionar os atributos e métodos. 1 - procurar por todas as classes que fazem a persistência e adicionar os métodos que pertencem ao padrão. 2 - alterar os construtores das classes que fazem a persistência. 3 - reutilizar a classe TableManeger sem modifica-la. A partir da comparação das ações necessárias para a reutilização da implementação do padrão de projeto Camada de Persistência observados na Tabela 1 é possível inferir que apesar de ter mais ações realizadas na versão Orientada a Aspectos são menos trabalhosas que as para realizar o reuso na versão Orientada a Objetos. Ações como procurar por pontos da aplicação que necessitam fazer a conexão como o banco de dados, despendem muito mais tempo do que a ação de especificar a captura desses pontos em um ponto de corte. 5. Considerações Finais Este artigo mostra uma experiência de reuso da implementação orientada a aspectos do padrão Camada de Persistência em um sistema de controle de estoque. Como os autores já tinham experiência em reusar a implementação orientada a objetos desse padrão em outros sistemas, foi possível identificar que o processo de reuso orientado aspectos possui um número maior de passos, porém são mais simples do que os passos do reuso orientado a objetos. Note-se que no contexto do estudo de caso realizado não foi considerado o conhecimento do engenheiro de software com programação orientada a aspectos. Os benefícios ou vantagens observados com o reuso do padrão implementado com aspectos foram: Facilidade de manutenção - Como o código fica mais modular e com menos redundâncias, o engenheiro de software não necessita procurar os trechos de código do padrão por todas as classes de aplicação, pois ele está localizado em poucos módulos; 12

Facilidade de compreensão do código - Da mesma forma que o tópico anterior, a modularidade faz com que o engenheiro de software se concentre em poucos módulos para entender a persistência; Facilidade de evolução - Como o código do padrão encontra-se bem modularizado, adicionar novos aspectos que tratam de outros interesses se torna mais fácil. Por exemplo, poderia ser adicionado um novo aspecto que cuidasse do interesse de geração de identificador automaticamente. Embora o padrão Camada de Persistência tenha se mostrado adequado para ser implementado com aspectos, não são todos os padrões de projeto que apresentam esse comportamento. Alguns dos padrões propostos por Gamma e outros [5] ficam mais complexos do que se estivessem implementados no paradigma Orientado a Objetos [9]. A utilização das expressões regulares [10] auxiliou a identificação do interesse de persistência, porém foi necessário o conhecimento da granularidade da implementação do padrão Camada de Persistência, pois as heranças e implementações de interfaces não estavam previstas na expressão regular. A elaboração de expressões regulares que reconheçam trechos de código relativos ao padrão deverá também ser incorporadas na abordagem Aspecting. A implementação do padrão Camada de Persistência com aspectos [2] já evoluiu bastante e já pode ser considerado como um framework de persistência orientado a aspectos. Infere-se que a utilização de um framework de persistência seja uma solução mais eficaz para o reuso do interesse de persistência. A abordagem Aspecting [10] permite que outros interesses sejam utilizados na reconstrução de sistemas orientados a objetos para sistemas orientados a aspectos que não foram tratados neste trabalho. Somente algumas partes dessa abordagem foram utilizadas aqui sendo referenciadas quando ocorreram. 6. Referências Bibliográficas [1] Cagnin, M.I. Avaliação das Vantagens quanto à Facilidade de Manutenção e Expansão de Sistemas Legados Sujeitos à Engenharia Reversa e Segmentação. Dissertação de Mestrado, DC-UFSCar, 1999. [2] Camargo, V.V. Masiero, P.C. UML-AOF Um Perfil UML para o Projeto de Frameworks Orientados a Aspectos. Relatório Técnico, ICMC-USP, 2004. Disponível para download em: http://www.icmc.usp.br/~valter/publicacoes. [3] Camargo, V.V.; Ramos, R.A.; Penteado, R.A.D.; Masiero, P.C. Projeto Baseado em Aspectos do Padrão Camada de Persistência. In: Simpósio Brasileiro de Engenharia de Software (SBES), Manaus, 2003. [4] Camargo, V.V. Reengenharia Orientada a Objetos de Sistemas COBOL com a utilização de Padrões de Projeto e Servlets. Dissertação de Mestrado, Departamento de Computação da Universidade Federal de São Carlos, 2001. [5] Gama, E., Helm, R., Johnson, R., Vlissides, J. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. 13

[6] Hannemann and Kiczales. Design Pattern Implementation in Java and AspectJ, Proceedings of the 17th Annual ACM conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), pages 161-173, November 2002. [7] Kiczales, G.; Hilsdale, E.; Hugunin, J.; Kersten, M.; Palm, J. Griswold, W.G. Getting Started with AspectJ. In: Anais do ACM, pág. 59-65, Outubro 2001. [8] Kiczales, G.; Lamping, J.; Mendhekar, A. RG: A Case-Study for Aspect-Oriented Programming. Artigo Técnico, SPL97. Xerox Palo Alto Research Center, 1997. [9] Noda, N. and Kishi, T. "Implementing Design Patterns Using Advanced Separation of Concerns", in Proceedings of OOPSLA 2001, Workshop on Advanced Separation of Concerns in Object-Oriented Systems, Tampa Bay, FL, October 2001. [10] Ramos, R., A. Aspecting: Abordagem para Migração de Sistemas OO para Sistemas AO. Dissertação de Mestrado. Programa de Pós Graduação em Ciência da Computação, Universidade Federal de São Carlos, São Carlos - SP, maio de 2004. [11] Yoder, J. W.; Johnson, R. E.; Wilson, Q. D. Connecting Business Objects to Relational Databases. Conference on the Pattern Languages of Programs, 1998. 14