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

102 Abstraction of a Problem Domain
Independently to the conceptual domain classes, objects can be ’classified’ into sorts
related to specific roles they play and specific properties they have. Objects may be
dependent or independent (autonomous), they can take initiative or wait for requests.
They may be statically or dynamically created, and ’live’ short or long. They may
have a supervisor task or a servant task in the system. These latter properties have
a more constructive style. Based on these properties objects and object classes can be
classified as ’sorts’ that are useful to discuss the design of an object model. Functional,
imperative, and active objects [Weg90] are the first three sorts discussed, and interpreted
for our method:
Functional objects are degenerate objects that do not have attributes. Their operations
are therefore side-effect-free. Data objects as well as process objects may
be built this way. Notice that this sort of object is relative primitive in the sense
that they cannot have a state, which lets them react differently in different circumstances.
Imperative objects have attributes shared by operations. An imperative object is
activated on reception of a message, it is passive otherwise [Weg90]. Data objects
are imperative objects. Process objects may be imperative objects. The internal
behaviour description consists of ’imperative’ (commanding) statements.
Active objects may already be active when receiving a message, so that incoming
messages must synchronise with ongoing activities in the object. Process objects
are in general of this sort.
Although the above ’classification’ is useful the naming of the sorts is not precise enough.
The property ’passive’ is not necessarily connected to imperative behaviour description
in our point of view. Active objects may be described as imperative. The notion ’active’
is also less precise because imperative objects will be active temporarily. Therefore we
define passive and autonomous object sorts as alternative:
Passive objects are passive unless activated by a message. (This definition causes
functional objects to become a special sort of passive object). Data objects are
always passive, process objects may be passive.
Autonomous objects determine themselves in what order what messages will be
accepted. This sort of object may actively or independently take initiative to
communicate with other objects. Only process objects can be autonomous.
In addition to these sorts we defined travelling objects and multiple objects:
Travelling objects are data objects that can be deep copied or transferred from one
process object to another. The receiving process object always gets a copy of this
’travelling object’ with a new identity.
Multiple objects. A multiple is a collection of process objects from one class, with
all objects of the multiple connected to the same channels. Individual objects may
have a different state.