Process Algebras

The importance of concurrency in direct manipulation interfaces has already been discussed. In recognition of this, techniques for modelling systems as a set of concurrent processes have been used for d ialogue modelling. These techniques include Communicating Sequential Processes (CSP) [Hoare95], Calculus of Communicating Systems (CCS) [Milner80] a nd Petri Nets [Peterson77,Reisig85]. A number of dialogue languages and user interface development systems have been developed based on these process algebras. These include SPI [Alexander87, Alexander90] b ased on CSP, Squeak [Cardelli85] based on CSP and CCS, Abowd's Agents based on CSP [Abowd90] and SCENARIOO [Roudaud90] which uses event graphs based on Petri nets.

Hoare's CSP is based on two classes of entities, events and processes. Process constructs supported by CSP are summarised in Figure 3.20. Note that since ( e

-> P ) is a process, if e1 and e2 are events, ( e1 -> ( e2 -> P )) is also a process. The

inner parentheses can be omitted to give ( e1 -> e2 -> P ).

P [] Q P ; Q P II Q choice sequence parallel

do event e, then behave like P

behave like process P then (when P has completed) behave like

behave like P and behave like Q, synchronising on common events

Figure 3.20: CSP process expressions.

Consider a simple example (from [Hoare95]), a vending machine that waits for a coin to be inserted, then dispenses a chocolate, and then repeats the process again, waiting for the next coin. In CSP such a vending machine could be described in the following

way:

VEND = ( coin - > ( choc - > VEND ) )

By convention, processes are in upper case and events in lower case. Repetition is handled in CSP by processes recursively calling themselves (either directly or indirectly via another process).

SPI, an interface prototyping environment based on CSP was developed by Alexander [Alexander87].

Dialogue design

in this environment

is

a two stage process:

1 .

The structure of dialogues

is

defined in terms of primitive steps (referred

to as events), using eventCSP, a subset of CSP.

2.

The events are defined using eventiSL.

Consider Figure 3.21 which contains part of the specification for a dialogue for

an automatic teller machine. The structure of the dialogue

is

given in (a)

consists of a list of d ialogue events such as put-in-card and read-card. The expression e -> P means deal with event e, then behave like process P. Process P may well be a further sequence · of events to be processed. The [] symbol represents choice, hence the interpretation of the second clause of the ATM dialogue specification is read-card or cannot-read (card) or stop-atm. Non­ termi nal symbols (eg; ATMl in the ATM dialogue specification represent further expression.

Figure 3.21(b) shows how an event is defined using eventiSL. The purpose of this definition is to specify when the event is available and to associate any actions that go with the event. Each dialogue has an associate state and the availability of an event is defined as a condition in terms of a predicate on the dialogue state. The when clause in (b) defines that the event thief? is only available if the number of tries (at entering the PIN number) is >= 3. Inputs, outputs and state transformations may also be associated with a n event definition.

ATM = ( put - in - card ->

( read - card -> ATMl

[ ] cannot- read - > e j ect - card -> take - card - >

ATM

[ ] stop -atm -> SKIP ) )

ATMl enter - p i n ->

( pin - ok? -> TRANSACTION [ ] p i n - not - ok? - >

event thief? = use tries in

( try - again? - > ATMl [ ] thief? - > ATM ) ) )

( a ) when tries � 3

out " Card retained ; please see the manager "

(b)

Figure

3.21:

Part of the SPI specification of a dialogue for an

ATM.

(a) Dialogue

definitions in eventCSP and

(b)

Definition of an event in eventiSL. (Adapted

from

[Alexander90]).

The dialogue example given in Figure

3.21

is purely sequential, the

specification appearing very similar to

a

specification in BNF. However, the

real strength of using CSP

is

that

it is

able to model concurrency.

Mouse = ( press - > g e t - posn -> send - posn - > re lease - > Mouse )

Kbd = ( get - char - >

.( newl ine? - > send - l ine -> Kbd

[ ] text - eh? -> add - t o - l ine - > Kbd ) ) Text = ( send- posn - > save -pos it ion -> Text

[ ] send - l ine - > write - l ine - > Text ) INPUT = ( Text I I Mouse I I Kbd )

Figure 3.22: Concurrent dialogues in eventCSP. (Adapted from [Alexander87])

Consider the example in Figure 3.22. Mouse, Kbd and Text are dialogue processes for handling Mouse inputs, Keyboard inputs and the accumulation of text characters in a buffer. The expression a I I b means execute processes a and b in parallel. Hence the definition for INPUT specifies that each of these input processes is executed concurrently. An important consideration in execu ting processes concurrently is synchronisation. CSP achieves this by synchronising processes on common events, hence in the Mouse, Kbd and Text example, the Mouse and Text processes would synchronise on the event

send-posn.

Using eventCSP, the brush shape dialogue can be modelled as shown in Figure 3.23. Reviewing the CSP based specification of the brush shape dialogue shown in Figure 3.23, the following observations can be made:

clearly specified

• CSP captures the separation of the paint and set shape dialogues well. The user is only able to resume interaction with the paint process after the set shape process has terminated.

• Sequences are captured well, with the specification appearing not dissimilar to BNF, particularly in the way that recursion is used for repetition.

• Concurrency is clear and straightforward to specify, for example defining

the concurrent invocation of the application functions to set vertical and horizontal brush thicknesses.

SET - SHAPE select - vthin -> VTH I N - SELECT ; SET- SHAPE [ ] select -vthick - > VTHICK - SELECT ; SET - S HAPE [ ] select - cancel -> CANCEL ; SKIP

[ ] select - ok - > OK ; SKIP )

SET - DEFAULTS de fault - vthin - > default- hthin - > SKIP

VTHIN- SELECT select - vthin -> highlight - vthin - >

VTH ICK - SELECT

HTHIN- SELECT HTHICK - SELECT

dehighlight - vthick - > SKIP ) select- vthick - > highlight - vthick - >

dehighlight - vthin - > SKIP )

select - hthin - > highlight - vthin - > dehighlight - hthick - > SKIP )

sele ct - hthick - > highlight - vthick - > dehighlight - hthin - > SKIP )

CANCEL = ( h ide - dialogue - box - > SKIP )

OK = ( ( SET- VERTICAL - TH I CKNESS I I SET- HORI ZONTAL - TH ICKNESS ) ; hide - dialogue - box - > SKIP )

event default - vthin =

out highlight - vthin set vert ical = thin

event defaul t - hthin =

out highlight - hthin set horizontal = thin

event select - vthin

set vert ical thin

event select - vthick =

set vertical thick

event select - hthin

set horizontal thin event select- hthick =

set horizontal = t hick

Figure 3.23: Specification of the brush shape dialogue in

CSP. poorly specified

•

The mutually exclusive grouping of thick and thin options in each

orientation is not clear, but is simply implied by the sequence of

highlighting and dehighlighting events.

• The state changes in the system are recorded within the event specifications.

This separation of sequence and associated state changes requires effort to relate the two together. ·

not specified

As was the case with grammars and ERL, user actions and display layout and appearance are not addressed.

A general criticism of CSP is that the clarity of the specification is very much dependent on the use of descriptive names.

In document Dialogue activation : an approach to user centred constructional modelling of direct manipulation interfaces : a dissertation presented in partial fulfilment of the requirements for the degree of Doctor of Philosophy at Massey University (Page 72-77)