Shahram Esmaeilsabzali Bernd Fischer

1. Monitoring Aspectsfor the Customization ofAutomatically Generated Codefor Big-Step Models Joanne M. Atlee Shahram Esmaeilsabzali Bernd Fischer jmatlee@cs.uwaterloo.ca b.fischer@ecs.soton.ac.uk shahram@mpi-sws.org

2. Modeling Languages and Code Generation • Modeling languages offer... • abstraction – domain specificity • analyzability – ... • ... but ultimately interested in code: code generation • However, code generation can be • opaque: generator implements unknown semantics • analyze generated code (in terms of modeling language) • iterative: model can change • automated approach • incomplete: not everything expressed in model • (ultimately) modify generated code Monitoring framework for alarge class of modelling languages and their code generators

3. Big Step Modeling Languages (BSMLs) Conjunction of (negation) events Microwave Boolean expression over variables Generated events Variable assignments Cooker Lock Controller M Idle Unlocked Off P t: trig [guard_cond] /var_assign^gen “Or” control states Cooking Locked On src1 dest1 t’: … Q src2 dest2 “And” control state “Basic” control states ... think Statecharts

4. Big Step Modeling Languages (BSMLs) Microwave Widely used class of languages and generators: • Statecharts (Rhapsody, Statemate, ...) • RSML • Argos • ... Cooker Lock Controller Idle Unlocked Off Cooking Locked On

5. Big Step Modeling Languages (BSMLs) Microwave Cooker Lock Controller Idle Unlocked Off Cooking Locked On Environmental Input I ti . . . tj … … … tk Small steps . . . Big step T

6. Big Step Modeling Languages (BSMLs) Microwave Cooker Lock Controller Idle Unlocked Off Cooking Locked On Statecharts: Does t3 always fire before t5? “Statecharts”: Does t5 fire always after t3?

7. Big-step initialization with environmental inputs Determine consistent enabled transitions Choose one high-priority small step Execute the small step End of big step Execution of a Big Step in a BSML Take One Take Many • Determine transitions enabled by events Remainder Next Small Step • Determine transitions enabled by variables Next Big Step GC Big Step No Maximal Big step? GC Small Step Yes

8. Big-step initialization with environmental inputs Determine consistent enabledtransitions Choose one high-priority small step Execute the small step End of big step Execution of a Big Step in a BSML core concepts core concepts • Determine transitions enabled by events • Determine transitionsenabled by variables No Maximal Big step? Yes

9. Our Contributions • A language for specifying monitors that: • uses the vocabulary of models and the modeling language, not the generated code • is independent of the semantics of the languagein which the model is specified in • A novel aspect-oriented technique to safely add monitors to the generated code • A method for automatic code customization forbig-step modeling languages • form of customization not determined in advance • functionality of customization not part of the model

10. Big-Step Monitoring Language (BML) Design goals: • check properties of BSML model, and correctnessof its implementation • check the properties of a BSML and its semantics Design approach: • logic (w/ flavor of domain-specific aspect language) • operators: enabledness, execution, reachability • monitors: invariants, witnesses

11. BML by Examples • Either the door can be locked or radiation can start (i.e., transitions t3 and t5 are not enabled together) implicit scope: big step invariant: property holds in all snapshots and all big steps (implicit universal quantifier) enabledness: transition is (not) enabled in big step

12. BML by Examples • Either the door can be locked or radiation can start (i.e., transitions t3 and t5 are not enabled together) • If the door is locked, radiation starts(i.e., if t3 is executed, t5 will also be executed) reachability: LTL formula over snapshots in big step execution: transition is taken in big step Note: also non-reachability, but is different from

13. BML by Examples • Either the door can be locked or radiation can start (i.e., transitions t3 and t5 are not enabled together) • If the door is locked, radiation starts(i.e., if t3 is executed, t5 will also be executed) • The door can be unlocked(i.e., transition t4 can be executed) witness: property holds in some snapshot in some big step (implicit existential quantifier)

14. BML by Examples (II) • Enabled transitions execute in the same big step • Execution of a transition does not invalidate its precondition (global consistency [Pnueli / Shalev, 1991]) • limited quantification: only two levels, syntactic sugar,outermost quantifier must match monitor type: • invariant ↔ universal • witness↔ existential

