RIVAR

RIVAR aimed 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:
  1. 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?”
  2. 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:
  1. 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.
  2. 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.
  3. 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 was supported by the European Union under FP7 Marie-Curie Intra-European Fellowship Contract No. 236381.