Jianwei%20Niu

1
Mapping Specification Notations to Analysis Tools
METRO

• Jianwei Niu
• jniu_at_uwaterloo.ca
• University of Waterloo

2
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

3
Model Checker
Model Checker X
Spec in input language for X
True or False with counter examples
Properties
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

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
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
Existing Model Checker (Notation X)
Translator from M to X
7
Current Approaches for Analyzing Specifications

• 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 DayJoyce, Dillion
  Stirewalt, Pezze Young

• 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
8
Current Approaches for Analyzing Specifications

Spec in Formal Notation M
Existing Model Checker (Notation X)
Semantics for Notation M
Model Compiler
Transition relation (e.g., Kripke structure)
Day Joyce, Dillion Stirewalt, Pezze Young
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)
10
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

11
Computation Model

• A hierarchical transition system (HTS) is a
  hierarchical, extended state machine without
  concurrency

12
Computation Model --- Syntax

• An HTS contains
• States and a state hierarchy
• Internal and external events
• Variables
• Transitions

13
Semantics of HTS --- Snapshot

• Snapshot observable point in execution

current states current internal events current
variable values current generated events
Basic Elements
14
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

15
Step Semantics

• Micro-Step one transition execution
• Macro-Step a sequence of micro steps until
  the system is stable

Input
stable
SS0
SS1
SS2
16
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

17
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

18
Template Parameters
how changed when a transition is taken
how reset at beginning of macro-step
NEXT
RESET
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
19
Template Parameters
how changed when a transition is taken
how reset at beginning of macro-step
NEXT
RESET
CS IE AV O CSa IEa AVa Ia en_states en_trig en_c
ond
Enabling Events
how used to enable a transition
20
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

21
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
SS1
SS0
IE ? Ia e trig(?) e
22
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
SS2
SS0
SS1
IE a Ia e trig(?) a
IE ? Ia e trig(?) e
23
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
SS3
SS0
SS1
SS2
IE a Ia e trig(?) a
IE ? Ia e trig(?) e
IE a Ia e trig(?) e
24
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 a Ia e trig(?) a
IE ? Ia e trig(?) e
IE a Ia e trig(?) e
IE a Ia e trig(?) ? IE ? Ia
25
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
SS1
SS0
IE ? Ia e trig(?) e
26
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
?2 a
?1 e /a
SS2
SS0
SS1
IE ? Ia e trig(?) e
IE a Ia ? trig(?) a
27
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
?2 a
?1 e /a
SS0
SS1
SS2
IE ? Ia e trig(?) e
IE a Ia ? trig(?) a
IE ? Ia ? trig(?) ? IE ? Ia
28
Template Parameters
how changed when a transition is taken
how reset at beginning of macro-step
NEXT
RESET
CS IE AV O CSa IEa AVa Ia en_states en_trig en_c
ond
Enabling Events
Enabling States
how used to enable a transition
29
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

30
Composition Operator
CP1
CP2
CP3
CP4
HTS3
HTS5
HTS4
HTS1
HTS2
31
Composition Operator

• Parallel
• Interleaving
• Synchronization
• Environmental synchronization
• Rendezvous synchronization
• Interrupt
• Sequence
• Choice

32
Composition Operator

• Parallel
• Interleaving
• Synchronization
• Environmental synchronization
• Rendezvous synchronization
• Interrupt
• Sequence
• Choice

33
Parallel Composition
Components execute in parallel
34
Parallel Composition
Each component takes a transition if both are
enabled simultaneously
35
Parallel Composition
Enabled component executes in isolation
36
Environmental Synchronization
y
x
x
Components synchronize on an external
synchronization event
37
Environmental Synchronization
y
x ? syncEv
x
x
Each component takes a transition if enabled by
an external synchronization event
38
Environmental Synchronization
y
y ? syncEv
x
x
Components interleave
39
Interrupt
Transfer control from one component to the other.
40
Interrupt
Interrupt transition has priority and executes
41
Interrupt
The left component has priority and steps
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

43
Interrupt --- Formal Definition
44
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

45
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
• Harels, Pnueli Shalevs, RSML, STATEMATE
• Niu Atlee Day, RE, 2003

46
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

47

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.

48
METRO
METRO
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)
49
METRO
Existing Model Checker X
METRO

• Spec in
• Formal
• Notation
• M

Specifics of M given by parameters
Express
. . .
Existing Model Checker Y
Common Semantics
Lu Atlee Day Niu., submitted for
publication, 2004
50
(No Transcript)
51
(No Transcript)
52
(No Transcript)
53
(No Transcript)
54
(No Transcript)
55
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
56
Comparison
Fusion
Semantic parameters, Composition operators
(expressed in logic)
type checker symbolic function eval comm template
semantics transition relation BDD model checker
MagicDraw (with plugin)
XML
S
57
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

58
Conclusions

• Template semantics is a new approach to
  structuring semantics of specification notations
• Capture common semantics and parameterize
  notation- specific behavior
• Define a notations execution semantics and
  composition operators as separate concerns
• Template semantics is effective and expressive
  for representing the semantics of many
  specification notations

59
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

60
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 149-158,
  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 188-199,
  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 866-882, 2003
• Yun Lu, Joanne M. Atlee, Nancy A. Day, and
  Jianwei Niu. Model Checking Template-Semantics
  Specifications, submitted for publication, 2004