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 aa aa bb bb bb bb b ret(f) call(h) ret(h) ret(g) ab ab call(f) call(g) Advice A: call(h) ret(h) source sink Φ = AG(A[aUb]) P: call(g);true* Before1 Befor e 2 After2 After1 propositions Propositions sub-formulas b b A[aUb], AG(A[aUb]) in out

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:  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 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