CSC264

Modelling and Computation

10. Modelling State

Steve Riddle, John Fitzgerald, Maciej Koutny

Computing Science

Semester 2 2005/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 = natClock :: 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

…

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 operationsbetter abstractionnot 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 signaturesNumObjects: 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 Objectrd xbound : natrd 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