junho/2002pucpr - ppgia - mestrado/20021 analisando o papel dos aspectos em projetos de software (...

Junho/2002 PucPr - PPGIA - Mestrado/2002 1

Analisando o papel dos aspectos em projetos

de software( um estudo de caso [Pace 2001] )

Alunos:

Acir Pereira de França [email protected] Wojciechowski

[email protected] João Bialecki Jr [email protected]

Sistemas Orientados a Objetos AOP Prof. Alcides Calsavara


• Introdução à AOP• AOP• AOP – Abordagem Lingüística• AOP – Abordagem OO• AOP – Abordagem Orientada à Arquitetura• Um caso de uso comparando tecnologias AOP• TCS – o ambiente de desenvolvimento• TCS – métricas utilizadas• TCS – fatores de qualidade• TCS – diferenças observadas • TCS – resultados observados• TCS – conclusões obtidas• Conclusão• Referências


Sumário:


Atualmente, o paradigma de programação dominante é a orientado a objetos – a idéia de construção de um sistema de software decompondo um problema em objetos e escrevendo código nestes objetos. A orientação a objetos é uma idéia inteligente, mas possui algumas limitações:

• Muitos requisitos não são decompostos de forma nítida;• A tecnologia de objetos tem dificuldade em identificar

responsabilidades, restrições e comportamentos generalizados;• Apresenta limitações também nas características de reuso e

adaptabilidade do código e/o aplicativo.


Introdução à AOP:


• A programação pós-objeto (POP) e os mecanismos que buscam acrescentar a expressividade do paradigma OO (Orientação a Objetos) constituem uma área fértil para pesquisa corrente. Os exemplos de tecnologias POP incluem linguagens de domínio específico, programação geradora, programação genérica, linguagens de restrição, reflexão e metaprogramação, orientado a desenvolvimento de características, visões/ponto de visões e corretor de mensagem assíncronas.


Introdução à AOP (cont.):


• Dentro da tecnologia de programação pós-objeto (POP) surge a Programação Orientada à Aspectos1:

• A AOP baseia-se no fato de que os sistemas de computador são melhores programados quando se especifica em separado todas as responsabilidades (concerns) – propriedades ou áreas de interesse - de um sistema, considerando também, seus possíveis relacionamentos.

• As responsabilidades podem variar desde segurança e qualidade do serviço até aspectos de baixo nível como a proteção de dados.


Introdução à AOP (cont.):

1 1. Maneira pela qual uma coisa ou pessoa se apresenta à vista; aparência exterior. 2. Semblante, fisionomia. 3. Cada um dos lados de uma coisa, um fenômeno ou fato que se apresenta à nossa observação; lado, face, ângulo, ponto de vista.


A programação orientada a aspectos é uma das mais promissoras alternativas para melhorar técnicas de OO convencionais. AOP surge para prover melhores meios de solucionar o problema da separação de responsabilidades, usando mecanismos especializados para encapsular tais responsabilidades conforme a essência do comportamento do aplicativo. Isto pode ocorrer utilizando-se de três abordagens básicas:

• uma visão lingüística, • uma visão purista da OO, e • uma visão orientada à arquiteturas.


AOP:


Cada uma destas abordagens envolve vários tradeoffs (custos e benefícios) inclusive na definição de aspecto, criação, apresentação, flexibilidade de políticas de aspecto e evolução.Além dos prós e contras destas alternativas, a pergunta central é: - O quê e como as tecnologias de AOP podem contribuir para promover boas práticas de projeto?Para tornar possível as promessas do AOP exige-se que tais tecnologias também lidem com os problemas onde os objetos tem sido tradicionalmente bem sucedidos. Neste trabalho estará sendo mostrado e discutido um estudo de caso [Pace 2001] de simulação empírica (baseada na experiência) para comparar as técnicas disponíveis de Orientação a Objetos contra a Orientação a Aspectos.


AOP (cont.):


• Visão Lingüística:

Baseia-se na definição de um conjunto de regras da linguagem, usadas para expressar aspectos e suas interações.

As responsabilidades relevantes são identificados no domínio do problema e traduzidas para a construção do aspecto e mais tarde integrado com o programa de decomposição de funcionalidades via interfaces bem definidas.

O aplicativo final é obtido criando a estrutura primária com os aspectos identificados.

Duas linguagens que permitem trabalhar com aspectos são a AspectJ (www.aspectj.org) e a Hyper/J (www.research.ibm.com). A figura 1 ilustra o processo:


AOP – Abordagem Lingüística:



AOP – Abordagem Lingüística (Fig 1):


• Visão Orientada à Objetos:Duas alternativas principais para o uso de aspectos são as estruturas de framework e arquiteturas refletivas (reflective architectures). - A estrutura framework (fig. 2) normalmente provê mais flexibilidade de construção que a linguagem comum. As responsabilidades do negócio estão agora materializadas como classes de aspecto, níveis de estrutura (framework) ou no nível aplicativo-usuário, os desenvolvedores podem personalizar estes aspectos usando mecanismos suportados pela estrutura (framework). Uma vantagem de usar estruturas é que elas podem ser combinadas com outras estruturas ou sistemas a fim de produzir sistemas maiores.- As arquiteturas refletivas incorporam estruturas para representação própria, de forma que o comportamento dos objetos de nível base podem ser realçados e adaptados pelos objetos de nível superior de acordo com requisitos específicos As técnicas refletivas permitem uma separação clara de preocupações mantendo os aspectos no nível superior e os componentes funcionais básicos no nível base.


AOP – Abordagem OO:



AOP – Abordagem OO (Fig. 2):

Estrutura Framework


• Visão Orientada à Arquitetura: Aqui propõe-se uma primeira identificação de responsabilidades usando modelos de arquitetura organizacional, que podem, mais tarde ser mapeados para aspectos usando diferentes tecnologias de implementação. Uma visao de arquitetura envolve um nível mais alto de abstração que as abordagens anteriores. Isto tipicamente inclui duas fases. Inicialmente os desenvolvedores devem identificar a arquitetura do problema, isto é, uma arquitetura representando a organização base para construir o software e a relação custo/benefício impostos por requisitos não-funcionais e possíveis arquiteturas. Diferentemente das abordagens anteriores, as responsabilidades são mapeadas na arquitetura inicial, em vez de codificação eles usam uma estrutura ou uma linguagem construtora. Tem-se então, uma descrição geral de responsabilidades relevantes que por sua vez ativa vários tipos de materialização de aspectos através de diferentes frameworks, mas que retêm as propriedades herdadas da arquitetura original.A figura 3 ilustra estra estrutura.


AOP – Abordagem Orientada à Arquitetura:



AOP – Abordagem Orientada à Arquitetura (Fig. 3):



Um caso de uso comparando tecnologias AOP:

Neste estudo de caso foi proposto uma aplicação para atender um Sistema de Controle de Temperatura (Temperature Control System), o cenário inclui um edifício com quartos exigindo temperaturas específicas e uma rede que consiste em radiadores, tubos e uma caldeira.

• A caldeira é a origem de calor é ela quem gera um fluxo de calor que é distribuído pelo circuito;

• Cada radiador recebe este calor e transfere uma parte para os quartos até que eles alcancem suas temperaturas pré determinadas;

• Para regular o fluxo de calor entre o radiador e o quarto, cada radiador é associado com uma válvula especial que pode ser ajustada pelo sistema de controle;

• O usuário pode configurar a temperatura desejada para um quarto, e quando a temperatura for mais baixo que este valor, uma ação de controle é ativada requisitando mais calor para a caldeira.

• Este exemplo simplificado está interessando em ilustrar a evidência prática de situações que exigem um tratamento de aspectos. Aspectos relacionados a modelos matemáticos, processos concorrentes (threads), programação (sincronização) e otimizações aparecem difundidas através do sistema.



TCS – o ambiente de desenvolvimento:O estudo envolveu quatro diferentes grupos de programadores implementando, em Java, o caso estudado de acordo com as alternativas de AOP mencionado previamente:

• O primeiro grupo implementou o TCS sob uma típica visão OO;• Dois outros grupos direcionaram o projeto para uma perspectiva de

aspectos, e modelaram o TCS usando ambos um linguagem de aspectos (AspectJ) e uma estrutura de AO refletiva, conhecida como TaxonomyAop1.

• Finalmente, o quarto grupo implementou o TCS em cima de uma arquitetura de framework (baseada em eventos) chamada Bolha (Buble). Para a análise, foram selecionados vários fatores de qualidade como:

• apresentação, complexidade, clareza, reusabilidade e adaptabilidadeQuanto ao desempenho, foram realizadas várias execuções dos programas de simulação, os resultados foram bem parecidos, exceto no caso da estrutura de TaxonomyAop que apresentou valores, aproximadamente três vezes mais que as demais implementações. As semelhanças achadas no estudo parecem indicar que ambas as implementações Buble e AspectJ apresentaram código padrões, muito parecidos. Porém, esta consideração pode depender do problema em particular (domínio). ____________________________________________________

1Taxionomia: Parte da ciência que trata a classificação das palavras



TCS – métricas utilizadas:

A métrica associada com estes fatores pretende dar informações dos desenvolvedores sobre a estrutura e código do projeto em OO e prover diretrizes para interpretar os valores. Para medir a complexidade das implementações, foram coletadas:

• estatística de código sobre número de classes e métodos,• número de sentenças por classe e por método,• métodos por classe, e • métrica CCN (Cyclomatic Complexity)1.

Foi observado uma superioridade aparente das abordagens baseadas em estruturas (frameworks) relativas à métrica CCN.

1A métrica de CCN (Cyclomatic Complexity), largamente utilizada e aceita na medição de software pode ser traduzida como uma medida de estabilidade e confiança para um programa. Introduzida por Thomas McCabe em 1976, mede o número de independências lineares existentes em um módulo do programa, fornecendo um único número ordinal que pode ser comparado à complexidade de outros programas. A CCN foi estendida também para abranger o projeto e a complexidade estrutural de um sistema.



TCS – fatores de qualidade:

Quanto a reusabilidade e adaptabilidade, foi usado uma abordagem baseada em cenário para análise de arquitetura de software.

• Cenários: são narrativas que descrevem os casos de uso do sistema, e pode ser usado para abstrair a funcionalidade do sistema ou descobrir falhas possíveis exigindo investimentos.

• Reusabilidade: é definido como a habilidade, a capacidade de componentes de software servirem para a construção de muitos outros aplicativos diferentes.

• Adaptabilidade: define a habilidade de um sistema de software poder ser ajustado, alterado de forma suave com mudanças para atender uma nova especificação do problema, produzindo um choque baixo nos componentes previamente implementados.

Fatores de qualidade Aplicaçãopadrão

Bolha TaxonomyAop AspectJ

Reusabilidade Baixo Baixo Médio Médio

Adaptabilidade Baixo Médio-para-Alto Médio Médio



TCS – diferenças observadas:

Algumas diferenças relativas ao reuso e facilidade de adaptação foram identificadas na avaliação de cenários:

• A implementação baseada em bolha limitou vantagens do reuso se comparadas com a implementação OO, considerando que as implementações com aspectos apresentaram uma pontuação moderada.

• Considerando que projetar para reusabilidade significa que o sistema deva ser melhor estruturado, então seus componentes podem ser escolhidos a partir de produtos previamente construídos e integrados em sistemas maiores, notou-se que tecnologias de AOP não enfocam especificamente este assunto, de qualquer forma eles ajudaram bastante na manutenção, controlando mudanças.

• Com relação a adaptabilidade, a implementação baseada em bolha mostrou resultados muito bons, principalmente com relação a arquitetura base da estrutura.

• As implementações usando aspectos proveram uma sensação mais restrita, que só se refere ao incremento da inclusão de aspectos no sistema e adição de mecanismos que possam ativar ou desativar parcialmente suas capacidades.



TCS – resultados observados:

• Os resultados mostraram que o aplicativo com tecnologia de AOP não possue desvantagem significante em relação ao desempenho. De fato, as duas implementações executaram em tempos quase idênticos com a versão padrão do TCS. A única exceção foi a implementação refletiva. Este diferencial em desempenho está principalmente ligado a abordagem baseada em linguagem, porem as abordagens baseadas em estrutura (frameworks) também apresentaram um desempenho interessante.

• Os esforços de desenvolvimento não foram aumentados no nível na fase de implementação. Ao invés disso, a quantia importante do trabalho era concentrada em níveis de projeto. A maior parte do tempo era dedicado nas interações entre responsabilidades relevantes e a estrutura primária do aplicativo. Foi observado que a codificação de exemplos de aspectos consumiram aproximadamente metade do tempo para entender o modelo, o problema propriamente dito e a outra metade para adaptar o sistema para as características de aspectos.



TCS – resultados observados (cont.):

• Na implementação baseada em bolha, o grupo passou mais tempo modelando o problema e ajustando-o na arquitetura de estrutura. Feito isto, a adaptabilidade foi direta.

• As implementações baseadas em estruturas mostraram que esta abordagem favorece algumas responsabilidades dentro da estrutura da organização e negligencia outras. O que pode tornar difícil para os projetistas, selecionar as responsabilidades corretas da estrutura sem lidar ao mesmo tempo com outras responsabilidades indesejadas. Além disso, as responsabilidades que foram esquecidas, freqüentemente produzem flexibilidade pobre. Foi observado esta situação na estrutura de Bolha, onde as responsabilidades relevantes eram incorporadas implicitamente em sua organização em vez de serem definidas como aspectos.



TCS – conclusões obtidas:

As considerações sobre vantagens e desvantagens de tecnologias de aspecto foram muitas:

• Observou-se que o problema central da tecnologia de aspecto, qualquer que seja a abordagem considerada no caso de uso, não foi somente um atalho ou separação de responsabilidade, mas ele envolveu uma pesquisa mais profunda sobre como entender várias partes do software como sendo artefatos separados e integrados (alguns deles) em um sistema coerente.

• Esta situação diz respeito também à comunicação, quanto mais interações houver com outros componentes (ou aspectos) mais o desenvolvedor terá que saber a fim de entender o sistema.

• Particularmente, os melhores resultados eram obtidos com a estrutura de Bolha.

• A partir dos resultados, outras duas observações devem consideradas:



TCS – conclusões obtidas (cont.):

• As tecnologias AOP são mais fáceis para escrever e mudar certos tipos de responsabilidades. Porém, outras responsabilidades têm que ser combinadas com o construção dos aspectos.

Os autores observaram que as duas implementações usando aspectos assumiram desde o início uma separação entre componentes de simulação e aspectos, mas às vezes esta separação era bastante prematura no sentido que existia pequena direção sobre como separar o projeto dos aplicativos.

• O projeto base de aplicações com aspectos é mais importante que os mecanismos providos pelas tecnologias de AOP, independente da sofisticação. Não foi discutido o valor de tecnologias existentes, apenas que uma boa separação de responsabilidades está em última instância relacionada pelo tipo da arquitetura aplicada.

As tecnologias são úteis neste contexto, com elas é possível promover boas práticas de projeto.



TCS – conclusões obtidas (cont.):

Dados estes resultados, a abordagem orientada a arquitetura propõe, em sua essência, o estudo, raciocínio sobre aspectos relevantes objetivando obter uma melhor concepção da arquitetura do sistema.

Expressando aspectos em um modelo de arquitetura os autores asseguram que fatores de qualidade também afetarão os aspectos escolhidos.

Usando a orientação para arquiteturas, os autores puderam obter uma arquitetura mapeada (e suas responsabilidades relevantes), para diferentes tipos de estruturas (frameworks) organizacionais identificando diferentes necessidades, obtendo também as características herdadas da arquitetura dentro desta materialização.

Finalmente, ele concluíram a abordagem lingüística é a melhor contribuição para facilitar a implementação de boas práticas de projeto.


A Orientação à Aspectos apresenta-se como uma nova técnica para desenvolvimento de projetos que pretende agregar valor a Programação Pós Objetos (POP), aproveitando tudo o que a OO possui e acrescendo os aspectos, que na sua essência representam as responsabilidades ou áreas de interesses da organização e que devem ser identificados, separados e direcionados para uma arquitetura de estruturas (frameworks).

Não é possível opinar sobre a AOP somente considerando o caso de uso estudado, porque este apresentou um projeto pouco comum, fora do nosso domínio e também não detalha sobre o código fonte.


Conclusão:


Para identificar todo o potencial da AOP, deve-se estudar mais, procurando identificar casos mais próximos dos projetos por nós desenvolvidos e também sobre as ferramentas apresentadas para desenvolvimento e identificação de aspectos (AspectJ, Hyper/J, TaxonomyAop).

Concluí-se que trata-se de uma uma opção muito interessante e que deve ser avaliada nos próximos projetos a serem desenvolvidos, talvez desenvolver um projeto piloto ou um projeto paralelo à outro já existente, tomando cuidado para que em qualquer das opções:

• utilizar-se de um domínio de problema bem conhecido;• limitar os objetivos à validar a técnica, sem maiores pretensões.


Conclusão (cont.):


1. Elrad T., Filman, R. E., Aspect-Oriented Programming. Communications of the

ACM, Oct 2001, v. 44 n. 10. p 29 – 32.

2. Pace J. A. D., Campo M. R., Analyzing the role of aspects in software design.

Communications of the ACM, Oct 2001, v. 44 n. 10. p 67 – 73.

3. Aspect-oriented software development. Disponível em <www.aosd.net> Acesso em

04 jun 2002.

4. Aspectj.org - Crosscutting objects for better modularity. Disponível em

<http://aspectj.org/servlets/AJSite> Acesso em 04 jun 2002.

5. Hyper/J: Multi-Dimensional Separation of Concerns for Java. Disponível em

<http://www.research.ibm.com/hyperspace/HyperJ/HyperJ.htm> Acesso 05 jun 2002.


Referências:

junho/2002pucpr - ppgia - mestrado/20021 analisando o papel dos aspectos em projetos de software (...

Documents