Manutenção de Frameworks Orientados a Objetos Usando Orientação a Aspectos

Transcrição

1 Manutenção de Frameworks Orientados a Objetos Usando Orientação a Aspectos André L. de Oliveira 1, Valter V. de Camargo, Rosângela Ap. D. Penteado 1 Departamento de Computação Universidade Federal de São Carlos (UFSCar) Caixa Postal São Carlos SP Brazil {andre_oliveira, valter, rosangela}@dc.ufscar.br Abstract. Object-Oriented Frameworks (OOF) need maintenance to evolve or be adapted to new technologies and environments. When maintenance activities use aspect-oriented (AO) techniques, some problems can emerge, such as increasing the number of framework components, hindering the coupling, as well as reducing the cohesion among them. In this study are presented some guidelines to support software engineers in performing maintenance of OOF using AO techniques in order to address those problems. Resumo. Frameworks orientados a objetos (FOO) necessitam de manutenção para evoluir ou serem adaptados a novas tecnologias e ambientes. Quando as atividades de manutenção envolvem técnicas de orientação a aspectos (OA) alguns problemas podem ocorrer, dentre eles, o aumento do número de componentes do framework, prejudicando o acoplamento e reduzindo da coesão dos componentes. Neste trabalho são apresentadas algumas diretrizes para auxiliar aos engenheiros de software a realizar manutenção em FOO utilizando técnicas de OA para resolver ou tratar esses problemas. 1. Introdução Quaisquer modificações que são realizadas em sistemas podem levar a efeitos colaterais e outros problemas diversos. O mesmo problema pode ocorrer no contexto de frameworks, fazendo com que o engenheiro de software tenha que tomar decisões sobre a forma como o framework deve ser reimplementado ou em como implementar uma solução para resolver um problema específico [Bosch et al., 2000]. O processo de manutenção de frameworks trata de modificações e adaptações que podem ocorrer em nível funcional (requisitos) e não-funcional e inclui aspectos qualitativos como portabilidade e reusabilidade [Fayad and Schmidt, 1997]. Uma das alternativas de manutenção existentes que podem ser aplicadas a frameworks orientados a objetos (OO) é utilizar técnicas de orientação a aspectos (OA). Quando se decide utilizar orientação a aspectos para a manutenção de frameworks OO, usualmente há aumento no número de seus componentes (classes, interfaces e aspectos) o que, consequentemente, leva ao aumento do tamanho do framework, a maiores níveis de acoplamento e à redução da coesão de seus componentes. Isso conduz ao aumento da complexidade do framework, o que dificulta o seu entendimento e consequentemente sua manutenção, extensão e utilização. Um framework de aplicação OO que tenha a implementação de um determinado interesse entrelaçada e espalhada pelo código fonte de várias classes pode ser re-projetado 1 Apoio Financeiro FAPESP Proc. Nro. 2008/

2 utilizando técnicas de Orientação a Aspectos. Duas estratégias podem ser utilizadas para modularizar a implementação desses interesses espalhados: 1) criar um aspecto para cada classe do framework que contém código relacionado ao interesse a ser modularizado. Esse aspecto irá introduzir/entrecortar um conjunto de atributos e operações relacionados a esse interesse nessa classe; 2) criar um único aspecto para introduzir/entrecortar um conjunto de atributos e operações relacionado ao interesse a ser modularizado em todas as classes que contém indícios desse interesse. O uso da estratégia 1) reduz a complexidade do código dos aspectos, favorecendo a legibilidade, porém, tem como desvantagem o aumento do número de componentes do framework. O uso da estratégia 2) reduz o número de componentes do framework, mas aumenta complexidade do código dos aspectos, dificultando a legibilidade. Neste trabalho são relatados os problemas que podem ocorrer quando essas estratégias são utilizadas e são fornecidas diretrizes para solucioná-los. Além desta seção há outras cinco. Na Seção 2 são discutidos os problemas do uso de orientação a aspectos na manutenção de frameworks OO. Na Seção 3 são apresentadas as diretrizes de manutenção que podem ser aplicadas para resolver problemas citados na Seção 2. Na Seção 4, um estudo de caso ilustra como as diretrizes foram aplicadas. Na Seção 5 são citados os trabalhos relacionados a este e na Seção 6 são apresentadas as considerações finais e as propostas de trabalhos futuros. 2. Problemas do Uso de Orientação a Aspectos na Manutenção de Frameworks OO Toda manutenção apresenta algumas dificuldades, principalmente aquelas em que a técnica ou tecnologia de desenvolvimento do software não é a mesma que a utilizada em sua manutenção. Nesta seção são relatados alguns problemas e armadilhas de manutenção que engenheiros de software podem se deparar ao utilizarem técnicas de OA para modularizar frameworks OO. Quando a implementação de um interesse se encontra distribuída por várias classes, uma solução é a utilização de aspectos para modularizar a implementação desse interesse. Como comentado anteriormente, duas estratégias podem ser usadas para modularizar esse interesse em aspectos. A estratégia 1) proporciona melhor legibilidade no código fonte que contém os aspectos, visto que cada aspecto introduz/entrecorta atributos e operações apenas de uma classe. Porém, há o aumento do número de componentes do framework e do acoplamento, além de ocorrer a quebra do princípio de separação de interesses [Dijkstra, 1976]: cada interesse deve ser implementado em uma única unidade (classe, interface, aspecto). O uso da estratégia 2) encapsula a implementação do interesse em uma única unidade, reduzindo o acoplamento e aumentando a coesão do framework e o tamanho do vocabulário do framework. Porém, há a redução da legibilidade do código dos aspectos, aumentando a complexidade do código. Outro problema que pode ocorrer é a dificuldade de mapeamento das variabilidades do framework. Sem um mapeamento preciso, não é possível refatorar todas as funcionalidades fornecidas pelo framework OO para aspectos. Um mapeamento falho pode conduzir a detecção imprecisa do nível de entrelaçamento e espalhamento de interesses. E, consequentemente, isso se reflete na modularização inadequada das funcionalidades do framework.

