1. Software Correctness Indexed Processes SWEN224 2017-T2.
David Streader
Engineering & Computer Science
Victoria University of Wellington

2. Review We have: Built sequential processes.
Composed processes in parallel
Synchronized events running in different processes
Made events private by
Hiding events
Removing hidden events
Simplifying processes
Labeled processes

3. Learning Objectives Understand how to:
Index Process states
Index Process events
How to build and model check small finite state approximations of infinite state systems.
Small world assumption: most real world errors can be detected in a small world
This assumption does not hold universally.

4. Revision Example:
We are going to build a two place buffer from two one place buffers. To be able to validate that the construction is correct requires you to decide what the behavior of a one and two place buffer is.
One place buffer
Two place buffer
Are the above acceptable arbiters of correctness

5. Labeling events
Given two simple one place Buffers that continually perform events in then out build a two place buffer.
We cannot use Buff||Buff as
both events would synchronise
First add label one to a Buffer with command one:Buff. This prepends one. to the start of each event name.
Second rename the one.out to move with
one:Buff/{move/one.out} giving:

6. Labeling events
Build a two place buffer Btwo by composing and hiding the move event in two renamed buffers .
(one:Buff/{move/one.out})||(two:Buff/{move/two.in})\{move}.
Abstracting and simplifying simp(abs(Btwo)) gives:
Is this a two place buffer?

7. Indexing Process State
To consider a class of processes.
For example an N place buffer.
const N = 4
automata {
Buff = B[0],
B[i:0..N] = (when i< N in -> B[i+1] |
when 0< i out ->B[i-1]). }
const N = 4 sets the value of variable N – hence automata size
B[i:0..N] = defines states 0 .. N
when <guard> event -> Process is a conditional event

8. Indexed Processes (state)
First we declare the index variable and bound its size
Our example consists of a loop of coin events. The number of states and events in the loop is controlled by the index.
C[i:1..N] are N processes where i has value 1,2,... N
Recurring style
<name> = Pin[1],
Pin[i:<rng>] = …
const N = 4
automata {
Money = C[1],
C[i:1..N] = (when(i<N) coin->C[i+1]
| when(i==N) coin->C[1]). }
2 lines
N states
C[1]
C[2]

9. Indexing events as well as state
So far we have indexed the state space of processes.
Indexes are like java variables they can be:
Initialised
Read
written
In addition we can pass values into events, but the input value can only be decided at run time.
in[v:0..N] allows the value v to be input on the in event.
out[v] outputs the value v when the out event is taken
Show example:

10. Indexed processes and events
We model a one place buffer that can hold values 2,3,4
The indexed in event are implicitly composed by choice.
Buffer = (in[i:2..N] ->State[i]), // scope of i end at “,“
The indexed process State uses indexed out events
State[x:2..N] = (out[x] -> Buffer).
const N = 4
Buffer = (in[i:2..N] ->State[i]),
State[x:2..N] = (out[x] -> Buffer).

11. Indexing for the lazy modeler
Indexing is just a shorthand way of specifying a model that could be specified with out indexing
The ability to see an automata greatly increases our confidence that we have defined the model we want
We might want to build a large model e.g. a model where
const N = 20
But large models can be very hard to understand.
Hence view the model where const N = 3 and then change just this line and build.

12. Counter example
Here none of the events are indexed but the number of states is controlled by the local index X
Count = Cnt[0],
Cnt[i:0..X] = ( when (i<X) inc->Cnt[i+1]
| when (i>0) dec->Cnt[i-1] ).

14. The natural language problem
Natural languages are:
Very expressive
Open to interpretation
People do not read (elaborate) instructions
Basic recipe for building indexed processes from a natural language specification.
Step 1 find indexes and indexed states
Step 2 find indexed events
Step 3 find all events
Step 4 build automata
Step 5 inspect the automata and validate it against specification

15. From English to automata
Closed doors are always locked. The door starts closed. The lock can hold any one of N codes. To open you need to input the correct code and after opening the door must close when the wrong code is input the door returns the start. Before using the door the code must be set.
Step 1 find indexes and indexed states
Step 2 find indexed events:
Step 3 find all events
Step 4 build automata
Step 5 inspect the automata and validate it against specification

