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

156 Modelling of Concurrent Reactive Behaviour
offer an interrupt and an abort mechanism that enable to break in on running behaviour
and switch to other behaviour. So the number of possible sequences of operations may
be huge.
6.2.3.3 Summary
In this section we described various aspects related to concurrency and synchronisation.
We decided to choose the following approaches:
A system model consists of asynchronous concurrent process objects. Asynchronous
concurrency is most natural for distributed systems. The concurrent
system parts can autonomously perform their operations at their own speed. They
are less dependent on each other’s progress. This makes our method suitable to
describe distributed concurrent hardware/software systems as well as (pseudo)
concurrent systems. In contrast many other methods are sequential or have synchronous
concurrency.
Objects encapsulate their state. This prevents sharing problems.
Process objects form the grain of concurrency. Internal behaviour of process objects
is sequential. This choice keeps the internal behaviour description of objects relatively
simple, in contrast to objects that can perform complex concurrent behaviour
internally.
Concurrency boundaries specify the concurrency properties of modules on system
level. They specify whether modules have a sequential or a concurrent internal
behaviour. Processes in a sequential module are modelled as a composite that
behaves sequential as a whole. Processes are alternately active in such a composite.
Interleaving semantics are used for the formal behaviour description of concurrency.
Processes synchronise their behaviour by synchronous message passing. We
restrict synchronisation of concurrent threads to one mechanism, which is synchronous
message passing via the message interface of process objects
6.3 Communication
6.3.1 Introduction
A specification and design method must be able to express various forms of communication.
We have chosen to emphasise to model systems as a collection of communicating
objects. Communication between objects is realised by message passing. All objectoriented
methods agree on that. At first glance this concept is straightforward and
simple. Problems arise when communication is related to concurrency, infinite (nonterminating)
activity of objects, and implicit assumptions about sharing. Recall that
SHE offers two kinds of objects, process objects and data objects. The communication