1. Mapping Specification Notations to Analysis Tools
METRO
Jianwei Niu
University of Waterloo

2. North Carolina State University
Formal Methods
Software engineering is about developing quality software in a predictable way
Errors in critical software can cause loss of life
Confidence in software can be obtained by using formal methods
Formal methods are rigorous means for specification and verification
Formal notations and powerful tools (e.g., model checkers) have been increasingly applied in modeling and reasoning about computer-based systems
March 26, 2004
North Carolina State University

3. North Carolina State University
Model Checker
Model Checker X
Spec in
input
language
for X
True or
False
with
counter
examples
Properties
March 26, 2004
North Carolina State University

4. Specification Notation
Specification notations describe systems’ behavior
Process algebras (e.g., CCS, LOTOS)
State-based notations (e.g., statecharts)
These notations are suitable and flexible modeling large reactive systems
They are intuitive for software practitioners
Their composition mechanisms provide facilities to represent concurrency and communication
Formal requirements models can be automatically analyzed and requirement errors are easier and cheaper to fix at the requirement stage
March 26, 2004
North Carolina State University

5. Current Approaches for Analyzing Specifications
Construct a specific tool to analyze a specification written in a certain notation [Cleaveland & Parrow & Steffen, Harel & Naamad]
Model Checker
for
Notation M
Spec in
Formal
Notation M
March 26, 2004
North Carolina State University

6. Current Approaches for Analyzing Specifications
Write a translator from the notation to an existing analyzer [Atlee & Gannon, Avrunin & Corbett & Dillion, Chan et al.]
Spec in
Formal
Notation M
Translator
from
M to X
Existing
Model
Checker
(Notation X)
March 26, 2004
North Carolina State University

7. Current Approaches for Analyzing Specifications
The number of translators can be reduced for verifying specifications in different notations using different tools
Problem for these approaches: semantics of notations is evolving over time
Solution: generating analyzers directly from notations’ semantics [Day&Joyce, Dillion & Stirewalt, Pezze & Young]
Current Approaches for Analyzing Specifications
Develop an intermediate notation and translate to the input languages for different tools [Bensalem et al., Bozga et al., Bultan]
Specification in
Formal
Notation M
Existing
Model Checker
(Notation X)
Intermediate
Notation
Specification in
Formal
Notation N
Existing
Model Checker
(Notation Y)
Specification in
Formal
Notation S
March 26, 2004
North Carolina State University

8. Current Approaches for Analyzing Specifications
Spec in
Formal
Notation M
Semantics for
Notation M
Existing
Model
Checker
(Notation X)
Model
Compiler
Transition relation
(e.g., Kripke structure)
[Day & Joyce, Dillion & Stirewalt, Pezze & Young]
March 26, 2004
North Carolina State University

9. A New Approach for Mapping Specification Notations to Analysis Tools
Template semantics
Specifics of M given by parameters
Spec in
Formal
Notation M
Existing
Model
Checker
(Notation X)
Common Semantics
Model
Compiler
Transition relation
(e.g., Kripke structure)
March 26, 2004
North Carolina State University

10. North Carolina State University
Outline of Talk
Template Semantics
Computation model
Step semantics
Template parameters
Composition operators
Template semantics for different notations
Generating analysis tools from template semantics
Model compiler
Parameterized translator
Conclusions and future work
March 26, 2004
North Carolina State University

11. North Carolina State University
Computation Model
A hierarchical transition system (HTS) is a hierarchical, extended state machine without concurrency
March 26, 2004
North Carolina State University

12. Computation Model --- Syntax
An HTS contains
States and a state hierarchy
Internal and external events
Variables
Transitions
March 26, 2004
North Carolina State University

13. Semantics of HTS --- Snapshot
Snapshot: observable point in execution
current states
current internal events
current variable values
current generated events
Basic
Elements
Auxiliary
Elements
used to determine which transitions
are enabled
auxiliary states
auxiliary internal events
auxiliary variable values
auxiliary external events
March 26, 2004
North Carolina State University