16. From English to automata
Closed doors are always locked. The door starts closed. The lock can hold any one of N codes. To open you need to input the correct code and after opening the door must close when the wrong code is input the door returns the start. Before using the door the code must be set.
Step 1 code is an index Lock in one of N states (codes)
Lock[code:1..N ] = …… Lock[code].
code := ? output := code
Information flow
Output
Input

17. From English to automata
Closed doors are always locked. The door starts closed. The lock can hold any one of N codes. To open you need to input the correct code and after opening the door must close when the wrong code is input the door returns the start. Before using the door the code must be set.
Step 2 find indexed events input[ ] setCode[ ]
input[cd:1..N] …… show[cd]
cd := ? output := cd
Information flow
Output
Input

18. From English to automata
Closed doors are always locked. The door starts closed. The lock can hold any one of N codes. To open you need to input the correct code and after opening the door must close when the wrong code is input the door returns the start. Before using the door the code must be set.
Step 3 find all events
open[] close return setCode[ ]

19. From English to automata
Closed doors are always locked. The door starts closed. The lock can hold any one of N codes. To open you need to input the correct code and after opening the door must close when the wrong code is input the door returns the start. Before using the door the code must be set.
Step 4 build automata
Lock = setCode [j:1..N] -> L[j],
L[i:1..N] = open [k:1..N] ->
( when i==k close->L[i] |
when i != k return ->Lock).

20. From English to automata
Step 3 build automata when N = 2
Understand the information flow. Do you know the value of the code held by the lock when it is the state represented one of the nodes?

21. English to Cooker model
Build a cooker that requires the time to first be set by a setTime event. The setTime event accepts integer t. The cooker then executes the cook event t times.
Step 1 find indexed states and events:
Cooker[time:1..N] setTime[t:1..N]
Step 2 find all events cook setTime
Step 3 build automata

22. English to Cooker model
Specify
Cook = setTime[t:1..N] -> C[t],
Information flow
C[n:0:N] = when n>0 -> C[n-1].
You can specify the automata then visually check the result. OR sketch the automata and then write the specification.

23. From English to automata
Modeling a petrol pump.
After the nozzle has been lifted the customer starts by inputting the required liters of petrol, from 1 to N. Each pump event delivers a liter. After delivering the required liters of petrol the nozzle is returned and the petrol paid for. The pump is now ready for the next customer.
Step 1 index is liters Pump state is liter delivered P[l:1..N]
Step 2 event start[s:1.N] is input
Step 3 all events:
lift, start[], pump, return, pay

24. Pay value not modeled Add return after lift Index acts like a variable
What would it look like with indexed pay[s] (s is output)?

25. Pay value modeled
Second variable

26. From English to automata
The previous petrol pump design can be thought of as prepay but an alternative design is
pump until you choose to stop or the tank is full and finally pay the amount owing hence pump must still be indexed by liters delivered
Events: lift, starts, pump, return, pay[]

27. Pump and Pay
With this model you can pump as much as you want and then pay for the petrol you took.

28. Pump and Pay Defining this pump is simpler in two respects
the start event does not need to accept a parameter
we do not need two parameters
With indexed processes it my be easier to think about the syntax rather than the automata.

29. Indexed number of Processes
NOT USED 2017

30. Indexed number of processes
We have seen the ability to define N states and to define N events. In addition we can define N processes. These N processes are independent of each other and run in parallel.
This independence is exemplified by a much simplified producer consumer design pattern. With N Producers of tasks each with it own consumers of the task.
Producer 1
Producer 2
Producer N
Consumer 1
Consumer 2
Consumer N

31. Indexed Processes Producer
N Producer each synchronise on [i].task event

32. Messy Details
3 Producers and Consumers is very messy

33. Less Messy
With just 2 Producers and Consumers there is still too much detail for easy understanding

34. A Simplified view Hiding all but the tasks
Gives a very easy to understand view: