A Formal (proved) Approach to Discrete System Development Modeling - - PowerPoint PPT Presentation

A Formal (proved) Approach to Discrete System Development Modeling

J-R. Abrial September 2004

Purpose of the Course

• Giving some insights about Formal Methods
• Showing that Formal Methods can be made practical
• Illustrating Formal Methods with examples

1

What you Will Learn

• By the end of the course you should be more comfortable with:
• Modeling (versus programming)
• Abstraction and Refinement
• Some mathematical techniques (for data structures)
• The idea of proving (what to prove)

2

The lectures

• 1st: Introduction by means of a small illustrating example
• 2nd: Introduction (cont’d) and another example
• 3rd: More complex examples

3

About the Examples

• All coming from the distributed programming area
• Other areas could have been chosen:
• Sequential programming
• Concurrent programming
• Electronic circuit development
• Complete systems (involving Software and Equipment)

4

Purpose of the First Lecture

• Learning about modeling
• Learning various conventions for modeling
• Learning some techniques for modeling
• Study a small example illustrating the introduced concepts

5

Formal Methods: a Great Confusion

• What are they used for?
• When are they to be used?
• Is UML a formal method?
• Are they needed when doing OO programming?
• What is their definition?

6

What About Other Engineering Disciplines

• Some mature engineering disciplines:
• Avionics,
• Space,
• Civil engineering,
• Mechanical engineering,
• Train systems,
• Ship building.
• Are there any equivalent approaches to Formal Methods?
• Yes, BLUE PRINTS

7

What is a Blue Print?

• A certain representation of the future system
• It is not a mock-up? (although mock-ups can be very useful too)
• The basis is lacking (you cannot “drive” the blue print of a car)
• Allows to reason about the future system during its design
• Is it important? (according to professionals) YES

8

Reasoning about the Future System?

• Defining and calculating its behavior (what it does)
• Incorporating constraints (what it must not do)
• Defining architecture
• Based on some underlying theories
• strength of materials,
• flight mechanics,
• gravitation,
• etc.

9

Techniques of “Blue Printing”

• Using pre-defined conventions (often computerized these days)
• Conventions should help facilitate reasoning
• Adding details on more accurate versions
• Postponing choices by having some open options
• Decomposing one blue print into several
• Reusing “old” blue prints (with slight changes)

10

What About BEFORE the Blue Print

• Define main objectives of future system
• Define requirements
• Study feasibility

11

What About AFTER the Blue Print

• Construct the system
• Perform functional tests
• Study how constraints are obeyed
• Organize maintenance

12

Definitions of Formal Methods (subjective)

• Formal methods are techniques for building and studying blue prints

ADAPTED TO OUR DISCIPLINE Our discipline is: design of hardware and software SYSTEMS

• Such blue prints are now called models
• Reminder:
• Models allow to reason about a FUTURE system
• The basis is lacking (hence you cannot “execute” a model)

13

Conventions for Model Writing and Reasoning

• Reminder (cont’d):
• Using pre-defined conventions
• Conventions should help facilitate reasoning (more to come)
• Consequence: Using ordinary discrete mathematical conventions:
• Classical Logic (Predicate Calculus)
• Basic Set Theory (sets, relations and functions)
• But drawings can be useful too (i.e. UML related conventions)

14

Examples of Systems we are Interested to Develop

• a “classical” piece of software
• an electronic circuit
• a file transfer protocol
• an airline booking system
• a PC operating system
• a nuclear plant controller
• a SmartCard electronic purse
• a launch vehicle flight controller
• a mechanical press controller
• etc.

15

Characterizing such Systems (general)

• They are made of many parts
• They interact with a possibly hostile environment
• They involve several executing agents
• They require a high degree of correctness
• There construction spreads over several years
• Their specifications are subjected to many changes

16

Characterizing such Systems (more technical)

• These systems operate in a discrete fashion
• Their dynamical behavior can be abstracted by:
• A succession of steady states
• Intermixed with sudden jumps
• The possibility of state changes is enormous
• Usually such systems never halt
• They are called discrete transition systems

17

What is our Unifying Underlying Theory?

• Theory of discrete automaton (more to come)
• Automatons are characterized by:
• a state
• a number of transitions
• We want to study whether:
• certain properties are maintained
• certain goals can be achieved

18

Defining Automatons: State and Events

• We start from a number of given sets
• We define some constants in terms of these sets
• We define some variables in terms of these sets and constants
• We define some transitions on the variables (now called events)

19

An Example: File Transfer Protocol

• A file is to be transfered from a Sender to a Receiver
• On the Sender’s side the file is called f
• On the Receiver’s side the file is called g
• At the beginning of the protocol, g is supposed to be empty
• At the end of the protocol, g should be equal to f
• Studied in many places, in particular in the following book:
• L. Lamport Specifying Systems: The TLA+ Language and Tools for

Hardware and Software Engineers Addison-Wesley 1999

20

The Sender and the Receiver

a b c a b c a b c

SENDER RECEIVER BEFORE AFTER channel channel

f g g f

21

File transfer. The constant part of the state: n and f

a b c f n 1 . . .

22

File transfer. The variables of the state: r and g

a b c f g r n

23

File transfer. The transition: receive

a b c c b a f f a g g r r n n

24

File transfer. The transition: receive

a b c c c b b a a f f f r b a a g g g r r n n n

25

File transfer. The transition: receive

c b a f r b a g n a b c c b a f f a g g r r n n c b a f b a c g r n+1

26

File Transfer Protocol State (1)

• Set: D
• Constants: n, f

prp 1 : n ∈ N prp 2 : f ∈ 1 .. n → D

• Constants are characterized by their properties

27

Conventions

∈ set membership operator

N

set of Natural Numbers: {0, 1, 2, 3, . . .} a .. b interval from a to b: {a, a + 1, . . . , b} S → T set of total functions from S to T

28

File Transfer Protocol State (2)

• Variables: r, g

inv 1 : r ∈ N inv 2 : g ∈ 1 .. n → D

• Variables are characterized by, so called, invariants
• Conventions

S → T set of partial functions from S to T

29

Events

• An event is made of two parts: the guard and the action
• The guard explains when the event can occur
• It is made of several conditions
• The action explains how the variables are modified
• It is made of several simple assignments
• Convention

when < guard > then < action > end

30

File Transfer Protocol Event: receive

• An event is a transition which we can observe

receive

• =

when r ≤ n then g := g ∪ {r → f(r)} r := r + 1 end

• The guard is made of one condition:

r ≤ n

• The action is made of two assignments:

  

g := g ∪ {r → f(r)} r := r + 1

31

Conventions

∪ set-theoretic union operator → pair constructing operator {. . .} set defined in extension

32

Initialization

• There exists a special initializing event

init

• =

begin g := ∅ r := 1 end

• Conventions

∅

empty set

33

Summary of the File Transfer Protocol Model

Set: D Constants: n, f Variables: r, g

prp 1 :

n ∈ N

prp 2 :

f ∈ 1 .. n → D

inv 1 :

r ∈ N

inv 2 :

g ∈ 1 .. n → D

init

• =

begin g := ∅ r := 1 end

receive

• =

when r ≤ n then g := g ∪ {r → f(r)} r := r + 1 end

34

Structure of a Model

• List of Sets (identifiers)
• List of Constants (identifiers)
• List of Properties (predicates built on sets and constants)
• List of Variables (identifiers)
• List of Invariants (predicates built on sets, constants, and variables)
• List of Events (next slide)

35

Shape of an Event

< name >

• =

when < guard > . . . then < variable > := < expression > . . . end

• < guards > are predicates built on sets, constants, and variables
• < expressions > are terms built on sets, constants, and variables

36

Something we would like to Prove

c b a f r b a g n a b c c b a f f a g g r r n n c b a f b a c g r n+1

When r = n + 1 then the protocol is finished: g = f

