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

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

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 RDT

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

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

Translation: Processes (3) 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

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); } };

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 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

The Connector

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