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

6.3 Communication 159
or to transform a data item (perform an operation). It can also be a command or simply
the reporting of an event. In this case it may be that no answer is expected. The message
can be interpreted as a request for the object to change its state.
A message name should clearly tell what the request to an object means. In general,
it is recommended to create message names such that their meaning has the notion of
a request to an object to perform some activity. The search for all necessary messages
is perhaps the most time consuming activity during system analysis. Every time a
new message is found the behaviour (operations) offered by existing objects (exported
services) may have to be extended or new objects may have to be defined.
We consider the early search for communication as an important means for finding objects
and their functions (operations). Here we differ strongly from traditional methods
such as OMT [R 91], OOA/OOD [CY91a, CY91b]. First they explicitly advise to postpone
the search for operations. They advise to seek for the objects first. They do not pay
very much attention to finding operations in the analysis phase. They focus on object
classes and their relations. Classes without explicit instances cannot visualise scenarios
of functional behaviour and communication. In traditional methods we experienced
that their non-functional class approach is less effective for reactive systems.
We recommend to focus on communication. In practice the analysis of communication
between objects leads to the need to process messages. Messages can only be processed
if an object offers the appropriate services (functions). So new messages can lead to a
need for new services. Consequently this leads to the question if such new services can
be fitted between services that an existing object class already offers. A negative answer
leads to the creation of a new class and/or to the redesign of existing classes.
Symbols and primitives expressing and showing message flows are crucial in SHE because
of the focus on communication. The visualisation of process objects and their
communication flows is perhaps the most important activity during system analysis.
Message Flow Diagrams show collaborating process objects. They are a graphical representation
of process objects (instances) and the messages between them. Message Flow
Diagrams are used extensively as a communication tool towards all persons that must
be involved in the specification process. So there is really a need that the representation
fits to the intuition of a variety of users, experts, and technicians. This enables teamwork
which is the only way to completeness of a specification. Diagrams must be clear, speak
for themselves and hide enough detail to focus on discussions of particular aspects of a
specification.
Message Flow Diagrams abstract from data objects. Data objects have rather dynamic
features. This makes it rather impractical to visualise the interconnections between
instances in a static graphical representation.
We will describe the forms of communication available for data objects as well as for
process objects in this section. We offer a set of primitives to express messages that
can be commands, requests, interrupts, etcetera. Flows represent messages that may