37

Reasoning: Theorems

thm 1 : r = n + 1 ⇒ g = f

• Theorems should be logically deduced from invariants
• But we cannot prove thm 1 from our properties and invariants

prp 1 : n ∈ N prp 2 : f ∈ 1 .. n → D inv 1 : r ∈ N inv 2 : g ∈ 1 .. n → D

38

Reasoning: Invariants

• We add the following two invariants (more to come here):

inv 3 : r ∈ 1 .. n + 1 inv 4 : g = (1 .. r − 1) ✁ f

• Conventions

✁ domain restriction operator

39

Observing Invariants

a b c c c c b b a a b a f f f f r g c b a b a a g g g r r r n n n n 1 n+1

inv 3 :

r ∈ 1 .. n + 1

inv 4 :

g = (1 .. r − 1) ✁ f

40

Proving Theorem

• Our theorem is then easy to prove

prp 1 : n ∈ N prp 2 : f ∈ 1 .. n → D inv 3 : r ∈ 1 .. n + 1 inv 4 : g = (1 .. r − 1) ✁ f thm 1 : r = n + 1 ⇒ g = f

41

Another Summary of the Protocol Model

Set: D Constants: n, f Variables: r, g

prp 1 :

n ∈ N

prp 2 :

f ∈ 1 .. n → D

inv 3 :

r ∈ 1 .. n + 1

inv 4 :

g = 1 .. r − 1 ✁ f

init

• =

begin g := ∅ r := 1 end

receive

• =

when r ≤ n then g := g ∪ {r → f(r)} r := r + 1 end

42

More Modeling Conventions

• The assignment:

g := g ∪ {r → f(r)}

• can be re-written

g(r) := f(r)

• Because r is not in the domain of g (more to come) since we have

inv 4 :

g = 1 .. r − 1 ✁ f

43

A Better Summary of the Protocol Model

Set: D Constants: n, f Variables: r, g

prp 1 :

n ∈ N

prp 2 :

f ∈ 1 .. n → D

inv 3 :

r ∈ 1 .. n + 1

inv 4 :

g = 1 .. r − 1 ✁ f

init

• =

begin g := ∅ r := 1 end

receive

• =

when r ≤ n then g(r) := f(r) r := r + 1 end

44

What is to be Proved

• Our task is not finished
• So far we have just observed that the invariants are maintained
• Observing is not enough
• We want to make precise what we have to prove

45

Transforming Assignments: Before-After Predicates

• Assignments are substitutions
• We shall transform them into before-after predicates
• Given constants c, variables v, and an assignment of the form

v := E(c, v)

• It can be mechanically transformed (by a tool) into the predicate

v′ = E(c, v)

46

Example: Event receive

These two forms of event receive are equivalent (more to come)

receive

• =

when r ≤ n then g(r) := f(r) r := r + 1 end

receive

• =

when r ≤ n then g′ = g ∪ {r → f(r)} r′ = r + 1 end

• We shall use the left form when writing models
• We shall use the right form when proving them

47

Invariant Preservation Statement

• Given constants c, properties P(c), variables v, and invariant I(c, v)
• Given an event of the form

when G(c, v) then v′ = E(c, v) end

• We have to prove

P(c) I(c, v) G(c, v) v′ = E(c, v) ⇒ I(c, v′)

48

Simplification

P(c) I(c, v) G(c, v) v′ = E(c, v) ⇒ I(c, v′) which simplifies to P(c) I(c, v) G(c, v) ⇒ I(c, E(c, v))

• This statement can be generated by a tool

49

Statement to be proved

prp 1 :

n ∈ N

prp 2 :

f ∈ 1 .. n → D

inv 3 :

r ∈ 1 .. n + 1

inv 4 :

g = 1 .. r − 1 ✁ f

receive

• =