3 3. Diretrizes de Manutenção Com o intuito de prevenir ou amenizar os problemas relacionados ao uso de OA na manutenção de frameworks OO, nesta seção são apresentadas as seguintes diretrizes: a) Analisar a documentação e o código fonte do framework e mapear suas variabilidades; b) Analisar a presença de espalhamento de interesses; c) Analisar a presença de entrelaçamento de interesses; d) Analisar entrelaçamento e espalhamento de interesses de maneira objetiva e subjetiva e; e) Encapsular o entrelaçamento, o espalhamento e cada variabilidade do framework em aspectos. a) Analisar a documentação e o código do framework e mapear suas variabilidades: deve-se identificar os pontos variantes ou variabilidades (hot spots) do framework e representá-las em um diagrama de features, utilizando a notação proposta por Kang et al. (1990) ou a de Gomaa (2004), baseada na linguagem UML. Isso facilita o engenheiro de software no processo de modularização de frameworks, permitindo a compreensão dos elementos obrigatórios, alternativos e opcionais do framework, levando-o a implementar cada feature de modo a desacoplá-la do núcleo (frozen-spots) do framework. b) Analisar a presença de espalhamento de interesses: deve-se verificar se a implementação de cada interesse do framework que passará por manutenção está distribuída por unidades modulares destinadas a implementar outros interesses. Ou seja, para um interesse x, verificar se há código relacionado a esse interesse nas unidades modulares que implementam os interesses y, w e z. c) Analisar a presença de entrelaçamento de interesses: deve-se verificar se a implementação de cada interesse do framework que passará por manutenção está misturada com a implementação de outros interesses. Ou seja, para um interesse x verificar se há código relacionado aos interesses y, w e z nas unidades modulares que implementam o interesse x. d) Analisar entrelaçamento e espalhamento de interesses de maneira objetiva e subjetiva: deve-se analisar o código fonte de cada método do framework e verificar a presença de indícios do interesse avaliado. Objetivamente, é possível identificar alguma palavra chave relacionada ao interesse em análise no código? Após isso, deve-se fazer uma análise subjetiva, ou seja, analisar o conteúdo semântico do método e concluir se está relacionado ao interesse avaliado. Dessa forma, evita-se problemas que um dado método m, destinado a implementar o interesse x, contenha em sua lista de parâmetros um tipo destinado a implementar o interesse y. Se o método m for analisado apenas quanto as palavras-chave pode-se concluir que ele é destinado a implementar os interesses x e y, quando, realmente, é destinado a implementar somente o interesse x. e) Encapsular o entrelaçamento, o espalhamento e cada variabilidade do framework em aspectos: deve-se analisar o diagrama de features do framework para identificar suas features opcionais e alternativas, encapsular cada uma delas em aspectos, analisar o entrelaçamento e o espalhamento de interesses e utilizar aspectos para modularizá-los. Por exemplo, dada a unidade modular u destinada a implementar o interesse x que contém código relacionado ao interesse y. Um aspecto deve ser criado para separar a implementação do interesse y da unidade modular u. Com isso, as funcionalidades do framework são refatoradas para aspectos, de modo a facilitar a composição de diferentes combinações de suas funcionalidades.

