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)

Controller

Microwave

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)

Controller

Microwave

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)

Controller

Microwave

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)

Controller

Microwave

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 forbig-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 implementedfor 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), 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.