Software product lines aim to create highly configurable programs from a set of features. Common belief and recent studies suggest that aspects are well-suited for implementing features. We evaluate the suitability of AspectJ with respect to this task by a case study that refactors the embedded database system Berkeley DB into 38 features. Contrary to our initial expectations, the results were not encouraging. As the number of aspects in a feature grows, there is a noticeable decrease in code readability and maintainability. Most of the unique and powerful features of AspectJ were not needed. We document where AspectJ is unsuitable for implementing features of refactored legacy applications and explain why. 1.

In this paper we present aspect-oriented programming laws that are useful for deriving refactorings for AspectJ. The laws help developers to verify if the transformations they define preserve behavior. We illustrate that by deriving several AspectJ refactorings. We also show that our laws are useful for restructuring two Java applications with the aim of using aspects to modularize common crosscutting concerns. 1.

This paper presents a human guided automated approach to refactoring object oriented programs to the aspect oriented paradigm. The approach is based upon the iterative application of four steps: discovery, enabling, selection, and refactoring. After discovering potentially applicable refactorings, the enabling step transforms the code to improve refactorability. During the selection phase the particular refactorings to apply are chosen. Finally, the refactoring phase transforms the code by moving the selected code to a new aspect. This paper presents the results of an evaluation in which one of the crosscutting concerns of a 40,000 LoC program (JHotDraw) is refactored. 1.

Aspect Oriented Programming (AOP) provides mechanisms for the separation of crosscutting concerns – functionalities scattered through the system and tangled with the base code. Existing systems are a natural testbed for the AOP approach, since they often contain several crosscutting concerns which could not be modularized using traditional programming constructs. This paper presents an automated approach to the problem of migrating systems developed according to the Object Oriented Programming (OOP) paradigm into Aspect Oriented Programming (AOP). A simple set of six refactorings has been defined to transform OOP to AOP and has been implemented in the AOP-Migrator tool, an Eclipse plug-in. A set of enabling transformations from OOP to OOP complement the initial set of refactorings. The paper presents the results of four case studies, which use the approach to migrate selected crosscutting concerns from medium–sized Java programs (in the range 10K to 40K lines of code) into equivalent programs in AspectJ. The case study results show the feasibility of the migration and indicate the importance of the enabling transformations as a pre-processing step. 1

Abstract. Aspect-oriented programming languages promise to provide better modularity than pure object-oriented decomposition. A typical benefit of increased modularity is ease of maintenance, evolution and reuse. However, it has been noted by various researchers that many of the first generation aspect languages do not provide the degree of reusability initially hoped for. In this paper, we argue that the problem is due to a lack of support for aspect genericity, respectively to a lack of support for a sufficiently powerful kind of genericity. We introduce the concept of uniform genericity for aspect languages and discuss in which ways it goes beyond previous approaches to generic aspects. Then we present LogicAJ, a uniformly generic aspect language. Using LogicAJ as an example, we show how uniform aspect genericity recommends itself for implementing reusable solutions of various problems discussed in literature, ranging from the generic replacement of object instantiation, over verification of constraints and conventions, to the generic implementation of design pattern variants. We believe uniform genericity to be an important ingredient for second generation aspect languages whose aspects are only loosely coupled to base programs, thus easing aspect reuse and independent evolution of aspects and base programs. 1

ABSTRACT. Aspect-orientation promises better modularity than pure object-oriented decomposition. A typical benefit of increased modularity is ease of maintenance, evolution and reuse. However, it has been noted by various researchers that many of the first generation aspect languages do not provide the degree of reusability initially hoped for. In this paper, we argue that the problem of insufficient reusability is due to a lack of support for aspect genericity. We analyze various problems of traditional aspect languages and define aspect genericity to be the ability to concisely express aspect effects that vary depending on the context of a join point known at weave-time, without falling back to runtime reflection. We identify the ability to parameterize aspect effects with meta-variables ranging over base language elements as the technical prerequisite for achieving genericity and describe the design space for generic aspect languages in terms of five basic questions that a language designer should consider. Within this space we review the different proposals for generic aspect languages made so far and compare them by showing which part of the possible design space is explored within these languages. Among the reviewed design options we identify predicate-based binding of logic metavariables, uniform genericity and fine-grained genericity as optimal answers to three of the discussed questions. Last but not least, we identify open research problems that are specific to aspect genericity or aggravated in the presence of genericity. We expect that genericity will be a key ingredient of a second generation of aspect languages. It will significantly reduce the dependency of aspects on base programs and will automatically select behavior depending on the weave-time context of a join point in the same way as dynamic binding does depending on the type of a message receiver.

In this paper, we present a solution that allows systems to remain active while they are evolving. Our approach goes out from the principle of separated concerns and has two steps. In the first step, we have to make sure that the system's evolvable concerns are cleanly separated. We propose aspect mining and static refactorings for separating those concerns. In a second step, we allow every concern to evolve separately. We present a preliminary reflective framework that allows dynamic evolution of separate concerns.

Aspect-Oriented Programming (AOP) introduces a new software module unit named aspect to encapsulate crosscutting concerns. While AOP modularizes crosscutting concerns to improve maintainability and reusability, AOP introduces a new factor of complexity. It is difficult to find defects caused by an aspect modifying or preventing the behavior of other objects and aspects. In this paper, we examine a method to support a debugging task in aspect-oriented software development. We propose an application of a call graph generation and program slicing to assist in debugging. A call graph visualizes control dependence relations between objects and aspects and supports the detection of an infinite loop. On the other hand, program slicing shows the user changes of dependence relations caused by aspects. We implement a program-slicing tool for AspectJ and apply it to certain programs. The experiment illustrates how our approach effectively helps developers understand the influence of aspects in a program. 1.

Abstract. One of the main problems in Aspect-Oriented Software Development is the so-called fragile pointcut problem. Uncovering and specifying a good robust pointcut is not an easy task. In this paper we propose to use Inductive Logic Programming, and more specifically the FOIL algorithm, to automatically identify intensional (or “pattern-based”) pointcuts. We present the tool chain we implemented to induce a pointcut given a set of identified joinpoints. Using several realistic medium-scale experiments, we show that our approach is able to automatically induce robust pointcuts for a set of joinpoints. 1

Creating a software product line from a legacy application is a difficult task. We propose a tool that helps automating tedious tasks of refactoring legacy applications into features and frees the developer from the burden of performing laborious routine implementations. 1.