when r ≤ n then g′ = g ∪ {r → f(r)} r′ = r + 1 end n ∈ N f ∈ 1 .. n → D r ∈ 1 .. n + 1 g = 1 .. r − 1 ✁ f r ≤ n ⇒ g ∪ {r → f(r)} = 1 .. r + 1 − 1 ✁ f r + 1 ∈ 1 .. n + 1

50

Semi-formal Proof

n ∈ N f ∈ 1 .. n → D r ∈ 1 .. n + 1 r ≤ n g = 1 .. r − 1 ✁ f ⇒ g ∪ {r → f(r)} = 1 .. r + 1 − 1 ✁ f r + 1 ∈ 1 .. n + 1 n ∈ N f ∈ 1 .. n → D r ∈ 1 .. n ⇒ 1 .. r − 1 ✁ f ∪ {r → f(r)} = 1 .. r ✁ f r + 1 ∈ 1 .. n + 1

51

Invariant Establishment Statement

• Given constants c, properties P(c), variables v, and invariant I(c, v)
• Given an initialization of the form

begin v′ = E(c) end

• We have to prove

P(c) v′ = E(c) ⇒ I(c, v′) which simplifies to P(c) ⇒ I(c, E(c))

52

Statement to be proved

prp 1 :

n ∈ N

prp 2 :

f ∈ 1 .. n → D

inv 3 :

r ∈ 1 .. n + 1

inv 4 :

g = 1 .. r − 1 ✁ f

init

• =

begin g′ = ∅ r′ = 1 end n ∈ N f ∈ 1 .. n → D ⇒

∅ = 1 .. 1 − 1 ✁ f

1 ∈ 1 .. n + 1

53

This Model of the “Protocol” is not Satisfactory

Set: D Constants: n, f Variables: r, g

prp 1 :

n ∈ N

prp 2 :

f ∈ 1 .. n → D

inv 3 :

r ∈ 1 .. n + 1

inv 4 :

g = 1 .. r − 1 ✁ f

init

• =

begin g := ∅ r := 1 end

receive

• =

when r ≤ n then g(r) := f(r) r := r + 1 end The Receiver accesses the original file We want to distribute the file transfer

54

Techniques of “Blue Printing” (Reminder)

• Adding details on different more accurate versions
• Postponing choices by having some open options
• Decomposing one blue print into several
• Reusing “old” blue prints (with slight changes)

55

A More Accurate Version (1)

a b c a b c

SENDER RECEIVER

a s r r

SENDER RECEIVER

s a s r send receive

56

A More Accurate Version (2)

a b c a b c

SENDER RECEIVER

a s r

SENDER RECEIVER

s receive a r s b r send

57

Initial Situation

a b c f d r g n s

58

Send

a b c c b a f f s n d d a r g g r n s

59

Receive

a b c c c b b a a f f f s n s n d d d a a g r r a g g r n s

60

Send

a b c c c b b a a f f f s n s n d d d a a g r r a f a b c s n d b g a r g g r n s

61

Receive

a b c c b a f f d d g g b a r a b b r n s n s

62

Send

a b c c c b b a a f f f n d d d c g a g g b a r a b b r n s r b s n s

63

Receive

a b c c c b b a a f f f n d d d c g a f a b c d g a g g b a r a b b r n s r b n s b c r c s n s

64

First Refinement of the Protocol Model

Set: D Constants: n, f, e Variables: r, g, s, d prp 3 : e ∈ D inv 5 : d ∈ D inv 6 : s ∈ 1 .. n + 1

init

• =

begin g := ∅ r := 1 s := 1 d := e end

send

• =

when s = r s ≤ n then d := f(s) s := s + 1 end

receive

• =

when s = r then g(r) := d r := r + 1 end

65

Refinement

• We have added a constant e
• We have added two new variables s and d
• We have modified the events receive and init
• We have added a new event send
• Note that the assignments in send and receive are not complete

66

Analysis of Refinement

• Refining an abstract event
• The problem of event completion
• The problem of distinct abstract and refined spaces
• “Refining” a new event
• Refining initialization
• Additional requirement for refinement

67

Refinement: the Situation

