Whole Part1

Information and Software Technology 43 (2001) 1939
www.elsevier.nl/locate/infsof
The whole-part relationship in object modelling: a definition in cOlOr

F. Barbier a,*, B. Henderson-Sellers b
a
Departement Informatique, University of Pau, Avenue de lUniversite, BP 576, 64012, Pau cedex, France
Faculty of Information Technology, University of Technology, P.O. Box 123, Broadway, NSW 2007 Sydney, Australia
Received 7 April 2000; revised 6 June 2000; accepted 8 June 2000
Abstract
In object models built according to popular object-oriented formalisms, the commonest relationship types (excluding inheritance) are the
structural relationships of association and of whole-part (often called aggregation). This last type is well known to have no accurately
prescribed semantics. Here, some of the aggregation semantics frequently presented in the literature and sometimes supported in current
object-oriented modelling languages, especially UML, are analysed and criticised. Because of defects, the use of a modelling notation based
on these aggregation semantics is dubious and limited. Moreover, many properties are candidates for characterising the whole-part relationship provided that no redundancy and no inconsistency exist between them. A framework known as cOlOr is then offered by means of a
metamodel in which the Whole-Part metatype inherits from the Structural-Relationship metatype. Defining a specific aggregation semantics
leads then, first, within cOlOr, to the creation of a subtype of the Whole-Part metatype. Next, the behaviour of this last type is extended and/or
restricted in using a constraint-based approach. Such a process is developed particularly for considering Composition in UML and Aggregation in OML more formally, as well as for dealing with domain-dependent aggregation semantics. Since a non-negligible feature of cOlOr is
the availability of a C library that implements the proposed metamodel, some implementation concerns are also briefly discussed.
2001 Elsevier Science B.V. All rights reserved.
Keywords: Object modelling; Structural relationship; Whole-Part relationship; Aggregation
1. Introduction
Relationships in object models express structural dependencies (e.g. associations, aggregations) and behavioural
dependencies (e.g. events, collaborations) between the
objects created from the types linked by these kinds of
relationship. The research results presented in this paper
do not refer to inheritance, but focus on structural dependencies. Specifically, it is shown that the Whole-Part (WP)
relationship differs from the standard notion of object association by using the fact that structural connections between
wholes and parts must be subject to particular and precise
constraints. Unfortunately, this is rarely well defined in
object-oriented methods or in object modelling languages.
As a result, object models are intelligible only with difficulty. In that connection, Lano writes in Ref. [28, p. 52]:
Thus an analyst or designer cannot rely on the person who
reads their diagrams and textual models having the same
interpretation of what an aggregate means as themselves.
In Section 2 of this paper, we review the evolution of
* Corresponding author. Tel.: 33-5-5992-3000; fax: 33-5-5980-8380.
E-mail addresses: Franck.Barbier@univ-pau.fr (F. Barbier),
brian@it.uts.edu.au (B. Henderson-Sellers).
structural and WP relationships in Object-Oriented Analysis

and Design (OOAD), leading quite recently to the UML
[8,32,33,36] and OML [13,25] object modelling languages.
We focus on the WP relationship since its treatment in UML
has changed in comparison with its progenitor OMT [35].
We introduce a rationale to characterise this very interesting, but also controversial, kind of structural relationship.
Instead of giving a unique and unified point of view, our aim
is to supply rules to combine the most frequent features
generally assigned to the WP relationship in the literature.
In Section 3, we note that many authors use these widespread and disparate properties (lifetime dependency,
sharing and ownership for example) and thus observe that
authors disagree about what really constitutes the WP
relationship. In addition, some authors create their own
aggregation semantics that raises problems. By using an
object metamodelling framework, we try to correct this
trend in Section 4. Using a semi-formal constraint-based
approach, we rigorously define a parameterised WholePart(Whole,Part) metatype as a subtype of a (also parameterised) Structural-Relationship(Black,White) metatype.
This is the core of the cOlOr framework [1], which permits
the progressive incorporation of any chosen property into
the built-in metamodel. Within cOlOr, one of our main
0950-5849/01/$ - see front matter 2001 Elsevier Science B.V. All rights reserved.
PII: S0950-584 9(00)00133-6
20
F. Barbier, B. Henderson-Sellers / Information and Software Technology 43 (2001) 1939
concerns is to compose standard or more innovative kinds of

WP relationship which are, above all, reliable and unambiguous. Indeed, we easily prove in Section 3 that Composition
in UML is, in its current state, a non-satisfactory, not to say
dubious, modelling construct. In Section 5, in order to
justify the usefulness of cOlOr, we re-specify more
formally, using a new style, UMLs Composition as well
as OMLs Aggregation. In closing, we present in Section 6 a
short industrial application example related to a non-standard aggregation semantics. Through this example, it is
especially shown that domain-specific types of WP relationship are needed, as well as repetitive ways to implement
them. Note that the term domain is referring to a business
area in which the same business objects and business rules
are shared by applications.
2. The structural relationship in OOAD

Since the arrival of OOAD methods at the beginning of
the current decade, some methodologists have preferred the
Entity/Relationship (E/R) paradigm (e.g. OMT) or have
proposed a more innovative approach [23]. Static aspects
of systems are, in particular, specified as structural relationships and depicted according to a graphical notation often
peculiar to each specific OOAD method. Despite some
remaining differences between methods and some extensions (to the E/R paradigm in particular) the WP
relationship is often supported more or less independently
of the E/R paradigm itself. The use of E/R constructs in
object modelling, such as the notion of association, is
controversial, not to say backwards looking. It is indeed
possible to argue for alternative object modelling techniques
instead of the E/R approach. However, the E/R paradigm is,
in practice, hard to avoid because one of its main advantages
is clearly simplicity. Thus, the challenge remains to identify
a good adaptation and/or recasting of traditional E/R modelling concepts in order to establish structural relationships. In
this line of reasoning, Graham et al. in Ref. [18] underline
that the E/R-derived association concept goes against the
object orientation principles, especially encapsulation.
They endorse the need to use mappings instead of associations. What is true for association is true for aggregation but
compounded by many more difficulties. In that connection,
Civello writes in Ref. [10, pp. 378379]: While it is generally acknowledged that whole-part associations bind classes
more strongly than other associations, there are no further
rules or constraints to guide design and implementation
decisions.
The recent development of the two modelling languages
of UML and OML has certainly improved the way in which
software engineers can elaborate static object models by
using the WP relationship. In our opinion, a significant
breakthrough is the acknowledgement and then the presence
in these languages of various distinct aggregation semantics; for example, the presence in UML of what is called
Aggregation and what is called Composition, whereas OMT

offers just one kind of WP relationship. This in particular
results from the fact that an aggregation pattern fitted to a
context or domain is not necessarily appropriate in another
context or domain. Many research works have been based
on the assumption that the WP relationship is concerned
with physical objects while it must also be about logical
objects. For instance, edges are parts of graphs or facts,
events and new developments are parts of stories. Another
important current contribution is the existence of a specification through a metamodelling approach. Certainly, a
metamodel furthers comprehension of the WP relationship,
especially when a given aggregation semantics is embodied
by a type in the metamodel. Unfortunately, this principle is
not applied in UML (for example, UMLs Composition does
not appear as a class in the UML metamodel) while OML or
other proposals view each kind of aggregation as a type. For
example in Ref. [6], an enhanced approach permits consideration of Aggregate Object Type and Aggregate Relation Type as subtypes of a common supertype called
Generalised Aggregate Type. In such a metamodelling
approach, but also in others, we believe that types in a
metamodel may be described in every detail with services
they offer, as well as associated constraints they satisfy. This
idea of dynamic object metamodelling is in particular
sketched in Ref. [3].
Numerous contributions relating to the characterisation of
aggregation exist, notably that of Winston et al. [40]. In objectoriented development, methodologists have proposed
several forms for the WP relationship that they feel appropriate: for example, just one pattern in Syntropy called
Aggregation [11], one called Composition in Ref.
[26], two in UML, two in OML (Aggregation and Membership) [19] and four according to Lanos approach [28].
Other authors, non-methodologists, have carefully
described how to consistently use the notion of aggregation
in analysis and design, but rarely in implementation
except [27]. In Refs. [10,12,27,37,38] a complete study of
possible aggregation properties makes analysts and
designers aware of the complexity of the WP relationship
and, as a consequence, the difficulties of using it correctly.
Civello does not settle on modelling concerns in proposing a
method to clarify how to deal differently with the WP relationship during analysis and during design. In the sixth
section of his paper, he introduces special guidelines for
rigorously building software micro-architectures resulting
from aggregation-based models. In contrast, Saksena et al.
propose additional notations for UML in Ref. [38] while
Dong and Duke discuss additional formal modelling extensions for Object-Z. More generally, techniques to correctly
cope with aggregation in object-oriented development are
useful, because, even if most authors are in agreement on its
relevance, few of them give a non-contradictory definition
of the standard types of WP relationship. In this respect,
Bock and Odell in Ref. [4] discuss a foundation for composition with the help of a rather innovative approach, insofar
Egg
Yolk
White
Eggshell
Fig. 1. An egg regarded as a WP relationship.
as they emphasise service categories (e.g. propagating

composite operations, maintaining connection between
parts). Unlike most authors, they encourage the description
of the WP relationship through operations in conjunction
with adequate assertions (i.e. contracts).
This paper focuses on an original way to specify, use and
implement several different semantics of the WP relationship. The Structural-Relationship and WP types are firstclass types. However, in contrast with most approaches,
Whole and Part types appear in the proposed metamodel
as parameterised types of a template type embodying a
given aggregation semantics. This approach is rather different from others since it considers Whole and Part types as
examples of a generic type. As it happens, a type defining an
aggregation semantics becomes effective, and then usable,
when Whole and Part are replaced by concrete parameters,
as for instance graph and edge types. In a domain like
mathematics for example, a graph can be considered as a
fixed structure (separability is not acceptable) while in
another domain edges can be added or removed from
graphs. In other words, the semantics assigned to a WP
relationship between the graph and the edge types may
vary according to different contexts. Logically, a given
semantics cannot then be incorporated into the graph and
the edge types in order to ensure reusability of both. In that
connection, Bock and Odell in Ref. [5] encourage the
consideration of roles as types, emphasising this benefit:
One benefit of a current, or role, type is that it can introduce
operations, attributes, and associations appropriate for that
role, without cluttering the allowed type with features of all
roles. Generally speaking, special properties must not be
assigned to a type because it is connected by a structural
relationship to another type in a model. We enhance this
principle in treating Whole and Part types as anonymous
types within cOlOr. This especially ensures that the
proposed metamodel is extensible.
2.1. A rationale for the characterisation of the WP
relationship
The main problem in characterising the concept of the
WP relationship is linked to the fact that empirical concerns
are often blended with theoretical ones. In Fig. 1, we have
modelled our vision of an egg. The formalism used throughout this paper is neutral, i.e. not that of a particular object
modelling language. We just use arrows to distinguish the
21
Whole type (origin of arrow) from the Part type (end of

arrow). Indeed, there is a consensus on the fact that the
Whole type has a dominant position compared to the
Part type. So, as a modellerpractitioner, we can affirm
that the model shown in Fig. 1 includes three WP relationships. Our hypothesis throughout this paper is that there is a
mathematical binary relation between the Egg set and the
Yolk set, Egg and White as well as Egg and Eggshell.
In contrast, a methodologist may be convinced that lifetime dependency is a foundation property of the concept of
WP relationship. In other words, given an instance of the
Whole type involved in a WP relationship, its death systematically generates the death of any instance of the Part type
linked to it. This methodologist would then say that the two
relationships in Fig. 1 between the Egg and the Yolk, as well
as between Egg and White, are not aggregations. If I break
an egg to eat it, its white and its yolk in particular outlive it.
Instead, the modellerpractitioner says that lifetime dependency is not a foundation of the concept of WP relationship,
because this assumption is incompatible with his/her model
which includes three archetypes of the WP relationship.
Who is right? The modellerpractitioner is right because
by intuitiveness, an egg is meaningless without its yolk, its
white and its eggshell. More generally, we cannot ignore the
observation that the concept of WP relationship has been
introduced in OOAD methods, and next in object modelling
languages, as a special form of structural relationship. In
fact, What is an egg? is a question whose answer forces
the modeller to draw the Egg type with the three WP relationships in Fig. 1. The methodologist is also right because
he/she cannot accept that each modeller gives their own
semantics to the notation used to draw aggregations. In
more general terms, the focus of the methodologist is to
assign a semantics and a notation for a recurrent pattern of
structural relationship. Is lifetime dependency frequent in
such situations? and Is it the best characterisation for the
WP relationship? are however two debatable questions. In
that connection, Fowler in Ref. [16] evokes this problem of
notation: Modeling Principle if you come across a repetitive situation that is difficult to model, then define a notation. However, define a notation only if the resulting
simplification outweighs the difficulty of remembering the
extra notation.
Other properties than lifetime dependency are frequently
used to define the WP relationship. Some methodologists
use them while others do not. As a result, divergent meanings of the WP relationship exist. So, Aggregation in Ref.
[10] differs from Composition in Ref. [26] which is not
the same as Aggregation and Composition in UML, itself
not easily mapped to Aggregation and Membership in OML
[15], and so on. We list the common properties found in the
literature, trying to show some possible redundancy and/or
inconsistency between them. Indeed, our characterisation
rationale does not aim to arbitrarily fix what the WP relationship is. Instead, by combining the recognised properties,
necessarily rigorously defined, we obtain several subtypes
22
derived from a general rather abstract type embodying the

