Uma ferramenta CASE para o Desenvolvimento de Software Orientado a Aspectos

Transcrição

1 Uma ferramenta CASE para o Desenvolvimento de Software Orientado a Aspectos Vinicius Cardoso Garcia 1, Daniel Lucrédio 1, Luíza Frota de Paula Pinto 1, Alexandre Alvaro 2, Eduardo Santana de Almeida 2, Antonio Francisco do Prado 1 1 GOES Grupo de Engenharia de Software Departamento de Computação Universidade Federal de São Carlos Caixa Postal 676 São Carlos, SP vinicius@dc.ufscar.br, lucredio@dc.ufscar.br, luiza@comp.ufscar.br, prado@dc.ufscar.br 2 Centro de Informática Universidade Federal de Pernambuco Centro de Estudos e Sistemas Avançados do Recife C.E.S.A.R. Caixa Postal 7851 Recife, PE aa2@cin.ufpe.br, esa2@cin.ufpe.br Abstract. This paper shows a tool to support Aspect-Oriented Software Development at the first process phases. Like this, a notation was defined, through the UML extension for the aspect-oriented paradigm, which enables the aspect identification in a high-level abstraction. An aspect-oriented implementation of the Observer design pattern is used to present how the tool supports this process. Resumo. Este artigo apresenta uma ferramenta para apoiar o Desenvolvimento de Software Orientado a Aspectos nas primeiras fases do processo. Para isto, foi definida uma notação, por meio da extensão da UML, para o paradigma orientado a aspectos, que permite a identificação de aspectos em um alto nível de abstração. Uma implementação orientada a aspectos do padrão de projeto Observer é utilizada para apresentar como a ferramenta dá suporte a esse processo. 1. Introdução A Programação Orientada a Aspectos (POA) [2] é um novo paradigma para o desenvolvimento de software que procura aumentar a modularidade reduzindo os problemas com entrelaçamento e espalhamento de código, tornando a estrutura do software mais clara e de mais fácil manutenção [2]. A POA pode ser aplicada para a implementação de vários interesses multi-dimensionais (crosscutting concerns) como, por exemplo, interação entre objetos, segurança, persistência, distribuição e tratamento de exceções, por meio de uma unidade modular chamada de aspecto. AspectJ 1 é uma linguagem de programação de apoio à POA por meio de novas construções para implementar os interesses multi-dimensionais. Enquanto AspectJ é uma Financiado pela Fundação de Amparo à Pesquisa do Estado da Bahia (FAPESB) - Brazil Financiado pela Fundação de Amparo à Pesquisa do Estado de São Paulo (FAPESP) - Brazil Financiado pelo Programa Institucional de Bolsas de Iniciação Científica - PIBIC/CNPq 1

