1 / 34

Interferences: aspect-base and between aspects

Interferences: aspect-base and between aspects. Shmuel Katz, using slides from Lodewijk Bergmans. Composition Conflicts (code interference). Syntactical e.g. in the case of source code weaving the woven code can no longer compile Structural

Download Presentation

Interferences: aspect-base and between aspects

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related