Managing Interferences Between Aspects in Code Composition

1. Interferences: aspect-base and between aspects Shmuel Katz, using slides from Lodewijk Bergmans

2. Composition Conflicts(code interference) • Syntactical • e.g. in the case of source code weaving the woven code can no longer compile • Structural • E.g. when introducing an existing method or creating cyclic inheritance • Semantic • Sometimes directly derivable from code • e.g. variable access, calling dependencies • design intentions • "is it a bug, or is it a feature?" • e.g. ordering of actions/events

3. Major Classification • aspect-base composition • aspect-aspect composition • especially at shared join points • (but not exclusively) • Due to weaving process/specification

4. 1. Aspect-base interference • Obliviousness is bliss? • obliviousness ≠ (programmer) ignorance • it is about reducing (cyclic) coupling • hence tool support can make a large practical difference • scalability is an issue, though • Goal: developer responsible for creating a dependency must be accountable for the consequences: so one introducing an aspect should show it does not make new problems (“cause no harm”) • kind of interferences: • behavioral conflicts (changing state or control flow) • through structural changes

5. Design information in pointcuts:treating the fragilepointcut problem • Fragile pointcuts: • susceptible to ‘break when changes are made to the (base) program. e.g. “call(void *.set*(Object))” • Design intentions • or: semantic information (semantic properties) • are implicitly present (encoded, hard-wired) in the sources of the program • Semantic property is an abstract notion; e.g. behavior of a program element, its intended meaning. • We would like to use design intentions as concrete ‘hooks’ to identify join points • hence not rely on the 'accidental' structure and naming conventions of the program

6. 'Semantic Pointcuts'expressing design intentions in pointcuts • Be able to refer to annotations in pointcuts • Reduces the obliviousness: need annotations • Example (in AspectJ 5): • Dedicated Pointcuts pointcut foo(Customer c): target(c) && hasAttribute(c, @PersistentRoot) && … • Extending Type Patterns pointcut updateMethods(): within(@PersistentRoot *) && execution(@Update * *(..));

7. 2. Aspect-Aspect interference • Indirectly through the base program • affecting the base program causes other aspects to break • because their assumptions are violated • can be due to: • state change • control flow changes • structural changes

8. Aspect-Aspect interference Cont'd • Interference at shared join points • depending on the correct composition operators • Can have one affect the other, or both relate only to base • dependencies among aspects • e.g. conditional execution • semantic incompatibility • among aspects/advices—in every composition • only in specific base context • i.e.aspect1/aspect2/baseX conflict • affected by different orderings

9. Aspect Interference • How can this happen? • Separation of concerns: • Pointcuts are developed separately • Thus, we may not be aware of shared join points • Aspects are usually written in Turing complete advices  AspectJ, AspectC++, AspectWerkz, JBossAOP … • This makes it hard to reason about the sanity of the composition • E.g. “What is the intended behavior of not calling the proceed in one specific around advice?”

10. Aspect Interference • Semantic conflicts • Is the intended behavior preserved when composing two aspects? • Hard to detect as you have to know the semantics of advice • “A semantic conflict, is a situation where the composition of multiple advices influences the behavior of the advices or of the base system, causing the system requirements to be violated.”

11. Example: • Encryption: • Encrypt all outbound traffic on some protocol • call(* *.sendData(String)) && args(data)  Encrypt advice • Decrypt all inbound traffic on some protocol • call(* *.receiveData(String)) && args(data)  Decrypt advice • Logging: • Log all sent and received data on the protocol: • call(* *.receiveData(String) || * *.sendData(String)) && args(data)  Log advice

12. Example: Encrypt Log Decrypt Superimposition Protocol class Log Protocol class Encrypt Log Decrypt void sendData(String) void receiveData(String) Encrypt Log Decrypt Log Composition void sendData(String) void receiveData(String)

13. Example: • Both orderings are correct from a compiler point of view! • However, depending on the requirements one order might be intended. • In a hostile domain we want to ensure that no unencrypted data is read. • In a protocol debugging domain we need to read the unencrypted data. • Assume we want the latter option: • Log before Encrypt and Decrypt before Log

14. Other examples • “If the authorization aspect denies access for a state-changing operation, a second aspect may not be executed" • e.g. the authorization around advice does not do a proceed() • "combining a real-time constraint aspect and a (possibly blocking) synchronization constraint" • "two advices that both modify e.g. the arguments or return value of a call" • unless these are associative modifications

15. Aspect ordering • Ordering of advice at shared join points • execution 'must' be sequential • an order is always chosen • ordering may affect behavior • desired order is determined by requirements! •  explicit, finegrained ordering specification is required • AspectJ: 'declare precedence' • EAOP: advice composition () • Compose*: declarative, fine-grained composition specification • ordering • conditional execution • static constraints

