Rich Interfaces for Verifiable Aspect Reuse (RIVAR)
RIVAR aims to define novel language constructs for aspect-oriented programming (in particular in AspectJ) that allow making explicit assumptions made by aspect developers about the context in which their aspects are woven. Making assumptions explicit like this, allows them to be verified when aspects are reused in new contexts or when the base evolves.
As a first step, we have performed a manual analysis of AspectJ projects to identify types of assumptions actually made by AspectJ developers. A catalogue of such assumption types can be useful in a range of situations:
- Code improvement. Some assumptions really indicate bugs or coding mistakes. Such assumptions can form the basis for extracting aspect-oriented anti-patterns, which could be used in tooling to provide improvement hints to developers.
- Assumption elicitation. Some assumptions in aspect-oriented code may be implicit; that is, developers may not
have been aware they were making these assumptions. A catalogue of typical aspect assumptions can help elicit such
assumptions in two ways:
- It can be used in code inspections. Developers can ask for each category and aspect: "Am I making an assumption similar to this in my own code here?"
- We can attempt to extract patterns from the examples of aspect assumptions we have already identified. These patterns can then be used to semi-automatically identify assumptions in other aspect code.
- Assumption verification. Finally, where assumptions are made (whether implicitly or explicitly) it would be
useful to enable developers to make them explicit in their code in a formalised manner. This enables (semi-)automatic
verification of these assumptions as aspects are reused in new contexts or as the base evolves. A catalogue of aspect
assumptions should enable us to provide more dedicated notation and verification strategies, thereby making fully automatic
verification a feasible goal for at least some of the assumption categories without requiring developers to be fluent in
formal specification techniques. This can be useful in a number of situations:
- Evolution of base system. Current syntactical pointcut expressions break easily when the base system evolves. If explicit aspect assumptions were available, they could be checked for an evolved base to establish which pointcuts have been broken and may need inspection and updating by the aspect developer. If assumptions are expressed in a formal manner, such checks can be performed automatically, enabling direct feedback to developers as part of the compilation and weaving process.
- Aspect reuse. When aspects are reused in a new context, their pointcuts may need to be adjusted. Without explicitly expressed assumptions, it is almost impossible to do this safely. When assumptions have been made explicit, they could be checked in the new usage context. Given the updated pointcut expressions, explicit assumptions could be used to verify that the aspect has been reused correctly.
- Library aspects. Library aspects are designed to be reusable. When using AspectJ to develop library aspects, a typical pattern is to use abstract aspects with abstract or empty pointcuts to be refined by sub-aspects for particular reuse contexts. However, as the abstract aspect cannot explicitly express the assumptions it makes about how a pointcut can be refined, sub-aspects can easily break the library aspect's contract.
RIVAR is supported by the European Union under FP7 Marie-Curie Intra-European Fellowship Contract No. 236381.
Here you can find materials that represent results from this project. These may include data collected, tools developed, etc. Publications resulting from this project will be listed separately below.
A bibliography of related literature.
This page collects the results from our initial retrospective study analysing three medium-size open-source AspectJ projects for the assumptions made by aspect developers. This study has been reported on in a paper currently submitted for review to AOSD 2011.
Sources for some initial abc extensions to support inclusion and mutual exclusion between aspects as well as checking for unused, mandatory ITDs. Notice, that this is very preliminary work, and I do not give any guarantees as to error-freenes or fitness for purpose. I make these available as I currently lack the time to continue working on them, and in the hope that someone might be able to continue on this basis.
Acceptance rate: 24%
[pdf] [slides] [http] [bibtex] [additional material] Refereed Conference Paper, research areas: Modularity, Empirical Software Engineering
Research contribution: Writing contribution: