Monitoring Aspects for the Customization of Automatically Generated Code for Big-Step Models Shahram Esmaeilsabzali Bernd Fischer Joanne M. Atlee

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 a large class of modelling languages and their code generators

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

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

Big Step Modeling Languages (BSMLs) Controller Microwave Off On Lock Cooker Unlocked Locked Idle Cooking … Environmental Input I... …… Small steps Big step T... titi tjtj tktk

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

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

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

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 language in 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 for big-step modeling languages –form of customization not determined in advance –functionality of customization not part of the model

Big-Step Monitoring Language (BML) Design goals: check properties of BSML model, and correctness of 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

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

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) execution: transition is taken in big step Note: also non-reachability, but is different from reachability: LTL formula over snapshots in big step

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)

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

BML is implemented as aspect-oriented runtime monitoring framework. At runtime, check for counter- and witness examples 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 a new thread at each snapshot when the antecedent of the expression becomes true.

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 reflection to obtain the necessary information to evaluate the monitors. –minimal change to code generator (change one set of variables into class attributes) only quantifier-free core of BML implemented for the output of the CGG

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

Conclusions Introduced BML, a language for specifying monitors for 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 technique to generate code to evaluate BMLs –We provided an automatic means for the customization of generated code

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

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

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.

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

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