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

2. Challenges What is an aspect supposed to do? How do we know the aspect itself is correct? When is it applicable? What new properties does it add? What does it maintain from the old system? Can multiple aspects interfere with each other?

3. Aspects as Subjects of Investigation Syntax and semantics: how to express them? Classification: What types are there? Spectative: only observes/records Regulative: affects control/ termination Invasive: changes values of existing fields Specification: what do they add, to what? Correctness/validation: how do we know they do what is intended?

4. 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

5. 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

6. 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)

7. 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

8. 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

9. 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.

10. 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

11. Properties in temporal logic mutual exclusion: always  ( cs 1  cs 2 ) non starvation: always (request  eventually grant) communication protocols: (  get-message) until send-message

12. Propositional temporal logic AP – a set of atomic propositions Temporal operators: Gp Fp Xp pUq Path quantifiers: A for all path E there exists a path

13. 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

14. 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)

15. 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

16. Semantics of an aspect system A state machine graph—that can evolve! expands as new objects are added Contracts as objects are removed Temporal assertions are for all paths through each graph during execution An aspect is a graph transformer Consider the changes from Original to Augmented graphs—to justify claims

17. Aspects Program modules designed to capture crosscutting concerns Advice: code…but here state machine fragments Pointcut Description of when to run the advice

18. 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 Before1 Befor e 2 After2 After1 propositions Propositions sub-formulas b b in out

19. Weaving an Aspect to Yield an Augmented System Rule: add all edges ‘pointcut’ → aspect initial aspect return → base Where the labels exactly match Remove other edges from pointcut states

20. An aspect that adds computations of w x= 0 x= 7 x= 2 x=0 w= ? x=7 w= ? x=2 w= 9 x=7 w= 9 x=7 w= 7 x=7 w= 0 join (a) original state graph (b) augmented state graph PP

21. Spectative aspects: The semantic definition Consider the projection of the augmented state graph onto the state variables of the base system Definition: The projection of the augmented state graph is identical to the state graph of the basic system, except that the projection contains repetitions of states connected by edges that correspond to aspect (advice) operations.

22. 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)

23. 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

24. 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

25. 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

26. X=1 Y=0 S=? X=1 Y=0 S=‘a’ X=2 Y=0 S=‘b’ X=2 Y=1 S=? join a b X=1 Y=0 X=2 Y=0 X=1 Y=1 X=2 Y=1 a a b b (a) Original fragment (b) After restrictive aspect

27. 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)

28. 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

29. 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… Weakly invasive: always reconnects to a state that existed in the original—so continuations are as before (Informally: fixes problems that might not arise)

30. Invariants for weakly invasive If the aspect is weakly 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

31. 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

32. 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….

33. 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

34. Additional questions Finer distinctions among Invasive Additional classes of properties Model checking for aspects Interactions among types of aspects