More on rdt
1 / 31

More on RDT - PowerPoint PPT Presentation

  • Uploaded on

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' More on RDT' - giacomo-allen

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
More on rdt

More on RDT

Robert John Walters

Rdt a reprise
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
RDT Processes

  • Inspired by RADs

  • Have named state

  • Three types of event:

    • Send

    • Receive

    • Create

  • *Processes describe a type of behaviour

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


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

proctype Source(chan Out)




:: Out?Out; goto initial;



proctype Sink(chan In, val)




:: In?Val; goto initial;



Translation models 1
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
Translation: Models (2)

chan ch0 = [CHLEN] of {chan};

chan nch0 = [0] of {chan};

/* Process definitions here */



Atomic {

run Source(ch0);

run Sink(ch0, nch0);



Translation models 3
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
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
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
Issues – Special case of Read


:: X?X; goto second;


chan tmp;


:: atomic{X?tmp; X = tmp; }

goto second;


Further work
Further work

  • I already have a tool which performs this translation automatically

  • Solution to the Create problem…

Postscript on the create issue
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
Hierarchy Problem

  • What we would like to draw:

Abstract connection

What we usually get
What we usually get

  • Boxes within Boxes

  • With the lines brought out to the edges

The usual problem
The Usual Problem

  • What we would like to draw:

  • What we actually do:

Using processes to build a model
Using processes to build a model

And this model only has three processes

Issues 1
Issues (1)

  • Need to distinguish which end of a connector is which

Issues 2
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
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?


  • 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