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

86 Abstraction of a Problem Domain
Recursive aggregate (contains, directly or indirectly, an instance of the same kind of
aggregate; the number of potential levels is unlimited).
Civello [Civ93] distinguishes three sorts of relations. Two of them are sorts of aggregates.
Additionally he describes a collection of semantic properties of aggregates in detail:
Strong WPAs: Functional aggregation relations (the part is conceptually included in the
whole and contributes to the function of the whole).
Weak WPAs: Non-functional aggregation relations (relations between independent entities,
as used in data modelling. Two sorts have been identified: tuples and groups).
Non-Whole-Part-Associations.
The lists of sorts mentioned above illustrate the complexity of the subject. All authors
distinguish sorts of aggregates, however there is no consensus on what properties. For
example, Rumbaugh et al. [R 91] state that aggregation is commonly encountered
in bill-of-materials or parts explosion problems. They also state that: ’unless there are
common properties of components that can be attached to the assembly as a whole, there is
little point in using aggregation.’ We do not agree with this narrow view. We consider
aggregation also as means for architecture design. Aggregates and composites can be
used for example to define a hierarchy of objects that act as controllers. A controller is a
whole object with the character of a supervisor over parts. The parts are subsystems that
on their turn may fall apart again. This kind of interpretation of whole part is needed for
complex system design. This means that besides traditional capturing of the semantics
of the problem domain, the capturing of various forms of hierarchical structure deserves
attention.
This point of view is confirmed by Civello [Civ93]. He observed that existing methods
do not give rules or guidelines for whole-part structures throughout analysis, design
and implementation. The difference between whole-part associations and other associations
is not emphasised, they are shown often only ’cosmetic and diagrammatic’. It is
however generally admitted that whole-part associations seem more strong than other
associations between classes. Especially the following statement matches with our observations:
’There are no further rules or constraints to guide design and implementation
decisions. For example, the duties of an aggregate object as owner and manager of its parts
are not sufficiently elaborated by any existing method....’ We also agree that ’most semantic
properties discussed above are not directly supported by current object-oriented programming
languages; however, as they impose important constraints on the implementation, they should
be explicitly captured in an object-oriented model’ [Civ93]. This statement legitimates our
special interest in whole-part relations, in the context of the path from analysis to design
and implementation. Civello [Civ93] describes a number of relevant properties of
whole-part relations, such as visibility, encapsulation, sharing, inseparability, ownership,
and various forms of collaborations in composites. Based on his work we interpret
these concepts for our purpose (see Section 4.8).