23.08.2013 Views

Specification of Reactive Hardware/Software Systems - Electronic ...

Specification of Reactive Hardware/Software Systems - Electronic ...

Specification of Reactive Hardware/Software Systems - Electronic ...

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

6.3 Communication 183<br />

6.3.9.4 Modelling Aspects<br />

Where data objects are very flexible with their dynamic links, process objects require<br />

static channels. The rigidity <strong>of</strong> the channel structure may give the feeling the SHE<br />

method is not powerful and flexible enough to describe a wide variety <strong>of</strong> systems, especially<br />

s<strong>of</strong>tware systems. The channel concept is introduced to describe static structures<br />

that are especially needed in hardware designs. There is however no fundamental<br />

constraint on our method. Nothing forbids us to make all process objects fully interconnected.<br />

Even one channel is sufficient to do this. As long as we define enough unique<br />

message identifiers we can perform the necessary communication. If we do so, the object<br />

identifiers can be used for full dynamic communication. When all process objects are<br />

connected to a common channel we create in fact a common address space. In the next<br />

subsection we show a conditional message-receive statement that enables addressing <strong>of</strong><br />

objects in the common space. So the concept <strong>of</strong> static channels does not limit the descriptive<br />

power <strong>of</strong> the POOSL language. Of course this is a pure theoretical discussion.<br />

We do not want to recommend to structure a model this way. On the contrary, we expect<br />

that the use <strong>of</strong> channels can also structure a s<strong>of</strong>tware system in a useful way.<br />

6.3.10 Behaviour Description <strong>of</strong> Communication<br />

6.3.10.1 Description <strong>of</strong> Process Object Communication<br />

Because process objects can have static links as well as dynamic links, we can identify<br />

the following situations:<br />

1. There are precisely two objects connected to a channel. They can communicate:<br />

a) pair-wise without the use <strong>of</strong> identifiers (autistically);<br />

b) pair-wise with the use <strong>of</strong> identifiers. The sending object must know the<br />

receivers identifier, and must use it explicitly in the send statement.<br />

2. There are more than two objects connected to a channel. These objects can communicate:<br />

a) pair-wise non-deterministically (without the use <strong>of</strong> identifiers). Any receiving<br />

object that accepts the message can finish the rendezvous.<br />

b) pair-wise with the use <strong>of</strong> identifiers. The sending object must know the<br />

receiver’s identifier, and use it explicitly in the send statement.<br />

The communication in cases 1.a) and 2.a) can be performed on static links. Cases 1.b)<br />

and 2.b) require dynamic links as well.<br />

The communication between a pair <strong>of</strong> process objects requires the simultaneous execution<br />

<strong>of</strong> a pair <strong>of</strong> matching statements: a message-send statement in the sender and a<br />

message-receive statement in the receiver. There are various POOSL constructs that can<br />

be used to describe communication. The main difference between the various constructs<br />

is in the determination <strong>of</strong> the actual receiver among all potential receivers on a channel.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!