2 poderosa linguagem para a POA, não existe ainda uma linguagem de modelagem orientada a aspectos que apóie o projeto orientado a aspectos, em um nível mais alto de abstração. Alguns projetos vêm sendo desenvolvidos para modelar aspectos em um alto nível de abstração, na fase de projeto. As pesquisas que estão em andamento ainda não propuseram uma padronização e não estão maduras o suficiente, entretanto, ainda sim, algumas vêm destacando-se, como, por exemplo [6] e [4]. Sendo assim, este artigo apresenta uma ferramenta CASE para apoiar o Desenvolvimento de Software Orientado Aspectos (DSOA) por meio de uma notação estendida da UML com os conceitos da POA e da semântica da linguagem AspectJ. Nas demais seções deste artigo são feitas considerações sobre o projeto orientado a aspectos e sua implementação em uma ferramenta CASE. 2. Projeto de Software Orientado a Aspectos O projeto orientado a aspectos organiza o processo de DSOA e possibilita a identificação de aspectos em um alto nível de abstração nas primeiras fases do processo, favorecendo assim a aprendizagem e a documentação do projeto de aspectos de uma forma mais intuitiva. A partir de então, esta documentação e o conhecimento adquirido no processo, facilitam e estimulam o reuso de aspectos [6]. Os conceitos básicos do paradigma orientado a aspectos, como pontos de combinação (join points), pontos de corte (pointcuts), entrelaçamento (crosscutt), sugestões (advices) e aspectos são fundamentos que devem estar presentes em todo o processo de desenvolvimento de software, desde a especificação até a implementação. Porém, sabe-se que estes conceitos foram originalmente propostos considerando-se apenas a sua implementação, por meio de uma linguagem de programação [1]. Contudo, a definição de um padrão para o projeto de software orientado a aspectos, a partir de modelos e técnicas de modelagem orientadas a aspectos independentes da linguagem de programação, vem despertando o interesse de pesquisadores. Todavia, ainda é uma área onde a pesquisa foi pouco desenvolvida. 3. A notação UAE A principal construção em AspectJ é o aspecto. Um aspecto define uma funcionalidade específica que pode afetar diferentes partes de um sistema, como, por exemplo, persistência em banco de dados. Além disso, os aspectos podem alterar a estrutura dinâmica de um sistema por meio dos pontos de combinação (join points) ou, ainda, alterar a estrutura estática por meio da declaração de introduções (introductions). Um aspecto normalmente define um ponto de corte (pointcut) que identifica os pontos de combinação e adiciona comportamentos a eles por meio de sugestões (advices). A partir do estudo das diferentes propostas para a modelagem orientada a aspectos, alguns pontos em comum foram identificados, indicando uma conformidade na representação de alguns conceitos da POA. Esta seção apresenta a notação UAE (UML-based Aspect Engineering) para a modelagem de sistemas orientados a aspectos, por meio da extensão da UML. Para dar suporte a esta notação, a ferramenta de modelagem MVCASE [3] foi estendida para apoiar o projeto orientado a aspectos através da notação UAE. Primeiramente o engenheiro de software deve, a partir do projeto já criado, inserir um novo diagrama na

3 visão lógica (Logical View), por meio da seqüencia de menus: New -> Aspect Diagram. A seguir, um novo diagrama é criado, permitindo ao engenheiro de software utilizar os estereótipos criados para representar as construções da POA, são eles: <<aspect>>, <<crosscuts>> e <<introduces>>, conforme mostra a Figura 1. Figura 1: Extensão da MVCASE para o Projeto Orientado a Aspectos Para facilitar a apresentação da notação, será utilizado como exemplo a modelagem orientada a aspectos do padrão de projeto Observer [5] aplicado para um problema envolvendo a visualização de temperaturas. Considere-se um conjunto de termômetros que colhem informação de uma fonte de temperatura. A todo momento que a temperatura mudar, o display do termômetro deve ser atualizado. A Figura 2 mostra esta modelagem, onde os elementos sombreados são específicos da notação UAE. Nesta notação, um aspecto possui uma representação diferente da classe, o que permite diferenciar mais facilmente os elementos, resultando em uma melhor qualidade visual do modelo. Uma interface do tipo Observer é definida para descrever a regra Observer. Todos os observadores devem implementar esta interface. O objetivo é permitir a cada observer ter um subject correspondente. Este exemplo não trata múltiplos subjects para um observer. Do mesmo modo, tem-se uma interface Subject, onde todos os subjects devem implementá-la. Figura 2: Notação UAE Na Figura 2 tem-se a classe Celsius que é uma fonte de dados de temperatura. Esta classe armazena as informações sobre a temperatura corrente em graus centígrados, que podem ser acessadas pelos métodos setdegrees e getdegrees. Outra classe importante é a classe Thermometer, que é a classe base para o conjunto de termômetros no exemplo, que vão implementar o Observer, as classes CelsiusThermometer e FahrenheitThermometer. Estas classes estendem a classe Thermometer.

