Upload
giacomo-allen
View
49
Download
2
Tags:
Embed Size (px)
DESCRIPTION
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. - PowerPoint PPT Presentation
Citation preview
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