WP relationship. We call it the Whole-Part metatype
because it is, by definition, a central type in the metamodel
making up cOlOr. As a result, each widespread example
from the literature (car-engine, club-member, cup-handle,
room-wall, etc.) can then be viewed as an instance (a prototype) of the exhibited subtypes of the Whole-Part metatype.
2.2. Primary versus secondary properties
An excellent principle found in Ref. [37] is to classify the
properties generally assigned to the WP relationship in the
literature. In applying such a principle, we can distinguish
primary properties from secondary properties. The list of the
primary properties has to be used to characterise the WholePart metatype. In other words, any property in the list of
primary features must be viewed as a foundation of the WP
relationship. Thus, a primary property is such that any form
of WP relationship must own it. Consequently, the list of the
secondary properties is used to construct special kinds of
WP relationship. While the classification principle proposed
in Ref. [37] is interesting, the classification obtained by
applying this principle requires further evaluation and
modification. In particular, we consider that some properties
are exclusive (i.e. incompatible) to each other, as proved
later in this paper (Section 4.2). So, a set of primary properties newly appears in Ref. [20]: whole-part, emergent, resultant, irreflexivity at instance level, antisymmetry at instance
level and antisymmetry at type level. The Whole-Part metatype owns these properties, as well as others known to be
consequences of any of these six primary properties.
Subtypes of the Whole-Part metatype may then own some
of the secondary features and access the primary features by
inheritance.
Emergent and resultant properties have been regarded in
Refs. [20,26] as first-class properties for the whole in a WP
relationship. In other words, a structural relationship can be
said to be a WP relationship if (this is necessary but nonsufficient) at least one emergent and one resultant properties
exist for the whole. In the case of an egg, its freshness is
emergent in the sense that it depends upon the laying date
while its taste is resultant because it directly depends upon
its yolk and its white. In terms of computation of these
properties for instances of Whole type, resultant properties
require collaborations between wholes and parts while
emergent ones do not. Saksena et al. classify them in Ref.
[37] as primary properties as do we [20]. However, we
point out that emergent and resultant are, technically, properties of the whole rather than the WP relationship itself. In
addition, we deduce in Ref. [20] that propagation of operations (this property is declared as typical of aggregation in
OMT [35]) from wholes to parts, is a natural consequence of
grounding aggregation with the help of the idea of resultant
properties. With respect to the emergent properties, whole
objects are a kind of abstraction for part objects in the sense
that they hide from client objects how values of properties
for wholes are computed by means of parts (resultant) or not

(emergent) [25]. A remark is that some authors sometimes
disclaim our choice. For instance, in talking about the colour
of a car as a resultant property of the colour of its coachwork, Cook and Daniels in Ref. [11]] reject resultant
because they consider it to be imprecise.
There is a greater consensus on the use of mathematical
properties. However, there is no agreement for determining
which are primary properties. In particular, we consider that
the WP relationship is such that, in an object model M, typeantisymmetry applies [27]. This means that a WP relationship from a type A playing the Whole role to a type B
playing the Part role, prevents the existence of a WP relationship from B (as whole) to A (as part). This is a foundation in OML, which is called unidirectionality [15]. In
addition, the WP relationship is such that instance-irreflexivity applies [27]. Moreover, the WP relationship is such
that instance-antisymmetry also applies. Indeed, an object
o1 that is part of an object o2 prevents the contrary if o1 and
o2 are instances of two disjoint types (type-antisymmetry).
In the case when o1 and o2 are instances of two types A and
B whose intersection is not necessarily empty, instanceantisymmetry precludes o2 from being part of o1 in the
case when o1 is already part of o2. To sum up, instanceasymmetry applies due to asymmetry x; y X xRy ):
yRx , irreflexivity x X : xRx antisymmetry x;
y X xRy yRx ) x y holds while at the type level
only antisymmetry is true.
Concerning instance-transitivity, its use as a foundation
property of the WP relationship has been either overestimated [35,37,38], or carefully delimited [27,40], even
merely ignored. Membership in OML is for example not
based on instance-transitivity. Indeed, an employee is a
member of a company, which is part of a holding, but the
employee is not part of the holding in the legal sense. More
generally, numerous other examples exist which lead to put
instance-transitivity into the background. We discuss typetransitivity in Section 4.2.1.
3. Some semantics of the WP relationship

In this section, we identify some of the problems of trying
to characterise the WP relationship. In particular, errors
easily occur when secondary properties are used as if they
were first-class properties in other words, the error of
defining the WP relationship by secondary rather than
primary properties. In addition, we show that, if recognised
features of aggregation are not properly defined, they cannot
be successfully combined. This leads to flavours of the
WP relationship without creating a safe semantics from
which a notation can be generated.
Cook and Daniels point of view about aggregation [11] is
based on three possible meanings: an implied sharing of
properties, encapsulation and life-time dependency.
They consider that these three criteria may be combined

ct1
: object lifecycle
cp1
cp4
: WP linkage
cp2
cti : container i
cpj : component j
cp3
23
A more unusual, yet appealing, approach presenting

Containment is to be found in Dong and Dukes
paper [12]: it is written in this paper that this notion
is very close to aggregation or composition, although by
its definition it is clearly not identical to any other
contribution. A main focus of Dong and Dukes discussion is a detailed analysis of the WP relationship
according to a number of dynamical issues. In this
respect, three important ideas appear:
ct2
Fig. 2. Lanos fourth type of aggregation. Note that the origin of arrows
representing aggregation links does not describe the moment where the link
is created but only how wholes refer to parts.
in various ways. They specifically endorse lifetime dependency as the best choice: We choose aggregation to mean
life-time dependency; in particular, that the life-times of the
parts are contained within the life-time of the whole. The
parts are permanently attached to the whole, and cannot be
removed from it without being destroyed. Conversely,
destroying the whole destroys the parts. [11] (our
underlining). Cook and Daniels approach is appealing but
they are not clear in first saying, it might happen that:
when the aggregate is destroyed the parts may become
components of another. Indeed, this last textual extract
contradicts the sentence we previously underlined. Next,
they draw [11] a WP relationship whose cardinality near
the Whole role is 0..n. So, destroying the whole destroys
the part (the chosen meaning) but a part may have several
wholes (cardinality 0..n). Such an inconsistent situation
leads us to stress that lifetime dependency is a dangerous
property due to its incompatibility with sharing. In fact, it
would be a great pity to limit aggregation to lifetime dependency, even if physical objects behave as objects having the
same lifecycle (e.g. cup-handle, leg-femur).
Bourdeau and Chengs paper [9] is a formal proposition
using algebraic specifications. Despite the quality of the
proposed approach, no interesting semantics is proposed:
A semantics for aggregation must take into account that
the endpoints of the aggregation association are treated
somewhat differently than those of general binary associations However, the endpoints of the aggregation association cannot be interpreted, directly, as constraints on the
association. Instead, endpoints are interpreted as constraints
on the part name given as a label. [9, p. 811]. Informally,
Bourdeau and Chengs semantics relies on the following
assumption: navigation through aggregations is different
from navigation through associations. Navigation paths
are in particular defined from wholes to parts with the
help of total functions: p: Whole ! Part or p: Whole !
Part-SET (Part-SET is the power-set of the set Part). PartSET is used when an instance of Whole is connected with
more than one instance of Part. Unfortunately, most of the
usual criteria for describing the WP relationship are completely omitted in Bourdeau and Chengs discussion.
Objects may overlap and share contained objects, e.g.

two rooms may share a wall in a building. [12, p. 42].
This idea is that of shareability since may means a
potential for being shared.
The geometry of object containment of a system is
dynamic because a contained object can relocate from
one container to another in the system. [12, p. 49]
(our underlining). This idea contradicts some other
opinions that reject possible separation between wholes
and parts.
In object-oriented systems it is sometimes the case that a
contained object is actually owned by the containing
object, i.e. the containing object has exclusive control
of the contained object, e.g. as in Eiffel. However, the
notions of containment and control are in general quite
distinct and should not be confused in system modelling:
[12, p. 52] (our underlining). This meaning assigned
by Dong and Duke to Containment is in particular
based on design and/or implementation concerns (they
refer to Eiffel). A contained object (object: expanded
Type; is a statement in an Eiffel class meaning a
management by value instead of by reference) can nevertheless be exported in Eiffel, and then visible from
outside. In such a case, control is not then actually
exclusive. So, the dynamics of the WP relationship is
rather relocation than control which, in their opinion,
seems inadequate.
Each of these three approaches gives a more or less
precise idea and/or specification of the WP relationship.
Other semantics differ in the sense that they offer a finite
number of flavours of the WP relationship. Each possible
property is then assigned to a well-identified flavour, or in
certain cases, a well-formed type of WP relationship. The
formal proposition in Ref. [28] is such a contribution in
exhibiting four types of the WP relationship. The proposition is in particular ruled by some acceptable combinations
of criteria. Namely, Lano writes in Ref. [28, p. 53]: binding: whether the component can exist without being part of
this aggregate: In this respect, he considers in particular
that a bound part dies when its linked whole dies: the
lifetime of the component is contained in that of the
container. Then he considers that bound has to be used
as a foreground property, so that a structural relationship is
classified as an aggregation. He puts together bound and
shareable to build a new kind of WP relationship after
24
the object they constitute [19, pp. 5253]. Beyond

