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

360 SHE Framework
from a completely different point of view. Figure 11.16 shows an example of an OCD.
First OCDs make us aware of the number of classes we have. In contrast, Message Flow
Diagrams invite us to define an ’unrestrained’ number of classes, in worst case as many
process object classes as there are process objects. By concurrent development of OCD
and Message Flow Diagrams we can promote a conscious design of classes. We give
some guidelines that implicitly define requirements for tools to be developed.
We recommend to denote a class in an OCD for every new object that we define in
a Message Flow Diagram. We must consider suitable existing classes as the class
of a new object.
Parameters on message flows require that we have corresponding data object
classes. These classes require special attention in OCDs because they are not
visualised otherwise. So their design must be performed in OCDs. By exploring
their relations, attributes and messages we must try to find well balanced reusable
objects. We observed that data objects tend to be reused much more than process
objects. So extra attention will pay.
The name of each message that is received by an object in a Message Flow Diagram
must be denoted in the object’s class symbol in an OCD. This notation of
message names helps the conscious design of classes. Scenarios and even scenario
assemblies do not show all messages that can be accepted by a class. By keeping
overview on them in OCDs we can take considered decisions whether a new
classes must be defined or existing ones can be reused.
Attributes determine the abstraction that we incorporate in a model. OCDs typically
show these attributes. The traditional way of object-oriented modelling
pays a lot of attention to the modelling of attributes and relations between object
classes. For this reason we do not elaborate on this subject. We refer to [R 91] for
an extensive description of heuristics and notations.
11.4.7 Modelling of Instance Structure Diagrams
The place of the development of Instance Structure Diagrams (ISDs) in an Essential Specification
has been illustrated in Figure 11.17. This figure shows the (idealised) place of
the development of ISDs in time and its relative modelling effort. This effort is relatively
small and therefore visualised as a relatively small area in Figure 11.17. ISDs formalise
two forms of structure that usually have been developed earlier. These two forms are
Message Flow Diagrams and Architecture Structure Diagrams. An important heuristic
in the method is that the structure that has been designed in the Architecture Structure
Diagrams must be consistently incorporated into Message Flow Diagrams. If this is
done adequately the design of Instance Structure Diagrams can be a straightforward
activity. Otherwise inconsistencies are discovered and must lead to adjustments of the
models.