More on rdt
This presentation is the property of its rightful owner.
Sponsored Links
1 / 31

More on RDT PowerPoint PPT Presentation


  • 82 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

More on RDT

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

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 Source(chan Out)

{

initial:

if

:: Out?Out; goto initial;

fi;

}

proctype Sink(chan In, val)

{

initial:

if

:: In?Val; 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


The Usual Problem

  • What we would like to draw:

  • What we actually do:


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


  • Login