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

202 Modelling of Concurrent Reactive Behaviour
6.6.2 Object-Orientation and Modelling Dynamic Behaviour
Events in the environment usually initiate the dynamic behaviour of a system. Behaviour
is performed by interactions of objects. They internally take decisions about
what communication and what actions are to be performed in what order. The exchange
of messages can happen in various ways: synchronous, asynchronous, continuous and
interrupt-driven. What happens on what event depends on the system’s history. In
many methods the control of sequences of actions can be described by the formalism of
finite state machines (FSMs). The traditional FSM formalism does not offer a communication
concept for communication between independent FSMs. Therefore there have
been attempts to extend the traditional FSM formalism.
Extended FSMs
Statemate [H 90] is an accepted method for the modelling of complex reactive systems
based on extended FSMs. Many concepts in Statemate resemble (real-time) structured
analysis and structured design methods such as [WM85, HP88]. These methods typically
unify data flow models and state machine models. Both [WM85] and [HP88] use
conventional finite state machines and do not offer appropriate machine interaction
primitives.
Conventional state diagrams are inappropriate for complex behaviour descriptions since
they suffer from being flat and unstructured, are inherently sequential in nature and
give rise to an exponential growth in the number of states [H 90]. These problems are
relieved in Statemate by incorporating the Statecharts formalism [Har87]. Statecharts
extend conventional machines by offering and/or decomposition of states and broadcast
communication. Statemate is an example of a method and a tool that has a sound formal
foundation.
Unfortunately the Statecharts formalism cannot be used straightforward for an objectoriented
approach. The grain of modularisation in Statemate is the activity which is
similar to the concept of process or transformation in [WM85] and [HP88]. These
concepts are based on a functional approach where data is visualised in stores and
data transformations in activities. This differs fundamentally from the encapsulation
concept in the object-oriented paradigm. State machines communicate by data-less
broadcast signals, by using shared variables and by monitoring each other’s states.
This is in conflict with encapsulation (see also Paragraph 6.3.3.4). The only way that
objects should monitor each others state is by explicit exchange of messages. Objects are
relatively loosely coupled encapsulating autonomous entities in contrast to Statemate’s
activities that are tightly coupled entities that share data stores.
A premise for a method for distributed systems is that the speed of computation of the
offered modules is independent. We achieved this by offering asynchronous concurrency.
In contrast, Statecharts is based on the synchrony hypothesis [BG85]. This means
that all concurrent entities in a system must proceed in lock-step mode (see Paragraph
6.2.2.6). For hardware designs this is often acceptable in case the system is synchronised
by a single clock. The model is however not natural for software concurrency, since