4 4. Estudo de Caso: Processo de Manutenção do Framework GRENJ Nesta Seção é apresentado um estudo de caso para ilustrar alguns dos problemas de manutenção que podem ocorrer quando se utiliza linguagem orientada aspectos para modularização de frameworks OO. GRN (Gestão de Recurso de Negócio Business Resource Management) [Braga et al., 1999] é uma linguagem de padrões, em nível de análise, composta por quinze padrões, para apoiar o desenvolvedor na modelagem de sistemas no domínio de gestão de recursos de negócio. GRENJ [Durelli, 2008] é um framework de aplicação OO, desenvolvido com base na linguagem de padrões GRN, que permite a instanciação de sistemas utilizando esses padrões para atender aos requisitos solicitados pelos clientes. Na forma como os padrões da GRN estão implementados na versão OO do GRENJ, há entrelaçamento e espalhamento de interesses relacionados a cada padrão. Isso gera muitos relacionamentos de dependência entre as classes do framework, fazendo com que toda aplicação baseada no GRENJ tenha que carregar todas as classes nele implementadas, independente se são ou não utilizadas. Por exemplo, dado os módulos A e B, que implementam padrões distintos, na versão OO do GRENJ há código relacionado ao módulo A dentro da implementação do módulo B. Para resolver esse problema, o framework GRENJ passou por um processo de modularização com orientação a aspectos, separando a implementação de cada padrão e suas variantes do núcleo do framework. Em virtude da restrição de espaço para apresentação do artigo, somente a modularização do padrão Quantificar Recurso é apresentada. É importante ressaltar que o uso de refatoração OO não é suficiente para efetuar essa modularização, visto que a adição de padrões ou variantes afetam o comportamento estático e dinâmico do framework. Desse modo, há a necessidade de utilizar construções como inter-type declarations e advices, presentes em linguagens orientadas a aspectos como AspectJ, para adicionar atributos e operações em classes, bem como comportamento no contexto de execução de determinados métodos do framework. A orientação a objetos não provê esses mecanismos. O padrão Quantificar Recurso fornece quatro formas de quantificar os recursos de negócio de uma aplicação: i) como único, quando não é necessário ter o controle de uma instância específica do recurso; ii) instanciável, quando é necessário ter o controle de uma instância específica do recurso, como em sistema de biblioteca, em que um livro (o recurso) contém várias cópias; iii) mensurável, quando é necessário lidar com certas quantidades de recurso; ou iv) em lotes. Cada uma dessas formas de quantificação é uma variante do padrão e sua implementação está entrelaçada com a implementação do padrão Identificar Recurso (P1), como ilustrado na Figura 1. Cada método da classe Resource está marcado com um estereótipo, que representa os padrões e variantes que eles implementam. Por exemplo, o método getmeasureunity() de Resource está marcado com os estereótipos <<QR-V2>> e <<QR-V3>>, indicando que é destinado a implementar as variantes Recurso Mensurável e Recurso em Lotes do padrão Quantificar Recurso. Na implementação OO do padrão Quantificar Recurso no GRENJ, há métodos relacionados aos padrões da GRN Locar Recurso e Comercializar Recurso, na classe QuantificationStrategy, que é destinada a implementar o padrão Quantificar Recurso, como ilustrado na Figura 1. Outro problema é a existência de métodos relacionados a todas as estratégias de quantificação em QuantificationStrategy.

5 Figura 1. Implementação OO do padrão Quantificar Recurso Com isso, a separação de interesses, o acoplamento e a coesão do código do padrão ficam afetados, uma vez que é necessário fornecer implementações vazias para métodos não correspondentes a estratégia de quantificação implementada por cada classe. Por exemplo, a classe SingleResource implementa a estratégia de quantificação Recurso Único, e dentro dessa classe é necessário fornecer implementações vazias para métodos como getmeasureunity() e getinstances(), que estão relacionados às estratégias de quantificação Recurso Mensurável ou em Lotes e Recurso Instanciável. Esse entrelaçamento existente na implementação das variantes desse padrão na versão OO GRENJ prejudica a manutenibilidade e a reusabilidade do código. Para modularizar o padrão Quantificar Recurso, primeiramente foram mapeadas as suas variabilidades. Posteriormente, foram analisadas as classes do framework para a detecção de entrelaçamento de espalhamento de interesses. Finalmente, a implementação de cada uma das variantes do padrão Quantificar Recurso foi modularizada com aspectos, como ilustrado na Figura 2. Essa implementação evita que as classes citadas forneçam implementações abstratas como comentado anteriormente. Além disso, na implementação OA desse padrão, os métodos relacionados a ele foram removidos da classe Resource, aumentando a coesão dessa classe e conseqüentemente da implementação do padrão Identificar Recurso. Os métodos relacionados aos padrões Locar Recurso e Comercializar Recurso também foram removidos da classe QuantificationStrategy, que implementa o padrão Quantificar Recurso, aumentando a coesão da mesma. Na Figura 2a) tem-se a representação das classes da implementação OA da variante Recurso Único. ResourceWithQuantificationContainerLoaderAspect é um aspecto comum a todas as variantes do padrão e introduz, por meio do mecanismo de inter-type declarations de AspectJ, atributos e métodos relacionados ao padrão Quantificar Recurso na classe Resource. Essa classe implementa o padrão Identificar Recurso, garantindo que o comportamento do framework permaneça inalterado.