• We have constants c
• We have an abstract state with variables v
• We have a refined state with variables w DISTINCT from v
• We have an abstract event and a refined event of the forms

when G(c, v) then v′ = E(c, v) end when H(c, w) then w′ = F(c, w) end

• WHAT IS TO BE PROVED?

68

Refinement: the Situation (cont’d)

• We have some properties P(c) on the constants c
• We have some invariants I(c, v) on the abstract variables v
• We also have some gluing invariants J(c, v, w) linking

concrete variables w to abstract variables v

69

State and Event Refinement

v v’=E(c,v) w’=F(c,w) H(c,w) w Abstract Event Concrete Event I(v’) I(v) G(c,v) J(c,v’,w’) J(c,v,w)

70

Correct Refinement Proof

• One has to prove (more in next lecture):

P(c) I(c, v) J(c, v, w) H(c, w) w′ = F(c, w) v′ = E(c, v) ⇒ G(c, v) J(c, v′, w′) which simplifies to P(c) I(c, v) J(c, v, w) H(c, w) ⇒ G(c, v) J(c, E(c, v), F(c, w))

• This statement can be generated by a tool

71

More on Before-After Predicates: Completion

• Given constants c, and distinct variables x and y, the assignment

x := E(c, x, y)

• can be transformed into the before-after predicate

x′ = E(c, x) y′ = y

• Variables x and y are the only variables of our model
• This completion can be done mechanically by a tool

72

Completion Example: Refined Event receive

These two forms of event receive are equivalent

receive

• =

when r ≤ n then g(r) := d r := r + 1 end

receive

• =

when r ≤ n then g′ = g ∪ {r → d} r′ = r + 1 s′ = s d′ = d end

• Notice the difference between the two

73

Completion Example: New Event send

These two forms of event send are equivalent

send

• =

when s = r s ≤ n then d := f(s) s := s + 1 end

send

• =

when s = r s ≤ n then g′ = g r′ = r d′ = f(s) s′ = s + 1 end

• Notice the difference between the two

74

Abstract and Concrete Events receive

(abstract )receive

• =

when r ≤ n then g(r) := f(r) r := r + 1 end (refined )receive

• =

when s = r then g(r) := d r := r + 1 end

• These events deal with the same variables g and r
• This cannot be the case
• Abstract and concrete states must have distinct variables
• Solution: change of variables and adding a trivial gluing invariant
• This can be done by a tool

75

First Refinement (Transformations made by a tool)

prp 3 : e ∈ D inv 5 : d ∈ D inv 6 : s ∈ 1 .. n + 1 inv 7 : r1 = r inv 8 : g1 = g

init

• =

begin g1 := ∅ r1 := 1 s := 1 d := e end

send

• =

when s = r1 s ≤ n then d := f(s) s := s + 1 end

receive

• =

when s = r1 then g1(r1) := d r1 := r1 + 1 end

76

To be proved for Refinement of Event receive (1)

(abstract )receive

• =

when r ≤ n then g′ = g ∪ {r → f(r)} r′ = r + 1 end (refined )receive

• =

when s = r1 then g′

1 = g1 ∪ {r → d}

r′

1 = r1 + 1

s′ = s d′ = d end inv 6 : s ∈ 1 .. n + 1 inv 7 : r1 = r inv 8 : g1 = g

77

To be proved for Refinement of Event receive (2)

P(c) I(c, v) J(c, v, w) H(c, w) w′ = F(c, w) v′ = E(c, v) ⇒ G(c, v) J(c, v′, w′) s ∈ 1 .. n + 1 r1 = r g1 = g s = r1 g′

1 = g1 ∪ {r → d}

r′

1 = r1 + 1

g′ = g ∪ {r → f(r)} r′ = r + 1 s′ = s d′ = d ⇒ r ≤ n r′

1 = r′

g′

1 = g′

78

Informal Proof: Applying Equalities

s ∈ 1 .. n + 1 r1 = r g1 = g s = r1 g′

1 = g1 ∪ {r → d}

