Date post: | 27-Dec-2015 |
Category: |
Documents |
Upload: | rudolf-bryant |
View: | 217 times |
Download: | 1 times |
March 26, 2004 North Carolina State University
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
March 26, 2004 North Carolina State University
3
Model Checker
Spec ininput
language for X Model Checker
XProperties
Trueor
False with
counter
examples
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]
Spec inFormal
Notation M
Model Checker for
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 inFormal
Notation M
ExistingModel
Checker(Notation
X)
Translatorfrom
M to X
March 26, 2004 North Carolina State University
7
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]
ExistingModel Checker
(Notation X)Specification in
FormalNotation N Existing
Model Checker
(Notation Y)
IntermediateNotation
Specification in
FormalNotation M
Specification in
FormalNotation S
Current Approaches for Analyzi
ng SpecificationsThe
number of
translators
can be
reduced
for
verifying
specificati
ons in
different
notations
using
different
tools
Problem
for these
approache
s:
semantics
of
notations
is evolving
over time
Solution:
generatin
g
analyzers
directly
from
notations’
semantics [Day&Joyce,
Dillion &
Stirewalt,
Pezze &
Young]
Current Approaches for Analyzi
ng SpecificationsThe
number of
translators
can be
reduced
for
verifying
specificati
ons in
different
notations
using
different
tools
Problem
for these
approache
s:
semantics
of
notations
is evolving
over time
Solution:
generatin
g
analyzers
directly
from
notations’
semantics [Day&Joyce,
Dillion &
Stirewalt,
Pezze &
Young]
March 26, 2004 North Carolina State University
8
Current Approaches for Analyzing Specifications
Spec inFormal
Notation M
ExistingModel
Checker(Notation
X)
ModelCompiler
Semantics for Notation M
[Day & Joyce, Dillion & Stirewalt, Pezze & Young]
Transition relation
(e.g., Kripke structure)
March 26, 2004 North Carolina State University
9
A New Approach for Mapping Specification Notations to Analysis
Tools
Spec inFormal
Notation M
ExistingModel
Checker(Notation X)
ModelCompiler
Common Semantics
Specifics of M given by parameters
Transition relation
(e.g., Kripke structure)
Template semantics
March 26, 2004 North Carolina State University
10
Outline of Talk
Template Semantics Computation model Step semantics Template parameters Composition operators
Template semantics for different notationsGenerating analysis tools from template semantics
Model compiler Parameterized translator
Conclusions and future work
March 26, 2004 North Carolina State University
11
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
src name: trig, [cond], /gen, /asn, #prty
dest
S1 t1: e [x>3] /a
S2
March 26, 2004 North Carolina State University
13
Semantics of HTS --- Snapshot
Snapshot: observable point in execution
BasicElements
current statescurrent internal eventscurrent variable valuescurrent generated events
AuxiliaryElements
used to determine which transitions are enabled
auxiliary statesauxiliary internal eventsauxiliary variable values auxiliary external events
March 26, 2004 North Carolina State University
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
March 26, 2004 North Carolina State University
15
Micro-Step: one transition execution Macro-Step: a sequence of micro steps until the system is stable
Step Semantics
macro-step
micro-step micro-step micro-step
Input
stableSS0 SS1 SS2
March 26, 2004 North Carolina State University
16
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
Step Semantics
March 26, 2004 North Carolina State University
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
March 26, 2004 North Carolina State University
18
current statecurrent int_evcurrent var_valcurrent output
history statehistory int_ev
history
var_val
history ext_even_states
en_trigen_cond
RESET NEXT
how reset atbeginning of macro-step
how changed when atransition is taken
how used toenable a transition
Template Parameters
March 26, 2004 North Carolina State University
19
CSIEAVO
CSa
IEaAVa
Ia
en_states
en_trigen_cond
RESET NEXT
how reset atbeginning of macro-step
how changed when atransition is taken
how used toenable a transition
EnablingEvents
Template Parameters
March 26, 2004 North Carolina State University
20
Enabling Events
Enabling internal events1. Events generated since the beginning of the macro-
step
2. Events generated in the previous micro-step
Enabling external events1. 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
Enabling Events
Enabling internal events1. Events generated since the beginning of the macro-
step
Enabling external events1. Events from the input are persistent through macro-
step
SS11: e /a
IE =
Ia = {e}
trig() = e
SS0
Input
March 26, 2004 North Carolina State University
22
Enabling Events
Enabling internal events1. Events generated since the beginning of the macro-
step
Enabling external events1. Events from the input are persistent through macro-
step
SS0 SS2SS0
IE = {a}
Ia = {e}
trig() = a
1: e /a 2: a
IE =
Ia = {e}
trig() = e
SS1
Input
March 26, 2004 North Carolina State University
23
Enabling Events
Enabling internal events1. Events generated since the beginning of the macro-
step
Enabling external events1. Events from the input are persistent through macro-
step
SS0 SS3SS0
IE = {a}
Ia = {e}
trig() = a
1: e /a 2: a
IE =
Ia = {e}
trig() = e
SS1 SS2
IE = {a}
Ia = {e}
trig() = e
3: e
Input
March 26, 2004 North Carolina State University
24
Enabling Events
Enabling internal events1. Events generated since the beginning of the macro-
step
Enabling external events1. Events from the input are persistent through macro-
step
SS0SS0
IE = {a}
Ia = {e}
trig() = a
1: e /a 2: a 3: e
IE =
Ia = {e}
trig() = e
SS1 SS2
IE = {a}
Ia = {e}
trig() = e
IE = {a}
Ia = {e}
trig() IE Ia
SS3
Input
March 26, 2004 North Carolina State University
25
Enabling Events
Enabling internal events2. Events generated in the previous micro-step
Enabling external events2. Events from the input are enabling only in the first
micro-step
SS11: e /a
IE =
Ia = {e}
trig() = e
SS0
Input
March 26, 2004 North Carolina State University
26
Enabling Events
Enabling internal events2. Events generated in the previous micro-step
Enabling external events2. Events from the input are enabling only in the first
micro-step
SS21: e /a
IE =
Ia = {e}
trig() = e
SS0
IE = {a}
Ia =
trig() = a
SS12: a
Input
March 26, 2004 North Carolina State University
27
Enabling Events
Enabling internal events2. Events generated in the previous micro-step
Enabling external events2. Events from the input are enabling only in the first
micro-step
1: e /a
IE =
Ia = {e}
trig() = {e}
SS0
IE = {a}
Ia =
trig() = {a}
SS12: a
IE = Ia =
trig() IE Ia
SS2
Input
March 26, 2004 North Carolina State University
28
CSIEAVO
CSa
IEaAVa
Ia
en_states
en_trigen_cond
RESET NEXT
how reset atbeginning of macro-step
how changed when atransition is taken
how used toenable a transition
EnablingEvents
EnablingStates
Template Parameters
March 26, 2004 North Carolina State University
29
Outline of Talk
Template Semantics Computation model Step semantics Template parameters Composition operators
Template semantics for different notationsGenerating analysis tools from template semantics
Model compiler Parameterized translator
Conclusions and future work
March 26, 2004 North Carolina State University
30
Composition Operator
CP1
CP2 CP3
CP4HTS3
HTS1 HTS2
HTS4 HTS5
March 26, 2004 North Carolina State University
31
Parallel
Interleaving
Synchronization Environmental synchronization Rendezvous synchronization
Interrupt
Sequence
Choice
Composition Operator
March 26, 2004 North Carolina State University
32
Parallel
Interleaving
Synchronization Environmental synchronization Rendezvous synchronization
Interrupt
Sequence
Choice
Composition Operator
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 Synchronization
x x
y
Components synchronize on an external synchronization event
March 26, 2004 North Carolina State University
37
Environmental Synchronization
x x
y
x syncEv
Each component takes a transition if enabled by an external synchronization event
March 26, 2004 North Carolina State University
38
Environmental Synchronization
x x
y
y syncEv
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
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
Composition Operators
March 26, 2004 North Carolina State University
43
Interrupt --- Formal Definition
March 26, 2004 North Carolina State University
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
March 26, 2004 North Carolina State University
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
Harel’s, Pnueli & Shalev’s, RSML, STATEMATE
Niu & Atlee & Day, RE, 2003
March 26, 2004 North Carolina State University
46
Outline of Talk
Template Semantics Computation model Step semantics Template parameters Composition operators
Template semantics for different notationsGenerating analysis tools from template semantics
Model compiler Parameterized translator
Conclusions and future work
March 26, 2004 North Carolina State University
47
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
Spec inFormal
Notation M
ExistingModel
Checker(Notation
X)Common Semantics
ModelCompiler
Specifics of M given by parameters
transition relation
(e.g.,Kripke structure)
March 26, 2004 North Carolina State University
49
Spec inFormal
Notation M
Existing
ModelCheck
erX
.
.
.
Common Semantics
Specifics of M given by parameters
Existing
ModelCheck
erY
Exp
ress
Lu & Atlee & Day & Niu., submitted for publication, 2004
March 26, 2004 North Carolina State University
50
March 26, 2004 North Carolina State University
51
March 26, 2004 North Carolina State University
52
March 26, 2004 North Carolina State University
53
March 26, 2004 North Carolina State University
54
March 26, 2004 North Carolina State University
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
March 26, 2004 North Carolina State University
56
type
che
cker
sym
bolic
func
tion
eval
com
m te
mpl
ate
sem
antic
s
tran
sitio
n re
latio
n
BD
D
mod
el c
heck
er
Fusion
MagicDraw(with plugin)
XML S+XML S+
Semantic parameters,Composition operators (expressed in logic)
SMVop
timiz
edtr
ansl
atio
n
Semantic parameters,(selected from menus of values)
tran
scrip
tion
Comparison
March 26, 2004 North Carolina State University
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
March 26, 2004 North Carolina State University
58
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
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
Conclusions
March 26, 2004 North Carolina State University
60
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
References