Shahram Esmaeilsabzali Bernd Fischer
description
Transcript of Shahram Esmaeilsabzali Bernd Fischer
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)
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.