r′

1 = r1 + 1

g′ = g ∪ {r → f(r)} r′ = r + 1 s′ = s d′ = d ⇒ r ≤ n r′

1 = r′

g′

1 = g′

s ∈ 1 .. n + 1 s = r ⇒ r ≤ n r + 1 = r + 1 g ∪ {r → d} = g ∪ {r → f(r)}

79

What remains to be proved

s ∈ 1 .. n + 1 s = r ⇒ r ≤ n r + 1 = r + 1 g ∪ {r → d} = g ∪ {r → f(r)} s ∈ 1 .. n + 1 s = r ⇒ r ≤ n d = f(r) This cannot be proved. But the following invariants are suggested inv 9 : s ∈ r .. r + 1 inv 10 : s = r ⇒ d = f(r)

80

Observing the invariant s ∈ r .. r + 1

a b c c c b b a a f f f n d d d c g a f a b c d g a g g b a r a b b r b n s b c r c n s s r (3) (3) (4) s (3)

81

Observing the invariant s = r ⇒ d = f(r)

a b c c c b b a a f f f n d d c g a f a b c d g a g g b a r a b b r n s r b n s b c r c s n s (4) (3) d=f(3)

82

But the New Invariants Have to be Proved

• After applying equalities again, we obtain

s ∈ 1 .. n + 1 s ∈ r .. r + 1 s = r ⇒ d = f(r) s = r ⇒ r ≤ n s ∈ r + 1 .. r + 1 + 1 s = r + 1 ⇒ d = f(r + 1) d = f(r) s ∈ 1 .. n + 1 d = f(r) s = r + 1 ⇒ r ≤ n s ∈ r + 1 .. r + 2 s = r + 1 ⇒ d = f(r + 1) d = f(r)

83

The Final Step

s ∈ 1 .. n + 1 d = f(r) s = r + 1 ⇒ r ≤ n s ∈ r + 1 .. r + 2 s = r + 1 ⇒ d = f(r + 1) d = f(r) r + 1 ∈ 1 .. n + 1 ⇒ r ≤ n r + 1 ∈ r + 1 .. r + 2 All this can be done by a tool

84

Adding New Events in a Refinement

• Each new event must (in general) refine skip
• New events must not take control for ever
• For this, they all decrease a variant V (c, w)
• For a new event of the form

when S(c, w) then w′ = K(c, w) end One has to prove P(c) I(c, v) J(c, v, w) S(c, w) w′ = K(c, w) ⇒ J(v, w′) 0 ≤ V (c, w′) V (c, w′) < V (c, w)

85

To be proved for Refinement of Event send

send

• =

when s = r1 s ≤ n then d′ = f(s) s′ = s + 1 r′

1 = r1

g′

1 = g1

end The variant V is n + 1 − s s ∈ 1 .. n + 1 s ∈ r1 .. r1 + 1 s = r1 ⇒ d = f(r1) r1 = r g1 = g s = r1 s ≤ n d′ = f(s) s′ = s + 1 r′

1 = r1

g′

1 = g1

⇒ s′ ∈ 1 .. n + 1 s′ ∈ r′

1 .. r′ 1 + 1

s′ = r′

1

⇒ d′ = f(r′

1)

0 ≤ n + 1 − s′ n + 1 − s′ < n + 1 − s

86

Informal Proof: Applying Equalities

s ∈ 1 .. n + 1 s ∈ r1 .. r1 + 1 s = r1 ⇒ d = f(r1) r1 = r g1 = g s = r1 s ≤ n d′ = f(s) s′ = s + 1 r′

1 = r1

g′

1 = g1

⇒ s′ ∈ 1 .. n + 1 s′ ∈ r′

1 .. r′ 1 + 1

s′ = r′

1

⇒ d′ = f(r′

1)

