Lecture - modeling 5

Modelling Software-based Systems

Lecture 5: Modeling Systems (invoicing,access

control)

Dominique Méry ([email protected])

(Université de Lorraine)

February 25, 2013

NUI Maynooth, Ireland

Two case studies

• The Invoice System

• The Access Control System by J.-R. Abrial

1

The case study.

Introduction

1. The subject is to invoice order.

2. To invoice is to change the state of an order (to change it from the state "pending" to "invoiced").

3. On an order, we have one and one only reference to an ordered product of a certain quantity.The quantity can be different to other orders.

4. The same reference can be ordered on several different orders.

5. The state of the order will be changed into "invoiced" if the ordered quantity is either less orequal to the quantity which is in stock according to the reference of the ordered product.

2

The case study.

You have to consider the two following cases:

Case 1

All the ordered references are references in stock. The stock or the set of the orders may vary,

• due to the entry of new orders or cancelled orders

• due to having a new entry of quantities of products in stock at the warehouse.

But, we do not have to take these entries into account. This means that you will not receive twoentry flows (orders, entries in stock). The stock and the set of orders are always given to you in aup-to-date state .

Case 2

You do have to take into account the entries of :

• new orders

• cancellations of orders

• entries of quantities in the stock

End of case study text

3

The INVOICE system

MODELCase1

SETSALL ORDERS; PRODUCTS

PROPERTIESALL ORDERS 6= ∅

VARIABLESorders, stock, invoiced orders, reference, quantity

INVARIANTorders ⊆ ALL ORDERS ∧stock ∈ PRODUCTS −→ N ∧invoiced orders ⊆ orders ∧quantity ∈ orders −→ N∗ ∧reference ∈ orders −→ PRODUCTS

INITIALISATIONstock, invoiced orders, orders, quantity, reference := PRODUCTS× {0}, ∅, ∅, ∅, ∅

EVENTS............END

4

The INVOICE system

invoice order =any

owhere

o ∈ orders− invoiced orders ∧quantity(o) ≤ stock(reference(o))

theninvoiced orders := invoiced orders ∪ {o}||stock(reference(o)) := stock(reference(o))− quantity(o)

end;

5

The INVOICE system

cancel orders =begin

orders, quantity, reference : | (orders′ ⊆ ALL ORDERS ∧invoiced orders′ ⊆ orders′ ∧quantity′ ∈ orders′ −→ N∗ ∧reference′ ∈ orders′ −→ PRODUCTS)

end;new orders =

beginorders, quantity, reference : | (orders′ ⊆ ALL ORDERS ∧

invoiced orders′ ⊆ orders ∧quantity′ ∈ orders′ −→ N∗ ∧reference′ ∈ orders′ −→ PRODUCTS)

end;delivery to stock =

beginstock : | (stock′ ∈ PRODUCTS −→ N)

end

6

Proof obligations for a B model

Proof obligation

(INV1) Γ(s, c) ` Init(x) ⇒ I(x)

(INV2) Γ(s, c) ` I(x) ∧ BA(e)(x, x′) ⇒ I(x′)

(DEAD) Γ(s, c) ` I(x) ⇒ (grd(e1) ∨ . . . grd(en))

(SAFE) Γ(s, c) ` I(x) ⇒ A(x)

