Aspect-oriented programming is emerging as a powerful tool for system design and development. In this paper, we study aspects as primitive computational entities on par with objects, functions and horn-clauses. To this end, we introduce ABC, a name-based calculus, that incorporates aspects as primitive. In contrast to earlier work on aspects in the context of object-oriented and functional programming, the only computational entities in ABC are aspects. We establish a compositional translations into ABC from a functional language with aspects and higher-order functions. Further, we delineate the features required to support an aspect-oriented style by presenting a translation of ABC into an extended p-calculus.

Nearly ten years after its first presentation and five years after its first application to operating systems, the suitability of Aspect-Oriented Programming (AOP) for the development of operating system kernels is still highly in dispute. While the AOP advocacy emphasizes the benefits of AOP towards better configurability and maintainability of system software, most kernel developers express a sound skepticism regarding the thereby induced runtime and memory costs: Operating system kernels have to be lean and efficient. We have analyzed the runtime and memory costs of aspects in general, on the level of µ-benchmarks, and by refactoring and extending the eCos operating system kernel using AspectC++, an AOP extension to the C++ language. Our results show that most AOP features do not induce a intrinsic overhead and that the actual overhead induced by AspectC++ is very low. We have also analyzed a test case with significant aspect-related costs. This example shows how the structure of the underlying kernel can have a negative impact on aspect implementations and how these costs can be avoided by an aspect-aware design. Based on this analysis, our conclusion is that AOP is suitable for the development of operating system kernels and other kinds of highly efficient infrastructure software.

Aspect-oriented software development is gaining popularity with the wider adoption of languages such as AspectJ. To reduce the manual effort of testing aspects in AspectJ programs, we have developed a framework, called Aspectra, that automates generation of test inputs for testing aspectual behavior, i.e., the behavior implemented in pieces of advice or intertype methods defined in aspects. To test aspects, developers construct base classes into which the aspects are woven to form woven classes. Our approach leverages existing test-generation tools to generate test inputs for the woven classes; these test inputs indirectly exercise the aspects. To enable aspects to be exercised during test generation, Aspectra automatically synthesizes appropriate wrapper classes for woven classes. To assess the quality of the generated tests, Aspectra defines and measures aspectual branch coverage (branch coverage within aspects). To provide guidance for developers to improve test coverage, Aspectra also defines interaction coverage. We have developed tools for automating Aspectra’s wrapper synthesis and coverage measurement, and applied them on testing 12 subjects taken from a variety of sources. Our experience has shown that Aspectra effectively provides tool supports in enabling existing test-generation tools to generate test inputs for improving aspectual branch coverage.

As aspect-oriented software development gains popularity, there is growing interest in using aspects to implement cross-cutting concerns in object-oriented systems. When aspect-oriented features are added to an object-oriented program, or when an existing aspect-oriented program is modified, the new program needs to be regression tested to validate these changes. To reduce the cost of regression testing, a regression-test-selection technique can be used to select only a necessary subset of test cases to rerun. Unfortunately, existing approaches for regression test selection for object-oriented software are not effective in the presence of aspectual information woven into the original code. This paper proposes a new regression-test-selection technique for AspectJ programs. At the core of our approach is a new control-flow representation for AspectJ software which captures precisely the semantic intricacies of aspect-related interactions. Based on this representation, we develop a novel graph comparison algorithm for test selection. Our experimental evaluation shows that, compared to existing approaches, the proposed technique is capable of achieving significantly more precise test selection. 1

Aspect-Oriented Programming (AOP) is a programming paradigm that supports the modular implementation of crosscutting concerns. Thereby, AOP improves the maintainability, reusability, and configurability of software in general. Although already popular in the Java domain, AOP is still not commonly used in conjunction with C/C++. For a broad adoption of AOP by the software industry, it is crucial to provide solid language and tool support. However, research and tool development for C++ is known to be an extremely hard and tedious task, as the language is overwhelmed with interacting features and hard to analyze. Getting AOP into the C++ domain is not just technical challenge. It is also the question of integrating AOP concepts with the philosophy of the C++ language, which is very different from Java. This paper describes the design and development of the AspectC++ language and weaver, which brings fully-fledged AOP support into the C++ domain.