4 Usando as técnicas de POA, é possível separar os elementos relacionados ao padrão Observer dos demais elementos. Para isso são utilizadas as seguintes construções: 3.1. Aspecto Um aspecto abstrato chamado ObserverPattern é definido para implementar a funcionalidade do padrão de projeto. O aspecto ConcreteObserverPattern estende o aspecto abstrato ObserverPattern e indica quais classes são observers, quais são subjects e em que casos os observers serão notificados Pontos de corte O aspecto abstrato ObserverPattern cria um ponto de corte abstrato, especificado pela etiqueta valorada com o nome +statechanges, e que é estendido no aspecto concreto para informar em quais situações os observers serão notificados. Ele implementa ainda uma sugestão do tipo after, especificada pela etiqueta valorada +after, que irá notificar todos os observers quando estes pontos de corte foram alcançados. O ponto de corte abstrato definido no aspecto ObserverPattern (linha 1, Figura 2) também é estendido no aspecto concreto e define que os observers irão ser notificados toda vez que o método setdegrees() for chamado (linha 2, Figura 2) Introduções É possível também especificar introduções, por meio do estereótipo <<intruduced>> e do relacionamento <<introduces>>. No caso so aspecto abstrato ObserverPattern, os seguintes atributos e métodos são criados dinamicamente na interface Subject: observers, add(..), remove(..) e getobservers(), e na interface Observer: subject, setsubject(..) e getsubject. Por meio de introduções também é possível mudar a estrutura das classes, conforme ocorreu com a classe Celsius, que passou a implementar a interface Subject, especificado por um relacionamento do tipo realize com o estereótipo <<introduced>>. Ainda sobre a classe Celsius, o método getdata() é introduzido, e tem sua implementação de acordo com a interface Subject. O mesmo ocorreu com a classe Thermometer, que passa a implementar a interface Observer e tem o método update() definido de acordo com a interface Observer. Após o engenheiro de software ter o modelo orientado a aspecto especificado, é possível gerar o código automaticamente em uma linguagem orientada a aspectos, no caso AspectJ. O código gerado é testado e caso erros sejam encontrados, ou novos requisitos sejam identificados, o engenheiro de software pode trabalhar no modelo, especificado na ferramenta CASE, e novamente gerar o código em AspectJ. Na Figura 3 é apresentada a geração do código do aspecto abstrato ObserverPattern, na MVCASE. 4. Trabalhos Correlatos A necessidade de uma notação satisfatória para o projeto de software orientado a aspectos foi reconhecida anos após o paradigma ter sido criado. Dentre as diferentes propostas para estender a UML destaca-se a proposta de Suzuki e Yammamoto [6] e a de Pawlak et al.[4].

5 Figura 3: Geração de código em AspectJ na MVCASE 4.1. Suzuki e Yammamoto A primeira proposta de extensão da UML com conceitos para o projeto de software orientado a aspectos foi apresentada por Suzuki e Yammamoto [6]. Nesta abordagem, uma nova meta-classe UML chamada aspect é introduzida. Esta meta-classe está relacionada à classe base por meio de um relacionamento de realização. Esta proposta tem dois problemas. Primeiro, os autores apresentam somente uma notação que pode ser usada para representar o conceito de introduções. Não está claro como os pontos de corte e as sugestões podem ser especificados na UML e como será representada a forma que os relacionamentos de entrecorte (crosscutts) afetam o comportamento das classes. Segundo, o uso de um relacionamento de realização para modelar a relação entre um aspecto e as classes que ele entrecorta não está totalmente de acordo com a semântica da AspectJ. Na UML uma realização é um relacionamento entre um elemento de modelo específico e o elemento de modelo que o implementa [7]. Em AspectJ, entretanto, uma sugestão não é uma pura declaração de um entrecorte. Em AspectJ, uma sugestão declara e implementa as características de um entrecorte Pawlak et al. A proposta de Pawlak et al. [4] para o Projeto de Software Orientado a Aspectos por meio da extensão da UML é a que se apresenta mais interessante. São definidos três novos conceitos na UML: (1) grupos (groups), que provêm meios de classificação para entidades distribuídas e heterogêneas, (2) relações de ponto de corte (pointcut relations) que permitem ao engenheiro de software definir entrecortes (crosscutts) dentro do programa funcional, e (3) a metaclasse aspecto (aspect-classes) que implementa a extensão do programa nos pontos de entrecorte (crosscutting points) especificados pelas relações de ponto de corte. Porém, alguns pontos sobre o trabalho de Pawlak et al. apresentam problemas: a utilização do papel de um relacionamento para representar os pontos de combinação acaba poluindo visualmente o modelo, visto que a definição de pontos de combinação normalmente envolve um grande número de caracteres. Outro ponto é a utilização de caracteres especiais como, por exemplo, sinal de exclamação (! ) que pode possuir outro significado em um linguagens de programação, resultando em confusão. A notação UAE busca solucionar estes problemas, oferecendo uma notação simples, onde a representação de aspectos é diferenciada em relação à de classes, com pouca

