No abstract

Aspect mining identifies cross-cutting concerns in a program to help migrating it to an aspect-oriented design. Such concerns may not exist from the beginning, but emerge over time. By analysing where developers add code to a program, our history-based aspect mining (HAM) identifies and ranks cross-cutting concerns. We evaluated the effectiveness of our approach with the history of three open-source projects. HAM scales up to industrial-sized projects: for example, we were able to identify a locking concern that cross-cuts 1 284 methods in Eclipse. Additionally, the precision of HAM increases with project size and history; for Eclipse, it reaches 90% for the top-10 candidates.

No abstract

As part of the evolution of software systems, effort is often invested to discover in what parts of the source code a feature (or other concern) is implemented. Unfortunately, knowledge about a concern's implementation can become invalid as the system evolves. We propose to mitigate this problem by automatically inferring structural patterns among the elements identified as relevant to a concern's implementation. We then document the inferred patterns as rules that can be checked as the source code evolves. Checking whether structural patterns hold across different versions of a system enables the automatic identification of new elements related to a documented concern. We implemented our technique for Java in an Eclipse plug-in called ISIS4J and applied it to a number of concerns. With a case study spanning 34 versions of the development history of an open-source system, we show how our approach supports the tracking of a concern's implementation through modifications such as extensions and refactorings.

Software may contain functionality that does not align with its architecture. Such cross-cutting concerns do not exist from the beginning but emerge over time. By analysing where developers add code to a program, our history-based mining identifies cross-cutting concerns in a two-step process. First, we mine CVS archives for sets of methods where a call to a specific single method was added. In a second step, such simple cross-cutting concerns are combined to complex cross-cutting concerns. To compute these efficiently, we apply formal concept analysis-an algebraic theory. History-based mining scales well: we are the first to report aspects mined from an industrial-sized project like Eclipse. For example, we identified a locking concern that crosscuts 1284 methods.

For many software projects, bug tracking systems play a central role in supporting collaboration between the developers and the users of the software. To better understand this collaboration and how tool support can be improved, we have quantitatively and qualitatively analysed the questions asked in a sample of 600 bug reports from the MOZILLA and ECLIPSE projects. We categorised the questions and analysed response rates and times by category and project. Our results show that the role of users goes beyond simply reporting bugs: their active and ongoing participation is important for making progress on the bugs they report. Based on the results, we suggest four ways in which bug tracking systems can be improved.

Aspect mining tries to identify crosscutting concerns in legacy systems and thus supports the refactoring into an aspect-oriented design. We briefly introduce DynAMiT, a dynamic aspect mining tool that detects crosscutting concerns based on tracing method executions. While the approach is generally fairly precise, further analysis revealed that some false positives were systematically caused by dynamic binding. Furthermore, some aspect candidates were blurred or not detected due to not-sufficient tracing mechanisms of method executions when using AspectJ's execution pointcuts for the trace generation. We enhanced the mining capabilities of DynAMiT by taking additional static type information into account and generating the traces using call pointcuts instead: In an initial case study with AnChoVis, a 1300 LOC Java program, the number of mined aspect candidates increased by a factor of three, while the number of false positives remained zero.

In this paper we refine the classical co-change to the addition of method calls. We use this concept to find usage patterns and to identify cross-cutting concerns for ArgoUML.