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

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

44 Concepts for Analysis, <strong>Specification</strong> and Design<br />

Sender<br />

process<br />

Single message flow<br />

Message with reply flow<br />

Continuous flow<br />

Interrupt message flow<br />

Interrupt with reply flow<br />

Buffered message flow<br />

Figure 3.8: Message Flow Symbols<br />

Receiver<br />

process<br />

<strong>of</strong> each individual object and consider the events that can happen, such as sending and<br />

receiving various possible messages. Behaviour is determined by the events that happen,<br />

and in which order they happen. Based on reception <strong>of</strong> a message an object changes its<br />

state and possibly performs calculations and produces results, replies or commands.<br />

System behaviour is modelled by a collection <strong>of</strong> concurrent process objects. However<br />

processes can be specified to wait for a result after sending a message. This way we<br />

can perform the whole behaviour <strong>of</strong> collaborating processes as sequential behaviour. In<br />

general, a mix <strong>of</strong> concurrent and sequential behaviour is performed in a complex system.<br />

Humans easily lose the overview on such a system. In practice it is precisely this problem<br />

that causes so many design errors in complex systems. There are no complete solutions<br />

for this problem. Simulation and automatic verification can help to diminish the number<br />

<strong>of</strong> errors in a design. This is only possible if the behaviour <strong>of</strong> the objects is formally<br />

described. This implies that a computer can perform the execution <strong>of</strong> the model. The<br />

method SHE incorporates the language POOSL which can describe system behaviour as<br />

well as system structure. System behaviour can be modelled adequately because POOSL<br />

has the power to describe the communication between parallel processes on an abstract<br />

level. POOSL <strong>of</strong>fers various powerful mechanisms such as non deterministic choice,<br />

interrupt, infinite behaviour, guarded commands, and branching statements such as ’if<br />

then else’ statements.<br />

Process objects communicate via statically interconnected channels. Figure 3.10<br />

visualises this for the Product Input Handler. Note that the message flow<br />

wakeAt(Position,Id)/wakeup(id) from Figure 3.9 represents a message and a reply. So<br />

there are two messages in opposite direction on channel wake <strong>of</strong> Figure 3.10. Notice<br />

further that both the message flows productArrived and currentPosition(Position) from<br />

Figure 3.9 are mapped on one channel named piti in Figure 3.10.<br />

All message flows that we showed in Figures 3.7 and 3.9 are mapped on such channels.

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

Saved successfully!

Ooh no, something went wrong!