0 ≤ n + 1 − s′ n + 1 − s′ < n + 1 − s r ∈ 1 .. n + 1 r ∈ r .. r + 1 r = r ⇒ d = f(r) r ≤ n ⇒ r + 1 ∈ 1 .. n + 1 r + 1 ∈ r .. r + 1 r + 1 = r ⇒ f(r) = f(r) 0 ≤ n + 1 − (r + 1) n + 1 − (r + 1) < n + 1 − r

87

Informal Proof: Applying Simple Reasoning

r ∈ 1 .. n + 1 r ∈ r .. r + 1 r = r ⇒ d = f(r) r ≤ n ⇒ r + 1 ∈ 1 .. n + 1 r + 1 ∈ r .. r + 1 r + 1 = r ⇒ f(r) = f(r) 0 ≤ n + 1 − (r + 1) n + 1 − (r + 1) < n + 1 − r r ∈ 1 .. n r ≤ n ⇒ r + 1 ∈ 1 .. n + 1 f(r) = f(r) 0 ≤ n − r n − r < n − r + 1

• Such a proof could be made by a tool

88

Refinement of Initialization

• We have constants c and properties P(c)
• We have an abstract state with variables v
• We have a refined state with variables w DISTINCT from v
• We have a gluing invariant J(c, v, w)
• We have an abstract init and a refined init of the forms

begin v′ = E(c) end begin w′ = F(c) end To prove P(c) v′ = E(c) w′ = F(c) ⇒ J(c, v′, w′)

89

To bo Proved for init

init

• =

begin g′ = ∅ r′ = 1 end

init

• =

begin g′

1 = ∅

r′

1 = 1

s′ = 1 d′ = e end e ∈ D g′ = ∅ r′ = 1 g′

1 = ∅

r′

1 = 1

s′ = 1 d′ = e ⇒ d′ ∈ D s′ ∈ 1 .. n + 1 s′ ∈ r′ .. r′ + 1 s′ = r′ ⇒ d′ = f(r′) r′ = r′

1

g′ = g′

1

90

Informal Proof: Applying Equalities

e ∈ D g′ = ∅ r′ = 1 g′

1 = ∅

r′

1 = 1

s′ = 1 d′ = e ⇒ d′ ∈ D s′ ∈ 1 .. n + 1 s′ ∈ r′ .. r′ + 1 s′ = r′ ⇒ d′ = f(r′) r′ = r′

1

g′ = g′

1

e ∈ D ⇒ e ∈ D 1 ∈ 1 .. n + 1 1 ∈ 1 .. 1 + 1 1 = 1 ⇒ e = f(1) 1 = 1

∅ = ∅

Such a proof could be made by a tool

91

Additional Requirement for Refinement

• A system stops when all the guards of its events are false
• When a refinement stops, its abstraction must have stopped
• In other words: no early stop for the refinement
• We have thus to prove one of the following

all refined guards false ⇒ all abstract guards false some abstract guards true ⇒ some refined guards true

92

Additional Requirement to be proved

(abs )receive

• =

when r ≤ n then g(r) := f(r) r := r + 1 end (ref )receive

• =

when s = r then g(r) := d r := r + 1 end

send

• =

when s = r s ≤ n then d := f(s) s := s + 1 end To be proved r ≤ n ⇒ s = r ∨ (s = r ∧ s ≤ n) simplified to r ≤ n s = r ⇒ s ≤ n

93

Some Ideas for a Second Refinement?

Set: D Constants: n, f, e Variables: r, g, s, d prp 3 : e ∈ D inv 5 : d ∈ D inv 6 : s ∈ 1 .. n + 1 inv 9 : s ∈ r .. r + 1 inv 10 : s = r ⇒ d = f(r)

init

• =

begin g := ∅ r := 1 s := 1 d := e end

send

• =

when s = r s ≤ n then d := f(s) s := s + 1 end

receive

• =

when s = r then g(r) := d r := r + 1 end

94

Third Version (1)

a b c a b c

SENDER RECEIVER

a s r

SENDER RECEIVER

s r send receive parity(s) a parity(r)

95

Third Version (2)

a b c a b c

SENDER RECEIVER

a s