14. North Carolina State University
Semantics of HTS
Behavior of an HTS is described by the possible execution steps it can take
Which transition is enabled
enabling states
enabling events
enabling variable values
How the HTS is affected by executing a transition
Step relates the current snapshot and the next snapshot of an HTS
March 26, 2004
North Carolina State University

15. North Carolina State University
Step Semantics
Micro-Step: one transition execution
Macro-Step: a sequence of micro steps until the system is stable
Input
macro-step
micro-step
SS0
SS1
SS2
stable
March 26, 2004
North Carolina State University

16. North Carolina State University
Step Semantics
Three types of macro-steps
Simple diligent
take a micro-step if a transition is enabled
Simple non-diligent
take a micro-step or stay idle
Stable: e.g., statecharts
a maximal sequence of micro-steps until no enabled transitions for the set of inputs
March 26, 2004
North Carolina State University

17. North Carolina State University
Template Semantics
Common semantics
reset
enabled transitions
apply
Template parameters
reset state info
reset event info
reset variable info
enabling states
enabling events
enabling variable values
change state
generate events
change variable values
March 26, 2004
North Carolina State University

18. Template Parameters how reset at how changed when a
beginning of macro-step
how changed when a
transition is taken
RESET
NEXT
current state
current int_ev
current var_val
current output
history state
history int_ev
history var_val
history ext_ev
en_states
en_trig
en_cond
how used to
enable a transition
March 26, 2004
North Carolina State University

19. Template Parameters Enabling Events how reset at how changed when a
beginning of macro-step
how changed when a
transition is taken
RESET
NEXT CS IE AV O
CSa
IEa
AVa Ia
en_states
en_trig
en_cond
Enabling
Events
how used to
enable a transition
March 26, 2004
North Carolina State University

20. North Carolina State University
Enabling Events
Enabling internal events
1. Events generated since the beginning of the macro-step
2. Events generated in the previous micro-step
Enabling external events
1. Events from the input are persistent through macro-step
2. Events from the input are enabling only in the first micro-step
March 26, 2004
North Carolina State University

21. North Carolina State University
Enabling Events
Enabling internal events
1. Events generated since the beginning of the macro-step
Enabling external events
1. Events from the input are persistent through macro-step
Input
1: e /a
SS0
SS1
IE =
Ia = {e}
trig() = e
March 26, 2004
North Carolina State University

22. North Carolina State University
Enabling Events
Enabling internal events
1. Events generated since the beginning of the macro-step
Enabling external events
1. Events from the input are persistent through macro-step
Input
1: e /a
2: a
SS0
SS0
SS1
SS2
IE =
Ia = {e}
trig() = e
IE = {a}
Ia = {e}
trig() = a
March 26, 2004
North Carolina State University

23. North Carolina State University
Enabling Events
Enabling internal events
1. Events generated since the beginning of the macro-step
Enabling external events
1. Events from the input are persistent through macro-step
Input
1: e /a
2: a
3: e
SS0
SS0
SS1
SS2
SS3
IE =
Ia = {e}
trig() = e
IE = {a}
Ia = {e}
trig() = a
IE = {a}
Ia = {e}
trig() = e
March 26, 2004
North Carolina State University

24. North Carolina State University
Enabling Events
Enabling internal events
1. Events generated since the beginning of the macro-step
Enabling external events
1. Events from the input are persistent through macro-step
Input
1: e /a
2: a
3: e
SS0
SS0
SS1
SS2
SS3
IE =
Ia = {e}
trig() = e
IE = {a}
Ia = {e}
trig() = a
IE = {a}
Ia = {e}
trig() = e
IE = {a}
Ia = {e}
trig()  IE  Ia
March 26, 2004
North Carolina State University

25. North Carolina State University
Enabling Events
Enabling internal events
2. Events generated in the previous micro-step
Enabling external events
2. Events from the input are enabling only in the first micro-step
Input
1: e /a
SS0
SS1
IE = 
Ia = {e}
trig() = e
March 26, 2004
North Carolina State University

