More on RDT

More on RDT

Robert John Walters

RDT – a reprise A Graphically based formal

modelling language Models represented as diagrams

(not text) Communications inspired by π-

calculus Drawn in two parts:

Behaviour of components (processes) How they are connected together

RDT Processes Inspired by RADs Have named state Three types of event:

Send Receive Create

*Processes describe a type of behaviour

Barber

Get Customer MyCh -> Custs

Initial

Request Fee

Work <- MyCh

Cost ->MyCh

Receive Instruction

Initial=

Awaiting Payment

Receive Payment Cash <- MyCh

Leave -> Info

Return -> Info

TakeBreak

Return

Outside

AwaitingInstructions

Cutting

RDT Models Process instances labelled

with a name and their type

Channels (names) known to an instance are shown and labelled

Connections between channels shown by lines

*Concerned with instances

Barber1: Barber

MyCh

Custs

Info

Customer1 : Customer

MyCh

Barber

Info

InInfo : Sink

Barber1: Barber

MyCh

Custs

Info

Customer1 : Customer

MyCh

Barber

Info

Barbershop

Why target SPIN? Highly regarded and widely

available Input language looks like “C” Direct input of property to be

checked Natural correspondence between

channels in Promela and RDT

Translation Several parts to the operation

RDT processes converted to Promela processes

RDT model conversion - the “init” process

Channel allocations Special consideration of features of

RDTSend

Out -> Out

Initial

Initial=

Source

Out

In

Sourc1 : Source

Sink1 : Sink Val

Translation: Processes (1) Could have used a single “do” loop

with process state stored in a variable State would have to be a number

(since there is no string type in Promela)

Establishing the extent to which a process is exercised is not straightforward Send

Out -> Out

Initial

Initial=

Source

Translation: Processes (2) Each RDT process is converted to a

process in Promela Label in Promela for each state of

the RDT process “if” statement with each label with

two statements which Perform the communication Move process to the next state

SendOut -> Out

Initial

Initial=

Source

Translation: Processes (3)

SendOut -> Out

Initial

Initial=

Source

ReadVal <- In

Initial

Initial=

Sink proctype Sink(chan In, val)

{

initial:

if

:: In?Val; goto initial;

fi;

}

proctype Source(chan Out)

{

initial:

if

:: Out?Out; goto initial;

fi;

}

Translation: Models (1) Performed (assembled) in the “init”

process Required instances of processes are

created (run) Actions enclosed in “atomic” statement

(So things don’t start happening until we are ready)

Connections implemented by appropriate allocation of channels as parameters to process instances Out

In

Sourc1 : Source

Sink1 : Sink Val

Translation: Models (2)

chan ch0 = [CHLEN] of {chan};chan nch0 = [0] of {chan}; /* Process definitions here */ init{ Atomic { run Source(ch0); run Sink(ch0, nch0); } };

Out

In

Sourc1 : Source

Sink1 : Sink Val

Translation: Models (3) Promela permits the creation of

channels which carry channels Length of channels

An issue – its not in the diagram Set by user at translation time

Each process is given a channel as a parameter for each channel name it knows

Issues – Unconnected channels Each process has a parameter for

each channel name it knows What if the name isn’t connected to

anything (at start up)? Omitting parameters to processes is

an error Unconnected names given a nil

length channel each to avoid problems

Issues – the Create type event Permits a process to bring a new channel

(value) into existence Translation scheme outlined so far

requires all channels to be declared before start of execution

Solution adopted is a provide processes with a collection of channels to use In current implementation, when these are

exhausted, create events can no longer occur

Issues – Special case of Read

Proc 1

AnEventX <- X

Initial

Second

if:: X?X; goto second;fi;

chan tmp;… if:: atomic{X?tmp; X = tmp; } goto second;fi;

Further work I already have a tool which

performs this translation automatically

Solution to the Create problem…

Postscript on the Create issue A loop could execute a create event an

unlimited number of times, creating a new channel each time

But: There is a limit to the number of channels

the processes in the model can “know” Ultimately each time a new channel is

created, one is lost Hence only a finite number needed, if lost

channels are re-cycled

Hierarchy Problem

What we would like to draw:

Abstract connection

What we usually get Boxes within Boxes

With the lines brought out to the edges

What we would like to draw:

What we actually do:

The Usual Problem

A process for the election algorithm

Using processes to build a model

And this model only has three processes

Executing the model

Building the same model with connectors

C1

C1

C1

P1 : P0Val1

P2 : P0Val2

P3 : P0Val3

The Connector

Conn1

Ch A

Ch B

Ch C

Ch D

Ack

Send

Rec.

Sig

Issues (1)

Need to distinguish which end of a connector is which

Issues (2) Allowing processes to be connected at

the higher, “connector” level Want to use the connectors in the model

definition (before connectors and processes fully elaborated)

Don’t want to add the connectors as a tidying exercise after model is complete

Tool draws either view – either showing connectors (plus any individually created channels), or the all of the detail

Issues (3) What about names in the process

not in the connector? What about strands in the

connector not known to the process?

What about strands which connect at just one end: dangling ends?

Conclusion Visual Formal Models can be useful Single level diagrams get cluttered Addressing this requires attention

to channels as well as processes This is not as simple as it appears