The growing popularity of aspect-oriented languages, such as AspectJ, and of corresponding design approaches, makes it important to learn how best to modularize programs in which aspect-oriented composition mechanisms are used. We contribute an approach to information hiding modularity in programs that use quantified advising as a module composition mechanism. Our approach rests on a new kind of interface: one that abstracts a crosscutting behavior, decouples the design of code that advises such a behavior from the design of the code to be advised, and that can stipulate behavioral contracts. Our interfaces establish design rules that govern how specific points in program execution are exposed through a given join point model and how conforming code on either side should behave. In a case study of the HyperCast overlay network middleware system, including a real options analysis, we compare the widely cited oblivious design approach with our own, showing significant weaknesses in the former and benefits in the latter.

The current AspectJ join points represent locations in the code that are at the interface of the Java objects. However, not all the "things that happen" happen at the interfaces. In particular, loops are a key place that could be advised for parallelisation. Although parallelisation via aspects can be performed in certain cases by refactoring the Java code, it is not always possible or desirable. This article presents a model of loop join point, which allows AspectJ to intervene directly in loops.

Abstract not found

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.

Abstract. This paper presents work in progress on the C4 toolkit, which is designed to bring AOSD techniques to system software written in C and which we have used for introducing aspects into the Linux 2.6 kernel. The design of our toolkit focuses on addressing key concerns raised by system software developers when handed a new programming paradigm: readability, compatibility, performance, and the preservation of existing development workflows. By addressing these concerns, we believe our toolkit can bring the benefits of AOSD techniques to any large and complex program written in C. 1

Abstract. We propose a new join point model for aspect-oriented programming (AOP) languages. In most AOP languages including AspectJ, a join point is a time interval of an action in execution. While those languages are widely accepted, they have problems in aspects reusability, and awkwardness when designing advanced features such as tracematches. Our proposed join point model, namely the point-in-time join point model redefines join points as the moments both at the beginning and end of actions. Those finer-grained join points enable us to design AOP languages with better reusability and flexibility of aspects. In this paper, we designed an AspectJ-like language based on the point-in-time model. We also give a denotational semantics of a simplified language in a continuation passing style, and demonstrate that we can straightforwardly model advanced language features such as exception handling and cflow pointcuts. 1

Performance evaluation of embedded software is essential in an early development phase so as to ensure that the software will run on the embedded device’s limited computing resources. Prevailing approaches either require the deployment of the software on the embedded target, which can be tedious and may be impossible in an early development phase, or rely on simulation, which can be very slow. In this paper, we introduce a customizable cross-profiling framework for embedded Java processors, including processors featuring a method cache. The developer profiles the embedded software in the host environment, completely decoupled from the target system, on any standard Java Virtual Machine, but the generated profiles represent the execution time metric of the target system. Our cross-profiling framework is based on bytecode instrumentation. We identify several pointcuts in the execution of bytecode that need to be instrumented in order to estimate the CPU cycle consumption on the target system. An evaluation using the JOP embedded Java processor as target confirms that our approach reconciles high profile accuracy with moderate overhead. Our cross-profiling framework also enables the rapid evaluation of the performance impact of possible optimizations, such as different caching strategies.

In AspectJ-like languages, there are several different kinds of advice declarations, which are specified by using advice modifiers such as before and after returning. This makes semantics of advice complicated and also makes advice declarations less reusable since advice modifiers are not parameterized unlike pointcuts. We propose a simpler join point model and an experimental AOP language called PitJ. The proposed join point model has only one kind of advice, but has finer grained join points. Even though we unified different kinds of advice into one, the resulted language is sufficiently expressive to cover typical advice usages in AspectJ, and has improved advice reusability by allowing pointcuts, rather than advice modifiers, to specify when advice body runs. Along with the language design, this paper gives a formalization of the join point model in a continuation-passing style (CPS).

We propose test-based pointcuts, a novel pointcut mechanism for AspectJ-like aspect-oriented programming languages. The idea behind the test-based pointcuts is to specify join points through unit test cases associated with the target program. The test-based pointcuts improve robustness and precision of pointcut languages. The test-based pointcuts are more robust against software evolution because they do not directly rely on identifier names in a target program. The test-based pointcuts are more precise because they can distinguish fine grained execution histories including conditional branches by comparing the runtime execution histories with recorded for ones of the unit test cases. This paper presents design and implementation of the test-based pointcuts as an extension of an AspectJ compiler. We evaluated robustness and runtime efficiency of test-based pointcuts through case studies that applied test-based pointcuts to several versions of practical application programs.

The most successful model of aspect-oriented modularity to date is that embodied in the AspectJ language. We have shown that the AspectJ notions of aspect and class can be unified in a new module construct that we called the classpect, and that this new model is significantly simpler and able to accommodate a broader set of requirements for modular solutions to complex integration problems. We embodied our unified model in the Eos language design, in which the basic unit of modularity is a classpect; and we realized the model in a concrete and usable form in the Eos compiler. The main contribution of this paper is a fairly demanding experimental evaluation of the Eos component model, language, and compiler in terms of their application to two significant systems: ConcernCov, a tool for concernbased code coverage analysis of test suites (20K LOC), and the Eos compiler, a near-industrial strength classpectoriented extension to the C # language (50K LOC). Our assessments of the resulting designs provides evidence for the potential design structuring benefits of the Eos model, the usability of the Eos language, and the practical utility of our language implementation in the Eos compiler. In a nutshell, we contribute a demonstration of the immediate practical value of our conceptual work.