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