PROCESS-ORIENTED SPECIFICATION

and since this specification is^fcij^j

(

^i;j

)

^2Eg-independent, it follows that NETWORK ^nfcij^j

(

^i;j

)

^{2Eg sat term}

(

^tr

)

⁾

(

^v01

(

^tr

) =

^i2Nwi

)

or in other words

DISTSUM sat term

(

^tr

)

⁾

(

^v01

(

^tr

) =

^i2Nwi

)

This completes the proof that on termination the sum of the outputs along c⁰¹ is equal to the sum of the weights on the nodes. Since NODE

(0)

ensures that at most one value is communicated along channel c01, this value must be the sum of the weights.

What has been proven is that if an answer is given out then it will be the right one.

This is a safety property: it states that the wrong answer will never be given. Observe that the connectedness of the graph was not used in establishing this property. Connectedness will be needed to show that all nodes in the graph participate in the run, and this does not need to be shown to establish the safety property. Rather, it is already assumed in the antecedent term

(

^tr

)

, since NETWORK can terminate only when all of its nodes are ready to do so, which requires that they all participate in the execution.

The fact that DISTSUM will indeed progress towards termination, and will not deadlock or diverge, will be shown in Chapters 7 and 8, where issues of liveness are addressed.

P^vP ^hv-reflexⁱ P0

vP1

^P1 vP2

)P0 vP2

hv-transⁱ

P^0vP^{1^}P^1vP⁰⁾P⁰

=

^{P1 hv-anti-symi}

RUN^vTP ^hvT-bottomⁱ

P^vTSTOP ^hvT-topⁱ

P⁰sat S

(

^tr

)

^{^P0vTP1)P1sat S}

(

^tr

)

^hvT-speci

Fig. 5.5 Laws for refinement

The ‘traces refinement’ check of FDR (see Appendix B) checks for exactly this refinement relation.

The relation may also be captured algebraically as follows:

P^0vTP^{1 ,} P⁰

=

^TP0uP1

Its equivalence to the definition is easily checked, though the interpretation of this character-ization is a little different. It states that if P0is indistinguishable from P0

u P1, then any situation where P0is suitable must allow that P0

uP1is suitable (since this is equal to P0), and so P1must also be suitable since the internal choice could always be resolved in favour of P1. The process P1is a refinement of P0because it will be appropriate in any environment which will find P⁰acceptable. An alternative way of thinking about the equivalence is that all of P¹’s behaviours must already be allowed by P⁰, since the introduction of P¹does not introduce any new behaviours. This algebraic characterization of refinement is also appropriate for other semantic models, as will be discussed in later chapters. If the model is clear from the context then the subscript to the refinement symbol will be dropped.

Refinement satisfies a number of laws, given in Figure 5.5: it is reflexive, transitive, and anti-symmetric in all models; the process RUN is trace-refined by any other process; STOP trace-refines every process; and refinement preserves sat specifications.

The resolution of internal choice is a refinement step: P^0uP^1vT P¹. If either P⁰or P¹ are acceptable, then certainly P¹by itself is acceptable. Furthermore, all of the CSP operators are monotonic with respect to refinement. What this means is that for any CSP function F

(

^Y

)

constructed from the CSP operators, the application of F will respect the refinement relation:

if P^0vTP¹then F

(

^P0

)

^vTF

(

^P1

)

. Finally, if

8Y

(

^F

(

^Y

)

^vTG

(

^Y

))

then P⁰

=

^F

(

^P0

)

^{vT P1}

=

^G

(

^P1

)

^.

Example 5.12

The process-oriented specification RUNspecifies that termination may not

occur, but imposes no other restriction. ²

Example 5.13

The specification P

=

^a!

(

^{P jjj b!STOP}

)

specifies that only a and b events may occur, and b may not occur more often than a. This process meets the property oriented specification tr^#b⁶tr^#a.

Now the function defining P may be refined as follows:

F

(

^Y

) =

^{T a!}

(

^{Y jjjb!STOP}

)

vT a^!b^!Y

and so it follows that P^vTP¹

=

^a!b!P1. The process that alternates on a and b refines the process that allows no more b’s than a’s. Since refinement preserves sat specifications, it follows that

P¹

=

