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.

174 Modelling <strong>of</strong> Concurrent <strong>Reactive</strong> Behaviour<br />

message<br />

a) throw away new message arriving at full buffer<br />

message<br />

b) throw away oldest message from full buffer<br />

Figure 6.9: Buffered Message Flow with Discard<br />

guard emergency process B<br />

Figure 6.10: An Interrupt Flow<br />

flow, must realise the continuous readiness to accept an interrupt. Without special<br />

interrupt language primitives, a behaviour description would become very disordered.<br />

This is because the modelling <strong>of</strong> an interrupt then would mean that we had to define<br />

the alternative behaviour to accept the interrupt for any statement. (Section 9.6 gives an<br />

elaborate description <strong>of</strong> this problem). We solve this problem by <strong>of</strong>fering two language<br />

primitives:<br />

the abort statement;<br />

the interrupt statement.<br />

An interrupt statement specifies that a piece <strong>of</strong> behaviour can be interrupted at the<br />

instants between the execution <strong>of</strong> the process statements, and can be resumed later, so<br />

that the original behaviour is continued from the place where it was interrupted.<br />

An abort statement specifies that a piece <strong>of</strong> behaviour can be stopped at the instants<br />

between the execution <strong>of</strong> the process statements, that form this piece <strong>of</strong> behaviour.<br />

Alternative behaviour that must be performed after the abort can be specified.<br />

The graphical symbol does not specify whether an interrupt message flow must be<br />

interpreted as an abort or as an interrupt. The final decision for an abort or an interrupt<br />

is made during the creation <strong>of</strong> the unified POOSL description. It can also be described<br />

in a scenario description (see also Section 6.5).<br />

1<br />

1

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

Saved successfully!

Ooh no, something went wrong!