Detecting broken pointcuts using structural commonality and degree of interest

Abstract

Pointcut fragility is a well-documented problem in Aspect-Oriented Programming; changes to the base-code can lead to join points incorrectly falling in or out of the scope of pointcuts. Deciding which pointcuts have broken due to base-code changes is a daunting venture, especially in large and complex systems. We present an automated approach that recommends pointcuts that are likely to require modification due to a particular base-code change, as well as ones that do not. Our hypothesis is that join points selected by a pointcut exhibit common structural characteristics. Patterns describing such commonality are used to recommend pointcuts that have potentially broken with a degree of confidence as the developer is typing. The approach is implemented as an extension to the popular Mylyn Eclipse IDE plug-in, which maintains focused contexts of entities relevant to the task at hand using a Degree of Interest (DOI) model. We show that it is accurate in revealing

AspectJ code analysis and verification with GASR

“…As a result, refactorings that impact shadow matches also include refactoring proposals for the pointcut, such that these remain valid. In the same line we find the work on pointcut rejuvenation and Fraglight [4,5]. New code that is added as the software evolves may also need to be captured by the existing pointcuts, i.e., they need to be changed.…”

“…Gasr is a source code analysis tool that works, as-is, on AspectJ source code only. Yet almost all published analyses of aspectual source code have been performed on AspectJ code [2,3,4,5,6,8,9,11,12,13], and it is commonly considered as being the most used aspect-oriented language. As a result, Gasr is a suitable alternative for these approaches and can also be used to analyse a substantial fraction of all aspectual source code.…”

“…New code that is added as the software evolves may also need to be captured by the existing pointcuts, i.e., they need to be changed. Custom analyses are developed that suggests changes to pointcuts when needed, either considering the aspect developer [4] or the base code developer [5]. Earlier work in this area [6,7] also used custom analyses.…”

“…We can use Gasr to perform fully automatic verification of this assumption, yielding a first step of the followup work proposed in the AA paper. The following logic rule will reveal violations of the assumption: (pointcut-concretizedby ?cpointcut ?rcpointcut))) 5 The third system investigated in AA currently fails to compile due to an AspectJ internal compiler error and hence could not be analysed by us.…”

“…An example of the latter interaction is that an aspect may change the class hierarchy, an example of the former interaction is pointcuts that are slightly or subtly incorrect and hence fail to match or match wrongly. As a result, many possible issues in aspectual code have been separately identified and source code analysis tools built to address them [2,3,4,5,6,7,8,9,10,11,12,13].…”