6 poluição visual e voltada à linguagem AspectJ. 5. Conclusões e Trabalhos Futuros Neste artigo foi apresentada uma ferramenta CASE para apoiar o DSOA e uma nova abordagem para representar os conceitos da POA e a semântica da AspectJ na UML. Na ferramenta é possível especificar as construções disponíveis pela linguagem para implementar os interesses multi-dimensionais em aspectos. São utilizados estereótipos específicos, e em alguns casos etiquetas valoradas, que estendem os conceitos da UML. Deste modo os interesses multi-dimensionais podem ser especificados em um alto nível de abstração, proporcionando em nível de modelo as vantagens que a POA já provê em nível de código (melhora na manutenibilidade, legibilidade do código, adaptabilidade e reuso, entre outras). A MVCASE foi modificada e agora possui uma interface específica para a criação de modelos orientados a aspectos. Além disto, também é possível gerar o código automaticamente em AspectJ, acelerando o DSOA. Na maioria das ferramentas de modelagem existentes não existe suporte para a geração de código nem para a modelagem de aspectos, sendo necessário utilizar os próprios mecanismos de extensão da UML, o que além de mais trabalhoso não resulta em boa legibilidade do modelo. Atualmente mais testes estão sendo realizados, para verificar a validade tanto da extensão da MVCASE como da notação UAE. Como trabalhos futuros, têm-se a adição de técnicas de modelagem para representar também o processo de weaving, que consiste na combinação, em tempo de compilação dos diferentes interesses multi-dimensionais. Isso facilitará o trabalho do engenheiro de software, possibilitando a geração automática de scripts de compilação, acelerando o processo de DSOA. Referências [1] G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm, and W. G. Griswold. An overview of AspectJ. In J. L. Knudsen, editor, Proceedings of 15th European Conference on Object-Oriented Programming (ECOOP 2001), Lecture Notes in Computer Science (LNCS) 2072, pages , Berlin, jun 2001b. Springer-Verlag. [2] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J.-M. Loingtier, and J. Irwin. Aspect- Oriented Programming. In Proceedings of the 11st European Conference Object-Oriented Programming (ECOOP 97), volume 1241 of LNCS, pages Springer Verlag, [3] D. Lucrédio, E. S. Almeida, C. P. Bianchini, A. F. Prado, and L. C. Trevelin. Orion - a component based software engineering environment. Journal of Object Technology, Special issue: TOOLS USA 2003, 3(4):51 74, April [4] R. Pawlak, L. Duchien, G. Florin, F. Legond-Aubry, L. Seinturier, and L. Martelli. A UML notation for aspect-oriented software design. In Proceedings of the 1st International Conference on Aspect-Oriented Software Development (AOSD 2002). ACM Press, April [5] E. K. Piveta and L. C. Zancanella. Observer pattern using aspect-oriented programming. In The Third Latin American Conference on Pattern Languages of Programming (SugarLoafPLOP 2003), [6] J. Suzuki and Y. Yamamoto. Extending UML with aspects: Aspect support in the design phase. In Proceedings of 13rd the European Conference Object-Oriented Programming (ECOOP 99). International Workshop on Aspect-Oriented Programming, June [7] UML. Unified Modeling Language (UML) - version 1.5. Object Management Group, May 2004.