Change impact analysis is a useful technique for software evolution. It determines the effects of a source editing session and provides valuable feedbacks to the programmers for making correct decisions. Recently, many techniques have been proposed to support change impact analysis of procedural or object-oriented software, but seldom effort has been made for aspect-oriented software. In this paper we propose a new change impact analysis technique for AspectJ programs. At the core of our approach is the atomic change representation which can precisely capture semantic differences between two versions of an AspectJ program. We also present a change impact model, based on static AsepctJ call graph construction, to determine the impacted program parts, affected tests and their responsible affecting changes. As an application of change impact analysis, we discuss how our model can help programmers locate the exact failure reason by narrowing down those affecting changes when debugging AspectJ programs. The proposed techniques have been implemented in Celadon, a change impact analysis framework for AspectJ programs. We performed an experimental evaluation of the proposed techniques on 24 versions of 8 AspectJ benchmarks. The results show that our proposed technique can effectively perform change impact analysis and provide valuable debugging information for AspectJ programs.

Aspect-oriented software development is gaining popularity with the adoption of languages such as AspectJ. Testing is an important part in any software development, including aspect-oriented development. To automate generation of unit tests for AspectJ programs, we can apply the existing tools that automate generation of unit tests for Java programs. However, these tools can generate a large number of test inputs, and manually inspecting the behavior of the software on all these inputs is time consuming. We propose Raspect, a framework for detecting redundant unit tests for AspectJ programs. We introduce three levels of units in AspectJ programs: advised methods, advice, and intertype methods. We show how to detect at each level redundant tests that do not exercise new behavior. Our approach selects only non-redundant tests from the automatically generated test suites, thus allowing the developer to spend less time in inspecting this reduced set of tests. We have implemented Raspect and applied it on 12 subjects taken from a variety of sources; our experience shows that Raspect can effectively reduce the size of generated test suites for inspecting AspectJ programs. 1

Aspect-oriented software presents new challenges for the designers of static analyses. Our work aims to establish systematic foundations for dataflow analysis of AspectJ software. We propose a control- and data-flow program representation for AspectJ programs, as basis for subsequent interprocedural dataflow analyses. The representation is built at the source code level and captures the semantic intricacies of various pointcut designators, multiple applicable advices per joint point, dynamic advices, and general flow of data to, from, and between advices. We also propose two dataflow analyses for AspectJ software: (1) a novel object effect analysis based on a flow- and context-sensitive must-alias analysis, and (2) a dependence analysis used for constructing the system dependence graph for slicing, refactoring, change impact analysis, etc. Both analyses are representative of a general category of dataflow analyses referred to as interprocedural distributed environment (IDE) problems. The two analyses are built on top of the proposed representation, and take into account the complex flow of control and data due to aspect-oriented features. We present a study of the proposed techniques on 37 program versions, using our AJANA analysis framework which is based on theabc AspectJ compiler. The results show that the representation can be built efficiently, that it is superior to an approach based on the woven bytecode, and that it enables analyses that are both faster and more precise. These findings strongly indicate that the proposed approach is a promising candidate for a foundation upon which various interprocedural analyses for AspectJ can be designed and built.

Abstract. Software development in the domain of embedded and deeply embedded systems is dominated by cost pressure and extremely limited hardware resources. As a result, modern concepts for separation of concerns and software reuse are widely ignored, as developers worry about the thereby induced memory and performance overhead. Especially object-oriented programming (OOP) is still little in demand. For the development of highly configurable fine-grained system software product lines, however, separation of concerns (SoC) is a crucial property. As the overhead of object-orientation is not acceptable in this domain, we propose aspect-oriented programming (AOP) as an alternative. Compared to OOP, AOP makes it possible to reach similar or even better separation of concerns with significantly smaller memory footprints. In a case study for an embedded system product line the memory costs for SoC could be reduced from 148–236% to 2 – 10 % by using AOP instead of OOP. 1

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. In this paper, we present an automated approach which limits fragility problems by providing mechanical assistance in pointcut maintenance. The approach is based on harnessing arbitrarily deep structural commonalities between program elements corresponding to join points selected by a pointcut. The extracted patterns are then applied to later versions to offer suggestions of new join points that may require inclusion. To illustrate that the motivation behind our proposal is well-founded, we first empirically establish that join points captured by a single pointcut typically portray a significant amount of unique structural commonality by analyzing patterns extracted from 23 AspectJ programs. Then, we demonstrate the usefulness of our technique by rejuvenating pointcuts in multiple versions of 3 of these programs. The results show that our parameterized heuristic algorithm was able to automatically infer new join points in subsequent versions with an average recall of 0.93. Moreover, these join points appeared, on average, in the top 4 th percentile of the suggestions, indicating that the results were precise.