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

88 Abstraction of a Problem Domain
need to coalesce these objects into one object that represents the one and only identity
that has been modelled. Besides operations for testing object identity (such as ==, see
4.4.2) one can imagine a coalescing operation to support this. This subject is outside the
scope of this thesis.
4.7.3 Identification of Process Objects and Clusters
Process objects are easily recognised as identities in an instance model of a system. Since
they are visualised in diagrams as statically connected communicating instances, they
clearly exist. However there is a need for identifiers for several reasons. An important
one is to enable easy communication with users and reviewers. Objects need to have
unique names to enable this. Besides that, identifiers are often needed to describe
communication related behaviour. For instance a message to a channel with many
receiving objects connected to it may require a unique destination. Identifiers can be
used to specify their destination.
Process objects do not have predefined identifiers. Identifiers are specified as properties
(attributes) of process objects. This leaves designers a complete freedom in defining
name spaces, at an appropriate grain, possibly related to subsystems (clusters) . For example
complex distributed systems require a careful design of name spaces, translation
of names at ports, etcetera.
The use of identifiers in the description of the communication between objects is one
of the modelling options. Process objects can also communicate simply by sending
messages to channels. In this case these objects communicate in a strongly distributed
fashion. If process objects use identifiers for their collaboration they communicate in a
weakly distributed fashion. The notions of strong and weak distribution are described in
detail in Section 6.3.
Clusters cannot be identified like objects. To reason about their presence and role in the
system, however, clusters need to be identified during analysis. Object identifiers are
used to determine the destination for a communication action. Clusters, on the other
hand, cannot be given an identifier. So clusters cannot be used as named destinations.
Clusters can be named in the form of comment only, without any formal status.
The reason that clusters are not uniformly handled as objects has a specific reason. SHE
is designed to support behaviour-preserving structure transformations. These transformations
allow the modification of the structure of a specification without changing its
behaviour. The transformation of structure is performed by introducing, removing and
modifying channels and clusters. In Chapter 10 a rich collection of behaviour-preserving
transformations is developed. Together, these transformations make that a specification
can be reshaped to satisfy almost any desired structure. This transformational power is
largely due to our design decision that a cluster does not have behaviour or attributes
other than the combined behaviour and attributes of its internals. So a cluster does
not have any behaviour or attributes of its own. Therefore clusters cannot have any
behaviour for the recognition and acceptation of messages that are specifically meant