^{a!b!P1 sat tr#b6tr#a}

This follows from an application of Law^vT-spec. ²

Example 5.14

A CSP process expression can describe the behaviour required of the dis-tributed summing network DISTSUM described in the case study. The resulting specification on DISTSUM is captured by the following refinement requirement:

c^1;0:

0

^!c01

!(

^i2Nwi

)

^{!SKIP vT DISTSUM}

This states that DISTSUM is intended to output the appropriate value on the channel v⁰¹

before terminating. ²

Example 5.15

When using CSP process expressions as specifications, it is important to ensure that no acceptable traces are excluded. For example, the requirement that a and b events should alternate (beginning with a) might use the recursive process P

=

^a!b!P,

but if no constraint is required on other events, then the acceptability of other events has to be included explicitly as a component RUNnfa^;b^g, and the entire specification will be written

P^jjjRUNnfa^;b^g

Using only P as a specification would introduce the additional constraint that no other events

may occur. ²

The model-checking tool FDR (see Appendex B) allows checks concerning the refine-ment relationship between two (finite state) CSP processes. This is often the quickest way to conduct process verification once the specification has been captured. The tool also assists debugging of implementations when they do not meet the specification by returning a wit-ness trace which may be performed by the implementation but which is not possible for the specification process.

Exercises

Exercise 5.1

Specify that a lift’s doors should not be open when the lift starts moving.

Assume that it has events open, close, moving, stopped in its alphabet.

Exercise 5.2

Specify the hygiene requirement that hands should be washed between han-dling raw meat and cooked meat. Use the events wash, raw, and cooked, to refer to these three activities.

Does the combination RAW ^k

fwash^g

COOKED meet your specification?

RAW

=

^raw!wash!RAW

COOKED

=

^{wash!cooked!COOKED}

Exercise 5.3

What does the predicate tr^6ha^;b^;c^iatr specify?

Exercise 5.4

What does the predicate last

(

^tr

) =

^b)a2

(

^tr

)

^specify?

Exercise 5.5

^{If P1sat tr#a6tr#b}

+

^{n and P2sat tr#a6tr#b}

+

m, then prove that P^1jjjP²sat tr^#a⁶tr^#b

+

ⁿ

+

^m.

Exercise 5.6

Prove the statements on Page 146, that P¹

=

^{b!a!P1 sat S}

(

^tr

) =

^tr#a6tr#b

P²

=

^{c!b!P2 sat T}

(

^tr

) =

^tr#b6tr#c

Exercise 5.7

Which of the following are sound proof rules for the interleaving operator?

P¹sat tr^#A⁶m P²sat tr^#A⁶n P1

jjjP2sat tr^#A⁶

(

^m

+

ⁿ

)

P¹sat tr^#a⁶tr^#b P²sat tr^#a⁶tr^#b P^1jjjP²sat tr^#a⁶tr^#b P¹sat tr^#a⁶tr^#b P²sat tr^#b⁶tr^#c P^1jjjP²sat tr^#a⁶tr^#c

Exercise 5.8

Prove the claims of Example 5.9 on Page 156, that

8Y

(

^{Y sat S2}

(

^tr

)

^{) on!Y sat S1}

(

^tr

))

8Y

(

^{Y sat S1}

(

^tr

)

^{) off !Y sat S2}

(

^tr

))

Exercise 5.9

Prove by recursion induction that the process DOOR

= (

^{open! close!}

DOOR

)

^2locked!STOP meets the following specifications:

1. two consecutive events are not both open;

2. two consecutive events are not both close (you will have to prove something stronger);

3. tr^#close⁶tr^#open⁶tr^#close

+ 1

^.

Exercise 5.10

Prove that STACK

=

^STACK

(

^hi

)

of Example 1.23 on Page 17 meets the specification

8vpop^:v in tr⁾push^:v in tr

Exercise 5.11

Specify the requirement that every output value (on channel out) must be less than or equal to some input value (on channel in), in both the property oriented and the process-oriented specification styles.

Exercise 5.12

Specify the requirement that a write event should always occur between an engage event and a release event, as a property oriented and as a process-oriented specification.

Exercise 5.13

Specify that a guard should never be up while a piece of machinery is switched on. A property-oriented specification should be expressed in terms of events guard^:up, guard^:down, on and off . Express the same specification in a process-oriented way.

Exercise 5.14

Can a node NODE

(

ⁱ

)

(Page 162) output its total to its parent node before it has sent out all of its initiating messages? Can it terminate before sending out all of its initiating messages?

Exercise 5.15

Show that NODE

(0)

satisfies the following specifications 1. tr⁺c01

6

=

^hi)tr+c106

=

^hi

2. tr^X6

=

^hi)tr+c016

=

^hi

3.

(

^tr+c10

)

^6h

0

ⁱ

4. tr^#c^{01:N 6}

1

No documento The CSP Approach (páginas 183-187)