Advice is a mechanism used by advanced object-oriented and aspect-oriented programming languages to augment the behavior of methods in a program. Advice can help to make programs more modular by separating crosscutting concerns more e#ectively, but it also challenges existing ideas about modularity and separate development.

This paper reports our experience using AspectJ, a general purpose aspect-oriented extension to Java, to implement distribution and persistence aspects in a web-based information system. This system was originally implemented in Java and restructured with AspectJ. Our main contribution is to show that AspectJ is useful for implementing several persistence and distribution concerns in the application considered, and other similar applications. We have also identified a few drawbacks in the language and suggest some minor modifications that could significantly improve similar implementations. Despite the drawbacks, we argue that the AspectJ implementation is superior to the pure Java implementation. Some of the aspects implemented in our experiment are abstract and constitute a simple aspect framework. The other aspects are application specific but we suggest that different implementations might follow the same aspect pattern. The framework and the pattern allow us to propose architecture-specific guidelines that provide practical advice for both restructuring and implementing certain kinds of persistent and distributed applications with AspectJ.

Abstract. Modeling four aspect-oriented programming mechanisms shows the way in which each supports modular crosscutting. Comparing the models produces a clear three part characterization of what is required to support crosscutting structure: a common frame of reference that two (or more) programs can use to connect with each other and each provide their semantic contribution. 1

This paper develops a simple object calculus with harmless aspect-oriented advice. A piece of harmless advice is a computation that, like ordinary aspect-oriented advice, executes when control reaches a designated control-flow point. However, unlike ordinary advice, harmless advice is designed to obey a weak non-interference property. Harmless advice may change the termination behavior of computations and use I/O, but it does not otherwise influence the final result of computations that trigger it. A simple type and effect system related to information-flow type systems helps enforce harmlessness. We have proven that harmless advice does not interfere with the mainline computation.

Persistence - the storage and retrieval of application data from secondary storage media - is often used as a classical example of a crosscutting concern. It is widely assumed that an application can be developed without taking persistence requirements into consideration and a persistence aspect plugged in at a later stage. However, there are no real world examples showing whether persistence can in fact be aspectised and, if so, can this be done in a manner that promotes reuse and is oblivious to the application. In this paper, we provide an insight into these issues drawing upon our experience with a classical database application: a bibliography system. We argue that it is possible to aspectise persistence in a highly reusable fashion, which can be developed into a general aspect-based persistence framework. Nevertheless, application developers can only be partially oblivious to the persistent nature of the data. This is because persistence has to be accounted for as an architectural decision during the design of data-consumer components. Furthermore, designers of such components also need to consider the declarative nature of retrieval mechanisms supported by most database systems. Similarly, deletion requires explicit attention during application design as mostly applications trigger such an operation.

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.

Aspect-oriented software design will need to support languages with first-class and higher-order procedures, such as Python, Perl, ML and Scheme. These language features present both challenges and benefits for aspects. On the one hand, they force the designer to carefully address issues of scope that do not arise in first-order languages. On the other hand, these distinctions of scope make it possible to define a much richer variety of policies than first-order aspect languages permit.

Aspect-orientation can help to separate concerns in software. One of the goals of this separation is to promote flexibility and configurability; this is especially true when constructing program families (and product-lines). This paper introduces a set of principles that instruct in the creation of flexible, configurable, aspect-oriented systems. We illustrate the principles through their application to a software product-line. The principle of dependency alignment serves as a guideline for structuring concern implementation in modules, eliminating unwarranted dependencies between concerns. The principles of orthogonal and weakly orthogonal aspects instruct in the design of aspects that are included in some system configurations, but not in others. We show how these principles scale to larger systems and larger concern implementations.

It is a well-known fact that evolving a software application accounts for the largest part of the software development process, and is currently the most problematic phase. Aspect-oriented software development is often touted as a means to ameliorate this situation: by providing new modularization mechanisms, it enables cleaner separation of concerns and reduced code tangling, and consequently makes evolving the application easier. Unfortunately, current research results only indicate that AOSD leads to applications that are better modularized, but fail to show that this improves their evolvability. Paradoxically, we have found indications of the contrary: current AOSD technologies deliver applications that are as hard, or perhaps even harder, to evolve than was the case before. We will show in this paper that the particular cause of this problem is that aspect programmers are forced to write aspects that only work for one specific version of an application.

Aspect-oriented programming (AOP) is a new programming paradigm whose goal is to more cleanly modularize crosscutting concerns such as logging, synchronization, and event notification which would otherwise be scattered throughout the system and tangled with functional code. However, while AOP languages provide promising ways to separate crosscutting concerns, they can also break conventional encapsulation mechanisms, making it di#cult to reason about code without the aid of external tools.