Categories of Aspects

1. Categories of Aspects Shmuel Katz Computer Science Department The Technion Haifa, Israel

2. Aspects (and esp. AspectJ) • Aspects: modular units that crosscut classes • Aspects are defined by aspect declarations and may include • pointcut declarations: where to add/replace • advice declarations: what to add or do instead • Can introduce new methods, variables, code… • Weave (=bind) aspect to different systems (but not entirely separated yet…)

3. Categories of Aspects: the idea • Identify standard types of aspects using dataflow, type checking, or other code analysis • Each type should either automatically maintain classes of properties of the underlying system, or be easier to analyze for new properties. • Most other work so far: what are the types of classes and how to identify them • Here: Effect on temporal logic properties

4. Outline • Identify categories of aspects, semantically • Identify types of properties and how to describe them in temporal logic • Show how to check for category of aspect by syntactic analysis (data-flow) • Prove that for aspects of category A, properties of type B • Are automatically preserved if originally true • Can be established by only considering the aspect code • Can be checked separately for the original and the aspect

5. Spectative aspects • Only gather information about original system, in variables local to the aspect • Logging, performance evaluation, debugging • Can be checked on the code level of the advice: all assignments are to local variables (also parameters given values)

6. Regulative aspects • Either like spectative, or only affect control of basic, by shutting possibilities • Can restrict the conditions for activating a method call of the original system • Adding password authorization, restricting choices to ensure fairness, aborting • Prune edges from the stategraph of the original system, plus add spectative parts

7. Invasive aspects • Allow changing variables/state of the original system • Treating discount policy, overflow, security with encode/decode • Can have restricted versions, e.g., to treat invariant extension

8. More categories • Observer (Clifton-Leavens): methodology for development, points out problems of aliasing in effective identification • Classification (Rinard-Salcianu-Bugrara): implemented tool for AspectJ, using compilation techniques…finer distinctions, but proof implications are not clear.

9. Temporal Logic Lite • A logic over sequences of states (in a tree?) • Gp: for every state later in the sequence, p • Fp: there is a later state with p • Xp: in the next state, p • A(Gp): For every possible sequence, Gp • E(Gp): There is a sequence with Gp • Sequence= a possible execution of the system

10. Types of Properties • Safety: hold in every state, may relate to the history leading to the state • Invariant: relates to each state (no history) • Class invariant: true before and after every method call of a class (and initially) • Temporal logic: AGp, (p has no future modalities) • Liveness: hold eventually for every execution • Termination, eventual response to a request • In temporal logic: AFp, or complex combinations

11. Types of Properties (cont.) • Next-state properties: Connect a state and the immediately following (or previous) one • Written as Xp (usually q => Xp) • Existence properties: There is a possible computation of the system • Written as EP (where P contains other temporal assertions, e.g., EGFp) • From each location, there is a path that reaches an interrupt state • Visibility properties: what is known outside the module under consideration • Special kind of safety properties, relates to all methods, fields (including new ones from the aspect)

12. Terminology • Underlying (system): the system before an aspect has been woven (also Original or Basic) • Aspect: pointcut plus advice • Augmented (system): the result after weaving in an aspect

13. The Semantics of a system • A state graph • expands as new objects are added • Contracts as objects are removed • Temporal assertions are for all paths through each graph during execution • Consider the changes from Original to Augmented graphs—to justify claims

14. Statemachine of Aspect System source call(f) Φ = AG(A[aUb]) a a call(g) a a Before1 Before2 • P: call(g);true* ret(g) b b After1 After2 Advice A: propositions ret(f) in b b b call(h) a b call(h) b b Propositions sub-formulas ret(h) a b ret(h) out b b b A[aUb], AG(A[aUb]) sink b

15. Spectative aspects--identification • C = set of variables/parameters of aspect code bound to those in underlying • No variable of C is assigned a value by the aspect code • Each advice is straightline code (or is guaranteed to terminate) • underlying resumes where interrupted (before/after, no exceptions thrown, or around with proceed)

16. Other analysis • Originally for optimization, now also for identifying categories in simplified AspectJ : (Sereni - de Moor) • Interference analysis, emphasizing the implications of inheritance and multiple instances (Storzer and Krinke) • Program slicing adapted to aspect languages

17. Spectative aspects--properties • All safety and liveness that are not next-state, and only involve underlying variables / methods—are maintained in augmented • No new properties of only underlying are added • For new properties, separate concerns: can check aspect variables in aspect, underlying variables in underlying • Note: visibility can be violated, due to new methods or variables of the aspect

18. Regulative aspects--identification • C, as before (all variables in aspect bound to variables of underlying) • Variables of C are not assigned (but…) • Advice can throw exceptions that terminate execution, or prevent external calls to methods of underlying (or, as before) • Strengthens conditions checked, so restricts possible transitions (erase edges in transition graph), but not skipping (which would add an edge)

19. Regulative-- properties • Safety properties not next-state, involving only variables/methods of underlying are maintained in augmented • Above is justified by considering the regulative augmented as a pruned graph of the underlying • Liveness properties may not be maintained • May have new safety properties, even of just the underlying variables • If only external calls are restricted, existential may be violated in augmented, but otherwise maintains safety and liveness like spectative

20. Invasive: how bad is it? • Reconnection problem: changes can create states not in the original, and continuing the underlying code can create entire new subgraphs… • Weak invasive: always reconnects to a state that existed in the original—so continuations are as before (Informally: fixes problems that might not arise)

21. Invariants for weak invasive • If the aspect is weak invasive, invariant of original can be extended to augmented by only checking the aspect statemachine • Example: an aspect that `resets’ the state to a fixed system state (in the original) under certain conditions • Allows model checking only the aspect, assuming the invariant both before and after

22. Strongly Invasive: extending invariants • For invariants of the underlying, that we want to also hold for augmented • Can we just check the advice? • Yes, when the invariant is inductive: just itself is needed to justify each step • {I} s {I} has been shown for each step s of the underlying—no matter what the state • Then just show {I} t {I} for each step t of the advice—without reproving for the underlying • Otherwise, may have to recheck underlying too

23. Extending inductive invariants: an example • x > y > 0 is an inductive invariant of an underlying system • Add an aspect with changes like: <complex-pointcut>  double(x,y) • Check {x>y>0} double(x,y) {x>y>0} • The invariant will hold for the augmented system, with no further checks and without analyzing <complex-pointcut> • Can be further refined….

24. Additional questions • Interactions among types of aspects • Finer distinctions among Invasive • Additional classes of properties • Model checking for aspects • Tools to be developed as part of a Common Aspect Proof Environment (CAPE) within AOSD-Europe

25. Summary • Identifying categories of aspects can often be done by static code analysis • Theorems on types of properties preserved, or new ones established are done only once • Provide theoretical basis for static analysis • Can save complex proof techniques, not yet developed for aspects • Will sometimes still need regular proofs