monitoring aspects for the customization of automatically generated code for big-step models shahram...
TRANSCRIPT
Monitoring Aspectsfor the Customization of
Automatically Generated Codefor Big-Step Models
Shahram Esmaeilsabzali Bernd Fischer
Joanne M. [email protected] [email protected]@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.