# Frame-conditions by xiagong0815

VIEWS: 3 PAGES: 13

• pg 1
```									Frame Conditions

Jan Bernhardt
Outline
 State transitions and conditions
 Example: IPod
 Example: Hotel room locking
 A different approach
 Conclusion
State Transitions and Conditions
   Pre condition
   Describes the states in which the operation can successfully
perform its intended function

   Post condition
   Describes the effects of the operation in generating the next
state

   Frame condition
   Describes what does not change between pre-state and post-
state of a transition
Example: IPod Playlists
open util/ordering[Time]

sig Time {}

sig Playlist {
songs: Time -> set Song }

// pre condition: song not in playlist
s not in p.songs[t] &&
let t’ = next(t) | {
// post condition: song added to playlist
p.songs[t’] = p.songs[t] + s
// frame condition: other playlists remain unchanged
all p’: Playlist – p | p’.songs[t’] = p’.songs[t] }
}
Example: Hotel Room Locking
   Hotel with disposable room keys and recodable locks

   Lock holds sequence of pseudo-random numbers
   Opened by current key combination, or its successor

   New key to next occupant
   Key recodes lock on first use, makes previous keys invalid

   Front desk uses same number generator, keeps records
of current combinations in step with locks
   No communication between front desk and locks after first
initialisation
Modelling State
   Add time atom in the last column of a relation to make it
time-dependent

   Order time atoms into traces
   Any pair of consecutive time instants is related by an operation
   State transitions are only possible through operations

   Key generator
   Single global ordering on keys with disjoint subsets for each lock

   sig Key {}
sig Time {}
open util/ordering[Time] as to
open util/ordering[Key] as ko
Rooms, Guests, and a Front Desk
   sig Room {
keys: set Key,
currentKey: keys one -> Time }

   sig Guest {
keys: Key -> Time }

   one sig FrontDesk {
lastKey: (Room -> lone Key) -> Time
occupant: (Room -> Guest) -> Time }
Entry Into a Room (1)
   Pre condition
   Key used to open the lock must be one of the keys held by the
guest

   Post condition
   Key either matches lock’s current key -> lock remains
unchanged
   Or matches its successor -> lock is advanced

   Frame conditions
   No changes to states of other rooms
   No changes to set of keys held by guests
   No changes to records at front desk
Entry Into a Room (2)
pred Entry(t,t’:Time, g:Guest, r:Room, k:Key) {
// pre: key is held by guest
k in g.keys.t
let ck = r.currentKey |
// post: key matches current key -> no change
(k = ck.t and ck.t’ = ck.t) or
// post: key matches successor -> advance key
(k = nextKey(ck.t, r.keys) and ck.t’ = k)
// frame: no room state changes
all r’:Room – r | r.currentKey.t’ = r.currentKey.t
// frame: no guest changes
all g’:Guest – g | g.keys.t’ = g.keys.t
// frame: no front desk changes
FrontDesk.lastKey.t’ = FrontDesk.lastKey.t
FrontDesk.occupant.t’ = FrontDesk.occupant.t }
Event-Based Approach
   No fixed idiom for modelling state machines in
Alloy

   Variation of the model for hotel room locking
 State space and transitions remain the same
 Constraints inside predicates become signature facts
 Arguments to operation predicates become fields of
event signatures
Entry Event
// events have pre- and post-states, and involve a guest
abstract sig Event {
pre, post: Time,
guest: Guest }

// events that involve a room and a key
abstract sig RoomKeyEvent extends Event {
room: Room,
key: Key }

sig Entry extends RoomKeyEvent {} {
// pre: key is held by guest
key in guest.keys.pre
let ck = room.currentKey |
// post: key matches current key -> no change
(key = ck.pre and ck.post = ck.pre) or
// post: key matches successor -> advance key
(key = nextKey(ck.pre, room.keys) and ck.post = key) }
Frame Conditions
fact Traces {
init(to/first())
all t:Time – to/last() | let t’ = to/next() |
some e:Event {
e.pre = t and e.post = t’
// frame: no room state changes except for Entries
currentKey.t = currentKey.t’ or e in Entry
// frame: no front desk changes except for Checks
occupant.t = occupant.t’ or e in Checkin + Checkout
// frame: no guest changes except for Checkins
(lastKey.t = lastKey.t’ and keys.t = keys.t’)
or e in Checkin }
}
Approach
   Making events concrete produces nicer visualisations
   Easier to tell which events are occurring in traces output by the
analyser

   Some properties can be written more succinctly and
directly

   Signature extension can be used to factor out common
properties of events

   Sometimes less cumbersome than “traditional” frame
conditions
   m state components, k operations
   Traditional: m-1 frame conditions, k x (m-1) equalities
   Otherwise: m equalities, one per operation

```
To top