traditional structural dependencies, configurationality
supposes behavioural dependencies. It is then clear that
an aggregation intuitively generates a dynamics between
wholes and parts, at a higher degree than in a conventional structural relationship.
Generalizable Element
Association
1
connection
2..*
{ordered}
AssociationEnd
isNavigable : Boolean
isOrdered : Boolean
aggregation : AggregationKind
multiplicity : Multiplicity
changeable : ChangeableKind
targetScope : ScopeKind
AggregationKind = {none,aggregate,composite}
ChangeableKind = {none,frozen,addOnly}
ScopeKind = {instance,classifier}
Fig. 3. UML partial metamodel related to structural relationships.
having written in Ref. [28, p. 54]: sharing: whether two or

more containers can share a common part:
As a result, this type of WP relationship, the second one
in his approach, is then qualified as: strange because it
means that all containers which share a common component
at any time in their lives must in fact have coincident lifetimes. Furthermore, his fourth type with the bound and
shareable properties, extends his second type with the
replaceable property set to true (Fig. 2).
It then becomes clear that this fourth type is incorrect
because at the time when ct1 (a container) dies, cp2 (one
of its components) dies because it is bound, even though
cp2 continues to be a component of ct2.
More generally, it appears that the mixing of potential
properties to construct a type of WP relationship is a difficult task. In a different way, a paper that breaks new ground
concerning several possible meanings of the WP relationship (called meronymy) is Ref. [40]. Although this survey
covers linguistics and knowledge-based systems instead of
object-orientation, it expresses three basic facets of the WP
relationship:
Homeomerous ()/Non-homeomerous () Parts are
similar/dissimilar to each other and to the whole to which
they belong. [40, p. 420] (our underlining). Non-homeomerous is the more encountered situation as confirmed
in Refs. [19] and [31] which have adapted for object
modelling, the broad view of Winston et al.
Separability (called relocation in Ref. [12], replaceability in Ref. [28] or variance in Ref. [31]) and its
contrary inseparability are regarded as first-class criteria
by Winston et al. They are both discussed in further
details later in this paper (Section 4.2.3).
Functional or not some sorts of aggregation are functional while others are not. This criterion has a major
influence in Odells taxonomy [31] which has enhanced
functional in replacing it by configurational. Aggregation
in OML is especially configurational while Membership
is not [14,19]. More generally, a kind of WP relationship
is configurational when the parts bear a particular
functional or structural relationship to one another or
Thus, approaches differ to various degrees. Namely,

OML intensively uses the three facets above while UML
ignores them. More generally, it does not seem realistic to
study all criteria exhaustively without a strict and objective
comparison. Indeed, recurrent keywords are used unfortunately for defining, often not in the same way, the tangible
concepts of the WP relationship. So, a framework in which
different aggregation semantics coexist, and might be correlated, requires an appropriate medium. We propose a metamodel as such a medium in first studying the semantics in
UML.
3.1. The WP relationship in UML
Although endorsed as an Object Management Group
(OMG) standard, UML offers an unsuitable framework for
coping with structural relationships. Indeed, Martin and
Odell in Ref. [29, p. 192] note that the commonest form
of aggregation is configurational and variant and then
later show that Composition in UML is invariant thus
excluding the most common form of aggregation from the
representation in UML.
In Fig. 3, the metaclass Association can be instantiated
so that modellers connect entities to each other in their
models. However, the metaclass AssociationEnd plays a
greater role than Association in the UML metamodel.
This is in particular due to its attributes: Attributes aggregation, when placed on a target end, specifies whether the
target end is an aggregation with respect to the source end.
Only one end can be an aggregation. [32, Semantics, p. 18].
So, the first main attribute is aggregation to describe the
two possible kinds of WP relationship in UML: Aggregation
(value aggregate corresponding to white diamond) and
Composition (value composite corresponding to black
diamond). By definition, a pure binary association owns
two association ends, whose value of each is none. In
UML, the Object Constraint Language (OCL) constraint
self.allConnections ! select(aggregation #none) ! size
1 prevents two association ends of an aggregation
from both having the value aggregate (this applies
for a Composition too). The second main attribute is
multiplicity and is such that the cardinality next to
the composite role in a Composition is always less
than or equal to 1: self.aggregation #composite
implies self.multiplicity.max 1. The third main
attribute is changeable (Fig. 3) and, unfortunately,
there is no OCL assertion to restrict its use.
The metamodel in Fig. 3 may therefore be instantiated in
imitation of a modeller building his/her model. As a result,

Organ
Cell
Toothbrush
25
Bristle
{xor}
Tumour
Wig
Fig. 4. Two special uses of UMLs Composition.
an Aggregation (viewed as an instance of Association) is

such that one of its two association ends has of course the
value aggregate for the attribute aggregation. As for a
Composition, the value is composite. Moreover, we
discuss some variations according to the possible values
of the multiplicity and the changeable attributes. An
important problem in UML is the possibility of assigning
none (i.e. no restrictions for adding or removing objects
involved in a structural relationship) for changeable, to
the two association ends of the Aggregation. It means that a
modeller can sometimes define an Aggregation that is a
weaker form of association, e.g. an association can have
frozen (no creation and deletion of linkages) for changeable at each end. So, Aggregation in UML is simply not
useable because its semantics is too large, not to say nonexistent.
In contrast, Composition is determined by a more limiting
set of constraints, namely the non-sharing principle and that
of coincident lifetime: Composition is a form of aggregation with strong ownership and coincident lifetime of part
with the whole. The cardinality of the aggregate end may
not exceed one (it is unshared). [32, Notation Guide, p. 62].
OCL allows the cardinality near a composite in a Composition to be less than or equal to 1. In such a case, let us
consider that the association end near the type playing the
composite role (cardinality 0..1 therefore) has the value
frozen for the changeable attribute. Nothing in UML
prevents the creation of a Composition with no
composite object (this situation conforms to 0..1)
while in the future no composite object can be added! In
other words, what is a Composition with no
composite object from its birth to its death? Undeniably,
this assertion is missing: self.aggregation #composite
and self.multiplicity.min 0 implies self.changeable#frozen. In contrast, in a Composition whose cardinality
near the type playing the composite role is 1..1 (i.e.
strictly equal to 1), parts must not be separated from
the whole, because a part object must always be linked
to a whole object. A problem occurs if the attribute
changeable has none for its value, for the association end near the type playing the component role.
More formally, we can write: self.aggregation #
composite and self.multiplicity.min 1 implies changeable#none for the other association end. There are in
fact many other combinations that lead to inconsistent
cases.
While the metamodel in Fig. 3 definitively remains ill
fitted, some correct uses of Composition are nevertheless
possible. A global solution is first to remove the value
none for changeable. Next, OCL may help the verification of compatible values between changeable and
multiplicity, for both association ends of a Composition. An extreme, but surely simple, solution is to definitively regard Composition as a fixed (frozen, no links
may be added after the creation of the source object.
[32, Semantics, p. 18]) structure with the cardinality
near the composite role being 1..1. In this case,
changeable becomes redundant because its value is
always frozen for each end. As with multiplicity,
it becomes useless for the association end embodying
the composite role.
Thus, Composition with the changeable attribute set to
frozen seems close to Lanos first type of aggregation
(bound, not shareable and not replaceable). Moreover, Composition with the changeable attribute set to
addOnly seems close to Lanos third type of aggregation
(bound, not shareable and replaceable). The difference is that, what Booch et al. say in Ref. [8]: Parts with
non-fixed multiplicity may be created after the composite
itself, but once created they live and die with it. is somehow in conformance with Lanos third type. As noted in
Ref. [21], this is not truly coincident lifetime because the
birth of wholes and parts does not coincide, even it is true
for the death.
Behind all of these observations appears the main drawback of the UML metamodel fragment in Fig. 3: Composition has not been viewed as a subclass of Association and
is not associated with the notions of emergent and resultant
properties. Even if the two new OCL expressions introduced
above improve the situation, to impose coincident lifetime
nevertheless remains difficult. Destroying the whole
destroys the parts is safe only if the Whole type properly
encapsulates the Part type. In Fig. 4(a), this does not seem to
be apply because an organ and a tumour may share a cell. Of
course, destroying the tumour leads to destroy the ill cells,
but the organ remains with the healthy cells. Paradoxically,
destroying the organ leads to destroy all the cells and then
justify our use of Composition! So, what is the best model?
The UML metamodel is incomplete in the sense it includes
no information in order to answer such a question. Civello in
Ref. [10]] usefully raises the problem in saying that A
shared part object cannot be encapsulated, as it must be
visible to more than one composite. In Fig. 4(b), the
model is more satisfactory since an exclusiveness constraint
is used (i.e. {xor}). In taking care of Civellos recommendation, it appears that encapsulation for the WP relationship
has to be formally defined (this definition will necessarily
exclude the possibility of sharing, especially in subtle cases
26
instance of
Whole-Part
Whole
Part
instance of
Metalmodel level
instance of
Model level
Instance level
Fig. 5. The WP relationship at the metamodel, model and instance levels.
as in Fig. 4) so that one can next, and only next, deal with the
idea of coincident lifetime.
4. Dynamic metamodelling for the WP relationship

In this section, we propose our own framework to define
the concept of WP relationship. We aim to clarify, and next

formalise, this concept in order to favour the potential
implementation of object models that include WP relationships. This framework is, in particular, defined by means of
object metamodelling to make a comparison between OML
and UML. This completes some elements of the discussion
in Ref. [24].
Role(T)
cardinal : Integer
role : set of T
Invariants:
cardinal = #role
whites
0..1
blacks
0..1
Black
White
Structural-Relationship(Black,White)
add(Black,White): Role(Black) x Role(White)
cardinality(Black): Integer
cardinality(White): Integer
min-Black, max-Black, min-White, max-White: Integer
remove(Black,White): Role(Black) x Role(White)
Invariants:
2
(Black,White) M (Black White) Structural-Relationship(Black,White) Structural-Relationship(White,Black) =
(b,w) Black x White (b blacks(w).role w whites(b).role) blacks(w) nil whites(b) nil
b: Black cardinality(b) = whites(b).cardinal
b: Black min-White cardinality(b) max-White
w: White cardinality(w) = blacks(w).cardinal
w: White min-Black cardinality(w) max-Black
const min-Black ; min-Black 0
const max-Black ; max-Black > 0 max-Black min-Black
const min-White ; min-White 0
const max-White ; max-White > 0 max-White min-White
Pre-conditions and post-conditions:
add: Section 3.2.4 of this paper
b: Black cardinality(b) [whites(b) nil] / []
w: White cardinality(w) [blacks(w) nil] / []
remove: Section 3.2.3 of this paper
Creation:*
(i,j,k,l: Integer) [] / [i = min-Black j = max-Black l = min-White k = max-White]
Whole-Part(Whole,Part)
Invariants:
Whole Black
Part White
min-Whole min-Black ; max-Whole max-Black
min-Part min-White ; max-Part max-White
Fig. 6. Core of cOlOr. The two referential metarelationships from Structural-Relationship to Role support an access key (or qualifier), whose type is Black for
the first and White for the second.
instance of
27
b1
b2
b3
a1
Role(B)
whites
0..1
A
A
Structural-Relationship(A,B)
instance of
a1
b1
b2
b3
Fig. 7. At the metamodel level, T, Black and White have been replaced by effective types (Role(A) is not shown) due to the existence in an object model M of a
structural relationship between A and B.
In Fig. 5, at a metamodel level, is shown the metatype

Whole-Part. Next, an instance of the metatype Whole-Part is
depicted at a model level: types Whole and Part are involved
in this instance of Whole-Part. Finally at an instance level,
an instance (w) of Whole is connected with an instance (p)
of Part in conformity with what is represented at the model
level.
4.1. cOlOr framework
In order to express the properties generally assigned to
the concept of WP relationship, we organise metatypes in
the metamodel, not only in a structural way (i.e. in using
connections with other metatypes) but also with the help of
operations suffered by these metatypes, as well as
constraints (i.e. assertions) associated with them. For that,
a notion of parameterised type is used, as well as a textual
formalism. There is a similarity between the properties of
parameterised metatypes in our framework and functions in
descriptions of abstract data types.
An important idea is to construct the WP type in deriving
the Structural-Relationship type. Another significant idea is
to regard Whole and Part as parameters of the metatype
Whole-Part in the metamodel of Fig. 6. In Fig. 6, the
arrow with two parallel lines means subtyping while the
two other arrows mean referencing. The Structural-Relationship metatype itself is parameterised with the symbolic
types Black and White. As a result, an invariant of the WP
metatype is Whole Black Part White with
meaning syntactically equivalent or renaming. We
remind the reader that UML offers a metaclass called Association which is close to the concept of structural relationship in cOlOr. Moreover, cOlOrs Black and White types
are regarded as two instances of Classifier. The Classifier metaclass is linked to AssociationEnd in the UML
metamodel thanks to an association (role type with
cardinality strictly equal to 1 near Classifier) [32, Semantics, p. 17]. In OML, the metatype Referential Relationship is linked to one and only one Client, as well as to
one and only one Server.
In Fig. 6, we focus on a new metatype called Role(T)
which is itself parameterised by the type T. Thus, given
an instance b of Black, there potentially exists one rb
instance of Role(White) such that rb embodies the set of
elements, instances of White, linked to b. In other words,
we have Structural-Relationship(Black,White)[b] rb in
which the square brackets act as an access operator and b
acts as the key. Intuitively, Role(T) describes the mapping
from Black to White when T is equal to Black, and viceversa. Fig. 7 gives an overview of the above principle. In
Fig. 6, two metarelationships from Structural-Relationship
(Black,White) to Role(T) indicate navigability. In Fig. 7,
given the type Structural-Relationship(A,B) from which
an instance is created to represent a structural relationship
between two types A and B in an object model M (Venn
diagram interpretation, bottom right), Role(B) is instantiated for each existing instance of A. An instance of
Role(B) is depicted here (Venn diagram interpretation, top
right) for an instance of A (a1) linked to three instances of B
(b1, b2 and b3).
28
Role(T)
whites
0..1
blacks
Compound(T)
wholes
0..1
0..1
Component(T)
parts
0..1
[redefines]
[redefines]
Black
White
Whole
Part
Fig. 8. Introduction of Component(T) and Compound(T) as subtypes of Role(T).
Directionality and navigability concerns are often

mismatched. Directionality aims to describe the coupling.
From the Whole type to the Part type is often preferred
because this results from the way propagation of operations
occurs [20]. However, some contributions do not analyse
aggregation according to collaboration criteria [12,27]
while other authors accept a direction from Part to Whole
as being valid and useful [10,37,38]. In UML, the association ends of an association are ordered and, for an Aggregation and a Composition, the first association end has for its
type Whole while the second has Part. Navigability aims to
represent the constrained way in which wholes depend on
parts, and vice-versa. We especially show in Section 6, that
navigation expressions may reduce directional possibilities.
Regarding cOlOr, we extend the metamodel fragment in
Fig. 6 so that two kinds of role can be distinguished. Our
general purpose is to permit constraints to be written for the
Whole role which are not necessarily applicable to the Part
role, and vice-versa. We manage the Whole role through
the parameterised metatype Compound(T) and the Part
role through Component(T) (Fig. 8). The [redefines]
constraint is used in order to reconsider the two metarelationships inherited from Role(T).
This metamodelling style is such that we divide the
content of each metatype into four parts. The first (always
depicted on the top of a box) contains the functions offered
by a type, e.g. in Fig. 6, the role operation defined for
Role(T) is a function returning a set of T. The second part is
called Invariants. The third concerns pre-conditions and
post-conditions for functions. The following textual notation (annotated by ) is intensively used in the rest of
the paper:
hypothesisoperation [pre]/[post]
Finally, the fourth and last part of a box is named Creation and corresponds to the creation protocol. This part is
annotated with in Fig. 6 because we refer to it in
Section 4.2.5.
In Fig. 6, we have fully specified the functions supported
by Role(T). For Structural-Relationship(Black,White), we
argue about its detailed specification in Section 4.2. As
subtypes, Compound(T), Component(T) and Whole-Part
(Whole,Part) conform to these functions but define their
own constraints. There are some functions to compute the
current cardinality as well as its maximum and its minimum.
Moreover, we have made the assumption that, by definition,
a structural relationship is an evolving structure. In other
words, instances of Black and White can be freely
connected to each other, so long as the maximum and minimum cardinalities are respected. So, the Structural-Relationship metatype is flexible enough to cover what is
generally known as a general-purpose association in an
object model.
4.2. A characterisation of the WP relationship
The characterisation discussed here enhances that in Ref.
[20]. The chosen primary properties remain the same while
the secondary properties are formalised in a different way to
build well-formed and specialised types of aggregation.
4.2.1. Encapsulation
Encapsulation is a secondary property in Ref. [20]. It is
used here as a partition in order to define four categories of
coupling between the Whole type and the Part type. For an
object (a part), it can, in particular, be said to be encapsulated by another one (a whole) if the whole is the only object
in the total system at any moment which handles a reference
one of its two ends as an instance of Part (or of Whole) is

necessarily related to WP. A rapid analysis of the definition
of strict encapsulation may lead us to believe that it is too
rigid, i.e. no example matches it. However, as shown below,
it is needed for use in conjunction with other properties
generally owned by the WP relationship.
Weak Encapsulation (WE). This form is introduced to
give some flexibility and to support Bock and Odells
broader view of the WP relationship [4]. Thus, given an
object model M as a set of types, given Whole and Part as
elements of M and a WP relationship from the Whole type
to the Part type (called WP in Fig. 10) and for any X belonging to M, there can exist a structural relationship between X
and Part (called SR in Fig. 10), if:
Fig. 9. Strict encapsulation for the WP relationship.
to the part. Models can be such that types are linked by WP

relationships for promoting some styles of coupling between
the types. These styles may themselves greatly limit nonencapsulation of instances. The set of necessary and sufficient conditions for instance-encapsulation is discussed in
Section 4.2.2.
Principle of Encapsulation for the WP Relationship
(beware that our definition is dedicated to the WP relationship while encapsulation has a more extensive meaning in
object orientation): any subtype of the WP metatype in Fig.
6 can be said to satisfy encapsulation if and only if:
Strict Encapsulation (SE). Given an object model M as a
set of types, given Whole and Part as elements of M and a
WP relationship from the Whole type to the Part type (called
WP in Fig. 9) and for any other X belonging to M, there is no
structural relationship between X and Part (Fig. 9(a)). For
X Whole or for X Part, the previous definition
prevents the existence of another relationship between
Whole and Part and, respectively, a self-relationship
concerning Part. So, the principle of strict encapsulation
is considered violated in a model M if at least one structural
relationship exists between X and Part. We call it SR in
Fig. 9(b).
However, different kinds of the SR relationship can be
studied, especially if SR is itself a WP relationship from Part
to X (Fig. 10(a)). This leads to a commonly occurring situation, i.e. a cascade of WP relationships. We propose that,
even if SR is a WP relationship from Part to X, strict encapsulation does not hold in a model M. Consequently, we add
a second definition of encapsulation: weak encapsulation
(see below). As before, we give the cOlOr invariant which
may be assigned to any subtype of the Whole-Part metatype
in order to characterise it by strict encapsulation. Note that
in the rest of the paper, we use P ! Q; R , P ) Q
not P ) R :
(WE-a) SR is itself a WP relationship from Part to X (Fig.

10(a)). While X Whole does not satisfy typeantisymmetry, X Part is acceptable. Indeed, even
though instance-irreflexivity is a primary property of
aggregation, type-irreflexivity is not. So, the case
(WE-a) is refined by replacing for any X belonging
to M by for any X belonging to M with X
Whole. However, it is important to notice that this
definition (WE-a), alone, cannot be assigned to a possible
subtype of the Whole-Part metatype, because it is based
on recursion without a starting point. For example,
factorial can be recursively defined only if a starting
point is given: factorial(0) 1. So, the case (WE-a) is
refined once again more precisely: SR is an instance of
Whole-Part-SE(Part,X) with Whole-Part-SE(Part,X) as a
subtype of Whole-Part(Whole,Part) and owning the
property of strict encapsulation.
(WE-b) SR is itself a WP relationship from X to Part
(Fig. 10(b)). Note that in the case (WE-b), X Whole
Whole and X Part are tolerated. One can consider
this case to be marginal but it is quite used in the literature [17,26,37], and is comparable to the two models in
Fig. 4.
(WE-c) SR is a direct instance of cOlOrs StructuralRelationship metatype in Fig. 6. The direct means
that SR IS NOT in any way (or does not behave as) an
instance of the Whole-Part metatype and there is a WP
relationship from Whole to X (called WP in Fig. 10(c)).
In other words, the existence of WP implies that SR
CANNOT BE a WP relationship. Let us imagine WP
simultaneously existing with SR as a WP relationship
from X to Part. This leads to high coupling as well as
an unclear and tortuous model. Now from Part to X,
the same conclusions apply. Moreover, a possible
Given (Whole,Part) M M and WP: WholePart (Whole,Part), X MX X Whole ! StructuralRelationship (X,Part) , Structural-Relationship
(X,Part) {WP}
In other words, at the instance level, any linkage that has
Whole
WP
Part
Whole
Part
Whole
SR
SR
(a)
WP
(b)
29
WP
X
(c)
Fig. 10. Weak encapsulation for the WP relationship.
WP
Part
SR
X
30
Car engine
Car
WP1
WP2
SR
Front axle
WP3
Part of front
axle
Fig. 11. Mixing of some encapsulation characterisations for the WP
relationship.
application of type-transitivity violates type-antisymmetry. Finally, note that for the case (WE-c), X Whole
and X Part are permitted.
As shown in the model in Fig. 11, WP1 is an instance of a
subtype of the Whole-Part metatype that owns the property
(WE-c). WP2 is an instance of a subtype of Whole-Part that
owns the properties (WE-a) or (WE-c). Finally, WP3 is an
instance of a subtype of Whole-Part that owns the property
of strict encapsulation. What does not appear in Fig. 11 is a
dedicated notation for each of these subtypes.
Encapsulation, as described above, is a first step in guiding how models have preferably to be built. However,
encapsulation has deeper impacts at the instance level that
requires further refinement. In Fig. 12, we first add four new
metatypes (we write inside the boxes just what is new
compared to what is already specified in Fig. 6). They correspond to our four definitions of encapsulation and are used
next, as for dealing with instance-encapsulation.
4.2.2. Sharing and non-sharing
There is often a general assumption for the notion of
sharing in the literature. As it happens, some approaches
(in UML or in Ref. [15] for example) consider sharing in an
object model M, for a given WP relationship. In Ref. [26],
they extend such an assumption in talking about local/
global sharing as well as local/global exclusiveness.
Local sharing is the sharing principle supported by