16. Semantic Interference Among Aspects: a formal view • One aspect causes another to operate incorrectly even though: • Aspect A satisfies its specification (PA, RA) • Aspect B satisfies its specification (PB, RB) • Recall P is assumption about base and R is guarantee about augmented • We have a base system satisfying both PAand PB

17. Aspect Interference A, B – aspects; S – underlying system (S + A) +B  WRONG S + A OK OR (S + B) +A  WRONG S + B OK OR S + (A+B)  WRONG

18. Example: Internet Access to Bank Accounts Underlying system: send (login, password) Internet terminal Server grant_access (info)

19. Adding Password Encryption Aspect A, responsible for encryption. A’s pointcut: a password is sent from login screen A’s assumption, PA: password-containing messages are sent only from login screen A’s guarantee, RA: each time any password is sent, it is encrypted

20. Example – contd. Aspect A: encrypt(password) System S: send (login, password) Internet terminal Server grant_access (info)

21. Retrieve Forgotten Psw. Aspect B e-mails the forgotten password if the security questions are answered B’s pointcut: a password is forgotten B’s assumption, PB: existence of an introductory operation, indicating that a password is forgotten B’s guarantee, RB: each time a password is forgotten, it’s e-mailed to the user, provided security questions are answered

22. Example – contd.(2) Aspect B: e-mail retrieved psw. S+A: send (login, encr(password)) forgot psw. Internet terminal Server grant_access (info)

23. Example – contd.(3) Unencrypted!!! (S+A)+B: B send (login, encr(password)) forgot psw. e-mail psw. Internet terminal Server grant_access (info)

24. Cause of the problem • Common join-points? – No. • Updating shared variables? – No. • The semantics of A and B? – Yes! 1. B’s advice (e-mailing password) violates A’s guarantee (all passwords encrypted) B can not be woven after A. 2. B’s advice violates A’s assumption (passwords sent from Login Screen only)  A can not be woven after B

25. Semantic Interference – more formally A – aspect, specified by (PA, RA) B – aspect, specified by (PB, RB) Definition:A does not interferewith B if for every system S, (*) (*) Notation: OKAB • Need to prove: OKAB and OKBA

26. Proving Non-Interference • Theorem (dividing the proof task): To prove OKAB, it’s enough to show [KPAB] (A preserves the assumption of B) [KRAB] (B preserves the guarantee of A)

27. Direct Proof Method: Based on Maven tool explained earlier 1.Build tableau T for PA PB 2.Use MAVEN to prove OKAB - weave A into T, then weave B - show RA RB on the result 3.Use MAVEN to prove OKBA - weave B into T, then weave A - show RA  RB on the result

28. Incremental Proof Method • Use MAVEN to prove KPAB - build tableau TP for PA PB - weave A into TP - show PB on the result 2.Use MAVEN to prove KRBA - build tableau TR for RA PB - weave B into TR - show RA on the result 3, 4 (for KPBA, KRBA) – symmetric ( OKBA) OKAB

29. Incremental method - advantages • Easier weaving • Quicker verification • Simplifications to 2 verification tasks (in not-so-rare special cases) • Advantage in failure analysis: the verification step at which we obtained the counterexample helps show exactly which aspect caused interference and how (= which property was violated) Cause: smaller models and TL formulas

30. Bank system – verification failures • KRAB fails  B can not be woven after A, because it does not preserve the guarantee of A, RA (B sends e-mailed password unencoded) • KPBA fails  B can not be woven before A, because B violates the assumption of A, PA (the passwords are sent not only from the “login” screen)

31. Ongoing research • Analyze counterexamples to correct assumption/pointcut/advice/guarantee • Investigate various weaving strategies including advice with joinpoints inside • Show categories of aspects have special interference properties • Detect interference problems for real-life collections of aspects

32. A Common Aspect Proof Environment (CAPE) • A framework with multiple tools for analyzing aspects and augmented systems • Preliminary version is under development by Technion, INRIA , Twente Univ., Lancaster Univ. • Includes syntactic analysis, model checking, type checking, for common internal representations • Can treat different aspect languages

33. AOSD-Europe • 6th Programme EU Network of Excellence on Aspect-Oriented Software Development • Includes those already listed, IBM, Siemens, and 5 other Universities • Developing tools for aspects, including easy aspect verification • See http://www.aosd-europe.net

34. Conclusions • Aspects provide opportunities, but need analysis • New kind of modularity (cross-cutting) and reuse • Potential for “on-demand” adaptation • Relevant for all stages of software development • Formal Methods for software deserve consideration • Elegant applications of mathematics (logic) • Software crisis in reliability, expensive debugging • Tools are finally becoming practical • Their combination has especially interesting questions and is potentially useful and practical