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

204 Modelling of Concurrent Reactive Behaviour
ROOM, SDL and Estelle is at the level of process objects. LOTOS supports concurrent
processes. LOTOS processes are pieces of behaviour, but they are not objects that perform
this behaviour. Nevertheless, objects can be modelled by processes. This is exploited in
the ROOA method [Mor94].
We offer data objects that can model data appropriately. Except for ROOM, none of the
methods supports data objects. LOTOS and SDL use abstract data types and Estelle uses
Pascal types for the modelling of data. Abstract data type descriptions are elegant from
a mathematical point of view, but are difficult to comprehend for non-experts. Pascal is
a procedural language and has no sufficient support for data modularisation.
SHE and POOSL offer adequate concepts for the description of complex dynamic behaviour
of distributed systems. We incorporate the design of structure using encapsulating
entities, with communication forms that respect encapsulation. The next subsections
describe various aspects of the modelling of dynamic behaviour.
6.6.3 State
In this subsection we describe a number of interpretations of concepts of state and their
use in our method. Our method can describe very complex parallel systems with an
infinite state space. For this we do not use the traditional finite state machine modelling
that is incorporated in most methods. The concept of state is however very important
for reasoning about behaviour. Especially named states can be of great help for analysis,
behaviour description, simulation, test and maintenance of a system.
6.6.3.1 Behaviour State
A behaviour state of a system can be determined and named if the behaviour of a system
can be partitioned. The state depends on which pieces of behaviour are active (concurrently).
Partitioning determines the size of the grain of behaviour. If a partitioning can
be performed hierarchically behaviour states can be decomposed into finer behaviour
states. In this way one can create various levels of complexity of behaviour states, from
global working modes to detailed execution steps.
Performing a behaviour state is modelled by the execution of the statements that specify
a corresponding piece of behaviour. A state takes a time period in which the statements
belonging to this state are performed. The finest grain of behaviour in a specification is
the atomic statement. An atomic statement contrasts a compound statement, which is
composed of atomic and/or compound statements. Although the notion of state may
seem to be a simple concept it is not. Therefore we elaborate on various aspects and
interpretations of state.
We must interpret our definition of behaviour state for complete systems modelled as
collaborating objects. A system can consist of numerous objects, each performing some
form of behaviour. Process objects have asynchronous concurrency. Such a collection
of collaborating concurrent objects gives an unmanageable number of system states,