UMLs Aggregation (cardinality max near the white
diamond is sometimes greater than 1). Local exclusiveness is the non-sharing principle supported by UMLs
Composition (cardinality max near the black diamond is
always equal to 1). Global exclusiveness (conceptual
sharing in Ref. [37]) can be safely managed in the UML
by using the {xor} constraint for the white diamond. For
instance, in Fig. 13, the absence of {xor} means that
instances of Picture may be shared. For Composition in
the UML, the presence of {xor} (Fig. 4(b)) is an embarrassing problem because nothing is stated in Refs. [32,33] in
order to tolerate or purely reject such a utilisation. Finally,
global sharing joined to local sharing seem to be fully
characterise UMLs Aggregation, as far as the model in Fig.
13 is acceptable in the UML. At a given time, an instance of
Book and an instance of Article can possibly share an
instance of Picture. This corresponds in particular to the
case (WE-b) in Section 4.2.1 (Fig. 10(b)).
In addition, most authors study sharing according to three
levels.
Level 1: WP relationships in a model M are such that an
instance of a type Part can be referenced by more than
one instance of a type Whole in a given WP relationship
between these two types. In Ref. [37], they call it homogeneous sharing while in Ref. [27], they call it local
sharing.
Level 2: WP relationships in a model M are such that an
instance of a type Part can be referenced by more than
one instance. Between them, we are nevertheless sometimes able to find at least two instances which do not
come from the same type (Fig. 13 demonstrates that a
specific use of UMLs Aggregation can generate such a
situation). In a model M, this supposes at least the existence of two WP relationships with Part playing the Part
role in both. In Ref. [37], they call it heterogeneous
sharing while in Ref. [27], they call it global sharing.
Level 3: Civello in Ref. [10, p. 385] writes Sharing. An
object is shared if two or more objects hold references to
it. It appears that we implicitly always regard sharing
within the scope of the WP relationship: could we talk
Whole-Part-WE-c(Whole,Part)
Whole-Part-WE-b(Whole,Part)
Whole-Part-WE-a(Whole,Part)
Whole-Part-SE(Whole,Part)
Invariants:
2
(WP1,WP2) Whole-Part-SE(Whole,Part) , X M
X Whole -> Structural-Relationship(X,Part) = , Structural-Relationship(X,Part) = {WP1 = WP2}
Fig. 12. Extension of cOlOrs core in dealing with encapsulation.
Book
Picture
Article
Fig. 13. An extended view of the sharing principle of UMLs Aggregation
(cardinalities are not expressed).
about sharing between X and Part in of Fig. 10(c) for

example? According to Civello, the answer is yes
because even if no direction between X and Part is
decided in this figure, direction may be later implemented from X to Part. Furthermore, most papers, like this
paper, prefer to view references from the Whole type to
the Part type. Intuitively, nobody really accepts that Part
instances refer to Whole instances. For the three models
in Fig. 10, except the one named (b), it appears that an
instance of Part may be shared by an instance of Whole
and an instance of X has no generally agreed meaning.
Within cOlOr, sharing is the default status of the Structural-Relationship metatype. Therefore, non-sharing may
be attributed to a potential subtype of the Whole-Part metatype, using an invariant, as follows: max-Whole 1.
Note that max-Whole is an operation of the Whole-Part
metatype, establishing the cardinality max near the type
playing the Whole role. If max-Whole 1 is true, then
we called that non-sharing. This invariant satisfies Level 1,
but it is not fully reliable for Levels 2 and 3.
In characterising any subtype of WP with the non-sharing
rule described above, modellers must be aware of the
problem in the two models in Fig. 10(c) (instances of X
may hold references to instances of Parts). In order to
solve this problem, we stress the idea of part-encapsulation
by relying on strict encapsulation:
Given (Whole,Part) M M and WP: Whole-Part
(Whole,Part), X MX X Whole ! StructuralRelationship (X,Part) , Structural-Relationship
(X,Part) {WP}
max-Whole 1
In other words:
Part-encapsulation , strict encapsulation
non-sharing
In practice, this equivalence basically ensures that a
model M is constructed such that any instance of Part is
linked to at most one instance of Whole and no instance
of another type. Indeed, strict encapsulation prevents the
existence in M of any structural relationship involving
Part, except a single WP relationship from Whole to it.
Thus, the definition of non-sharing, alone, can be efficiently
31
added, if desired, to the specification of not only the WholePart-SE metatype (Fig. 12), but also the Whole-Part-WE-a
(we called that part-encapsulation based on WE-a) and
Whole-Part-WE-c (we called that part-encapsulation
based on WE-c) metatypes in Fig. 12. Finally, adding it
to Whole-Part-WE-b is possible but is not safe at all
because, by definition, instances of Part may be shared by
instances of two different types (Fig. 10(b)).
4.2.3. Separability and inseparability
As was the case with sharing, separability is, within
cOlOr, the default status of the Structural-Relationship
metatype. As a result, we may want to specify inseparability
and consider that such a property has to be given to a possible subtype of the Whole-Part metatype. Within cOlOr, the
remove operation of the Structural-Relationship metatype
is, in particular, used so that linkages between instances of
the two types participating in a given structural relationship
disappear.
Civello in Ref. [10, p. 385] emphasises Whole-Part
Inseparability as well as Part-Whole Inseparability.
However, he blends separabilityinseparability concerns
with lifetime dependency concerns. As it happens, with
Whole-Part Inseparability, an inseparable whole is such
that The part object cannot be deleted without causing the
deletion of the whole. Moreover, he considers that the lifetime of the whole is included within that of its part. Instead,
we give here a less restrictive definition and defer the analysis of lifetime dependency concerns to Section 4.2.5. As a
result, keeping Whole-Part Inseparability and PartWhole Inseparability is not justified within cOlOr.
Principle of separability for the structural-relationship
metatype
Invariants:
(b,w) Black WhiteX (b blacks(w).role , w
whites(b)role) ) blacks(w) nil whites(b) nil
This invariant means that the existence of a linkage
between b and w is materialised by an access for b,
respectively for w, to its linked whites, respectively
its linked blacks. Consequently, the multiplicity
constraint 0..1 of both metarelationships from
Structural-Relationship(Black,White) to Role(T) is
necessarily equal to 1 (i.e. if a linkage between b
and w exists.
Pre-conditions and post-conditions: (see for the
general form and note that in the rest of the part the use of
apostrophe means new value)
(b,w) Black WhiteX remove(b,w) [b blacks
(w).role]/[blacks(w).role blacks(w).role {b}
whites(b).role whites(b).role {w}]
In Fig. 7 for instance, whites(a1) is an instance of
Role(B), whites(a1).role {b1,b2,b3} and, as a result,
whites(a1).cardinal cardinality(a1) 3. After removing (a1,b1) for example, whites(a1).cardinal 2 and
blacks(b1).role blacks(b1).role (i.e. ) {a1}.
32
Thus, for a potential subtype of the Whole-Part metatype,

we recommend the altered behaviour as follows:
Inseparability , (w,p) Whole PartX
remove(w,p)[false]/[ ]
We give here a simple and, above all, open characterisation
of separability and inseparability. For some authors, inseparability of a Part instance in relation to a Whole instance
implies that the whole is responsible for destroying the
part. This seems suitable for consistency: at the time the
whole dies, the part must die with it because it cannot be
separated. In our strict definition, we prefer to consider that
the death of the whole generates the deletion of the linkage
(implicitly) to the part without destroying the part itself. In
fact, our characterisation is such that inseparability does not
prevent dissociation in a special case: the end of the life for
the whole and the end of that of the part. Such a choice is
debatable but has more advantages than it has drawbacks,
especially because the authors who emphasise automatic
propagation of creation and/or deletion of parts and/or wholes
raise many problems in their semantics. For instance in Ref.
[37], if the lifetime of Part instances are contained within
that of instances of Whole, for a WP relationship, then parts
cannot be separated. Such a rule is cumbersome: a human
being is made up of a heart. Shall we say that the lifecycle of
the heart is contained in that of the human being? In a biological sense, the answer is yes, but the heart may be separated
in case of serious heart trouble. Such an event is by definition
the lifetime end of the part. The other case is when the human
being dies in special circumstances permitting its heart to be
reused for someone else. Such an event is by definition the
lifetime end of the whole. So, in order to model a Human
being-Heart WP relationship within cOlOr, we paradoxically,
but nevertheless consistently, consider it as an instance of a
metatype owning inseparability. In fact, we consider that
inseparability does not preclude dissociation at the end of
lifetimes. More generally, inseparability is viewed independently of lifetime dependency.
4.2.4. Mutability and immutability
An immutable WP relationship is such that the Whole and
Part instances involved in it do not change over time in
identity and in number. In fact, this number must be set in
the interval used for expressing multiplicity constraints. In
Fig. 1, an egg is made up of a white part, a yolk part and an
eggshell part. It is not possible to change the eggshell part of
an egg by using another eggshell instance (identity stability), or by substituting nothing (number stability). In addition, one cannot replace the egg, considered as the whole,
according to any WP relationship among the three in Fig. 1.
More generally, multiplicity constraints for these three WP
relationships are crucial properties.
Civello in Ref. [10, p. 387] introduces a subtle example
about immutability: A sailing boat, for example, needs a
sail (inseparability), but the sail can be changed for an
equivalent sail without affecting the function of the boat.

Inseparability is here different from our use of the word in
Section 4.2.3. Civellos illustration of immutability is such
that Whole instances remain the same in identity while Part
instances are not subject to such a constraint. So, he outlines
that immutability implies Whole-Part Inseparability.
Moreover, if a sailboat, during a temporary repair, has no
sail, then it cannot be (or be called) a sailboat. More
formally, the strict respect of multiplicity constraints (at
least one sail) of this WP relationship can be set, for convenience, to false over time. What is central to understand is
that without the sail role, the sailboat notion is meaningless.
Civellos definition of Whole-Part Inseparability is
nevertheless not always adequate, because it means the
sail object cannot be deleted without causing the deletion
of the sailboat. (Section 4.2.3: we replace part by sail
and whole by sailboat). Even if this applies at the design
level (i.e. for software entities), his choice imposes the
destruction and, next, the creation of sailboat instances
when sails are deleted. This reinforces our conviction that
lifetime dependency is unrelated to separabilityinseparability concerns.
What is more certain is that immutability is connected
with inseparability. Within cOlOr, we first ensure that
Whole and Part instances involved in a WP relationship
do not change in identity over time by considering that
immutability ) inseparability. Next, we need participating Whole and Part instances not to change over time in
number. For that, we review the behaviour of the add
operation in the Structural-Relationship metatype.
Principle of evolution for the structural-relationship
metatype
Pre-conditions and post-conditions: (see for the
general form)
(b,w) Black WhiteX add(b,w)
[blacks(w) nil whites(b) nil b
blacks(w).role]/[blacks(w).role
blacks(w).role {b} whites(b).role
whites(b).role {w}]
Thus, for a potential subtype of Whole-Part metatype, the
assertion relating to immutability is as follows:
Immutability , inseparability ((w,p)
Whole Partadd(w,p)[false]/[ ])
We take care not to mix encapsulation(non-)sharing on
one side, and (in)separability(im)mutability on the other
side. In our opinion, these two major characteristics are
unrelated to each other. In this respect, immutability is
concisely defined to obtain, if desired, fixed (i.e. frozen)
WP structures. For example, a Room-Wall WP relationship
is known to be a fixed structure while sharing may occur
when two rooms share the same wall.
Whole
1..max-Whole
WP
Part
0..max-Part
Whole
0..max-Whole
WP
Part
1..max-Part
Whole
33
Part
WP
1..max-Whole
1..max-Part
(a)
(b)
(c)
Mandatory participation for Part
Mandatory participation for Whole
Mandatory participation for Part