26. North Carolina State University
Enabling Events
Enabling internal events
2. Events generated in the previous micro-step
Enabling external events
2. Events from the input are enabling only in the first micro-step
Input
1: e /a
2: a
SS0
SS1
SS2
IE = 
Ia = {e}
trig() = e
IE = {a}
Ia = 
trig() = a
March 26, 2004
North Carolina State University

27. North Carolina State University
Enabling Events
Enabling internal events
2. Events generated in the previous micro-step
Enabling external events
2. Events from the input are enabling only in the first micro-step
Input
1: e /a
2: a
SS0
SS1
SS2
IE = 
Ia = {e}
trig() = {e}
IE = {a}
Ia = 
trig() = {a}
IE = 
Ia = 
trig()  IE  Ia
March 26, 2004
North Carolina State University

28. Template Parameters Enabling Events Enabling States how reset at
beginning of macro-step
how changed when a
transition is taken
RESET
NEXT CS IE AV O
CSa
IEa
AVa Ia
en_states
en_trig
en_cond
Enabling
Events
Enabling
States
how used to
enable a transition
March 26, 2004
North Carolina State University

29. North Carolina State University
Outline of Talk
Template Semantics
Computation model
Step semantics
Template parameters
Composition operators
Template semantics for different notations
Generating analysis tools from template semantics
Model compiler
Parameterized translator
Conclusions and future work
March 26, 2004
North Carolina State University

30. North Carolina State University
Composition Operator
CP1
CP2
CP3
CP4
HTS3
HTS4
HTS5
HTS1
HTS2
March 26, 2004
North Carolina State University

31. North Carolina State University
Composition Operator
Parallel
Interleaving
Synchronization
Environmental synchronization
Rendezvous synchronization
Interrupt
Sequence
Choice
March 26, 2004
North Carolina State University

32. North Carolina State University
Composition Operator
Parallel
Interleaving
Synchronization
Environmental synchronization
Rendezvous synchronization
Interrupt
Sequence
Choice
March 26, 2004
North Carolina State University

33. Parallel Composition Components execute in parallel March 26, 2004
North Carolina State University

34. Parallel Composition Each component takes a transition
if both are enabled simultaneously
March 26, 2004
North Carolina State University

35. Parallel Composition Enabled component executes in isolation
March 26, 2004
North Carolina State University

36. Environmental Synchronizationx x
Components synchronize on
an external synchronization event
March 26, 2004
North Carolina State University

37. Environmental Synchronization
x  syncEv x x
Each component takes a transition
if enabled by an external synchronization event
March 26, 2004
North Carolina State University

38. Environmental Synchronization
y  syncEv x x
Components interleave
March 26, 2004
North Carolina State University

39. Interrupt Transfer control from one component to the other.
March 26, 2004
North Carolina State University

40. Interrupt Interrupt transition has priority and executes
March 26, 2004
North Carolina State University

41. Interrupt The left component has priority and steps March 26, 2004
North Carolina State University

42. Composition Operators
Compose multiple HTSs into a system, and represent
Concurrency
Communication
Synchronization
Constrain
Which component to execute
When to transfer control to each other
How to exchange events and data
Rely on parameters
March 26, 2004
North Carolina State University

43. Interrupt --- Formal Definition
March 26, 2004
North Carolina State University

44. North Carolina State University
Validation
Instantiate the template semantics
Define parameters
Choose composition operators
Using our template semantics to describe the semantics for
CCS, CSP, LOTOS, statecharts variants, and SDL
Niu & Atlee & Day, FSE, 2002
Niu & Atlee & Day, TSE, 2003
March 26, 2004
North Carolina State University

45. North Carolina State University
Validation
Template semantics is expressive and succinct to represent different notations
SCR, Petri Nets
Template semantics eases users’ effort in comparing and understanding specification notations, such as variants of statecharts
Harel’s, Pnueli & Shalev’s, RSML, STATEMATE
Niu & Atlee & Day, RE, 2003
March 26, 2004
North Carolina State University

