Semantic Aspect Interactions and Possibly Shared Join Points

1. Semantic Aspect Interactions and Possibly Shared Join Points Authors:Emilia Katz, Shmuel Katz {emika,katz}@cs.technion.ac.il The Technion E. Katz, S. Katz FOAL'10

2. Aspects at a Shared Join Point Aspect B Aspect A Aspect C … … shadow join point • Which aspects will be applied? • In what order? AspectJ operational semantics… E. Katz, S. Katz FOAL'10

3. “Zoom in”: Pointcut Occurrence A B C shadow j.p. is reached last state of shadow j.p. … … arrival + actual join-point of A pointcut occurrence of C actual join-point of B arrival join-point of B pointcut occurrence of A pointcut occurrence of B arrival + actual join-point of C E. Katz, S. Katz FOAL'10

4. Motivating Example Aspects for systems with message sending (part of communication aspects library): • Logging (4 variants) • Log messages before sending • Encryption • Encrypt messages before sending • Authorization • Is the user allowed to send this message to this server? Shared join-point: the moment when a message is about to be sent E. Katz, S. Katz FOAL'10

5. Logging Aspect Variants • L1: log sent messages as they were originally attempted to be sent • L2: log messages as they were actually sent to the server • L3: log messages, but ignore content • L4: log all the attempts to send a message, even the aborted ones E. Katz, S. Katz FOAL'10

6. Aspect Application Order • Question: When does the order of aspect application matter? • “Matter” = lead to aspect interference • One approach: different resulting states for different application orders • Our claim: Not necessarily so! • Two different cases: E. Katz, S. Katz FOAL'10

7. Logging vs. Encryption (1) last state of shadow j.p. shadow j.p. is reached Reminder: L2 logs messages as they were actually sent to the server L2 Enc. … … … msg_to_send becomes false; msg_send becomes true msg_to_send becomes true msg = <enc(c), t> msg = <c, t> Added to log: <c, t> msg = <enc(c), t> ==> Goal of L2 is not reached: message logged  message sent E. Katz, S. Katz FOAL'10

8. Logging vs. Encryption (2) Reminder: L3 logs messages to measure network activity only L3 Enc. Added to log: <c, t> msg = <enc(c), t> … … … msg = <enc(c), t> msg = <enc(c), t> Different states? – Yes! Goal of L3 violated? – No! Goal of Enc violated? – No! msg = <c, t> msg = <c, t> Enc. L3 … … … msg = <enc(c), t> Added to log: <enc(c), t> E. Katz, S. Katz FOAL'10

9. Aspect Influence Cases New problems of shared join-points: • Input variables changed before aspect execution (between arrival and actual join-point) • Variables changed after aspect execution before they are used in the computation • Pointcut invalidation before/after advice execution E. Katz, S. Katz FOAL'10

10. The Setting: System Representation • Advice, base system = state machine • Abstract representation as state-transition system of all possible states • Obtained during the modeling stage, or built from code (e.g., by tools like Bandera) • Pointcut = state predicate about the base system • Weaving (abstract version): • Every join-point in the base is connected to the corresponding initial states of the advice (instead of its former next states) • Every last state of the advice is connected to all the corresponding states in the base system model E. Katz, S. Katz FOAL'10

11. The Setting: Aspect Specification What is a “correct” aspect? … since model-checking is used in proof method automatization … LTL formulas Specification of an aspect A is (PA, RA) A assumes: PA holds in the base system: • what’s true at joinpoints • global properties of base system • properties of aspect parameters • what’s true for computations starting from all A’s resumption states that were unreachable in the base system A guarantees:RA is true in the woven system • new properties added by A • properties of base system maintained in woven system in anyreasonable base system for A in any woven system with A possibly global! E. Katz, S. Katz FOAL'10

12. Temporal Logic Specifications … Gφ φ φ φ φ φ … Fφ φ … … φ ψ φ φUψ … … φ ψ φ OR φWψ … φ φ φ φ φ E. Katz, S. Katz FOAL'10

13. Specification Refinement Goals • For each aspect, which cases of influence are harmful? • What assumption would ensure that no harmful influence of other aspects at a shared join-point is possible? E. Katz, S. Katz FOAL'10

14. Case 1: “Change Before” <c, t> <enc(c), t> Enc. L1 Influence type: input variables changed before aspect execution … … … arrival + actual join-point of E. Added to log: <enc(c), t> actual join-point of L1 <enc(c), t> arrival join-point of L1 Reminder: L1 logs messages as originally attempted to be sent ==> Goal of L1 is not reached: message logged  original message E. Katz, S. Katz FOAL'10