and Whole
Fig. 14. Mandatory versus optional participation.
4.2.5. Lifetime dependency

In essence, the notion of lifetime dependency requires
dealing with the creation and the deletion of objects.
Numerous programmers (notably those using C because
they have to manage their own deletion policies) view
lifetime dependency as a fundamental principle of the
WP relationship. In object modelling, lifetime dependency is surely a most dangerous notion, and is the
bete noire of the WP relationship in general [17].
We first observe that authors who have placed this
notion under the spotlight have offered unsatisfactory
descriptions and definitions. We next believe that specifying the deletion of objects presumes the existence of
deletion capabilities, which refer to object-oriented
programming languages. Whitmire shares such a point
of view in Ref. [39]: Whether the parts survive as
independent objects or are destroyed along with the
whole should be a deliberate design decision and a
prominent part of the design. Either way, it is not an
inherent part of the aggregation relationship. So, our
approach then is to specify coincident birth of wholes
and parts, as well as to give necessary but non-sufficient
conditions for coincident death of wholes and parts
whilst deletion remains an implementation-dependent
consideration.
Within cOlOr, we are convinced that lifetime dependency
between instances of the Whole and Part types is strongly
connected with the way multiplicity constraints are
expressed for both roles. In this line of reasoning, Kilov
and Ross in Ref. [26, pp. 9091] talk about mandatory/
optional participation of instances of both types, playing
the two roles in a structural relationship. They especially
define mandatory participation as: the existence of an
instance of the entity implies the existence of a corresponding instance of the association The invariant for an entity
with mandatory participation in an association implies that
both the entity instance and the first corresponding association instance must be created in the same business process.
Fowler and Scott confirm in Ref. [17] that a general-purpose
association, using a 1..1 cardinality for example, is indicative of some lifetime dependencies. However, classifying
it as an aggregation requires further analysis.
Within cOlOr, by the use of dynamic object metamodelling, we are able to cope with the lifecycle of Part and
Whole instances, as well as the lifecycle of linkages managed through the Whole-Part metatype.
Coincident birth of Part instances with WP linkages (i.e.

the life start of any part cannot precede the creation of any of
its linked wholes)
min-Whole 0
In essence, if min-Whole 0 (Fig. 14(b)), it means
then that Part instances have an optional participation in
the WP relationship. In that connection, as underlined
above, UMLs Composition basically relies on the
assumption of coincident lifetime while the cardinality
min near the composite role may be equal to 0 (some
fragments of the UML metamodel use such a hypothesis).
So, min-Whole 0 is a necessary but non-sufficient
clause. In addition, p PartX min-Whole cardinality(p) max-Whole is an inherited invariant (Fig.
6). If 0 min-Whole max-Whole then, over time,
the number of linkages between a given instance of Part
and instances of Whole, may vary. If min-Whole
max-Whole (no variation), then the creation of Part
instances must coincide with the creation of their linkages
to Whole instances (i.e.p Part X cardinality(p)
min-Whole max-Whole). In order to be able to deal
with the general case (i.e. 0 min-Whole maxWhole) we add:
(w,p) Whole PartX add(w,p)[false]/[ ]
This clause simply prevents creating new linkages. As a
result, the creation process of the WP relationship
becomes critical because it must support the creation of
Part instances. Kilov and Ross talk about the same business process. Nevertheless, adding this property does
not guarantee that Part instances are created for and
only for the purpose of being components of composites, instances of Whole. In order to formally specify
such a constraint a logic with temporal operators is
needed. For example, in Ref. [28], values of expressions depend on time. Instead, we propose a simpler
way.
Given an instance b of Black (respectively, w of White),
the assertion whites(b) nil (respectively, blacks
(w) nil) is only true from the life start of b (respectively, of w). Note that in Fig. 6 the multiplicity constraint
is 0..1 near the blacks and whites roles played by
the Role(T) metatype. Consequently we specify that,
given an instance b of Black so that whites(b) nil,
means that b does not yet exist at the time of the expression evaluation. This astuteness is used for avoiding
34
specifications which could be cumbersome at implementation time, i.e. requiring a specific technique for the
creation of objects. As a result, in regard to the creation
process of the WP relationship, the following pre-condition is required: p PartX wholes(p) nil. This
means that no instance of Part existed at any moment
before linkage creation. To complete the specification
we write:
Creation: (this signature complements the general form
indicated by in Fig. 6)
( ) [p PartX wholes(p) nil]/( )
Coincident birth of Part and Whole instances with WP
linkages
We already have:
min-Whole 0
(w,p) Whole PartX add(w,p) [false]/[ ]
And we symmetrically add (mandatory participation
for Whole instances):
min-Part 0
Finally the creation protocol is modified as follows:
Creation: (this signature complements the general
form indicated by in Fig. 6)
( ) [p PartX wholes(p) nil w
Wholeparts(w) nil]/[ ]
Coincident death of Part instances with WP linkages
(necessary but non-sufficient)
min-Whole 0
If Part instances have optional participation, they
can exist before Whole instances to which they
will be connected (see above), as well as being
able to outlive the Whole instances to which they
were connected. So min-Whole 0 is once again
necessary.
part-encapsulation part-encapsulation based on
WE-a
Part-encapsulation is a safe mode because it supposes
non-sharing as well as the absence of references to
parts, except that of their single whole.
(w,p) Whole PartX remove(w,p)[false]/[ ]
Moreover, inseparability is obviously necessary.
Coincident death of Part and Whole instances with WP
linkages (necessary but non-sufficient)
We already have:
min-Whole 0
WE-a
(w,p) Whole PartX remove(w,p) [false]/[ ]
And we symmetrically add (mandatory participation
for Whole instances):
min-Part 0
Coincident lifetime (necessary but non-sufficient)
min-Whole 0
(w,p) Whole PartX add(w,p)[false]/[ ]
min-Part 0

WE-a
(w,p) Whole PartX remove(w,p) [false]/[ ]
Creation: (this signature complements the general
form indicated by in Fig. 6)
( ) [p PartX wholes(p) nil w Wholeparts
(w) nil]/[ ]
A synthesis of the previous expressions shows that coincident lifetime implies immutability (inseparability plus no
addition of linkages) and non-sharing (from part-encapsulation or part-encapsulation based on WE-a). This consequently requires that 0 min-Whole max-Whole 1
(from non-sharing). This especially confirms that the
cardinality near the composite role of UMLs Composition
must not be 0..1 but 1..1.
4.2.6. Other properties
In the list of numerous candidate properties, most of them
have an unclear and/or imprecise meaning. We analyse in
detail ownership because it is in widespread use in the literature. However, as with many other general-purpose candidate characteristics, there is no unified point of view on it.
Ownership is often a redefinition and/or a mixture of other
features.
Ownership is sometimes considered as a typical property
of the WP relationship. However, it is important to notice
that, for some authors, it is not in any way a criterion for
defining aggregation [11,15,19,26,27]. In addition, for other
authors, its sense is seldom the same from one author to
another. Booch, for example, in Ref. [7], suggests that a
structural relationship from a type Shareholder to a type
Share is an aggregation relationship. He writes: The shareholder uniquely owns shares, but the shares are by no means
a physical part of the shareholder. [7, pp. 102103]. He
does not in particular attribute a semantics to ownership,
except saying that it is rather conceptual compared to,
what he calls, physical aggregation. This example is queried in Ref. [22].
Civello in Ref. [10, p. 387] takes a quite different direction in writing: More precisely, an object owns another if
deletion of the whole object implies deletion of the part
object. However, he especially adds that ownership does
not prevent separability: for example, a member object
owned by a group may be owned by the group but also
separable from it (it can be released and continue its existence outside the group). This last example is an archetype
of OMLs Membership, which is not known as having the
ownership property.
Saksena et al. in Ref. [37] put into the foreground a new
point of view, as follows: An object owns its parts in the
sense that it controls the behavior of its parts, that is, the
whole controls how and when the services of its parts are
used. This requires that an aggregate class have methods
that call the methods of the parts. Their definition is relatively light because, they add: A part may be owned by
one or more wholes at a particular time, and its owners may

change over the parts lifetime. Moreover, they consider
ownership as a basic property of the WP relationship by
classifying it as primary property a viewpoint challenged
by Henderson-Sellers [20].
Finally, the idea of strong ownership related to Composition in UML (The part is strongly owned by the composite and may not be part of any other composite. [32,
Semantics, p. 18]) seems to make strong ownership and
non-sharing synonyms. Furthermore, it results in the existence of weak ownership which is indisputably related to
UMLs Aggregation [32, Semantics, p. 38] (i.e. white
diamond notation).
Some fundamental observations have to be made. In
particular, we believe that ownership, as a possible feature
of aggregation, is not at all the formal and general-purpose
relation between an object (as possessor) with regard to
another one (as possessee). In that connection, as already
underlined in Ref. [22], Boochs example above is an incorrect case of aggregation. Choosing strong ownership
closely related to non-sharing and weak ownership as a
synonym for sharing, as in UML, is merely a syntactical
effect which only spreads confusion. Regarding Civellos
definition, it contradicts that of UML because: composition
A form of aggregation with strong ownership and coincident
lifetime as part of the whole. [32, Semantics, p. 150] (our
underlining). Indeed, in UML, coincident lifetime
complements strong ownership for fully defining Composition. Instead, for Civello, ownership is the coincident
death of a wholes linked parts when this whole disappears
and, as a result, something which is close to (or included in)
coincident lifetime. As for Saksena et al., their characterisation is rather expansive and is quite similar to, for example,
exclusive control in Ref. [12]. In fact, most authors agree
that a whole requests the services of its linked parts while
they logically cannot call those of their whole(s). In order to
ensure that a whole really and fully controls its linked
parts, can the services of these last objects be launched by
other objects than their whole(s)? More formally, in considering a WP relationship from a type Whole to a type Part,
with S a service suffered by Part, can S be executed outside
the scope of WP? A type X in a model M can be such that it
gets a visibility on the type Part. At run-time, instances of X
call S for instances of Part. This form of collaboration can
be viewed as breaking ownership. Saksena et al. do not give
a solution to such a problem.
Unfortunately, we believe that ownership comes from
implementation-focussed thinking. The main explanation
depends upon the C and Eiffel following constructs:
class Egg { // C
private:
Eggshell eggshell;
White& white;
Yolk& yolk;
35
};
class Egg feature Eiffel
eggshell: expanded Eggshell;
white: White;
yolk: Yolk;
end
Such a dependency between the Egg and the Eggshell
classes views objects as values. In contrast, in most
object-oriented programming languages (Java and
Smalltalk in particular), the common way to handle
objects is by reference. In the previous code, an
instance of Egg manages an instance of Eggshell by
value. This last instance is invisible from outside
(private: in C and absence of export in Eiffel).
However, it is not mandatory to restrict the interface of
the Egg class so that the eggshell attribute is inaccessible from outside.
The code above seems to be appropriate to represent
ownership. Indeed, each time an instance of Egg is created,
an instance of Eggshell is automatically created. Furthermore, the code above is such that Civellos observation
becomes true: deletion of the whole object implies
deletion of the part object. The difference is that this
code prevents separability despite Civellos acceptance
of it. Finally, it is important to notice that any instance
embodied by the eggshell field can only react to
stimuli (service calls) from the instance of Egg owning
this field. We may change that in allowing this attribute
to become visible-but this raises other problems. To
sum up, we believe that:
Defining ownership at the analysis level is not a good
idea, because this requires taking into account relations
between wholes and parts, in taking care of implementation details. These relations are rarely programming
language-free specifically when they refer to deletion
mechanisms. In contrast, we might say that it is possible
to represent ownership independently of programming
languages provided that we do not use such dynamical
mechanisms.
Ownership is difficult to characterise at the designimplementation level in the case of one-to-many relationships. Indeed, an aggregation from Egg to
Eggshell is a simplistic example compared to a
Whole object that owns an arbitrary number of Part
objects. This implies the use of collections (i.e.
containers) and then the need for extra implementation. In addition, remember that neither Java nor
Smalltalk support object management by value. This
dramatically limits the spectrum of ownership. Our
regret (which is also a criticism!) is that some
well-known contributions have reversed the problem
in giving a definition of the WP relationship, said to
be free of programming languages, but actually
36
Structural Relationship(Black,White)
UML-Composition(Whole,Part)
coincident lifetime: Section 3.2.5 of this paper
Whole-Part-SE(Whole,Part)
Fig. 15. Specification of UMLs Composition in cOlOr.
correlated to a given one (e.g. UMLs CompositionC).

