; Frame-conditions
Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out
Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

Frame-conditions

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 }

pred addToPlaylist(s:Song, p:Playlist, t:Time) {
   // 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
     Events  instead of operations
     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 }
}
Advantages of Event-Based
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