EVENT RENAMING - The CSP Approach

When a process’ pattern of communication has been described in terms of particular events, it is possible to obtain a new process by renaming those events. Its executions are essentially those of the original process but where the events are renamed. This allows the reuse of particular descriptions of process behaviour without the need to rewrite the process in full and replacing all the original event names with the new ones.

A total function on events f

:

^X ^!

^X is used to describe the required change of event names. For any such function, there are two ways a process can have its events renamed:

by applying the function f to each event, or by applying its inverse f^?1to each event. The interface through which the process interacts with its environment is transformed by f and f^?1 respectively. The function f must map external events to external ones—it cannot be used to make events internal. Termination cannot be renamed, so f

(

) =

^X^,^a

=

^Xfor any event renaming function.

Forward renaming

The process f

(

)

is able to perform an event f

(

)

precisely when the process P could perform the corresponding event a. Furthermore, f

(

)

can perform internal events whenever P can.

This behaviour is captured by the following transition rules:

P ^?^!^a P⁰

(

)

^?^f^?⁽^!^a⁾ ^f

(

^P⁰

)

P ^?^! P⁰ f

(

)

^?^! ^f

(

^P⁰

)

If the function f is one-one, then the process P might be thought of as capturing a generic behaviour pattern, with f

(

)

a particular instance of it. Whenever f

(

)

offers or performs some event b, then that corresponds to P offering or performing f^?1

(

)

. Choices offered by P become choices offered by f

(

)

Example 3.11

The children of Example 2.8 have similar patterns of behaviour. The be-haviour of Isabella was described by

ISABELLA

=

îsabella^:^get^:^box^!îsabella^:^get^:êasel^!îsabella^:^paint^!

isabella^:drop^:box^!isabella^:drop^:easel^!ISABELLA

2isabella^:get^:easel^!isabella^:get^:box^!isabella^:paint^! isabella^:drop^:box^!isabella^:drop^:easel^!ISABELLA

and the behaviour of Kate was obtained by taking the description ISABELLA and replacing all occurrences of the name isabella with the name kate. Instead of doing this explicitly, this may be accomplished by means of event renaming. Let the function f

:

^X^!

^Xbe defined by

(

^isabella^:^x

) =

^kate^:^x

(

) =

^y if y is not of the form isabella^:x

We will adopt the convention in function definition that the function is defined to be the identity on events which are not explicitly covered by the definition. Hence the above function could have been defined simply by the clause f

(

^isabella^:^x

) = (

^kate^:^x

)

. In either case,

KATE

=

(

^ISABELLA

)

gives an alternative definition for KATE. ²

Example 3.12

The process CHAIN in Example 2.11 is made up of a number of individual one-place buffers. Each of those buffers behaves in essentially the same way, but on different channels. The behaviour pattern can be captured as the generic one-place buffer COPY of type^Z, defined first in Example 1.15:

COPY

=

ⁱⁿ

?

:

^Z^!^out

!

^x^!^COPY