SENDER RECEIVER

receive a r s r send parity(r) b parity(s)

96

A Small Theory of Parities

prp 4 : pty ∈ N → {0, 1} prp 5 : pty(0) = 0 prp 6 : ∀ n · (n ∈ N ⇒ pty(n + 1) = 1 − pty(n)) thm 2 : ∀ x, y ·

            

x ∈ N y ∈ N x ∈ y .. y + 1 pty(x) = pty(y) ⇒ x = y

            

97

The 2nd Refinement. Adding two Variables p and q

inv 11 : p = pty(r) inv 12 : q = pty(s) Exercises:

• Determine the before-after pred.
• State the theorems to prove
• Prove them

init

• =

begin g := ∅ r := 1 s := 1 d := e p := 1 q := 1 end

send

• =

when q = p s ≤ n then d := f(s) s := s + 1 q := 1 − q end

receive

• =

when q = p then g(r) := d r := r + 1 p := 1 − p end

98

Adding an Initial Model

prp 1 :

n ∈ N

prp 2 :

f ∈ 1 .. n → D

inv 0 :

g ∈ N → D

init

• =

begin g :∈ N → D end

terminate

• =

begin g := f end This model is necessary to prove that the protocol terminates

99

First Refinement

inv 3 :

r ∈ 1 .. n + 1

inv 4 :

g = 1 .. r − 1 ✁ f

init

• =

begin g := ∅ r := 1 end

receive

• =

when r ≤ n then g := g ∪ {r → f(r)} r := r + 1 end

terminate

• =

when r = n + 1 then

skip

end

100

Second Refinement

init

• =

begin g, r, s := ∅, 1, 1 d :∈ D end

inv 5 :

s ∈ 1 .. n + 1

inv 6 :

s ∈ r .. r + 1

inv 7 :

s = r ⇒ d = f(r)

send

• =

when s = r s ≤ n then d := f(s) s := s + 1 end

receive

• =

when s = r then g := g ∪ {r → d} r := r + 1 end

terminate

• =

when r = n + 1 then

skip

end

101

Third Refinement

inv 10 :

p = pty(r)

inv 11 :

q = pty(s)

terminate

• =

when r = n + 1 then skip end

init

• =

begin g := ∅ r, s := 1, 1 p, q := 1, 1 d :∈ D end

send

• =

when q = p s ≤ n then d := f(s) s := s + 1 q := 1 − q end

receive

• =

when q = p then g := g ∪ {r → d} r := r + 1 p := 1 − p end

102

What we Have Learned

• Some mathematical conventions
• How to write a model (only a little more on next lecture)
• What kind of things we have to prove
• How the proof can help finding invariants
• Many things can be done by tools
• A small theory of parities

103

Reminder of Conventions for Modeling (1)

∈ set membership operator

N

set of Natural Numbers: {0, 1, 2, 3, . . .} a .. b interval from a to b: {a, a + 1, . . . , b} S → T set of total functions from S to T S → T set of partial functions from S to T

104

Reminder of Conventions for Modeling (2)

∪ set-theoretic union operator → pair constructing operator {. . .} set defined in extension

∅

empty set ✁ domain restriction operator

105

Structure of a Model

• List of Sets (identifiers)
• List of Constants (identifiers)
• List of Properties (predicates built on sets and constants)
• List of Variables (identifiers)
• List of Invariants (predicates built on sets, constants, and variables)
• List of Events (next slide)

106

Shape of an Event

< name >

• =

when < guard > . . . then < variable > := < expression > . . . end

• < guards > are predicates built on sets, constants, and variables
• < expressions > are terms built on sets, constants, and variables

107

A Small Theory of Parities

Constant: pty pty ∈ N → {0, 1} pty(0) = 0 ∀ n · (n ∈ N ⇒ pty(n + 1) = 1 − pty(n)) ∀ x, y ·

            

x ∈ N y ∈ N x ∈ y .. y + 1 pty(x) = pty(y) ⇒ x = y

            

108