CSC264 Modelling and Computation 10. Modelling State Steve Riddle, John Fitzgerald, Maciej Koutny Computing Science Semester /06

10(2)CSC264 State-Based Modelling Limitations of functional style Persistent state State and Operation definitions Case study: Explosives Store revisited

10(3)CSC264 Limitations of functional style So far, the models we have looked at have used a high level of abstraction. Functionality has been largely modelled by explicit functions, e.g. Update: System * Input -> System Update(oldsys, val) == mk_System( … ) Few computing systems are implemented using only pure functions

10(4)CSC264 Persistent state More often, “real” systems have variables holding data, which may be modified by operations invoked by a user VDM-SL provides facilities for state-based modelling:  state definition  operations  auxiliary definitions (types, functions)

10(5)CSC264 Example: Alarm Clock An alarm clock keeps track of current time and allows user to set an alarm time The alarm could be represented as a record type: Time = nat Clock :: now : Time alarm: Time alarmOn: bool Instead, we will use a state-based model

10(6)CSC264 State definition State is defined with the following syntax: state Name of component-name : type … component-name : type inv optional-invariant init initial-state-definition end Definition introduces a new type ( Name ) treated as a record type, with state variables as fields

10(7)CSC264 State definition Variables which represent the state of the system are collected into a state definition This represents the persistent data, to be read or modified by operations state Clock of now : Time alarm : Time alarmOn : bool init cl == cl = mk_Clock(0,0,false) end A model has only one state definition Init clause sets initial values for persistent data

10(8)CSC264 Operations Procedures which can be invoked by the system’s users – human or other systems – are operations Operations (can) take input and generate output Operations have side effects – can read, and modify, state variables Operations may be implicit or explicit, just as with functions

10(9)CSC264 Explicit Operations An explicit operation has signature and body just like an explicit function, but the body need not return a value: e.g. alarm is set to a given time, which must be in the future: SetAlarm: Time ==> () SetAlarm(t) == (alarm :=t ; alarmOn := true) pre t > now Note features:  no return value (in this case)  sequence of assignments to state variables

10(10)CSC264 Implicit Operations Explicit operations produce a relatively concrete model Normally in state-based model, begin with implicit operations  better abstraction  not executable e.g. implicit version of SetAlarm operation: SetAlarm(t: Time) ext wr alarm: Time wr alarmOn: bool rd now: Time pre t > now post alarm = t and alarmOn

10(11)CSC264 Implicit operations Implicit operations have the following components: header with operation name, names and types of input and any result parameters externals clause lists the state components used by the operation, and whether they are read-only or may be modified by the operation pre-condition recording the conditions assumed to hold when the operation is applied post-condition relates state and result value after the operation is completed, to the initial state and input values. Post-condition must respect restrictions in the externals clause, and define “after” values of all writeable state components

10(12)CSC264 Implicit operation syntax OpName(param:type, param:type, …) result:type ext wr/rd state-variable:type wr/rd state-variable:type... wr/rd state-variable:type pre logical-expression post logical-expression Operation definition is a specification for a piece of code with input/output parameters and side effects on state components

10(13)CSC264 Alarm clock: modelling time We might also model the passing of time: Implicit operation: Tick() ext wr now: Time post now = now~ + 1 Explicit operation: Tick: () ==> () Tick() == now := now + 1;

10(14)CSC264 State-based modelling Development usually proceeds from abstract to concrete  identify state and persistent state variables  define implicit operations in terms of their access to state variables, pre and postconditions  complete definitions of types, functions noting any restrictions to be captured as invariants and preconditions, check internal consistency  transform implicit operations to explicit (and to code) by provably correct steps

10(15)CSC264 Case Study: Explosives Store revisited System is part of a controller for a robot that positions explosives in a store. The store is a rectangular building. Positions are represented as coordinates with respect to the origin. The store’s dimensions are represented as maximum x and y coordinates. Objects in the store are rectangular, aligned with the walls of the store. Each object has x and y dimensions. The position of an object is represented as the coordinates of its lower left corner. All objects must fit within the store and there must be no overlap between objects. y x

10(16)CSC264 Explosives Store Recall functionality: 1.Return number of objects in a store 2.Suggest a position where an object may be placed in a given store 3.Update the store to record placing of an object in a position 4.Update the store to record removal of all objects at a given set of positions

10(17)CSC264 Explosives Store: Pure Functional Model Types: Store :: contents : set of Object xbound : nat ybound : nat inv mk_Store = … Object :: position : Point xlength : nat ylength : nat Point :: x : nat y : nat Function signatures NumObjects: Store -> nat SuggestPos: nat * nat * Store -> Point Place: Object * Store * Point -> Store Remove: Store * set of Point -> Store

10(18)CSC264 Explosives Store: State definition The state is defined as: state Store of contents : set of Object xbound : nat ybound : nat inv mk_Store(contents, xbound, ybound) == (forall o in set contents & InBounds(o,xbound,ybound)) and not exists o1,o2 in set contents & o1 <> o2 and Overlap(o1,o2) init s == s = mk_Store({},50,50) end

10(19)CSC264 Explosives Store: Operations 1. Return the number of objects in a store  In functional model, we had a function with this signature: NumObjects: Store -> nat  In state based model we define an implicit operation which uses state component contents, returning a natural number result: NumObjects() r: nat ext rd contents : set of Object post r = card contents

10(20)CSC264 Place Operation 3. Update the store to record placing of an object in a position. Store is to be modified, therefore read and write access to state component is needed. Place(o: Object, p:Point) ext pre post … wr contents : set of Object rd xbound : nat rd ybound : nat RoomAt(o, contents, xbound, ybound, p)

10(21)CSC264 Place Operation: Postcondition After the operation, the store’s contents will be the same as the old contents, but with the new object added. Use “ ~ ” notation to refer to state component before the operation is applied. post let new_o = mk_Object(p,o.xlength, o.ylength) in contents = contents~ union {new_o}

10(22)CSC264 Review State-based models are used where we need to represent persistent data and operations with side-effects on state variables Appropriate if model’s purpose is to document design of a software system with global variables Operations are normally recorded implicitly, defining access to state variables (read-only or read-write), post-conditions and pre-conditions