5. The WP relationship in UML and OML
Combining properties can lead to the generation of
numerous kinds of WP semantics. However, few are really
needed since the frequency of their occurrence in modelling
situations is very low. In this line of reasoning, in both UML
and OML, there is a small number of types of aggregation to
meet recurrent requirements. Within cOlOr, our goal is then
to find a position for two of the most well-known types of
WP semantics, e.g. Composition in UML and Aggregation
in OML.
5.1. UMLs composition
Although here and in Ref. [21], it is proved that black
diamond owns contradictory features, some choices have to
be made in order to respect the initial spirit of UML. So,
the first grounding property of Composition is non-sharing.
The second one is coincident lifetime. Within cOlOr, the
use of this last principle requires part-encapsulation or
part-encapsulation based on WE-a (Section 4.2.5) and
implies non-sharing. So in Fig. 15, we may then regard
UML-Composition as a subtype of Whole-Part-SE. This
clearly rejects the two models in Fig. 4, even if the {xor}
constraint is used as in Fig. 4(b).
Another partition of Composition is determined by different values of the changeable attribute as discussed in
Section 3.1. Thus, frozen leads to immutability for
Composition while addOnly is simply inseparability.

Within cOlOr, coincident lifetime also implies immutability
which itself implies inseparability. So, as shown in Section
3.1, only frozen is adequate.
5.2. OMLs Aggregation
OMLs Aggregation is known to be configurational. This
exactly matches with the (WE-c) pattern of encapsulation in
Section 4.2.1. Since the whole creates a synergy between the
parts, the following invariant is needed: min-Part 0. As
a result, two part objects are at least involved as far as (Fig.
10(c)) two WP relationships are required. Moreover, OMLs
Aggregation is neutral according to separabilityinseparability concerns. Within cOlOr, this allows parts to be separable from wholes, because separability is the default
behaviour of Structural-Relationship. It is consequently
inherited by OML-Aggregation in Fig. 16. We deduce
then that mutability is permitted which excludes coincident
lifetime.
6. Domain-specific WP relationship types and their
implementation
Some semantics of the WP relationship may be original.
No notation is then needed but a good framework should
favour the description of such rare cases while preserving
the essential point: the primary properties. Within cOlOr, a
new kind of aggregation is first introduced and specified
through a type inheriting from one of the existing
Structural Relationship(Black,White)
Whole-Part-WE-c(Whole,Part)
OML-Aggregation(Whole,Part)
Invariants:
min-Part > 0
Fig. 16. Specification of OMLs Aggregation using cOlOrs style.
Optical path
0..1
1..max-Part
Optical-path-layerlink-connection
Fig. 17. A domain-dependent WP relationship.
metatypes. Next, special features of this type are represented

while those inherited are reused and possibly adapted.
Fig. 17 is an example concerning the area of Submarine
Telecommunications Network Management (STNM) [2].
For experts, the concept of Optical path (which is in fact a
potential communication channel under the sea between two
land plants) is meaningless without the notion of Opticalpath-layer-link-connection. A typical resultant property of
an optical path is the communication capacity that depends
upon that of its Optical-path-layer-link-connections. A
significant emergent property is its two extremities that
are two geographical sites. Origins and ends of opticallayer-link-connections are indeed switching equipment or
terminal equipment. In addition, we have:
Two instances of Optical path must not share the same
Optical-path-layer-link-connection instance. UMLs
Composition might seem suitable except that wholes
and parts in Fig. 17 have no coincident lifetimes.
Over time, any Optical-path-layer-link-connection
instance has two main possible states: whether or not
connected with an instance Optical path. Cardinality
0..1 expresses that. In this respect, Optical-path-layerlink-connection objects which are parts of an Optical path
object may outlive it when this Optical path object disappears (cable break, fibre pair break or power feeding breakdown are events which lead to the death of Optical path
objects). Consequently, when Optical path objects are
created, they do not have a non-changeable structure (i.e.
a definite number of Optical-path-layer-link-connection
objects as their parts). Hence, Optical-path-layer-linkconnection objects are dynamically linked to them according to history constraints.
A special state for an Optical path object is malfunctioning. In this context, its Optical-path-layer-link-connection parts become a candidate to be disconnected from it,
while it continues to transmit signals (damaged mode).
The purpose is to relocate as soon as possible some of
these objects to create new Optical path objects or to
modify existing ones. In order to support military and
civil defence telecommunications, Optical path objects
are created primarily for that. Nevertheless, before the
relocation occurs, an Optical path object in the malfunctioning state must be destroyed to ensure reliable telecommunications.
37
To sum up, given an instance op1 of Optical path and an

instance opllc of Optical-path-layer-link-connection, since
the start of the life of op1, opllc cannot become a component
of op1 if it was the case in the past. This implies that
op1 keeps a history of Optical-path-layer-link-connection
components which have been disconnected from it in the
past. Moreover, opllc must not be, at the time of the
dynamic binding, an old component of any existing instance
of Optical path. This implies that there exists a history about
any Optical-path-layer-link-connection objects disconnected from any Optical path object. First, let us imagine
that the dynamic binding between op1and opllc is a success.
Next, let us suppose that opllc is not currently a component
of any instance of Optical path, except naturally op1 after
the success. A possible scenario is that opllc is disconnected
from op1. For op2 whose type is Optical path, opllc cannot
become a component of op2 until op1 is destroyed. Let us
now assume that op1 is destroyed; then opllc can dynamically become a component of any instance of Optical path
because, currently, no instance of Optical path knows it as
an old component.
6.1. Specification
The specification is based on Fig. 8 because it is mandatory to distinguish the Whole role from the Part role. The
Whole-Part-STNM(Whole,Part) metatype is then introduced as subtype of Whole-Part(Whole-Part) (for short,
we do not discuss a special style of encapsulation). Besides,
we incorporate a function into the Component(T) metatype: removed: set of T.
We first modify in Whole-Part-STNM(Whole,Part)
the assertion concerning the add operation. Note that
all general forms related to Structural-Relationship
(Black,White) are preserved (Section 4). The symbol
is then used to indicate this preservation: (w,p)
Whole PartX add(w,p) [ p parts(w).removed]/[ ].
Next, for consistency, the remove operation is reviewed as
follows: (w,p) Whole PartX remove (w,p) [ ]/[
parts (w).removed parts(w). removed {p}]. Finally,
we need a generalisation for add: (w,p) Whole
Part,c: Component (Part)X add(w,p) [ p c.removed]/
[ ]. This last assertion takes the place of the first version for
add.
In using effective types, we obtain: (op,opllc)
Optical path Optical layer link connectionX add(op,opllc)
[ opllc parts(op).removed]/[ ]. In other words, the
relocation is subject to the fact that the linkage did not exist
in the past between the same objects. In addition, we have:
(op,opllc) Optical path Optical layer link connection,c: Component(Optical layer link connection)X add
(op,opllc) [ opllc c.removed]/[ ]. By hypothesis,
there are as many as Optical path objects as there are
Component(Optical layer link connection) objects. In
other words, the relocation is subject to the fact that no
existing Optical path object (including op) was linked to
38
opllc in the past. Indeed, the non-existence of an Optical

path object is such that parts(op) nil.
6.2. Implementation
Our implementation strategy is simply to predefine C
template classes in order to precisely capture the cOlOr
metamodel. Implementation of associations is also
discussed in Ref. [34] but this problem is not really solved,
in the sense that aggregations are omitted. These classes
make up a library of reusable assets. Structural_RelationshipBlack,White and Whole_PartWhole,Part are customisable classes from which a class Whole_Part_
STNMWhole,Part can be derived. Only the history
constraints above have to be implemented in this last
class. This in particular needs the use of a class variable
and overriding of the add inherited function. The direction
decided in Fig. 17 (from the Whole type to the Part type)
leads us to put a field wp into the Optical_path class.
class Optical_layer_link_connection;
class Optical_path {
private:
Whole_Part_STNM
Optical_path,Optical_layer_link_connection wp;
public:
Optical_path( );
Optical_path(Optical_layer_link_connection&);
};
Optical_path Optical_path( ): // first constructor
wp(Whole_Part_STNM
Optical_path,Optical_layer_link_connection
(0,1,1,INT_MAX))
{}
Optical_path Optical_path(Optical_layer_link_
connection& opllc): // second constructor
wp(Whole_Part_STNM
Optical_path,Optical_layer_link_connection
(0,1,1,INT_MAX))
{}
The last part of the code above states precisely the
multiplicity constraints. The first constructor automatically creates an instance of Optical_layer_link_connection to be linked to the current instance of
Optical_path, while the second one requires this
instance as argument.
with such a formal characterisation. In contrast, we cannot

