model checking uml statecharts and collaborations · but: uml vastly more expressive than target...
TRANSCRIPT
Model CheckingUML Statecharts and Collaborations
Stephan Merz
INRIA Lorraine, LORIA, Nancy
Alexander Knapp
Institut für Informatik
Ludwig-Maximilians-Universität München
Formal methods and UML
UML : more than pictures ?
– used by developers to communicate designs
– tool support : code generation, schedulability, performance, . . .
Why so many diagram types ?
– represent different aspects of system
– used in different phases of development
– redundancy is intentional
What can formal methods help ?
– ensure consistency between different views
– improve quality by correctness checks throughout the design process
2
This talk
1. Hugo : model checking UML designs
– analyze dynamic system behavior
– ensure consistency between state machine and collaboration views
2. Speculate on further applications of formal methods
– abstraction analyze infinite-state systems
– refinement support top-down system development
3
Hugo overview
Verification and code generation from same models
UML editor XMI Hugo/Spin .prverification
(counter)example
Hugo/Java .javacode skeleton
simulation
.taverification
(counter)exampleHugo/RT
spin
uppaal
javac
http://www.pst.informatik.uni-muenchen.de/projekte/hugo/
4
ATM example
Grossly simplified interaction between ATM and bank
Static structure: two (active) classes
«signal» doneverifyPIN()
«signal» PINVerified
«signal» abort«signal» reenterPIN
1
atm
1
bank Bank
int maxNumIncorrect = 2int numIncorrect = 0boolean cardValid = true
ATM
5
ATM state machine
ReturningCard
AmountEntryVerification
CardEntry
Counting
Dispensing
PINEntry
Giving Money
PINVerified
abort
/ ^bank.done
/ ^bank.verifyPIN()
reenterPIN
Abstract from actual data
Represent user interaction as completion events
6
Bank state machine
CardValidVerifyingCard
Idle
PINCorrect
entry / numIncorrect = 0
PINIncorrect
VerifyingPIN
[else] / ^atm.abort
[cardValid]
[else] / cardValid = false; ^atm.abort
/ ^atm.PINVerified
[numIncorrect < maxNumIncorrect]/ numIncorrect++; ^atm.reenterPIN
Verifying
verifyPIN()
done
7
Collaborations as specifications
Expected run: second attempt successful
atm banka : ATM b : Bank
1: verifyPIN()3: verifyPIN()
4: PINVerified2: reenterPIN
Undesired run: card verified after invalidation
atm banka : ATM b : Bank
3: verifyPIN()
4: PINVerified2: abort
1: verifyPIN()
Possibility of interactions can be formulated as a reachability problem
8
UML model checking
Analyse dynamic behavior of (sets of) active objects
– compile UML state machines for off-the-shelf model checkers
– properties: deadlocks, invariants, LTL properties, collaborations
But: UML vastly more expressive than target languages
Use intermediate representation
– (extended) hierarchical automata [Mikk 97, Latella 99]
– static computation of transitions [Lilius & Porres 99]
– Hugo: use UML meta model
Side effect: expose ambiguities in UML semantics
9
Hugo/Spin: first implementation
activeSub
container
outTrans
Activity TransHandler
EvtDispatcher
State
evtQueue
evtQueueCompletion
Faithful implementation of UML meta model: modular and flexible
– objects (of meta model) encoded as processes
– communication within single machine via synchronous message passing
– combinatorial explosion controlled by mutex
10
Problems with interpreting implementation
Efficiency problems
– ≈ 106 states generated for ATM example
– code replication: intermediate C code of several megabyte
– compilation time can be much larger than verification time
Reliance on complex data structures and optimizations
– channels passed as parameters
– encoding uses nested arrays
– huge memory overhead (mitigated by Spin’s compression)
11
New versions of Hugo
Current version based on compilation instead of interpretation
– one process per state machine, configuration encoded by constants
– ≈ 103 states generated for ATM example
– 4.7 megabyte of memory needed
– drawback: correctness of compilation non-trivial
Upcoming version will introduce intermediate UML model
– “flattening” removes hierarchy, resolving priority conflicts
– simpler back-ends for Spin and Uppaal
– formally define expression syntax?
– formal verification w.r.t. “Turku” semantics?
12
Hugo/RT: timed models
UML targets real-time applications
Basic construct: time events after(d)
– raised d time units after entering source state
– dispatched like completion events
– Hugo also allows clock variables (as in timed automata)
Timing assumptions (deliberately) not specified by UML
– delays introduced by message queue no
– time taken to perform RTC step none
– communication delays bounded
– delay before raising completion event arbitrary
13
Hugo/RT: timed models
UML targets real-time applications
Basic construct: time events after(d)
– raised d time units after entering source state
– dispatched like completion events
– Hugo also allows clock variables (as in timed automata)
Timing assumptions (deliberately) not specified by UML
– delays introduced by message queue no
– time taken to perform RTC step none
– communication delays bounded
– delay before raising completion event arbitrary
14
Hugo/RT example: Generalized Railroad Crossing
(g +g )
ta tg
gd+
u o+ EDA CB
entry sensor exit sensor
Safety gate down when train crosses
Utility gate up unless necessary
15
Class structure
Class diagram
– define interfaces of participating objects
– specify attributes, methods, and associations (communication links)
– behavior will be defined by associated state machines
Control
+«signal» enter(i : int)+«signal» exit(i : int)
−trains: int
−«signal» doOpen−«signal» doClose
Track
−«final» id : int
Gate
+«signal» open+«signal» close
1
ctl
k
1 1
gate
16
State machines: gate and track
Gate behaviorOpen Closing
ClosedOpening
gdafter( )guafter( )
open
close
Track behavior
NoTrain Approach Approach2
after( − )taTa
Crossingtgafter( )
taafter( )
after( − )tggT
/ ^ctl.enter(id)
/ ^ctl.exit(id)
/ ^ctl.exit(id)
Crossing2
17
Gate control
Open Closed/ ^gate.close
doClose doOpen
[else]
/ ^gate.open[trains == 0]
Away1 Entered1
kAway Entered k Nearby k Critical kafter( + )gu ogkenter( )
Nearby1 Critical1after( + )gu og
at gd+ gu
+after( − − )
at gd+ gu
+after( − − )
.........
exit(1) / trains−−, ^doOpen
enter(1)
kexit( ) / trains−−, ^doOpen
/ trains++ / ^doClose
/ ^doClose/ trains++
18
Timed Sequence Diagrams (1)
Specification of expected behavior: constraints express timing
{ − <= − }
track1 : Track track2 : Track ctl : Control gate : Gate
d c{ − <= }∆
ta gdb a
enter(1)
close
enter(2)
b
exit(1)
exit(2)
opend
a
c
19
Timed Sequence Diagrams (2)
Specification of erroneous behavior: utility property violated
ctl : Control gate : Gate
b a{ − < + }ug og
open
close
a
b
“Negative examples” can sometimes specify safety properties
. . . but not the absence of messages
. . . and neither upper bounds on timing
More expressive formalism desirable
20
Compilation to timed automata
Representation of state machines
– two timed automata per active object: state machine, event queue
– network automaton for inter-object communication
– UML state configuration encoded in control state
– UML state transition ; sequence of automata transitions
– generate clocks for nodes with outgoing time transitions
Translation of sequence diagrams
– generate observer automaton as for Spin
– translate timing annotations into clock constraints
x < + ba gu go
x := 0ba
closeRcvd?
ErrorbacloseRcvd?openRcvd?
Final
21
Example translation
UML model
G
D
E B
F
A
C
b
a /
x:=x+1
b
[x>0]
a /
o^b
a
Uppaal timed automaton
G
AC
F
BDbAck?x:=x+1 bToNet!
c cEC
aDisp?
bDisp?x<=0
x>0
aDisp?bDisp?
22
Results of verification
GRC case study (two tracks)
10 timed automata, 200 locations, 11 clocks
expected collaboration < 1 sec
utility property 11 sec
But: does this imply correctness?
Safety property
∀2(Track1.Crossing∨ Track2.Crossing⇒ Gate.Closed)
fails due to race condition between messages
23
Results of verification
GRC case study (two tracks)
10 timed automata, 200 locations, 11 clocks
expected collaboration < 1 sec
utility property 11 sec
But: does this imply correctness?
Safety property
∀2(Track1.Crossing∨ Track2.Crossing⇒ Gate.Closed)
fails due to race condition between messages
24
Corrected control state machine
enter( ) / trains−−, ^doOpen
Open Closed/ ^gate.close
doClose doOpen
[else]
/ ^gate.open[trains == 0]
Away1 Entered1
kAway Entered k Nearby k Critical kafter( + )gu ogkenter( )
Nearby1 Critical1after( + )gu og
at gd+ gu
+after( − − )
at gd+ gu
+after( − − )
kexit( ) / trains−−, ^doOpen
k
.........
exit(1) / trains−−, ^doOpen
enter(1)
/ trains++ / ^doClose
/ ^doClose/ trains++
enter(1) / trains−−, ^doOpen
25
Ongoing / future work
Tool extensions
– better integration via intermediate format
– add missing features to Hugo/RT (code generation, parameters, deferred events, . . . )
– replay of traces at UML level
– semantic account of translation
– better expressiveness: OCL support, LSCs
Beyond model checking
– provide assistance for system development: refinement
– handle infinite-state models: abstraction
. . . but pay attention to UML concepts
26
Visual verification formalism
Deductive verification interactive theorem proving
, arbitrary, infinite-state systems
/ tedious, requires expert knowledge
Algorithmic verification model checking
, automatic debugging technique
/ restricted applicability
Hybrid approach: abstraction
system specification � predicate diagram � property
27
Example: “dining mathematicians”
Mutual exclusion for two processes
int n > 0loop
t0 : await even(n);
e0 : n := n div 2endloop
‖
loopt1 : await ¬even(n);
e1 : n := 3 ∗ n + 1endloop
Associated predicate diagram
'
&
$
%at e0, at t1
n > 0, even(n)
'
&
$
%at t0, at e1
n > 0, ¬even(n)
'
&
$
%at t0, at t1
n > 0, even(n)
'
&
$
%at t0, at t1
n > 0, ¬even(n)
? ?
?
(n,≤)
6
(n, <)
?���������������*
HHHH
HHH
HHHH
HHH
HY
2(n > 0)
2¬(at e0 ∧ at e1)
23at e0
23at e1
28
Refinement of predicate diagrams
Top-down application of diagrams Spec � Gn � · · · � G2 � G1 � Prop
– support development process, preserving properties
– document system design
Which notion of refinement?
– methodological concerns
– tool support
– flexibility
Distinguish safety and liveness conditions
– safety part structural refinement: graph structure + non-temporal proof obligations
– liveness part non-local refinement, established by model checking
29
Example: mutex protocols (1)
Initial diagram obviously ensures mutual exclusion
~(crit1 /\ crit2)
First refinement introduce program counter
pc1 # crit, pc2 # crit
pc1 = crit,pc2 # crit
pc1 # crit,pc2 = crit
criti ≡ pci = crit
30
Example: mutex algorithms (2)
Second refinement introduce fairness
pc1 = ncrit, pc2 = ncrit
pc1 = ncrit,pc2 = try
pc1 = try,pc2 = try
pc1 = crit,pc2 = ncrit
pc1 = crit,pc2 = try
pc1 = try,pc2 = ncrit
pc1 = try,pc2 = crit
pc1 = ncrit,pc2 = crit
SF(Enter1)
SF(Enter2)
ensures liveness for both processes (“semaphore protocol”)
31
Example: mutex algorithms (3)
Third refinement introduce priorities
pc1 = ncrit, pc2 = ncrit
pc1 = ncrit,pc2 = try
pc1 = crit,pc2 = ncrit
pc1 = crit,pc2 = try
pc1 = try,pc2 = ncrit
pc1 = try,pc2 = crit
pc1 = try,pc2 = try,
turn=1
pc1 = try,pc2 = try,
turn=2
pc1 = ncrit,pc2 = crit
fairness conditions
no longer necessary
ensures one-bounded overtaking (“Peterson algorithm”)
Bakery algorithm can be obtained by one more refinement step
32
Example: mutex algorithms (4)
Distribution identify responsibilities
'
&
$
%
u �?
u �?����ncrit1
����try1
����crit1-
turn:=2-
turn=1 ∨at ncrit2
' $?
u �?����ncrit2
����try2
����crit2-
turn:=1-
turn=2 ∨at ncrit1
' $?
Issues
– global vs. local views
– distribution of fairness
– meaningful use of hierarchy
33