15. BML is implemented as aspect-oriented runtime monitoring framework. • At runtime, check for counter- and witnessexamples for invariants and witness monitors, respectively. • Generated Java aspects evaluate BML expressions, via evaluating en and ex predicates. • only aspect of code generator that needs to be exposed • Reachability / unreachability expressions fork anew thread at each snapshot when the antecedentof the expression becomes true.

16. Prototype Implementation for CGG • Family of code generators [Prout, Atlee, Day, and Shaker 2008] • Generated aspects take advantage of the structure of the generated code • can use reflectionto obtain the necessary informationto evaluate the monitors. • minimal change to code generator(change one set of variables into class attributes) • only quantifier-free core of BML implementedfor the output of the CGG

17. Experiments • Microwave system (and variations) • exhausted various semantic options • monitors behaved as expected • Elevator system • uses buffered events (out of the scope of BSMLs) • but generated code has a structure that is compatible with our implementation

18. Conclusions • Introduced BML, a language for specifying monitorsfor big-step models: • independent of the semantics of a particular language, and thus can be adopted by any BSML • can be used to specify interesting properties • Implemented core of BML for the output of a family of code generators. • We developed a novel, aspect-based, multi-threaded techniqueto generate code to evaluate BMLs • We provided an automatic means for the customization of generated code

19. Future Work • Extending BML to support: • new predicates, to capture the notions like becoming enabledor becoming disabled⇒ allows specifying a wider range of monitors. • a notion of actionto allow modifying the behavior of generated code systematically⇒ disable(t) action that disables an enabled transitioncan enforce global consistency semantics for a model • Supporting quantification in our implementation

20. Related Work: Runtime Monitoring Runtime monitoring frameworks (RMFs): • Java PathExplorer[Drusinski 2000] • Temporal Rover [Havelund, Roşu 2001] • use the vocabulary of programs Aspect-based RMFs: • Trace Matches [Allan, Avgustinov, Christensen, Hendren, Kuzins, Lhoták, de Moor, Sereni, Sittampalam, Tibble, 2005.] • Mop [Chen, Roşu 2007.] • use pointcut vocabulary in programs

21. Related Work: Aspects & Code Generation Aspect generation: • Meta AspectJ[Zook, Huang, Smaragdakis, 2004] • Aspect C++ [Lohmann, Blaschke, Spinczyk, 2004] • Generative AOP [Smith, 2004.] • use general purpose aspects Aspects at model level: • Aspect-oriented domain modelling [Gray, Bapty, Neema, Schmidt, Gokhale, Natarajan, 2003] • Model-based pointcuts[Kellens, Mens, Brichau, Gybels, 2006] • We unify code, model, and aspects, automatically.

22. References Esmaeilsabzali, Day, Atlee, Niu: Deconstructing the semantics of big-step modelling languages. Requirements Engineering 15(2), 2010. Pnueli,Shalev: What is in a step: On the semantics of statecharts. TACAS, 1991. Prout, Atlee, Day, Shake: Semantically configurable code generation. MoDELS, 2008. Drusinsky: The temporal rover and the ATG rover. SPIN, 2000. Havelund, Roşu: Monitoring Java programs with Java PathExplorer. RV, 2001. Allan, Avgustinov, Christensen, Hendren, Kuzins, Lhoták, de Moor, Sereni, Sittampalam, Tibble: Adding trace matching with free variables to AspectJ. OOPSLA, 2005.

23. References (II) Chen, Roşu: Mop: an efficient and generic runtime verification Framework. OOPSLA, 2007. Zook, Huang, Smaragdakis: Generating AspectJ programs with Meta-AspectJ. GPCE, 2004. Lohmann, Blaschke, Spinczyk: Generic advice: On the combination of AOP with generative programming in AspectC++. GPCE, 2004. Smith: A generative approach to aspect-oriented programming. GPCE, 2004. Gray, Bapty, Neema, Schmidt, Gokhale, Natarajan: An approach for supporting aspect-oriented domain modeling. GPCE, 2003. Kellens, Mens, Brichau, Gybels:Managing the evolution of aspect-oriented software with model-based pointcuts. ECOOP, 2006.