(FIS) Γ(s, c) ` I(x) ∧ grd (E) ⇒ ∃x′ · P (x, x′)

7

Proof obligations of the INVOICE system (INV1)

stockinvoiced ordersordersquantityreference

=

PRODUCTS× {0}∅∅∅∅

⇒

orders ⊆ ALL ORDERS ∧PRODUCTS× {0} ∈ PRODUCTS −→ N ∧∅ ⊆ ∅ ∧∅ ∈ orders −→ N∗ ∧∅ ∈ orders −→ PRODUCTS

8

Events

Event : E Before-After Predicate

begin x : |P (x, x′) end P (x, x′)

when G(x) then x : |P (x, x′) end G(x) ∧ P (x, x′)

any t where G(t, x) then x : |P (x, x′, t) end ∃ t· (G(t, x) ∧ P (x, x′, t) )

9


orders ⊆ ALL ORDERS ∧stock ∈ PRODUCTS −→ N ∧invoiced orders ⊆ orders ∧quantity ∈ orders −→ N∗ ∧reference ∈ orders −→ PRODUCTS

∧ invoice order

⇒orders′ ⊆ ALL ORDERS ∧stock′ ∈ PRODUCTS −→ N ∧invoiced orders′ ⊆ orders′ ∧quantity′ ∈ orders′ −→ N∗ ∧reference′ ∈ orders′ −→ PRODUCTS

10


invoice order =any

owhere

o ∈ orders− invoiced orders ∧quantity(o) ≤ stock(reference(o))

theninvoiced orders := invoiced orders ∪ {o}||stock(reference(o)) := stock(reference(o))− quantity(o)

end;

11


invoice order =

∃o.

o ∈ orders− invoiced orders ∧quantity(o) ≤ stock(reference(o))∧invoiced orders′ = invoiced orders ∪ {o}∧stock′(reference(o)) = stock(reference(o))− quantity(o)orders′ = orders ∧ reference′ = reference ∧ quantity′ = quantity

12



∧

∃o.


⇒

orders′ ⊆ ALL ORDERS ∧stock′ ∈ PRODUCTS −→ N ∧invoiced orders′ ⊆ orders′ ∧quantity′ ∈ orders′ −→ N∗ ∧reference′ ∈ orders′ −→ PRODUCTS

13



∧


⇒

orders′ ⊆ ALL ORDERS ∧stock′ ∈ PRODUCTS −→ N ∧invoiced orders′ ⊆ orders′ ∧quantity′ ∈ orders′ −→ N∗ ∧reference′ ∈ orders′ −→ PRODUCTS

14


orders ⊆ ALL ORDERS ∧stock ∈ PRODUCTS −→ N ∧invoiced orders ⊆ orders ∧quantity ∈ orders −→ N∗ ∧reference ∈ orders −→ PRODUCTSo ∈ orders− invoiced orders ∧quantity(o) ≤ stock(reference(o))∧invoiced orders′ = invoiced orders ∪ {o}∧stock′(reference(o)) = stock(reference(o))− quantity(o)

⇒

orders ⊆ ALL ORDERS ∧stock′ ∈ PRODUCTS −→ N ∧invoiced orders′ ⊆ orders ∧quantity ∈ orders −→ N∗ ∧reference ∈ orders −→ PRODUCTS

15


orders ⊆ ALL ORDERS ∧stock ∈ PRODUCTS −→ N ∧invoiced orders ⊆ orders ∧quantity ∈ orders −→ N∗ ∧reference ∈ orders −→ PRODUCTSo ∈ orders− invoiced orders ∧quantity(o) ≤ stock(reference(o))∧invoiced orders′ = invoiced orders ∪ {o}∧stock′(reference(o)) = stock(reference(o))− quantity(o)

⇒(

stock′ ∈ PRODUCTS −→ N ∧invoiced orders′ ⊆ orders ∧

)

16

Proof obligations of the INVOICE system (DEAD)


⇒

∃o.


TRUETRUETRUE

17

Guards of event

Event : E Guard: grd(E)

begin S end TRUE

when G(x) then T ; G(x)

any t where G(t, x) then T end ∃ t·G(t, x)

18

Proof obligations of the INVOICE system (FIS)


∧

∃ o.

(o ∈ orders− invoiced orders ∧quantity(o) ≤ stock(reference(o))∧

)

⇒

∃ orders′, stock′, invoiced orders′, reference′, quantity′.

orders′ ⊆ ALL ORDERS ∧stock′ ∈ PRODUCTS −→ N ∧invoiced orders′ ⊆ orders′ ∧quantity′ ∈ orders′ −→ N∗ ∧reference′ ∈ orders′ −→ PRODUCTSorders′ = orders ∧ reference′ = reference ∧ quantity′ = quantity

19

Refinement of Case1

modelCase2

refinesCase1

variablesorders, stock, invoiced orders, reference, quantity

initialisationstock, invoiced orders, orders, quantity, reference := PRODUCTS× {0}, ∅, ∅, ∅, ∅

eventscancel orders =

ANYo

WHEREo ∈ orders− invoiced orders

THENorders := orders− {o}||quantity := {o} −C quantity||reference := {o} −C reference

END;

20

Refinement of Case1

delivery to stock =ANY

p, nWHERE

p ∈ PRODUCTSn ∈ N

THENstock(p) := stock(p) + n

ENDEND

new orders =ANY

o, q, pWHERE

o ∈ ALL ORDERS− ordersq ∈ N∗p ∈ PRODUCTS

THENorders := orders ∪ {o}||quantity(o) := q||reference(o) := p

END;

21

A Case Study by J.-R. Abrial

- To control accesses into locations.

- People are assigned certain authorizations

- Each person is given a magnetic card

- Doors are “one way” turnstyles

- Each turnstyle is equipped with:

- a card reader

- two lights (one green, the other red)

22

Turnstyle

23

Access Protocol (after introducing card in reader)

- If access permitted

- green light turned on- turnstyle unblocked for 30 sec

- Passing, or 30 sec elapsed

- green light turned off- turnstyle blocked again

- If access refused

- red light turned on for 2 sec- turnstyle stays blocked

24

Goal of System Study

- Sharing between Control and Equipment

- For this: constructing a closed model

- Defining the physical environment

- Possible generalization of problem

- Studying safety questions

- Studying synchronisation questions

- Studying marginal behaviour

25

Basic System Properties

P1: The model concerns people and locations

P2: A person is authorized to be in some locations

P3: A person can only be in one location at a time

D1: Outside is a location where everybody can be

P4: A person is always in some location

P5: A person is always authorized to be in his location

26

Example

Sets

persons = { p1, p2, p3 }locations = { l1, l2, l3, l4 }

Authorizations

p1 l2, l4p2 l1, l3, l4p3 l2, l3, l4

Correct scenario

p1 l4p2 l4p3 l4

→p1 l2p2 l4p3 l4

→p1 l2p2 l1p3 l4

→p1 l4p2 l1p3 l4

→p1 l4p2 l1p3 l3

27

Model (1)

Basic sets : persons prs and locations loc (prop. P1)

Constant : authorizations aut (prop. P2)

aut is a binary relation between prs and loc

aut ∈ prs↔ loc

28

Model (2)

Constant: outside is a location where everybody is authorized to be

(decision D1)

outside ∈ loc

prs× {outside} ⊆ aut

29

Model (3)

Variable : situations sit (prop. P3 and P4)

sit is a total function between prs and loc

A total function is a special case of a binary relation

sit ∈ prs→ loc

Invariant: situations compatible with auth. (prop. P5)

The function sit is included in the relation aut

sit ⊆ aut

30

A magic event which can be observed

- GUARD:

- Given some person p and location l- p is authorized to be in l : p, l ∈ aut- p is not currently in l : sit(p) 6= l

- ACTION: - p jumps into l

pass =any p, l where

p ∈ prs ∧l ∈ loc ∧p 7→ l ∈ aut ∧sit(p) 6= l

thensit(p) := l

end

31

Relation overriding

Given two relations a and b

Overriding a by b yields a new relation a <+ b

a <+ b = (dom (b)−C a) ∪ b

Abbreviation

f(x) := y = f := f <+ {x 7→ y}

32

Invariant Preservation Proof

INVARIANT ∧ GUARD⇒ACTION establishes INVARIANT

sit ⊆ aut ∧p ∈ prs ∧l ∈ loc ∧p 7→ l ∈ aut⇒({p} −C sit) ∪ {p 7→ l} ⊆ aut

33

First Refinement: Introducing Geometry

P6: The geometry define how locations communicate

P7: A location does not communicate with itself

P8: Persons move between communicating locations

34

Refined Model

Constant: communication com (prop. P6 and P7)

com is a binary relation between loc

The intersection of com with the identity relation on loc is empty

com ∈ loc↔ loc

com ∩ id(loc) = ∅

35

Correct Refinement Verification (reminder)

Concrete events do not block more often than abstract ones

I(x) ∧ J(x, y) ∧disjunction of abstract guards⇒

disjunction of concrete guards

New events block eventually (decreasing the same quantity V (y))

I(x) ∧ J(x, y) ∧ H(y) ∧ V (y) = n⇒ V (F (y)) < n

36

Refined Event

Event (prop. P8)

The guard is strengthened

The current location of p and the new location l must communicate


p ∈ prs ∧l ∈ loc ∧p 7→ l ∈ aut ∧sit(p) 6= l

thensit(p) := l

end


p ∈ prs ∧l ∈ loc ∧p 7→ l ∈ aut ∧sit(p) 7→ l ∈ com

thensit(p) := l

end

37

Proofs

Invariant preservation: Success

Guard strengthening: Success

∃ (p, l) · ( p 7→ l ∈ aut ∧ sit(p) 7→ l ∈ com )⇒∃ (p, l) · ( p 7→ l ∈ aut ∧ sit(p) 6= l )

Deadlockfreeness: Failure

∃ (p, l) · ( p 7→ l ∈ aut ∧ sit(p) 6= l )⇒∃ (p, l) · ( p 7→ l ∈ aut ∧ sit(p) 7→ l ∈ com )

38

Safety Problem

P9: No person must remain blocked in a location.

Solution

P10: Any person authorized to be in a location must also be autho-

rized to go in another location which communicates with the first one.

aut ⊆ aut ; com−1

p 7→ l ∈ aut⇒ ∃m · ( p 7→ m ∈ aut ∧ l 7→ m ∈ com )

39

Example

p1 l2 p2 l4p1 l4 p3 l2p2 l1 p3 l3p2 l3 p3 l4

aut

l1 l3l1 l4l3 l2l4 l1l4 l2l4 l3

com

l1 l4l2 l3l2 l4l3 l1l3 l4l4 l1

com−1

p1 l1 p2 l4p1 l3 p3 l1p1 l4 p3 l3p2 l1 p3 l4

aut; com−1

- Opening a door between l2 and l4

- Authorizing p2 to go to l2

40

b4

b3

b1

b2p1 p3

p2 p3

p1 p2 p3p2

p2

41

Solution

p1 l2 p2 l4p1 l4 p3 l2p2 l1 p3 l3p2 l2 p3 l4p2 l3

aut

l1 l3l1 l4l2 l4l3 l2l4 l1l4 l2l4 l3

com

l1 l4l2 l3l2 l4l3 l1l3 l4l4 l1l4 l2

com−1

p1 l1 p2 l3p1 l2 p2 l4p1 l3 p3 l1p1 l4 p3 l2p2 l1 p3 l3p2 l2 p3 l4

aut; com−1

Decision

D2: The system that we are going to construct does not guarantee

that people can move “outside”.

42

A better solution (1)

Constante: exit is a function, included in com, with no cycle

exit ∈ loc− {outside} → loc

exit ⊆ com

∀s · ( s ⊆ loc⇒ (s ⊆ exit−1[s]⇒ s = ∅) )

∀x · (x ∈ s⇒ ∃y · ( y ∈ s ∧ (x, y) ∈ exit ) )⇒

s = ∅

exit is a tree spanning the graph represented by com

43

A better solution (2)

P10’: Every person authorized to be in a location (which is not “out-

side”) must also be authorized to be in another location communicat-

ing with the former and leading towards the exit.

aut−B {outside} ⊆ aut ; exit−1

p 7→ l ∈ aut ∧l 6= outside⇒

p 7→ exit(l) ∈ aut

44

For the experts

Show that no cycle implies the possibility to prove property by induc-

tion and vice-versa

∀s · ( s ⊆ loc ∧ s ⊆ exit−1[s]⇒ s = ∅ )⇔∀t · ( t ⊆ loc ∧ outside ∈ t ∧ exit−1[t] ⊆ t⇒ t = loc )

t ⊆ locoutside ∈ t∀ (x, y) · ( (x 7→ y) ∈ exit ∧ y ∈ t⇒ x ∈ t )⇒

t = loc

45

Second Refinement: Introducing Doors

P11: Locations communicate via one-way doors.

P12: A person get through a door only if accepted.

P13: A door is acceptable by at most one person at a time.

P14: A person is accepted for at most one door only.

P15: A person is accepted if at the origin of the door.

P16: A person is accepted if authorized at destination.

46

Extending the Model (1)

Set: the set dor of doors

Constants: The origin org and destination dst of a door (prop. P11)

org ∈ dor → locdst ∈ dor → loc

com = (org−1 ; dst)

47


Variable: the rel. dap between persons and doors (prop. P12 to P16)

dap ∈ prs 7� dor(dap ; org) ⊆ sit(dap ; dst) ⊆ aut

48

Second Refinement: More Properties

P17: Green light of a door is lit when access is accepted.

P18: When a person has got through, the door blocks.

P19: After 30 seconds, the door blocks automatically.

P20: Red light is lit for 2 sec.when access is refused.

P21: Red and green lights are not lit simultaneously.

49


Definition: grn is exactly the range of dap (prop. P17 to P19)

grn = ran (dap)

50


Variable: The set red of red doors (prop. P20)

red ⊆ dor

Invariant: grn and red are incompatible (prop. P21)

grn ∩ red =

51

Condition for Admission

P22: Person p is accepted through door d if

- p is situated within the origin of d

- p is authorized to move to the dest. of d

- p is not engaged with another door

admitted (p, d) =org(d) = sit(p) ∧p 7→ dst(d) ∈ aut ∧p /∈ dom (pad)

52

A New Event (1)

Accepting a person p - GUARD:

- Given some person p and door d- d is neither green nor red- p is admissible through d

- ACTION: - make p authorized to pass d

accept =any p, d where

p ∈ prs ∧d ∈ dor ∧d /∈ grn ∪ red ∧admitted (p, d)

thendap(p) := d

end

53

A New Event (2)

Refusing a person p

- GUARD:

- Given some person p and door d- d is neither green nor red- p is not admissible through d

- ACTION: - lit the red light

refuse =any p, d where

p ∈ prs ∧d ∈ dor ∧d /∈ grn ∪ red ∧¬ admitted (p, d)

thenred := red ∪ {d}

end

54

Refining Event pass


p ∈ prs ∧l ∈ loc ∧p, l ∈ aut ∧sit(p), l ∈ com

thensit(p) := l

end

pass =any d where

d ∈ grnthen

sit(dap−1(d)):= dst(d) ||

dap:= dap−B {d}

end

55

New Event (3)

Turning lights off

off grn =any d where

d ∈ grnthen

dap := dap−B {d}end

off red =any d where

d ∈ redthen

red := red− {d}end

56

Synchronization

accept refuse

↙ ↘ ↓

pass off grn off red

57

Proofs

- Event pass is a correct refinement: OK

- Other events refine skip: OK

- Event pass does not deadlock more: OK

- New events do not take control indefinitely: FAILURE

58

Permanent Obstruction of Card Readers

DANGER

- People without the required authorizations

try indefinitely to enter some locations.

- Other people with the authorization

always change mind at the last moment.

SOLUTIONS

- Make such practice impossible ???

- Card Readers can “swallow” a card

59

Final Decision

D3: The system we are going to construct will not prevent people

from blocking doors indefinitely:

- either by trying indefinitely to enter places into

which they are not authorized to enter,

- or by indefinitely abandoning “on the way” their

intention to enter the places in which they are

in fact authorized to enterl.

60

Third Refinement: Introducing Card Readers

A decision

D4: Each card reader is supposed to stay blocked

between:

- the sending of a card to the system

- the reception of an acknowledgement.

61

Third Refinement: Model Extension

The set BLR of blocked Card Readers

The set mCard of messages sent by Card Readers

The set mAckn of acknowledgment messages

BLR ⊆ dor

mCard ∈ dor 7→ prs

mAckn ⊆ dor

62

Third Refinement: Invariant

dom (mCard), grn, red, mAckn partition BLR

dom (mCard) ∪ grn ∪ red ∪ mAckn = BLR

dom (mCard) ∩ (grn ∪ red ∪ mAckn) = ∅

mAckn ∩ (grn ∪ red) = ∅

63

Events (1)

CARD =any p, d where

p ∈ prsd ∈ dor −BLR

thenBLR := BLR ∪ {d} ||mCard := mCard ∪ {d 7→ p}

end

64

Events (2)


p ∈ prs ∧d ∈ dor ∧d /∈ grn ∪ red ∧admitted (p, d)

thendap(p) := d

end


d, p ∈ mCard ∧admitted (p, d)

thendap(p) := d ||mCard := mCard−

{d 7→ p}end

65

Events (3)


d, p ∈ mCard ∧¬ admitted (p, d)

thenred := red ∪ {d} ||mCard := mCard− {d 7→ p}

end

66

Events (4)

pass =any d where

d ∈ grnthen

sit(dap−1(d)) := dst(d) ||dap := dap−B {d} ||mAckn := mAckn ∪ {d}

end

67

Events (5)


d ∈ grnthen

dap := dap−B {d} ||mAckn := mAckn ∪ {d}

end


d ∈ redthen

red := red− {d} ||mAckn := mAckn ∪ {d}

end

68

Events (6)

ACKN =any d where

d ∈ mAcknthen

BLR := BLR− {d} ||mAckn := mAckn− {d}

end

69

Synchronization

CARD

↙ ↘

accept refuse

↙ ↘ ↓

pass off grn off red

↘ ↓ ↙

ACKN

70

Fourth Refinement: Physical Doors and Lights

Decisions

D5: When a door has been cleared, it blocks itself automatically

without any intervention from the control system.

D6: Each door incorporates a local clock for

- the extinction of the green light after 30 sec.

- the extinction of the red light after 2 sec.

71

Extending the Model: the Green Chain (1)

The set mAccept of acceptance messages (to doors)

The set GRN of physical green doors

The set mPass of passing messages (from doors)

The set mOff grn of messages (from doors)

mAccept ⊆ dor

GRN ⊆ dor

mPass ⊆ dor

mOff grn ⊆ dor

72

Extending the Model: the Green Chain (2)

mAccept, GRN, mPass, mOff grn partition grn

mAccept ∪ GRN ∪ mPass ∪ mOff grn = grn

mAccept ∩ (GRN ∪ mPass ∪ mOff grn) = ∅

GRN ∩ (mPass ∪ mOff grn) = ∅

mPass ∩ mOff grn = ∅

73

Extending the Model: the Red Chain (1)

The set mRefuse of messages (to doors)

The set RED of phyical red doors

The set mOff red of messages (from doors)

mRefuse ⊆ dor

RED ⊆ dor

mOff red ⊆ dor

74

Extending the Model: the Red Chain (2)

mRefuse, RED, mOff red partition red

mRefuse ∪ RED ∪ mOff red = red

mRefuse ∩ (RED ∪ mOff red) = ∅

RED ∩ mOff red = ∅

75

Events (1)


d, p ∈ mCard ∧admitted (p, d)

thendap(p) := d ||mCard := mCard− {d 7→ p} ||mAccept := mAccept ∪ {d}

end

76

Events (2)

ACCEPT =any d where

d ∈ mAcceptthen

GRN := GRN ∪ {d} ||mAccept := mAccept− {d}

end

77

Events (3)

PASS =any d where

d ∈ GRNthen

GRN := GRN − {d} ||mPass := mPass ∪ {d}

end

78

Events (4)

pass =any d where

d ∈ mPassthen

sit(dap−1(d)) := dst(d) ||dap := dap−B {d} ||mAckn := mAckn ∪ {d}||mPass := mPass− {d}

end

79

Events (5)

OFF GRN =any d where

d ∈ GRNthen

GRN := GRN − {d} ||mOff grn := mOff grn ∪ {d}

end

80

Events (6)


d ∈ mOff grnthen

dap := dap−B {d} ||mAckn := mAckn ∪ {d}||mOff grn := mOff grn− {d}

end

81

Events (7)


d, p ∈ mCard ∧¬ admitted (p, d)

thenred := red ∪ {d} ||mCard := mCard− {d 7→ p} ||mRefuse := mRefuse ∪ {d}

end

82

Events (8)

REFUSE =any d where

d ∈ mRefusethen

RED := RED ∪ {d} ||mRefuse := mRefuse− {d}

end

83

Events (9)

OFF RED =any d where

d ∈ REDthen

RED := RED − {d} ||mOff red := mOff red ∪ {d}

end

84

Events (10)


d ∈ mOff redthen

red := red− {d} ||mAckn := mAckn ∪ {d} ||mOff red := mOff red− {d}

end

85

Synchronization

CARD↙ ↘

accept refuse↓ ↓

ACCEPT REFUSE↙ ↘ ↓

PASS OFF GRN OFF RED↓ ↓ ↓

pass off grn off red↘ ↓ ↙

ACKN

86

Communications

Hardware Network Software

CARD → mCard → accept (1)

refuse (2)

ACCEPT ← mAccept ← (1)

PASS → mPass → pass (3)

OFF GRN → mOff grn → off grn (3)

REFUSE ← mRefuse ← (2)

OFF RED → mOff red → off red (3)

ACKN ← mAckn ← (3)

87

Decomposition (1)

Software Data

aut ∈ prs↔ locorg ∈ dor → locdst ∈ dor → loc

aut ⊆ aut; dst−1; orgsit ∈ prs→ locdap ∈ prs 7� dorred ⊆ dor

88

Decomposition (2)

Network data

mCard ∈ dor 7→ prs

mAckn ⊆ dor

mAccept ⊆ dor

mPass ⊆ dor

mOff grn ⊆ dor

mRefuse ⊆ dor

mOff red ⊆ dor

89

Decomposition (3)

“Physical” Data

BLR ⊆ dor

GRN ⊆ dor

RED ⊆ dor

90

Software Operations

test soft(p, d)

accept soft(p, d)

refuse soft(d)

pass soft(d)

off grn soft(d)

off red soft(d)

91

Physical Operations

(p, d)←− CARD HARD

ACCEPT HARD(d)

REFUSE HARD(d)

d←− PASS HARD

d←− OFF GRN HARD

d←− OFF RED HARD

ACKN HARD(d)

92

Network Software Operations

(p, d)←− read card

write accept(d)

write refuse(d)

d←− read pass

d←− read off grn

d←− read off red

write ackn(d)

93

Network Physical Operations

SEND CARD(p, d)

d←− RCV ACCEPT

d←− RCV REFUSE

SEND PASS(d)

SEND OFF GRN(d)

SEND OFF RED(d)

d←− RCV ACKN

94

CARD =var p, d in

(p, d)←− READ HARD;SEND CARD(p, d)

end

accept refuse =var p, d, b in

(p, d)←− read card;b←− test soft(p, d);if b = true then accept soft(p, d);write accept(d) else refuse soft(d);write refuse(d) end

end

ACCEPT =var d in

d←− RCV ACCEPT;ACCEPT HARD(d)

end

REFUSE =var d in

d←− RCV REFUSE;REFUSE HARD(q)

end

95

PASS =var d in

d←− PASS HARD;SEND PASS(d)

end

OFF GRN =var d in

d←− OFF GRN HARD;SEND OFF GRN(d)

end

OFF RED =var d in

d←− OFF RED HARD;SEND OFF RED(d)

end

pass =var d in

d←− read pass;pass soft(d);write ackn(d)

end

off grn =var d in

d←− read off grn;off grn soft(d);write ackn(d)

end

off red =var d in

d←− read off red;off red soft(d);write ackn(d)

end

ACKN =var d in

d←− RCV ACKN;ACKN HARD(d)

end

Conclusion

22 Properties et 6 “System” Decisions - One Problem Generalization

- Access between locations

- One Negative Choice:

- Possible Card Readers Obstructions

- Three Physical Decisions

- Automatic Blocking of Doors

- Automatic Blocking of Card Readers

- Setting up of Clocks on Doors

- The overall development required 183 proofs

- 147 automatic (80%)

- 36 interactive

96

Lecture - modeling 5

Documents

Transcript of Lecture - modeling 5