accept that a notation for aggregation in an object modelling
language is meaningless. As a trade-off, we have chosen a
minimal set of foundation properties (whole-part, emergent,
resultant, type-antisymmetry and instance-asymmetry also
called primary properties) so that any example does not
refute the initial hypothesis. By dynamic metamodelling
and by paying attention to some of the current metamodel
defects (UML in Section 3 1), we propose, in Section 4, to
assign primary properties to an abstract metatype named
Whole-Part and to defer, to its subtypes, how to deal consistently with the more subtle and/or tricky properties also
called secondary properties (encapsulation, sharing/nonsharing, separability/inseparability, mutability/immutability,
lifetime dependency and configurationality,). The inherent
style of metamodelling allows a review of standard types of
aggregation, e.g. those in UML and OML (Section 5), as
well as domain-dependent ones (Section 6).
A main consideration in this paper is the careful distinction between implementation modelling and conceptual
modelling. In this respect, Fowler in Ref. [16, p. 314] has
already pointed out that UML is too close to implementation
modelling by preferring the term class to the detriment of
that of type. While cOlOr focuses on conceptual concerns,
we nevertheless show that this does not preclude facilitating
implementation afterwards (Section 6.2). The only embarrassment is that our notation is not UML-compliant but this
may become possible by using OCL.
An interesting perspective of this research work is then a
possible proposal for a new version of the UML metamodel
based around the concept of structural relationship. This
metamodel is constantly subject to improvements in the
scope of the OMG [33]. Another action in progress is the
development of an industrial package of the C library
mentioned in Section 6. This library, currently based on
STL [30], allows the reuse of the generic algorithms available in STL and may be highly useful in CASE tools. A last
and more academic focus is to extend our study of the
literature outside the scope of object development. Such a
large survey of aggregation may bring new ideas into the
field of object orientation.
Acknowledgements
This is Contribution number 99/5 of the Centre for Object
Technology Applications and Research.
7. Conclusions
References
In object modelling, a plethora of papers on aggregation
gives a very non-uniform view of this kind of structural
relationship. This phenomenon was illustrated in Section
3. Theoretically, it is possible to attribute a set of axiomatic
properties to the WP relationship but, as discussed in
Section 2, it is then easy to find an example that clashes
[1] F. Barbier, Systematic Construction of UML Associations and Aggregations Using cOlOr Framework, Proceedings of Automating the
Object-Oriented Software Development in ECOOP98 Workshop
Reader, Lecture Notes in Computer Science, vol. 1543, Springer,
New York, 1998 (pp. 480482).
[2] F. Barbier, J. Cherel, S. Rideau, Submarine Telecommunications
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
Network Management: An Object-Oriented Software Engineering

Approach, Proceedings of ECBS98, IEEE Computer Society Press,
Silver Spring, MD, 1998 (pp. 281289).
F. Barbier, B. Henderson-Sellers, Object modeling languages: an
evaluation and some key expectations for the future, Annals of Software Engineering 10 (2000) (in press).
C. Bock, J. Odell, A foundation for composition, Journal of ObjectOriented Programming 7 (6) (1994).
C. Bock, J. Odell, A more complete model of relations and their
implementation: roles, Journal of Object-Oriented Programming 11
(2) (1998) 5154.
C. Bock, J. Odell, A more complete model of relations and their
implementation: aggregation, Journal of Object-Oriented Programming 11 (5) (1995).
G. Booch, Object-Oriented Analysis and Design with Applications,
2nd ed., Addison-Wesley, Reading, MA, 1994.
G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling
Language User Guide, Addison-Wesley, Reading, MA, 1999.
R. Bourdeau, B. Cheng, A formal semantics for object model
diagrams, IEEE Transactions on Software Engineering 21 (10)
(1995) 799821.
F. Civello, Roles for composite objects in object-oriented analysis and
design (proceedings of OOPSLA93), ACM Sigplan Notices 28 (10)
(1993) 376393.
S. Cook, J. Daniels, Designing Object Systems Object-Oriented
Modelling with SYNTROPY, Prentice-Hall, Englewood cliffs, NJ,
1994.
J. Dong, R. Duke, The geometry of object containment, Object
Oriented Systems 21 (1) (1995) 4163.
D. Firesmith, B. Henderson-Sellers, Clarifying specialized forms of
association in UML and OML, Journal of Object-Oriented Programming 11 (2) (1998) 4750.
D. Firesmith, B. Henderson-Sellers, Upgrading OML to Version 1.1:
referential relationships, Journal of Object-Oriented Programming 11
(3) (1998) 4857.
D. Firesmith, B. Henderson-Sellers, I. Graham, OPEN Modeling
Language (OML) Reference Manual, OPEN Modeling Language
(OML) Reference Manual (SIGS Books), Cambridge University
Press, Cambridge, 1997.
M. Fowler, Analysis Patterns-Reusable Object Models, AddisonWesley, Reading, MA, 1997.
M. Fowler, K. Scott, UML Distilled Applying the Standard Object
Modeling Language, Addison-Wesley, Reading, MA, 1997.
I. Graham, J. Bischof, B. Henderson-Sellers, Associations considered
a bad thing, Journal of Object-Oriented Programming 9 (9) (1997)
4148.
B. Henderson-Sellers, OPEN relationships-compositions and containments, Journal of Object-Oriented Programming 10 (7) (1997) 5155.
B. Henderson-Sellers, F. Barbier, What is this thing called aggrega-
[21]
[22]
[23]
[24]
[25]
[26]
[27]
[28]
[29]
[30]
[31]
[32]
[33]
[34]
[35]
[36]
[37]
[38]
[39]
[40]
39
tion, Proceedings of TOOLS EUROPE99, IEEE Computer Society

Press, Silver Spring, MD, 1999 (pp. 236250).
B. Henderson-Sellers, F. Barbier, Black and white diamonds,
Proceedings of UML99, Lecture Notes in Computer Science, vol.
1723, Springer, New York, 1999 (pp. 550565).
B. Henderson-Sellers, A. Bulthuis, Object-Oriented Metamethods,
Springer, New York, 1998.
B. Henderson-Sellers, J. Edwards, BOOKTWO on Object-Oriented
Knowledge: The Working Object, Prentice-Hall, Sydney, 1994.
B. Henderson-Sellers, D. Firesmith, Comparing, Comparing OPEN
and UML: the two third-generation OO development approaches,
Information and Software Technology 41 (3) (1999) 139156.
B. Henderson-Sellers, A. Simons, H. Younessi, The OPEN Toolbox
of Techniques, Addison-Wesley, Reading, MA, 1998.
H. Kilov, J. Ross, Information Modeling An Object-Oriented
Approach, Prentice-Hall, Englewood cliffs, NJ, 1994.
M. Kolp, A. Pirotte, An aggregation model and its C implementation, Proceedings of OOIS97, Springer, New York, 1997 (pp. 211
221).
K. Lano, Formal Object-Oriented Development, Springer, New York,
1995.
J. Martin, J. Odell, Object-Oriented Methods: A Foundation UML
Edition, Prentice-Hall, Englewood cliffs, NJ, 1998.
D. Musser, A. Saini, STL Tutorial and Reference Guide-C
Programming with the Standard Template Library, Addison-Wesley,
Reading, MA, 1996.
J. Odell, Six different kinds of composition, Journal of ObjectOriented Programming 6 (8) (1994) 1015.
OMG, UML Summary, Semantics and Notation Guide, version 1.1,
September 1997.
OMG, OMG Unified Modeling Language Specification, version 1.3,
June 1997.
J. Rumbaugh, Models for design: generating code for associations,
Journal of Object-Oriented Programming 8 (9) (1996) 1317.
W. Premerlani, F. Eddy, W. Lorensen, Object-Oriented Modeling and
Design, Prentice-Hall, Englewood cliffs, NJ, 1991.
J. Rumbaugh, I. Jacobson, g. Booch, The Unified Modeling Language
Reference Manual, Addison-Wesley, Reading, MA, 1999.
M. Saksena, R. France, M. Larrondo-Petrie, A characterization of
aggregation, Proceedings of OOIS, Springer, New York, 1998 (pp.
1119).
M. Saksena, M. Larrondo-Petrie, R. France, M. Evett, Extending
Aggregation Constructs in UML, Proceedings of UML98, Lecture
Notes in Computer Science, vol. 1618, Springer, New York, 1998 (pp.
435441).
S. Whitmire, Object-Oriented Design Measurement, Wiley, New
York, 1997.
M. Winston, R. Chaffin, D. Herrmann, A taxonomy of part-whole
relations, Cognitive Science 11 (1987) 417444.

Whole Part1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Whole Part1

Uploaded by

Copyright:

Available Formats

Information and Software Technology 43 (2001) 1939

The whole-part relationship in object modelling: a definition in cOlOr

Received 7 April 2000; revised 6 June 2000; accepted 8 June 2000

structural and WP relationships in Object-Oriented Analysis

F. Barbier, B. Henderson-Sellers / Information and Software Technology 43 (2001) 1939

concerns is to compose standard or more innovative kinds of

2. The structural relationship in OOAD

Aggregation and what is called Composition, whereas OMT

F. Barbier, B. Henderson-Sellers / Information and Software Technology 43 (2001) 1939

Fig. 1. An egg regarded as a WP relationship.

as they emphasise service categories (e.g. propagating

Whole type (origin of arrow) from the Part type (end of

F. Barbier, B. Henderson-Sellers / Information and Software Technology 43 (2001) 1939

derived from a general rather abstract type embodying the

for wholes are computed by means of parts (resultant) or not

3. Some semantics of the WP relationship

F. Barbier, B. Henderson-Sellers / Information and Software Technology 43 (2001) 1939

A more unusual, yet appealing, approach presenting

Objects may overlap and share contained objects, e.g.

F. Barbier, B. Henderson-Sellers / Information and Software Technology 43 (2001) 1939

the object they constitute [19, pp. 5253]. Beyond

Fig. 3. UML partial metamodel related to structural relationships.

having written in Ref. [28, p. 54]: sharing: whether two or

Thus, approaches differ to various degrees. Namely,

F. Barbier, B. Henderson-Sellers / Information and Software Technology 43 (2001) 1939

Fig. 4. Two special uses of UMLs Composition.

an Aggregation (viewed as an instance of Association) is

F. Barbier, B. Henderson-Sellers / Information and Software Technology 43 (2001) 1939

Fig. 5. The WP relationship at the metamodel, model and instance levels.

4. Dynamic metamodelling for the WP relationship

the concept of WP relationship. We aim to clarify, and next

F. Barbier, B. Henderson-Sellers / Information and Software Technology 43 (2001) 1939

In Fig. 5, at a metamodel level, is shown the metatype

F. Barbier, B. Henderson-Sellers / Information and Software Technology 43 (2001) 1939

Fig. 8. Introduction of Component(T) and Compound(T) as subtypes of Role(T).

Directionality and navigability concerns are often

F. Barbier, B. Henderson-Sellers / Information and Software Technology 43 (2001) 1939

one of its two ends as an instance of Part (or of Whole) is

Fig. 9. Strict encapsulation for the WP relationship.

to the part. Models can be such that types are linked by WP

(WE-a) SR is itself a WP relationship from Part to X (Fig.

Fig. 10. Weak encapsulation for the WP relationship.

F. Barbier, B. Henderson-Sellers / Information and Software Technology 43 (2001) 1939

Local sharing is the sharing principle supported by

Fig. 12. Extension of cOlOrs core in dealing with encapsulation.

F. Barbier, B. Henderson-Sellers / Information and Software Technology 43 (2001) 1939

about sharing between X and Part in of Fig. 10(c) for

F. Barbier, B. Henderson-Sellers / Information and Software Technology 43 (2001) 1939

Thus, for a potential subtype of the Whole-Part metatype,

equivalent sail without affecting the function of the boat.

F. Barbier, B. Henderson-Sellers / Information and Software Technology 43 (2001) 1939

Mandatory participation for Part

Mandatory participation for Whole

Mandatory participation for Part

Fig. 14. Mandatory versus optional participation.

4.2.5. Lifetime dependency

Coincident birth of Part instances with WP linkages (i.e.

F. Barbier, B. Henderson-Sellers / Information and Software Technology 43 (2001) 1939

part-encapsulation part-encapsulation based on

F. Barbier, B. Henderson-Sellers / Information and Software Technology 43 (2001) 1939

one or more wholes at a particular time, and its owners may

F. Barbier, B. Henderson-Sellers / Information and Software Technology 43 (2001) 1939

correlated to a given one (e.g. UMLs CompositionC).

Composition while addOnly is simply inseparability.