6 Figura 2. Implementação OA do padrão Quantificar Recurso Na implementação OA, da variante Recurso Mensurável ou em Lotes, Figura 2b), os métodos relacionados a essas variantes foram removidos das classes Resource e QuantificationStrategy, sendo encapsulados nos aspectos MeasurableQuantStrategyContainerLoaderAspect e MeasurableResourceContainerLoaderAspect. Esses aspectos introduzem métodos relacionados a essa variante, como getquantityinstock() e getmeasureunity(), nas classes Resource e QuantificationStrategy. Evita-se, assim, que essa variante fique entrelaçada com a implementação de outros padrões e as suas demais variantes. Esse mesmo processo ocorreu com a implementação OA da variante Recurso Instanciável, (Figura 2c). Com a elaboração da versão OA dos padrões da GRN implementados no framework GRENJ, verificou-se que o desenvolvedor pode utilizar um aspecto para introduzir membros ou entrecortar métodos em cada classe que contém indícios do interesse a ser modularizado, para separar esse interesse dessas classes. Dessa forma, é possível reduzir a complexidade do código dos aspectos já que há redução do número de linhas de código de uma unidade modular, facilitando a compreensão e manutenção do código. Um problema com essa estratégia é o aumento do número de componentes do padrão. Além disso, essa estratégia quebra o princípio básico de separação de interesses da orientação a aspectos (cada interesse deve ser implementado em um único módulo) fazendo com que existam vários aspectos que encapsulam a implementação do mesmo interesse. Para resolver esse problema as diretrizes de manutenção da Seção 3 foram usadas. Os interesses relacionados a cada padrão ou variante foram encapsulados em um único aspecto, como ilustrado na Figura 3. O aspecto ResourceWithQuantification, como ilustrado na Figura 3, é comum a todas as variantes do padrão, e introduz atributos e métodos relacionados ao padrão Quantificar Recurso na classes Resource, que implementa o padrão Identificar Recurso. Os aspectos MeasurableQuantStrategyContainerLoaderAspect e MeasurableResourceContainerLoaderAspect, que introduzem atributos e operações relacionados à variante Recurso Mensurável ou em Lotes do padrão Quantificar Recurso nas classes Resource e QuantificationStrategy, foram removidos e foi criado o aspecto MeasurableQuantStrategy para introduzir esses atributos e operações em ambas as classes, como mostrado na Figura 3b). O mesmo procedimento foi utilizado para o Recurso Instanciável, sendo criado o aspecto InstantiableQuantStrategy.

