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

212 Modelling of Concurrent Reactive Behaviour
attributes. They are not found during analysis, but they emerge from the design of an
algorithm for the method.
The behaviour of a method is described in a user defined expression E. Such an expression
describes a sequential behaviour. Data expressions E are typically elements such
as
E m(E1 ¥¡ ¡ ¡ ¥ En) ’the message-send expression’
x ’instance variables’
u ’local variables or parameters’
self ’the object that is currently evaluating this expression’
¡ ’primitive objects, constants’
new (C) ’new data object of class C’
Data statements S are typically statements such as
E ’data expression’
x : E ’assign the value of E to x’
S1; S2
’sequential composition of statements’
if E then S1 else S2 fi ’if statement’
do E then S od ’do statement’
For examples of data class definitions we refer to Subsection 12.3.8.
6.6.5.2 Heuristics for data object modelling
The design of data objects requires a continuous awareness for striving for real objectorientedness.
The construction of data objects determines a part of the modularity in the
system. As long as objects are found in a natural way in the problem domain the word
construction may not feel adequately used. However many products nowadays contain
at least a part that is artificially constructed (designed) instead of discovered. Mature
judgement is necessary to make decisions that give an elegant model.
Data objects require special attention. They are not depicted in the Message Flow Diagrams
(see Paragraph 4.4.3.5) that play a dominant role in an analysis process. The need
for data objects in a model comes in general with the modelling of the collaborating process
objects. The variables in the process objects refer to data objects. They are private
to process objects. In addition they are used as parameters for the inter-process communication.
Data objects often model data structures. They can be joined to composites or
aggregates. Although the search for data object classes may be postponed compared to
the study of collaborating process objects, there is a point in time where the analysis of
relations between object classes becomes important.
Object classes are visualised in Object Class Diagrams (see Subsection 4.11.1). The
relations specified in these diagrams must be formalised into the behaviour description
of the system. Relations can be implemented as instance variables or as functional
behaviour. Some relations must be emancipated into new object classes. Heuristics for
class modelling are described in a very practical way for OMT in [R 91]. We recommend