1 / 33

Verifying Aspect Advice Modularly By:Shiram Krishnamurthi Kathi Fisler Michael Greenberg

Verifying Aspect Advice Modularly By:Shiram Krishnamurthi Kathi Fisler Michael Greenberg. Presented by:Iddit Shalem. Aspect Verification. Aspect Oriented Programming becomes increasingly important. All software cycle stages are expected to be supported.

maeve
Download Presentation

Verifying Aspect Advice Modularly By:Shiram Krishnamurthi Kathi Fisler Michael Greenberg

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. Verifying Aspect Advice ModularlyBy:Shiram Krishnamurthi Kathi FislerMichael Greenberg Presented by:Iddit Shalem

  2. Aspect Verification • Aspect Oriented Programming becomes increasingly important. • All software cycle stages are expected to be supported. • Validation of behavioral properties is especially important.

  3. Program Verification • There are algorithms for verifying complete programs ( expressed as state-machine). • A naive approach would be to compose all advices against the program . • Problematic: • Time consuming . • Potentially difficult • Requirment – Separate verification

  4. Separate verification - Problem setup Advice Authors Program Developers • Interface generated at the program developer side. • The advice authors does not receive the program, only the interface. Program PCDs Properties Properties Aspect Interface Generation Validation Verification Interface

  5. Backround • Aspect-Oriented programming . • Model-Checking – a verification technique.

  6. Aspect-oriented programming Pointcut designator (PCD) is a language for describing when an advice should apply (describing joinpoints). • Here we consider only a subset of the PCD language of AspectJ – expresses patters over the shape of the call stack => function calls are the only joinpoints considered.

  7. PCD Language • PCD are a restricted form of regular expressions • Pointcut atom • Call(f) for some function name f • !Call(f) for some function name f • true • Pointcut element • a pointcut atom • a* where a is a pointcut atom. • (e) where e is a pointcut element • e1 & e2 where e1 and e2 are pointcut elements • e1 | e2 where e1 and e2 are pointcut elements • Pointcut designator • a point cut element • (d) where d is a pointcut designator • d1;d2 where d1 and d2 are pointcut designator • d1|d2 where d1 and d2 are pointcut designator

  8. PCD language Cont’ • PCD are a restricted form of regular expressions. • A PCD subscribes a set of program states at which it applies ( pointcut). • Example PCD : call(h);true*;call(f);true*describes function h called from the flow of function f.

  9. Aspects • An aspect consists of: • PCD. • Advice. • Advice type ( before, after , around).

  10. Model Checking – Formal Models • Program source code => Program state machine. • Program state machine represents the control-flow of a program fragment. • State Machine is a tuple <S,T,L,ssrc,ssink,Scall,Srtn> • S – states. • T – included in SxS. • L – labels of the states. • ssrc,ssink – program’s entry and exit states. • Scall,Srtn - Subsets of S.

  11. Program State Machine Example source call(g) call(f) a a a a ret(g) b b ret(f) b b b call(h) Program state machine describing a main program which invokes f and then h, while f invokes g. Constructed from source code using inline depth parameter. b b ret(h) b b sink b

  12. CTL language • CTL atoms are propositions that label states. • Standard combinations by !,∧∨ • Properties of a path is expressed by the operators: • G(φ) – φ is true for all states of the path. • F(φ) – φ is true at some state of the path. • [φ U ψ]φ is true at all states until a state where ψ is true. • X(φ) – φ is true at the next state. • Properties referring to paths leaving a common state is expressed by the operators: • A – All paths • E – There Exists a path. • For example :A[φ U ψ]

  13. CTL Model-Checker • Input: • program state machine • CTL formula φ • Labels each state with all the sub-formulas of φ that are true at that state.

  14. Modular verification of Aspects • The presented techniqe is very limited. • Verifies only property preservation. • Supports spectative aspects only.

  15. Modular verification of Aspects • Input: • Aspects • Property ( CTL Formula) that holds for the main program. • Interface to the program. ( the labeled state-machine, including only function call , return, source and sink states). • What to do: • Identify states that satisfy PCDs. • Verify the advice (only) when applied at the relevant point-cuts.

  16. Aspect Verification Process source call(f) Φ = AG(A[aUb]) a a call(g) a a • P: call(g);true* ret(g) b b Advice A: ret(f) b b call(h) a b call(h) b b ret(h) a b ret(h) b b sink b

  17. Aspect Verification Process source call(f) Φ = AG(A[aUb]) a a call(g) a a Before1 Before2 • P: call(g);true* • Q: call(h);true*; call(f);true* ret(g) b b After1 After2 Advice A: propositions ret(f) in b b b call(h) a b call(h) b b Propositions sub-formulas ret(h) a b ret(h) out b b b A[aUb], AG(A[aUb]) sink b

  18. Aspect Verification Process • Assuming pointcuts are marked • Add ‘in’/’out’ states to the advice • Mark the advice ‘out’ state with all the labels from After2 ( or Before2) • Mark the advice ‘in‘ state with propositions of After1 ( Before1). • Preform model checking on the advice alone • If the advice passed the validation, the composed program satisfy the property.

  19. Around Advice Verification • Two cases for around advice • Calling proceed() • Not calling proceed().

  20. Around Advice Calling Proceed Base Program Around Advice propositions src call(g) Before1 a a a a Before2 Around1 After2 ret(g) b b b b Around2 After1 proceed Propositions sub-formulas sink

  21. Around Advice Not Calling Proceed • Around without proceed can bypass existing states. Φ = AF(b) no b b • Can invalidate a label copied to the advice out state.

  22. Around Advice Not Calling Proceed • This problem arises only under the conditions: • Formulas that capture eventual behavior. • There is a path from the function return state to the call state. • Fix : • Add more formulas to the interface to be validated. • When ever a model checker labels call state and return state with an eventual property, needs to add a formula that checks if this property is discharged before reaching the return state. In example case A((!return) U b). • If this formula succeeds at the call state of the base program, the formula is included in the interface for the call state to be checked against the advice.

  23. Identifying Pointcut States From PCDs source call(f) Φ = AG(A[aUb]) a a call(g) a a Before1 Before2 • P: call(g);true* • Q: call(h);true*; call(f);true* ret(g) b b After1 After2 Advice A: ret(f) b b call(h) a b call(h) b b ret(h) a b ret(h) b b sink b

  24. Identifying Pointcut States From PCDs • First Suggestion. • PDCs are regular terms. • Use the cross-product between the PCD state machine and the program state machine. • To identify pointcuts in advice, mark the advice ‘in’ state with the PCD state. • Problems: • PCD state machine more complicated than the PCD • We expand the states in the tested system.

  25. Identifying Pointcut States From PCDs – Avoiding cross products • We can express a PCD by CTL expression. • Reverse all edges in the program state machine • We can identify the point-cut states, by Model-Checking the PCD CTL formula.

  26. Identifying pointcut states from PCD by Model Checking • Example • call(h); true*;call(f);true*; Call(f) Call(h) ret(h) ret(f) Call(h) ret(h)

  27. Identifying pointcut states from PCD by Model Checking • Example • call(h); true*;call(f);true*; • call(h) ∧E ( true U call(f) ) • True for the pointcput states. • But what are all the states where the formula becomes true? • Where is the problem? Call(f) before1 before2 Call(h) ret(h) ret(f) Call(h) ret(h)

  28. Identifying pointcut states from PCDs • Translate PCD into a CTL formula • Reverse the program state machine graph. • Redirect edges outgoing function return states, to the successor state of the corresponding call state. • Model check the new graph • Formula becomes true only on pointcut states.

  29. Identifying pointcut within advice Aspect A Call(f) Call(g) before1 before2 Call(h) ret(g) ret(h) ret(f) Call(h) ret(h) Adivce type : Before PCD: call(g);true*;call(f);true*

  30. Identifying pointcut within advice Aspect A E(true U call(f)) Call(f) Call(g) before1 before2 Call(h) ret(g) ret(h) ret(f) • call(g) ∧ E ( true U call(f) ) Call(h) ret(h) Adivce type : Before PCD: call(g);true*;call(f);true*

  31. Identifying pointcut states from PCDs - Summary • How will we identify pointcuts within an advice? • Copy labels, relevant to the CTL formula, to the source of the advice • Preform model checking for identifying pointcut on the advice.

  32. Conclusions • We’ve seen a technique • identifies pointcuts • Given all pointcuts, verifies properties, checked on the base program, are reserved in the presence of advices. • Modular verification - separate verification, between the base program and the applied advices

  33. Future exploration • Preserving properties. What about new properties we want to check only for the advices. • Spectative aspects supported only. • Limited PCD language . • Each advice may be validated many times ( maybe once per each state in the point cut that advises it.

More Related