1. Course: Software Engineering ©Alessandra RussoUnit 2: States and Operations, slide number 1 States and Operations This unit aims to:  Define: State schemas for formalising system’s states. ( models are possible states of a system ) Operation schemas for expressing change of states. ( models are possible instances of applying an operation )  Illustrate these using an example about computer memory. Aims and Objectives

2. Course: Software Engineering ©Alessandra RussoUnit 2: States and Operations, slide number 2 Simple Computer Memory Suppose a computer has 16-bit addressing. A 16-bit word can be used as either a pure number or the address of a memory location. N Define WORD = {n  N | 0  n < 2 16 }. Describe memory state by a function store: WORD  WORD. Except that - Assume mechanism for restricting access (e.g. avoiding segmentation errors):  to describe accessible memory, “store” must be a partial function (i.e. result might not be defined for all arguments).

3. Course: Software Engineering ©Alessandra RussoUnit 2: States and Operations, slide number 3 A state schema Write a schema whose models are memory states: finite partial functions from WORD to WORD: In any model, store is a set of pairs (location, contents). FIt’s necessarily finite (F for set of finite subsets). The axiom ensures that this table assigns at most one value to each location. Different memory states give different models of this schema. Store F store: F(WORD  WORD)  a:WORD.  x,y:WORD. ((a,x)  store  (a,y)  store  x=y)

4. Course: Software Engineering ©Alessandra RussoUnit 2: States and Operations, slide number 4 Initialising the Store Imagine getting new memory locations one at a time and being told where they are. Initialise with nothing allocated: store is empty. Two schemas to specify initialisation: InitialStore Store store = Ø Using schema inclusion InitialStore store: F(WORD  WORD)  a:WORD.  x,y:WORD. ((a,x)  store  (a,y)  store  x=y) store = Ø Written in full

5. Course: Software Engineering ©Alessandra RussoUnit 2: States and Operations, slide number 5 Models of InitialStore? InitialStore has at most one model: store can only be Ø. Exactly one? Must check store = Ø is consistent with the other axiom. It is! Good! Otherwise store could never get going.

6. Course: Software Engineering ©Alessandra RussoUnit 2: States and Operations, slide number 6 Allocating new memory +afterwards, store has a new entry (address, value); +“address” is returned as a result –we shan’t specify any particular new location to be used (we leave it to implementation to choose) +but it must be genuinely new (no entry for that address before) +the previously allocated store must be preserved unchanged –we shan’t specify any particular initial value at that address Note: The positive requirements (+) must be expressed in a specification schema. For the other points ( – : “we shan’t specify”) the schema will say nothing. Memory allocation is an operation.

7. Course: Software Engineering ©Alessandra RussoUnit 2: States and Operations, slide number 7 Change of state  The operation changes store: –need “before” and “after” versions of store. –decorate it with a prime “ ' ” for value after. –cf. first year Reasoning: decorated symbols with subscript “ 0 ” for values before.  This is the standard convention in Z.  Other decoration conventions: –!denotes symbol is for an output value (e.g. “address!”) –?denotes symbol is for an input value (examples later)

8. Course: Software Engineering ©Alessandra RussoUnit 2: States and Operations, slide number 8 Schema Inclusion. “Undecorated” for state before. “!” shows output result new location is genuinely new new store is old store, unchanged, + new location “Decorated” inclusion. “ ' ” for state after. Allocate Store Store ' address!:WORD ¬  x:WORD. (address!,x)  store  y:WORD. store ' = store  {(address!,y)}

9. Course: Software Engineering ©Alessandra RussoUnit 2: States and Operations, slide number 9 Decorated inclusion  Store is included twice in Allocate: once undecorated (“Store”) and once decorated with ' (“Store'”). – other decorations are possible  If you expand a decorated included schema like “Store'”, then all its symbols take the same decoration.