46. North Carolina State University
Outline of Talk
Template Semantics
Computation model
Step semantics
Template parameters
Composition operators
Template semantics for different notations
Generating analysis tools from template semantics
Model compiler
Parameterized translator
Conclusions and future work
March 26, 2004
North Carolina State University

47. North Carolina State University*
METRO
Map specification notations to analysis tools using template semantics
Use template-based semantics to generate a transition-relation, which then can be used as an input to formal analysis tools
* Metro is an environmentally friendly system for rapid transit between disparate places. By analogy, the template semantics approach aims to ease the transit between verification environments.
March 26, 2004
North Carolina State University

48. METRO METRO Specifics of M given by parameters Spec in Formal Notation
Existing
Model
Checker
(Notation X)
Common Semantics
Model
Compiler
transition relation
(e.g.,Kripke structure)
March 26, 2004
North Carolina State University

49. North Carolina State University
METRO
Existing
Model
Checker X
METRO
Spec in
Formal
Notation M
Specifics of M given by parameters
Express .
Common Semantics
Existing
Model
Checker Y
Lu & Atlee & Day & Niu., submitted for publication, 2004
March 26, 2004
North Carolina State University

50. North Carolina State University
March 26, 2004
North Carolina State University

51. North Carolina State University
March 26, 2004
North Carolina State University

52. North Carolina State University
March 26, 2004
North Carolina State University

53. North Carolina State University
March 26, 2004
North Carolina State University

54. North Carolina State University
March 26, 2004
North Carolina State University

55. North Carolina State University
Validation
Use two case studies
A single lane bridge
A heating system
Demonstrate model compiler: generating an analyzer from the template semantics description for a given notation
Compare Express with model compiler
METRO
METRO
March 26, 2004
North Carolina State University

56. Comparison Fusion MagicDraw XML S+ SMV comm template semantics
Semantic parameters,
Composition operators
(expressed in logic)
comm template semantics
symbolic function eval
transition relation
model checker
type checker
BDD
MagicDraw
(with plugin)
XML S+
XML S+
SMV
optimized
translation
Semantic parameters,
(selected from menus of values)
transcription
March 26, 2004
North Carolina State University

57. North Carolina State University
Future Work
Problem: integrate specifications in Multiple Notations
Software practitioners tend to write specifications of different aspects of the system using different notations
A framework to parameterize the composition operators while composing
Different step semantics
Different event languages
Different data languages
March 26, 2004
North Carolina State University

58. North Carolina State University
Conclusions
Template semantics is a new approach to structuring semantics of specification notations
Capture common semantics and parameterize notation- specific behavior
Define a notation’s execution semantics and composition operators as separate concerns
Template semantics is effective and expressive for representing the semantics of many specification notations
March 26, 2004
North Carolina State University

59. North Carolina State University
Conclusions
Key benefit
a template semantics description of a notation can be used as an input to a tool for generating formal analysis tools
Secondary benefit
template semantics eases the specifiers’ effort in understanding and comparison of different notations
March 26, 2004
North Carolina State University

60. North Carolina State University
References
Jianwei Niu, Joanne M. Atlee, and Nancy A. Day. "Composable Semantics for Model-Based Notations", Proc. of the 10th ACM SIGSOFT Int. Symp. on the Foundations of Soft. Eng. (FSE), pages , 2002
Jianwei Niu, Joanne M. Atlee, and Nancy A. Day. "Comparing and Understanding Model-Based Specification Notations", Proc. of the 11th IEEE Int. Requirements Eng. Conf. (RE), pages , 2003
Jianwei Niu, Joanne M. Atlee, and Nancy A. Day. "Template Semantics for Model-Based Notations", IEEE Transactions on Soft. Eng., vol. 29, no.10, pages , 2003
Yun Lu, Joanne M. Atlee, Nancy A. Day, and Jianwei Niu. “Model Checking Template-Semantics Specifications”, submitted for publication, 2004
March 26, 2004
North Carolina State University