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

2.5 Modelling Concepts 25
Traditional Object-Oriented Methods
To model dynamic behaviour, most currently accepted object-oriented methods [CY91a,
CY91b, J 92, Boo91, SM88] use conventional state-machine models similar to those of
structured analysis and structured design techniques [WM85, HP88]. Others [C 94] use
simple object interaction diagrams. The only accepted method that deals with complex
behaviour is OMT [R 91]. OMT builds upon Statecharts [Har87], but violates this
elegant formalism by ’extending’ it with several doubtful and badly defined constructs
(such as inheritance of state diagrams). In OMT each class of objects is assigned a private
state diagram. This enhances modularity and encapsulation. However, OMT permits
objects to communicate by direct monitoring each other’s states: ’Guarded transitions
for one object can depend on another object being in a given state’ (sic!). OMT does
not offer any decent primitive for inter-machine communication [HC91] and hence the
support for concurrency is doubtful.
HOOD and HRT-HOOD
The HOOD method [Rob92] and its hard real-time variant HRT-HOOD [BW95] have
a well-defined notion of objects. Both methods provide several forms of inter-object
communication, including synchronous, asynchronous and interrupt-driven communication.
Objects are specified in an Ada-like language. HOOD and HRT-HOOD are
software-oriented methods that have no support for the modelling of physical architecture
or topology.
Formal Description Techniques and ROOM
From all methods we studied, the methods LOTOS [Tur93, Pir92, Bri88], SDL
[Tur93, BH93] and Estelle [Tur93, D 89] as well as ROOM [SGW94] satisfy our re-
quirements best 3 . These methods are based on autonomous, independent, encapsulated
concurrent entities that are connected in a static topology of channels and that communicate
using well-defined interaction primitives. Communication in SDL, Estelle and
ROOM, however, is buffered asynchronously 4 . Buffered asynchronous message passing
is certainly a useful concept 5 and should be supported, but it is not sufficient for reactive
hardware/software systems. We have experienced that especially at higher levels of
abstraction, the concept of synchronous communication 6 is indispensable. This is also
pointed out in [itV94] and [Wor91]. It should be noted that asynchronous interaction
can easily be expressed in terms of synchronous interaction. This is not true in the other
direction. Synchronous interaction is incorporated in the LOTOS language. Although
it is based on undirected (multi-way) action synchronisation, and not message passing,
it can be used to express directed message passing too [Mor94], be it in less natural
3 A disadvantage of LOTOS is that it does not support a powerful modularisation concept [Mau91]. A
formalism that has the advantages of LOTOS, but in addition has modularisation of data and processes
is PSF [Mau91, MV93].
4 A sender can always send a message without knowing the readiness of the receiver. In general,
messages are buffered until they are consumed by the receiver, but under some circumstances they can
also be discarded.
5 This form of message passing is in particular useful to model telecommunication systems. LOTOS,
SDL and Estelle were originally developed for this purpose.
6 A sender may only send a message if the receiver is ready and willing to receive it.