Loading...
Please wait, while we are loading the content...
Similar Documents
Identifying Cross-Cutting Concerns from History
| Content Provider | CiteSeerX |
|---|---|
| Author | Breu, Silvia Zimmermann, Thomas |
| Abstract | As object-oriented programs evolve, they may suffer from the “tyranny of dominant decomposition”: The program can be modularised only one way at a time, leaving cross-cutting concerns scattered across many modules and tangled with one another. Aspectoriented programming (AOP) tries to remedy this by encapsulating these concerns into aspects. Aspect mining identifies such cross-cutting concerns and thus helps to migrate existing software to an aspectoriented program. Aspect mining of large software system like Eclipse is a problem: dynamic approaches depend on test cases and have trouble covering all code and thus detecting all cross-cutting functionality. And static approaches simply cannot analyse systems this big unless they work incrementally. We offer a new approach based on the observation that cross-cutting functionality does not exist from the beginning. Instead, it is introduced over time. More specifically, we speculate that considerable cross-cutting functionality is introduced within short periods of time. To find these, we analyse code additions from development tasks as they are recorded in a software repository like CVS. Since we analyse one task at a time, our approach is independent of a project’s total size. This enables us to report crosscutting functionality for Eclipse, a 1.6 MLOC Java program. In this paper we sketch the basic idea of history-based aspect mining and some initial results. 2 History-based Aspect Mining Previous approaches to aspect mining considered only a single version of a program using static and dynamic program analysis techniques. We introduce the additional dimension of time by mining CVS transactions that introduce new code. Within each transaction we identify those changes that are likely to introduce cross-cutting concerns, which we call aspect candidates. 2.1 Transactions and Aspect Candidates The history of a program can be modelled as a sequence of transactions. A single transaction collects all code changes between two program versions made by a programmer to complete one development task. From a technical point of view, a transactions is de- |
| File Format | |
| Access Restriction | Open |
| Subject Keyword | Cross-cutting Concern Development Task Cross-cutting Functionality Single Transaction Aspectoriented Program Dominant Decomposition Many Module Project Total Size Aspect Mining History-based Aspect Mining Short Period Code Addition Software Repository Identifies Cross-cutting Concern Considerable Cross-cutting Functionality New Code Large Software System Object-oriented Program Mloc Java Program History-based Aspect Mining Previous Approach Single Version Cv Transaction Dynamic Program Analysis Technique Program Version Dynamic Approach Aspect Candidate Code Change Static Approach Initial Result Technical Point Additional Dimension |
| Content Type | Text |
| Resource Type | Article |