15. Question 1 • Are there any input variables of A for which the advice of A depends on their value at the arrival join-point? • Yes => list these variables • For each v in the list, add an assumption: CB(v) = G[(at(ptc)∧ v=V) →(v=VW(after_prev_asp(A)∧ v=V))] • In our example: • L1: Assumptions added: CB(c), CB(t) • L2: No • L3: No • L4: Assumptions added: CB(c), CB(t) arrival join-point of A the only candidate for actual join-point of A E. Katz, S. Katz FOAL'10

16. Case 2: “Change After” L2 Enc. <enc(c), t> <c, t> Influence type: variables changed before intended use … … … arrival + actual join-point of L2 actual join-point of E <enc(c), t> arrival join-point of E. Added to log: < c, t> Reminder: L2 logs messages as they were actually sent ==> Goal of L2 is not reached: message logged  message sent E. Katz, S. Katz FOAL'10

17. Question 2 • Are there any state variables of the system, the value of which should be preserved after A’s execution is finished? • Yes => list of “<variable, state of use>” • For each <v,use_v> in the list, add an assumption: CA(v)= G[(asp_ret(A)∧ v=V) →(v=VW(use_v∧ v=V))] • In our example: • For L1, L2, L3 use_v = msg_send • L1: Assumptions added: CA(msg_t ) • L2: Assumptions added: CA(msg_c ) , CA(msg_t ) • L3: Assumptions added: CA(msg_t ) • L4: No return states of A E. Katz, S. Katz FOAL'10

18. Case 3: “Invalidation Before” … Aut. L4 <c, t> Influence type: aspect is not executed at all in its pointcut occurrence message is not sent … … … arrival + actual join-point of A. should’ve been actual join-point of L4 L4 is never executed in this pointcut occurrence arrival join-point of L1 Reminder: L4 logs all the attempts to send a message ==> Goal of L4 is not reached: message is attempted to be sent, but is not logged E. Katz, S. Katz FOAL'10

19. Question 3 • Is it an error if the condition for A’s application is invalidated by previously executed aspects? • Yes => add an assumption: IB = G[at(ptc)→(ptcW(after_prev_asp(A)∧ ptc))] • In our example: • L1: No • L2: No • L3: No • L4: Assumption IB is added arrival join-point of A actual join-point of A E. Katz, S. Katz FOAL'10

20. Case 4: “Invalidation After” Influence type: aspect is executed in its pointcut occurrence, though its pointcut is invalidated by aspects applied after it … L2 Aut. <c, t> message is not sent … … … arrival + actual join-point of L2 actual join-point of A. arrival join-point of A. Added to log: < c, t> ==> Goal of L2 is not reached: message is logged, but is not actually sent Reminder: L2 logs messages as they were actually sent E. Katz, S. Katz FOAL'10

21. Question 4 • Q.4.1. Does the reason for a state to be A’s join-point lie in the future of the computation? • Yes => Q.4.2. Is it an error if A’s advice is performed, but the presumably-following event does not follow? • Yes => provide predicates: foll_event and (optionally) vals_after_asp and vals_at_foll_event; add an assumption: IA = G[(asp_ret(A) ∧ vals_after_asp)→F(foll_event∧ vals_at_foll_event)] • In our example: • For L1, L2, L3, foll_event = msg_send • L1 and L3: vals_after_asp = vals_at_foll_event = “msg_t = T” • L2: vals_after_asp = vals_at_foll_event = “msg_c = C ∧ msg_t = T” • L4: No presumably-following event return states of A Connection between the state after A’s execution and at the “following event” Connection between the state after A’s execution and at the “following event” E. Katz, S. Katz FOAL'10

22. Full Verification Process • Verification goal: given a library of aspects • Correctness check of each aspect individually • Interference freedom check of the library • Modular verification (independent of any concrete base system; enables offline checks and reuse without proof) • In presence of possibly shared join-points: • Perform user-guided specification refinement and extend model before running existing verification tools • Verification tools used: • MAVEN: modular aspect verification (GK’07, KK’09) • InterFree: interference detection (KK’08) E. Katz, S. Katz FOAL'10

23. Interference summary for our example CB = Change Before CA = Change After IB = Invalidation Before IA = Invalidation After E. Katz, S. Katz FOAL'10

24. Summary Our contributions: • In-depth analysis of aspect semantics and mutual influence at shared join-points • Helps to distinguish between potential and actual interference at shared join-points • Interactive semi-automatic procedure for specification refinement • Helps to define the desired aspect behavior more precisely • Enables modular verification and interference detection among aspects Future work: • Implementation of the specification-refinement procedure • Implementation of aspect modeling for aspects with possibly shared join-points, for verification purposes E. Katz, S. Katz FOAL'10

25. Thank you!