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

114 Abstraction of a Problem Domain
a continuous flow represents that a receiver can take initiative at any time to receive
a message;
a buffered message represents that a sender can always send a message;
an interrupt message represents an interruption of behaviour by temporal alternative
behaviour, or an abortion by alternative behaviour.
Traditional sequential object-oriented languages typically use ’request with waiting for
reply’ messages. SHE enables concurrency and an event-oriented modelling. There has
been a panel discussion about ’the heresy of event-orientation in the world of objects’
on the OOPSLA conference in 1992. The goal of the discussion was to get a better
understanding of the differences between the ’mainstream’ methods based on ’real
world’ domain analysis, and the ’heretical’ perspective that focuses on behaviour. The
behaviour approach recognises that objects may be built ’around events and transactional
sequences that an application must handle’ [C
92]. Notice that this is an important topic in
our research. This topic is the balanced integration into object analysis of data-oriented
application domain analysis and event-oriented functional analysis. This is achieved by
the concept of process object with its typical uncoupling of methods and messages, and
the addition of message flows that represent events, commands and interrupts. With this
expressive power, concurrent process objects can typically play the role of controllers
that are the backbone of complex reactive systems. Such systems can be modelled clearly
by creation of a hierarchy of controllers, that handle the order of processing at various
levels. On the highest levels controllers determine the global states of operation, also
called working modes. At the lower levels, controllers determine the order of detailed
actions necessary to perform detailed computation, processing and control tasks. By
playing scenarios of interactions of objects we can find the order in which objects must
handle actions and communications. The knowledge gained by playing scenarios (see
Section 6.5) must be used to structure the internal behaviour of an object class. Such a
behaviour description is structured as a collection of methods that sequentially call each
other.
4.16 Formalisation: Class Definitions and Types
A class definition is a formal POOSL description of the behaviour of its objects. POOSL is
an imperative language. Many alternative descriptions can be used to describe the same
externally observable behaviour. An object class definition is a behaviour specification
that is ’implemented’ using POOSL constructs. A class definition is an implementation
that represents the behaviour of a type.
This behaviour description can be used to discover and verify various properties of
a model. Notice however, that the real implementation of the system must follow the
POOSL ’implementation’, which is only a specification. This requires a transformation of
a POOSL behaviour description into an implementation language such as C, C++ or into
a hardware description. It all depends on the variety of implementation technologies
for the various system parts. The ease of this transformation is an important issue.