CSC264 Modelling and Computation 10. Modelling State

1. CSC264Modelling and Computation10. Modelling State Steve Riddle, John Fitzgerald, Maciej Koutny Computing Science Semester 2 2005/06

2. State-Based Modelling • Limitations of functional style • Persistent state • State and Operation definitions • Case study: Explosives Store revisited

3. 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

4. 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)

5. 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

6. State definition • State is defined with the following syntax: • state Name of • component-name : type • 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

7. 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

8. 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

9. 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. 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

11. 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

12. 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

13. 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;

14. 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

15. 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

16. Explosives Store • Recall functionality: • Return number of objects in a store • Suggest a position where an object may be placed in a given store • Update the store to record placing of an object in a position • Update the store to record removal of all objects at a given set of positions

17. 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

18. 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

19. Explosives Store: Operations • 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

20. Place Operation • 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)

21. 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 beforethe operation is applied. • post let new_o = mk_Object(p,o.xlength, o.ylength) in contents = contents~ union {new_o}

22. 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