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

162 Modelling of Concurrent Reactive Behaviour
communication (message passing) must be synchronous or asynchronous.
1. Synchronous communication is a form of communication where two or more process
objects participate at the same moment. A message can only be passed if sender
and receiver are ready to do so simultaneously.
2. Asynchronous communication is a form of communication where two or more process
objects may start an interaction without concern about the readiness of the others.
In general, messages must be buffered in languages with asynchronous message
passing. Languages with synchronous message passing can express buffered
asynchronous interaction in terms of synchronous interaction.
We experienced synchronous interaction to be very expressive in building simple and
understandable models. Especially at the higher levels of abstraction, the expressive
power of synchronous interaction primitives can be exploited efficiently and effectively.
This point of view is confirmed in the work of Huis in ’t Veld who studied language
characteristics for design frameworks for communication systems [itV94].
Besides the expressive power that a communication primitive has for analysis, there
are more aspects. Complex system specification and design requires that modelling
is supported by consistency checking, verification, validation, and model transformations.
This requires a formal basis. The language POOSL with its formal mathematical
semantics forms this basis. POOSL is based on the concepts of Milner’s calculus of
communicating systems (CCS) [Mil80, Mil89]. CCS and CSP [Hoa85] form the root of
a family of so-called process calculi and process algebras. Over the past years process
theories have proven to be very useful for the description of systems in which concurrency
and communication are major features. Moreover, a collection of techniques and
tools, supporting various kinds of design activities, have been developed. Examples
include: formal verification [CPS93, RV94], simulation [vE89] and rapid prototyping
[MMvT89], compilation [MM89], correctness-preserving transformations [Lan92], conformance
tests derivation techniques [Bri89] and performance evaluation [VvR95].
Since POOSL is strongly related to CCS, we foresee that many of these techniques
and tools can be incorporated in the SHE development environment. In a design
project for a POOSL compiler special attention has been paid to enable translation
to various target languages. This tool is intended to establish a link to a wide variety
of automated verification tools, thereby incorporating formal verification in the SHE
method. Currently the POOSL compiler (developed by Kuppens [Kup96]) can translate
to PROMELA [Hol93], thereby enabling the use of the SPIN [Hol93] tool for formal
verification. SPIN can check for deadlocks, unreachable code, progress, system invariant
correctness, etcetera. In addition SPIN can perform simulations.
Besides verification we aimed at a particular form of formal design transformations. The
careful selection of the concepts such as process and synchronous message passing enabled
the specific definition of observation and transformation equivalence that is given in
Chapter 9 about the semantics of POOSL and in Chapter 10 about behaviour-preserving
transformations.