Reusing aspects in different applications is currently a topic of intensive discussion in the research community. A number of contributions have been made showing how reusable aspects can be produced for specific purposes, but a generic solution supporting developers in building reusable aspects has not been achieved yet. As part of my RIVAR fellowship, I am interested in making aspects more reusable. Here, I collect related work, both concerning the challenges of aspect reuse and first solutions addressing these challenges. This bibliography is by no means complete. Any hints or suggestions are more than welcome.

To enable developers to confidently reuse aspects, they need some sort of reassurance that the aspects will behave as expected in the new reuse environment. Ideally, it should be able to provide a proof that this is the case. A number of aspect properties cause particular challenges to the reuse of aspects in different contexts; or sometimes even with a modified (evolved) base. Most importantly, these are:

• Reliance on syntactic pointcuts leading to the so-called fragile-pointcut problem;
• Lack of explicit interfaces making modular reasoning more complicated; and
• Obliviousness, making it more difficult to decide which aspects need to be considered in a particular reasoning scenario.

Many aspect-oriented systems (most notably AspectJ) use syntactic patterns over names of elements of the base code to define where aspects should be woven into the base. As a consequence, there is a gap between a developer’s intention about the relation between aspect and base and the specification of this relation. Thus, when base code is changed or when the aspect is reused in a different context, the specification may no longer correctly represent the developer’s intention. This is often referred to as the fragile-pointcut problem.

One way of addressing the fragile-pointcut problem is to introduce more semantic pointcut specification languages that rely less on syntactic features and, thus, can narrow the gap between a developer’s intention and the pointcut specification. Ostermann et al. present one such approach using a flexible pointcut language inspired by Prolog. Chitchyan et al. discuss another approach, specifically geared at aspect-oriented requirements engineering.

As an alternative, Khatchadourian et al. aim to reverse-engineer the intention behind a syntactic pointcut specification and use this to guide developers in software maintenance and evolution.

Another approach to addressing pointcut fragility is to introduce explicit interfaces for aspects. Approaches such as Object Teams, Explicit Pointcut Interfaces (XPIs), and Open Modules aim to decouple the pointcut specifications used in an aspect from the actual names used within a core application. This is also true for Invasive Software Composition as realised in the Reuseware tool. Typically, these approaches introduce intermediary names that form an explicit interface between core modules and aspects. The interface definition is still completely based upon syntactic information only; semantic assumptions of aspect designers cannot be expressed in this form. Mapping between names used in the pointcut definition and names in the core module is still a manual and error-prone task. Because no semantic information is available, the correctness of these mappings cannot be verified or tested.

In the area of aspect-oriented modelling, contracts and interfaces for aspect or base models have been proposed, for example, by Oldevik et al and by Klein and Kienzle.

An important discussion in the AO community is whether core modules should be oblivious of aspects woven into them. This is also relevant for aspect reuse, because oblivious aspects may be manipulated by other aspects at any time, making verification harder.

An important requirement for aspect reuse is being able to verify aspect behaviour independently.

---

A number of papers aim to classify aspects into categories, so that all aspects in a category share the same constraints regarding how they can at most influence properties of the base code.

Goldman and Katz present work that allows to prove that an aspect guarantees certain LTL properties for any application that it is woven with, as long as this application fulfils certain assumptions, also expressed as an LTL formula.

A number of papers focus on showing that properties of a core module are maintained even if an aspect is woven.

All of these approaches rely on the correct formal representation of aspect assumptions and guarantees. There is some work that aims to address this challenge: Oliviera et al. provide a Haskell-based representation of assumptions and guarantees. Katz and Katz allow formal specifications for complicated cases to be constructed interactively. Zschaler presents a retrospective study of what assumptions aspect developers make.