Monitoring Aspectsfor the Customization of

Automatically Generated Codefor Big-Step Models

Shahram Esmaeilsabzali Bernd Fischer

Joanne M. Atleeshahram@mpi-sws.org jmatlee@cs.uwaterloo.cab.fischer@ecs.soton.ac.uk

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

Big Step Modeling Languages (BSMLs)

ControllerMicrowave

Off

On

Lock Cooker

,{: ^1 lockstartt}startcook

,{: ^2 unlockstopt}stopcook

;: falselboolean

Unlocked

Locked

lockt :3

;:/ truel

unlockt :4

][ falsel

Idle

Cooking

startcookt :5

][ truel

stopcookt :6

;:/ falsel t: trig [guard_cond] /var_assign ^gen

t’: …

dest1

P

Q

Conjunction of (negation) events Boolean expression

over variablesVariable assignments

Generated events

“And” control state

“Or” control states

M

src1

dest2src2

“Basic” control states

... think Statecharts

Big Step Modeling Languages (BSMLs)

ControllerMicrowave

Off

On

Lock Cooker

,{: ^1 lockstartt}startcook

,{: ^2 unlockstopt}stopcook

;: falselboolean

Unlocked

Locked

lockt :3

;:/ truel

unlockt :4

][ falsel

Idle

Cooking

startcookt :5

][ truel

stopcookt :6

;:/ falsel

Widely used class of languages and generators:• Statecharts (Rhapsody, Statemate, ...)• RSML• Argos• ...

Big Step Modeling Languages (BSMLs)

ControllerMicrowave

Off

On

Lock Cooker

,{: ^1 lockstartt}startcook

,{: ^2 unlockstopt}stopcook

;: falselboolean

Unlocked

Locked

lockt :3

;:/ truel

unlockt :4

][ falsel

Idle

Cooking

startcookt :5

][ truel

stopcookt :6

;:/ falsel

…

Environmental Input I . . .

1T

…

2mT

…

1mT

Small steps

Big step T

. . .

ti

tj

tk

Big Step Modeling Languages (BSMLs)

ControllerMicrowave

Off

On

Lock Cooker

,{: ^1 lockstartt}startcook

,{: ^2 unlockstopt}stopcook

;: falselboolean

Unlocked

Locked

lockt :3

;:/ truel

unlockt :4

][ falsel

Idle

Cooking

startcookt :5

][ truel

stopcookt :6

;:/ falsel

}{ 1t}{start }{ 3t }{ 5t

][ truel

}startcook,,{ lockstart

}startcook,,{ lockstart

}startcook,,{ lockstart

}{ 1t}{start }{ 3t

][ truel

}startcook,,{ lockstart }{start

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

NextBig Step

GCBig Step

GCSmall 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

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 anew thread at each snapshot when the antecedentof 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.

ReferencesEsmaeilsabzali, 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.

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.