7 Figura 3. Padrão Quantificar Recurso após a aplicação das diretrizes de manutenção 5. Trabalhos Relacionados Bayer e Milewski (2008) desenvolveram uma IDE para apoiar o processo de manutenção. Ela fornece informação do projeto comportamental por meio de um formulário gráfico, o que possibilita que os engenheiros de software compreendam mais facilmente como o sistema funciona e possam localizar o código fonte relevante, sem a necessidade de consultar a documentação. Essa abordagem pode auxilia a detecção de entrelaçamento e espalhamento de interesses e o mapeamento das variabilidades de frameworks. Kawakami et al. (2007) propuseram uma ferramenta de reengenharia denominada ReJAsp (Reengenharia de Java para Aspectos), um plugin do Eclipse, para automatizar a abordagem Aspecting [Ramos et al. 2004], que trata da identificação de interesses transversais. É possível a identificação dos interesses transversais de persistência em banco de dados relacional, persistência em memória intermediária e logging. Posteriormente, Costa et al. (2009) desenvolveram uma ferramenta chamada DMAsp, também um plugin do Eclipse, para apoiar a geração de um modelo orientado a objetos anotado com indícios de interesses transversais, identificados pela ferramenta ReJAsp. Para a aplicação das diretrizes Analisar a Presença Espalhamento de Interesses e Analisar a Presença Entrelaçamento de Interesses propostas neste trabalho, pode-se utilizar as ferramentas ReJAsp e DMAsp. A abordagem Phoenix (Garcia et al., 2005) realiza a reengenharia de software OO para uma mistura de objetos com abstrações OA. Tem seu enfoque em aspect-mining para identificar potenciais interesses transversais a serem modelados e implementados como aspectos, e em técnicas de refactoring para reorganizar o código utilizando transformações de código, o que possibilita a recuperação de um projeto OA. Assim, a abordagem Phoenix pode ser utilizada juntamente com as diretrizes aqui apresentadas para a manutenção de frameworks, sendo gerado um modelo de projeto OA a partir de um código OO. 6. Considerações Finais Durante a manutenção de um framework OO utilizando OA foram verificados problemas como, por exemplo, a existência de vários interesses implementados com entrelaçamento e espalhamento e para modularizá-los foram utilizados aspectos. Na análise da versão original do GRENJ, usado como estudo de caso, foi verificado que a implementação de um interesse se encontra distribuída por várias classes framework. Após essa análise, pode-se utilizar aspectos para modularizar a implementação desse interesse. Uma das duas estratégias comentadas na Seção 2 pode ser utilizada. O uso das diretrizes de manutenção de frameworks apresentadas auxilia na composição de cada uma das features do framework a ser modularizado. Isso permite que aplicações baseadas em

8 frameworks tenham somente código relacionado às funcionalidades necessárias aos requisitos da aplicação. Ao contrário do que ocorre em frameworks convencionais como Spring (2010) e Hibernate (2010) em que é necessário carregar todas as features do framework independente se são utilizadas ou não. Além disso, o uso dessas diretrizes conduz ao projeto de um framework com um menor nível de acoplamento e alta coesão entre suas classes. Isso facilita a manutenção, a extensão e o processo de uso e reúso do framework. A elaboração de um processo para apoiar a manutenção de frameworks orientados a objetos para orientado a aspectos, bem como um estudo sobre o impacto e os problemas do uso de métricas de software nesse processo de manutenção são alguns dos trabalhos futuros. Referências Bayer, R., Milewski, A. E. (2008). Improving Software Maintenance Efficiency With Behavior-Based Cognitive Models. In Proceedings of SMC 2008, Singapore. Bosch, J., Molin, P., Mattsson, M., and Bengtsson, P. (2000). Object-oriented framework-based software development: problems and experiences. ACM Comput. Surv. 32, 1es (Mar. 2000). Braga, R. T. V., Germano, F. S. R., e Masiero, P. C. (1999). A Pattern Language for Business Resource Management. Proceedings of the Annual Conference on Pattern Languages of Programs, 6:1 33. Costa, H. A., Junior, P. A., de Camargo, V. V., and Penteado, R. A. (2009). Recovering Class Models Stereotyped with Crosscutting Concerns. In Proceedings of the 16th Working Conference on Reverse Engineering (October 13-16, 2009). WCRE. IEEE Computer Society, Washington, DC, Dijkstra, Edsger W. (1976). A Discipline of Programming. Prentice-Hall, NJ. Durelli, V. (2008). Um processo de reengenharia ágil de frameworks OO. Dissertação de Mestrado. Departamento de Computação, Universidade Federal de São Carlos. Fayad, M. and Schmidt, D. C. (1997). Object-oriented application frameworks. Communications of ACM 40, 10 (Oct. 1997), Garcia, V. C., Lucrédio, D., Prado, A. F. do, Almeida, E. S. de, Alvaro, A., Meira, S. R. de L. (2005). Towards an Approach for Aspect-Oriented Software Reengineering. In the 7th International Conference on Enterprise Information Systems (ICEIS'2005), May, Miami, USA. Gomaa, Hassan. (2004). Designing Software Product Lines With UML From Use Case to Pattern- Based Software Architectures. Addison-Wesley, 1a. Edição, Hibernate (2010). Hibernate Framework. Kang, K. C., Cohen, S. G., Hess, J. A., Novak, W. E., Peterson, A. S. Feature Oriented Domain Analysis (FODA), (1990). Feasibility Study. Techinical Report CMU/SEI-90-TR-21, Software Engineering Institute, Carnegie Mellon University. Kawakami, D., Penteado R. A. D., Ramos, R. A. (2007). Uma Abordagem para Reengenharia de Sistemas implementados em Java para AspectJ. 1st LA-WASP. Ramos, R. A.; Penteado, R. A. D.; Masiero, P. C. (2004) Um Processo de Reestruturação de Código Baseado em Aspectos. XVIIII SBES v. 1. p Spring (2010). Spring Framework.