10. Course: Software Engineering ©Alessandra RussoUnit 2: States and Operations, slide number 10 Allocate expanded Allocate Store Store' address!:WORD ¬  x:WORD. (address!,x)  store  y:WORD. store' = store  {(address!,y)} Allocate F store: F(WORD  WORD) F store': F(WORD  WORD) address!:WORD  a:WORD.  x,y:WORD. ((a,x)  store  (a,y)  store  x=y)  a:WORD.  x,y:WORD. ((a,x)  store'  (a,y)  store'  x=y) ¬  x:WORD. (address!,x)  store  y:WORD. store' = store  {(address!,y)} It was better unexpanded!

11. Course: Software Engineering ©Alessandra RussoUnit 2: States and Operations, slide number 11 Exercises How would you rewrite Allocate schema to specify that new location is initialized to 0 ? How would you rewrite Allocate schema to take an initialisation value as input “init?” ?

12. Course: Software Engineering ©Alessandra RussoUnit 2: States and Operations, slide number 12 States and Operations  Store is a state schema. –Its models are the possible memory states.  Allocate is an operation schema. –It describes state before and state after and output. –Each model is a permissible combination of these three.  In general, for an operation schema the different models are – –the different possible applications of the operation –the different possible combinations of state before, inputs, state after and outputs.

13. Course: Software Engineering ©Alessandra RussoUnit 2: States and Operations, slide number 13  – change of state  S S S' If S is a state schema, then a new schema  S is defined like this. It includes two copies of all the symbols and axioms of S, - one undecorated and one with “ ' ” Hence can rewrite Allocate: Allocate  Store address!:WORD ¬  x:WORD. (address!,x)  store  y:WORD. store' = store  {(address!,y)} Change of state is so common that it has special notation for “two copies” of schema, undecorated for state before, primed for state after.

14. Course: Software Engineering ©Alessandra RussoUnit 2: States and Operations, slide number 14  – state remains unchanged  S  S equations between corresponding symbols of S and S' Beware!  Don’t use  in state schemas –a state schema is about just one state, so the possibility of change doesn’t arise   is used in operation schemas, to require the operation not to change something –state after is unchanged from state before Also use  (Greek Xi, looks like big  ) to show states before and after are the same:

15. Course: Software Engineering ©Alessandra RussoUnit 2: States and Operations, slide number 15 More examples What happens if address? is not accessible in store? At present, no combination of state after and outputs can cope with this input. Look at two solutions: non-defensive and defensive. Lookup  Store address?, value!: WORD (address?, value!)  store Assign  Store address?, value?: WORD  x:WORD. ((address?,x)  store  store' = store – {(address?,x)}  {(address?,value?)}) Note “?” for inputs to operations.

16. Course: Software Engineering ©Alessandra RussoUnit 2: States and Operations, slide number 16 Preconditions (non-defensive)  The specification has failed to deal with bad inputs (address? inaccessible).  Perhaps preconditions can indicate the failure is deliberate – the specification refuses to deal with bad inputs.  At least for good inputs, the operation schema should be total (satisfactory outputs specified for every good input) Lookup  Store address?, value!: WORD pre:  x:WORD. (address?, x)  store (address?, value!)  store Says address? is currently accessible

17. Course: Software Engineering ©Alessandra RussoUnit 2: States and Operations, slide number 17 But... But this precondition adds nothing! –It’s already implied by the post-condition. –Logically, the new Lookup says exactly the same as the old one. –So what’s the point?  We’d like Lookup to be total - for every permissible entry configuration (state before + input) there’s a satisfactory exit configuration (state after + output) –precondition helps define “permissible” entry configurations.

18. Course: Software Engineering ©Alessandra RussoUnit 2: States and Operations, slide number 18 Lookup example We could describe entry configuration for Lookup using a schema: LookupEntry Store address?:WORD pre:  x:WORD. (address?, x)  store Imagine this being implicitly included in Lookup. Every model of LookupEntry is a reduct of a model of Lookup, (remove the parts of the structure that interpret Store' and value!) Pre-condition

19. Course: Software Engineering ©Alessandra RussoUnit 2: States and Operations, slide number 19 Totality of operations An operation is total iff for every possible entry configuration (state before + inputs) there is at least one permissible exit configuration (state after + outputs) for the operation. –having more than one allows implementation choice –having none at all (not total) doesn’t give implementers a chance.

20. Course: Software Engineering ©Alessandra RussoUnit 2: States and Operations, slide number 20 Lookup is total  Lookup is total provided precondition is made explicit –reduces range of entry configurations (i.e. models of LookupEntry) to consider Why is it total? Because if we are given (store, address?) as the entry configuration, then the precondition tells us there is some x with (address?,x) in store. We can use such an x as value!, and of course store' = store. These make up a model of Lookup.

21. Course: Software Engineering ©Alessandra RussoUnit 2: States and Operations, slide number 21 Entry configurations In practice, don’t consider schemas such as LookupEntry explicitly. But it’s implicit from the notational conventions used. It comprises – –state before (unprimed variables) –inputs (end in “?”) –preconditions (marked with “pre:”) Adding preconditions often makes no logical difference, –but it makes an implicit difference to the implementer’s job.

22. Course: Software Engineering ©Alessandra RussoUnit 2: States and Operations, slide number 22 Exception handling (defensive) Suppose there are checks to trap invalid addresses (for instance, hardware segmentation error). –Two kinds of operation instance: normal and exception. –Distinguish by a “report”, a special value that’s either “OK” or “address_error”. –Let REPORT be the set of possible report values: REPORT = {OK, address_error} –Might need more values later, e.g. “memory_full”.

23. Course: Software Engineering ©Alessandra RussoUnit 2: States and Operations, slide number 23 Specifying exception cases It’s convenient to specify the exception cases separately. Use a single schema to describe the address_error instances for all the operations: AddressError  Store address?:WORD report!:REPORT ¬  x:WORD. (address?,x)  store report! = address_error  because don’t want to mess up existing store Reason for error

24. Course: Software Engineering ©Alessandra RussoUnit 2: States and Operations, slide number 24 Normal operations The operation schemas given before were for normal operations. We modify them to include an OK report: LookupOK  Store address?, value!: WORD report!:REPORT (address?, value!)  store report! = OK AssignOK  Store address?, value?: WORD report!:REPORT  x:WORD. ((address?,x)  store  store' = store–{(address?,x)}  {(address?,value?)}) report! = OK NB: No pre-conditions with defensive specification!

25. Course: Software Engineering ©Alessandra RussoUnit 2: States and Operations, slide number 25 Schema disjunction  Now use schema disjunction: –Lookup = LookupOK  AddressError –Assign = AssignOK  AddressError Basic idea is simple: –Take two schemas –Merge their signatures (symbols that are in both signatures must be declared the same way) –Take the disjunction ( , “or”) of their axiom parts –If an axiom part has several axioms in it, consider them conjoined (and’ed together) first. General definition is not always straightforward. –You won’t need it, but it is discussed in the notes.

26. Course: Software Engineering ©Alessandra RussoUnit 2: States and Operations, slide number 26 e.g. Assign = AssignOK  AddressError  x:WORD.(address?,x)  store  store' = store–{(address?,x)}  {(address?,value?)})  report! = OK Assign  Store address?, value?: WORD report!:REPORT  store' = store  ¬  x:WORD. (address?,x)  store  report! = address_error This is what the schema disjunction means (but the disjunction notation above is much clearer) AssignOK  Store address?, value?: WORD report!:REPORT  x:WORD. ((address?,x)  store  store' = store–{(address?,x)}  {(address?,value?)}) report! = OK AddressError  Store address?:WORD report!:REPORT ¬  x:WORD. (address?,x)  store report! = address_error

27. Course: Software Engineering ©Alessandra RussoUnit 2: States and Operations, slide number 27 Summary For states: write schemas whose models are the possible states. For an operation: write operation schemas whose models are the possible combinations of state before, inputs, state after and outputs. »Schema inclusion. » “'” for state after. »  for two states (before and after) »  for two states but no change » Schema disjunction: good notation for exceptions