Section 9.6. CONCLUSION


9.6. CONCLUSION

In this chapter, we have presented a model (and three instantiations) for AOP based on execution traces. We have focused on the following points:

  • Expressive and stateful aspect definitions

  • A model conceptually based on weaving of executions

  • Reasoning about and analysis of aspect properties, in particular aspect interaction

  • Enforcement of properties by program transformation (i.e., static weaving)

We now briefly consider these contributions in turn and compare our approach with related work.

We have advocated and presented expressive (i.e., stateful) aspect languages. The crosscut language of AspectJ [14] consists mostly of single instruction patterns matching events such as a method calls or field accesses. AspectJ's patterns are very similar to our basic aspects C Our model is conceptually based on a monitor observing execution events and weaving execution traces, similar to the approach proposed by Filman and Havelund [11]. Other techniques can be related to execution monitors. Computational reflection is a general technique used to modify the execution mechanisms of a programming language. Restricted approaches to reflection have been proposed in order to support AOP. For instance, the composition filter model [2] proposes method wrappers in order to filter method calls and returns. De Volder et al. [6] propose a meta-programming framework based on Prolog. Unfortunately, these approaches do not allow stateful aspects.

By appropriate restrictions of the aspect language, we have proposed some solutions to the difficult problem of aspect interactions. Few other program analyses for AO programs have been proposed, most notably by Sereni and de Moor for the optimization of AspectJ's cflow construction [18] and by Shiman and Katz to verify applicability of aspects using model checking techniques [19]. At the tool-level, AspectJ provides limited support for aspect interaction analysis using IDE integration: the base program is annotated with crosscutting aspects. This graphical information can be used to detect conflicting aspects. However, the simple (i.e. stateless) crosscut model of AspectJ would entail an analysis detecting numerous spurious conflicts because the bookkeeping code cannot be taken into account. In case of real conflicts, AspectJ programmers must resolve conflicts by reordering aspects using the keyword dominate. When two aspects are unrelated with respect to the domination or hierarchy relations, the ordering of inserts is undefined.

In order to define static interaction analysis, we had to formally define aspects and weaving (see [7] for a formal treatment of Section 9.4). There are several approaches to the formalization of AOP. Wand et al. [22] propose a denotational semantics for a subset of AspectJ. Lämmel [15] formalizes method call interception with big-step semantics. Andrews' model [1] relies on algebraic processes. He focuses on equivalence of processes and correctness (termination) of the weaving algorithm. Other operational approaches to the formalization of AO systems have been proposed by Walker et al. [21] and Tucker and Krishnamurti [20] using different forms of abstract machines, as well as Jagadeesan et al. [13] based on process calculi.

Finally, we have shown in Section 9.5 that by restricting the insert language, aspects can be seen as formal properties, which can be enforced by program transformation. Dynamic monitors (such as VeriSoft [12] and AMOS [4]) or "security kernels" (such as Schneider's security automata [17]) have been used to enforce security properties. By contrast, our programming language approach permits many optimizations and avoids extending the run-time system or the language semantics.

The different aspect languages presented suggest several extensions. For example, allowing crosscuts of the same aspect to share variables makes the aspect language more expressive (cf. [8]). The possibility of associating an instance of an aspect with a run-time entity (e.g., each instance of a class in a Java program) would facilitate the application of our model to object-oriented languages. It would have been interesting to characterize a larger class of inserts (beyond abort) allowing us to keep the semantic impact of weaving under strict control. More generally, we believe that an important avenue for further AOP research is to provide more safeguards in terms of static analyses and specially tailored aspect languages. In order to make these analyses applicable in the context of large-scale application, their integration with standard model checking techniques [10] seems promising.



Aspect-Oriented Software Development
Aspect-Oriented Software Development with Use Cases
ISBN: 0321268881
EAN: 2147483647
Year: 2003
Pages: 307

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net