1 / 31

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.

giacomo-allen
Télécharger la présentation

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. More on RDT Robert John Walters

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

  3. RDT Processes • Inspired by RADs • Have named state • Three types of event: • Send • Receive • Create • *Processes describe a type of behaviour

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

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

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

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

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

  9. 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; }

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

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

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

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

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

  15. Issues – Special case of Read if :: X?X; goto second; fi; chan tmp; … if :: atomic{X?tmp; X = tmp; } goto second; fi;

  16. Further work • I already have a tool which performs this translation automatically • Solution to the Create problem…

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

  18. Hierarchy Problem • What we would like to draw: Abstract connection

  19. What we usually get • Boxes within Boxes • With the lines brought out to the edges

  20. The Usual Problem • What we would like to draw: • What we actually do:

  21. A process for the election algorithm

  22. Using processes to build a model And this model only has three processes

  23. Executing the model

  24. Building the same model with connectors

  25. The Connector

  26. Issues (1) • Need to distinguish which end of a connector is which

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

  28. 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?

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

More Related