This process has in^:Z^[out^:Zas its interface.

Each process Piin the chain was defined explicitly as Pi

=

^cⁱ

?

:

^Z^!^cⁱ⁺¹

!

^x^!^Pⁱ

Each one could instead be defined using a corresponding event renaming function fidefined by

(

ⁱⁿ^:^m

) =

^cⁱ^:^m

(

^out^:^m

) =

^cⁱ⁺¹^:^m

The processes Picould instead have been defined as Pi

=

^fⁱ

(

^COPY

)

The interface of each Piwill be the interface of COPY transformed by fi, which is ci^:Z[ci⁺¹^:Z.

One special form of one-one event renaming attaches a particular label to all events in a process description. If the label is l, then the function flto be applied is given by

(

) =

^l^:^x

f f

f JANET SYLVIE f

phone^:janet

&

^sylvie

answer^: janet

answer^: sylvie answer^:

janet

answer^: sylvie

Fig. 3.3 The interface of the process f⁽OFFICE⁾

for all x²

^{, and f}^l

(

) =

^X. Then the process fl

(

)

performs events l^:a whenever P would have performed a. There is a special form for this kind of event renaming. The process construction l

:

P is shorthand for fl

(

)

^{where f}^lis as defined above.

Example 3.13

In Example 2.8, the generic behaviour pattern of a child painting is captured as the process PAINT:

PAINT

=

^get^:^box^!^get^:^easel^!^paint^!^drop^:^box^!^drop^:^easel^!^PAINT

2get^:easel^!get^:box^!paint^!drop^:box^!drop^:easel^!PAINT

Then KATE and ISABELLA can be described as particular instances of this process, as kate

:

PAINT and isabella

:

PAINT respectively. ²

All aspects of process behaviour are transformed directly when a process is renamed under a one-one function. A function which maps a number of different events to the same single event can alter some features of the process’ behaviour, particularly with regard to choice. If two events of a choice are mapped to the same event, then the environment is no longer able to choose between these two branches of the choice, since they are now both triggered by the same event: if the environment chooses that event, then either branch could be chosen, and no further control over which one is actually chosen is available externally. Hence many-one event renaming may affect the nature of particular choices and may introduce some internal choices where there were previously external ones.

Example 3.14

Janet and Sylvie share an office which contains two phones. To converse with either of them it is sufficient to dial their phone number. The possibilities for phoning and answering are described as follows:

OFFICE

=

^JANET^jjj^SYLVIE

JANET

=

^phone^:^janet^!^answer^:^janet^!^JANET

SYLVIE

=

^phone^:^sylvie^!^answer^:^sylvie^!^SYLVIE

The two phones are given the same number, required to serve both Janet and Sylvie. The effect of this is to map both phone^:janet and phone^:sylvie to a single event phone^:janet

&

sylvie. The effect on OFFICE is to transform it through the event mapping f given by

(

^phone^:^janet

) =

^phone^:^janet

&

^sylvie

(

^phone^:^sylvie

) =

^phone^:^janet

&

^sylvie

The process f

(

^OFFICE

)

, pictured in Figure 3.3, initially offers the event phone^:janet

&

^sylvie.

The next event could be either answer^:janet or answer^:sylvie, and the caller no longer has any control over which of these will occur. The event renaming has altered the nature of the choice

available to the caller. ²

Backward renaming

A process may also have its interface changed through renaming under f^?1where f is again a total function on

^X. The intention here is that the process f^?1

(

)

can perform a whenever P can perform f

(

)

. Internal events are again unchanged by this form of renaming. Its effect is described by the following transition rules:

P ^?^f^?⁽^!^a⁾ P⁰

f^?1

(

)

^?^!^a ^f^?1

(

^P⁰

)

P ^?^! P⁰

f^?1

(

)

^?^! ^f^?1

(

^P⁰

)

In the case where f is bijective then f^?1is also a bijection and the process f^?1

(

)

^can

also be treated as a forward renamed process (renamed by the function f^?1).

When f is many-to-one, then backward renaming is different from any form of forward renaming. In this case, whenever P is able to perform an event a, the process f^?1

(

)

^is

able to perform any of the events that map onto the event a. This allows a single event in the description of a process’ behaviour pattern to correspond to a choice of alternatives at its interface: all the events that map onto a are available to the environment of f^?1

(

)

^{, and any}

of them can be chosen. This form of renaming represents interface expansion, where single events in the behaviour pattern can be triggered by a number of different possibilities at its interface.

SALE

cash

cheque pay

choose

choose f

f f f

credit card

Fig. 3.4 Interface expansion of SALE through backward renaming

Example 3.15

The generic pattern of behaviour when a shop makes a sale is that items are chosen, and then paid for. This simple pattern may be described by the process

SALE

=

^choose^!^pay^!^SALE

The shop offers a number of alternative payment methods: cash, credit card, or cheque. Rather than redefine the process SALE it is possible to describe these alternatives by use of the event renaming function

(

^cash

) =

^pay

(

credit card

) =

^pay

(

^cheque

) =

^pay

Then whenever the process SALE is ready to accept pay, the process f^?1

(

^SALE

)

is prepared to engage in any of those events that map onto pay: it offers a choice to the customer between

the events cash, credit card, and cheque. ²

Chaining

Using event renaming, any event in the interface of one process can be connected to any event from a second process’ interface so the two processes must synchronize on their performance of these events. The two events are each renamed to the same new event, and then the processes are composed in parallel. Their interfaces are effectively reconfigured so that they must now co-operate on these events.

A special form of this interface reconfiguration is useful for pipe processes, which have exactly two channels: in and out. When two such processes are connected together, the intention is that the output of the first is connected to the input of the second. This is accomplished by renaming each of these channels to mid, composing the resulting processes

in out

P Q

Fig. 3.5 A chain of two pipe processes

in parallel, and finally hiding the mid channel. The renaming functions required are particular instances of swapc^;dfor channel names c and d, defined as follows:

swapc^;d

(

^c^:^x

) =

^d^:^x

swapc^;d

(

^d^:^x

) =

^c^:^x

swapc^;d

(

) =

^y ^{if y}⁶

=

^c^:^{x and y}⁶

=

^d^:^x

The chaining operator on pipe processes may then be defined in terms of the operators that have already been defined earlier in this chapter:

P¹P²

(

^swap^out^;^mid

(

^P¹

)

^k^swapⁱⁿ^;^mid

(

^P²

))

ⁿ^mid

The resulting process is again a pipe: the only two channels it has are in and out. The operator is illustrated in Figure 3.5.

Example 3.16

Two instances of the COPY process chained together produce a pipe which is a buffer of capacity two:

No documento The CSP Approach (páginas 77-82)