Pitfalls in Aspect Mining

"The research domain of aspect mining studies the problem of (semi-)automatically identifying potential aspects and crosscutting concerns in a software system, to improve the system’s comprehensibility or enable its migration to an aspect-oriented solution. Unfortunately, most proposed as- pect mining techniques have not lived up to their expectations yet. In this paper we provide a list of problems that most aspect mining techniques suffer from and identify some of the root causes underlying these problems. Based upon this analysis, we conclude that many of the problems seem to be caused directly or indirectly by the use of inappro- priate techniques, a lack of rigour and semantics on what is being mined for and how, and in how the results of the mining process are presented to the user."
By Kim Mens, Andy Kellens.

Resumo do artigo:

O artigo fala dos problemas apresentados nas técnicas mais utilizadas em mineração de interesses, qual é a causa dos problemas e qual é o futuro desta área de pesquisa.
A area de mineração de interesses preocupa-se de encontrar interesses transversais (aspectos candidatos) dentro do código fonte para poder ser refatorizados em aspectos. O artigo está focado em analisar propostas de mineria de aspectos automatizadas que utilizam técnicas de data mining como “data analysis, formal concept analysis, cluster analysis” e técnicas de analise de código como “program slicing, software metrics and heuristics, clone detection, pattern matching, dynamic analysis”.

Os problemas encontrados são os seguintes:
1. Pobre presisão (P = aspectos candidatos relevantes/todos os candidatos encontrados).
O problema é que a maioria das técnicas apresentam muitos falsos positivos que tem impacto na escalabilidade e os resultados são apresentados sem indicar o tipo de granularidade que pode ser a um nivel individual, do código ou grupo de interesses. A falta de um usuario especialista em identificar interesses para fazer uma comparação com a ferramenta de mineração de aspectos, fazem que os resultados publicados perdem subjetividade.
2. Pobre recall (R= aspectos candidatos relevantes não descobertos/aspectos candidatos relevantes ).
Um dos problemas encontrados é que não se conhece quais são os aspectos relevantes a serem identificados a menos que exista um usuario especialista. Outro problema é que a maioria das técnicas, identifican apenas alguns sintomas de aspectos perdendo ocorrências de aspectos que apresentem outros sintomas. A maior precisão menor recall e vice versa.
3. Subjetividade.
Muitas técnicas apresentam ambiguidade em seus resultados. Depende das definições dos aspectos que as pessoas indicam. Cada ferramenta aplica seus própios filtros e são as pessoas que finalmente fazem a seleccão dos aspectos, assim, a intervenção dos usuarios podem causar subjetividade.
4. Escalabilidade.
Um factor importante a considerar é o tempo-eficiência da ferramenta. A quantidade de tempo requerido para calcular seus resultados. Porém, onde existem maiores problemas é onde existe intervenção humana. Pré-processamento (preparar dados de entrada) e pós-processamento (analisar os resultados).
5. Validação Empírica.
Para validar a qualidade de uma ferramenta, devem ser considerados a medição da precisão e o recall dos resultados em distintos níveis de granularidade. Porém, precisa-se de um benchmark comum para evaluar técnicas de mineração de aspectos que reconheza distintos tipos de aspectos onde exista um consenso.
6. Outros problemas encontrados. como comparação dos resultados de diferentes técnicas, compor distintas técnicas para melhores resultados e o jeito em que os interesses são programados pode mudar dependendo do programador.

Analise dos problemas:

Os problemas têm suas raízes por usar técnicas inadequadas (técnicas de propósito geral, suposições rigidas, propostas excessivamente otimista, técnicas que identifican código espalhado mas não enmaranhado, falta de informação semântica), Definições imprecisas (extração de interesses que não precisam ser convertidas em aspectos), representação inadequada dos resultados (falta de granularidade e uma representação padronizada porque assim não é factível comparar e poder combinar com diferentes técnicas).

Conclusões finais:

Com relação ao presisão e recall: Para um entendimento inicial de um programa de software, pouca presisão e recall não é necessariamente um problema, mas se é necessario migrar para aspectos, estos indicadores devem ser rigorosos.

Com relação as técnicas de mineração de aspectos:

1. Deveriam têr em conta uma maior quantidade de informação semântica, olhando sintomas de “tangling” em adição dos sintomas de “scattering”. Além disso, tomar em conta outras informações. Perguntar-se, É realmente necessario transformar os interesses encontrados em aspectos? Si fora assim, têr uma boa justificação para fazer isso.
2. Utilizar um framework para comparar metodologicamente difetentes técnicas .
3. Precisa-se de técnicas mais inteligentes, a tendência é combinar técnicas que façam mineração de padrões de desenho (ocorrencias de padrões) em vez de representações de estruturas, combinado com máquinas de estado para filtrar falsos positivos.
4. AspectJ é criticado por a falta de base semântica.

Aspect Recommendation for Evolving Software

Cross-cutting concerns are unavoidable and create difficulties in the development and maintenance of large-scale systems. In this paper, we present a novel approach that identifies certain groups of code units that potentially share some cross-cutting concerns and recommends them for creating and updating aspects. Those code units, called concern peers, are detected based on their similar interactions (similar calling relations in similar contexts, either internally or externally). The recommendation is applicable to both the aspectization of non-aspect-oriented programs (i.e. for aspect creation), and the evolution of aspect-oriented programs (i.e. for aspect updating). The empirical evaluation on several real-world software systems shows that our approach is scalable and provides useful recommendations.

By Tung Thanh Nguyen, Hung Viet Nguyen, Hoan Anh Nguyen, Tien N. Nguyen.

Resumo do Artigo: Aspect Recommendation for Evolving Software – Daniel San Martín Santibañez

O artigo apresenta uma inovadora proposta para identificar unidades de código que provavelmente compartilham interesses transversais e suas recomendações para a criação ou atualizacão de aspectos. Essas unidades de código são chamadas concern peers e são detectadas por meio das interações similares que possam ter. Essas interações podem ser internas (dentro do corpo do método) ou externas (chamadas para métodos de outras classes) que estejam relacionadas em contextos similares.

A proposta está sustentada em definições matematicas baseadas na teoría de conjuntos.

A solução algoritmica para a detecção dos interesses transversais é a siguinte (ver o código nos slides):

1. Busca dos candidatos.
   1. XScan procura e adiciona todos os pares de métodos com porções de código similares na lista de candidatos C (MethodsHaveSimilarCode).
   2. XScan adiciona os métodos que tenham o nomes similares na lista de candidatos C (MethodsHaveSimilarName).
   3. XScan adiciona métodos que sobrecarregam ou implementam um mesmo método pai na lista de candidatos C (RelativeMethods).
2. Busca de peers.
   1. Os pares de métodos candidatos na lista C estão ordenados descendentemente por o valor de suas interações similares (função sim).
   2. Se dois métodos candidatos tem , XScan elimina o par de métodos da lista C e é adicionado na lista L.
   3. Com os peer pairs da lista L, procura novos candidatos de métodos com nomes similares (MethodsHaveSimilarName) e que estejam dentro das classes dos métodos selecionados.
   4. Repetir até que não sejam identificados mais peers.

3. Detectar e classificar por rango os peer groups.
   1. Todos os peer pairs da lista L são usados para formar um grafo onde um nodo representa um método peer, e cada aresta representa um peer pair em L.
   2. XScan percorre o grafo e reporta a cada conjunto de nodos conectados como um grupo de peers. O ranking é feito por a maior quantidade de interações externas que possa ter esse grupo de peers.
      
      

A solução algoritmica para a recomendação de uma criação ou atualização de um aspecto é a siguinte (ver o código nas slides).

1. Criação de aspectos em programas OO.
   1. Uso de Eclipse para obter as interações internas e externas.
   2. Eliminar as bibliotecas padrões de Java e os métodos get, set e util para distinguir interesses transversais.
   3. Utilizar o algoritmo para ranking de peers.

2. Criação ou atualização de aspectos em programas AO.
   1. Detectar as mudanças nos métodos dos programas P1 com P2.
   2. Detectar novos aspectos eliminados ou adicionados A1 com A2.
   3. Detectar peer groups em P2.
   4. Para cada shadow group S nos aspectos de P2 ie. em A2, fazer um matching com os peer groups detectados. Se S corresponde com um novo aspecto adicionado, todos os métodos que fazem matching são recomendados. De outra manera, só os métodos modificado ou adicionados são tomados em conta.
   5. Todos os métodos que não fizeram matching, XScan recomenda a criação de novos aspectos.

A avaliação empírica demostra um alto grau de escalabilidade e a exatidão da mineração de aspectos. A exatidão foi definida em termos de precição e cobertura onde os resultados obtidos comparados com os resultados de outra ferramenta de mineração de aspectos são, na maioria dos casos, melhores.