A User-Level Model of Composition
James J. Odell
Most modellers express composition as a special kind of relationship
between object types. However, when pressed to articulate how and
why a compositional relationship differs from general relationships,
a lot of hand waving results. In other words, composition often
functions as a place holder for user intuitions that have not been
articulated. Consequently, users have no common way to interpret
composition when they see it on diagrams. This problem can be
alleviated by showing how composition differs from other kinds of
relationships. This column suggests:
Report On Object-Oriented Analysis and Design
Vol2, No 7. May/June 1996
Copyright © 1996
SIG Publications, Inc, New York, NY
Also available in Advanced Object-Oriented Analysis and Design Using UML
by James J. Odell, Cambridge University Press, 1998
A foundation for composition has already been published in JOOP [Bock/Odell, 1994]. (Portions of
this foundation were also described in version 0.8 of the Unified
Method [Booch, 1995].) Additionally, a
taxonomy of compositional forms was described by Odell [Odell 94]. This month's column balances
these previous discussions by focusing on the user's model of
Composition is defined as a relationship that associates a whole and
its parts, in which:
Only the first and fifth of these features are in current
methodologies, even though most of them are needed in common
- Each part is of a certain type.
- Each component of an object must be of some object type.
For example, the component hierarchy expressed by an
organizational chart consists of Organization Unit
objects. The components of an Engine could be objects
types such as Engine Block, Piston, and Crankshaft-or
even just Engine Part objects. The way in which these
part types relate may be specified in an object diagram
(as in Figure 1) or via a Part Type hierarchy (where each
Part Type may consist of 0, 1, or many other Part Types).
- Parts may be connected in certain ways unique to the
- For example, an engine in a car powers the wheels, but an
engine in a boat powers the propeller.
- Each part has an identifiable role in the composite.
- As indicated above, the same engine can be part of a car
or a boat. When a given engine is part of a car, it is
playing the role of a Car Engine; and when part of a
boat, a Boat Engine. Each role can be thought of an
object type in its own right-sometimes referred to as a
qua-type. (A qua-type is a subtype created solely to
support a role [Bock/Odell, 1994]).
- Parts may be assigned properties unique to the composite.
- For example, a Car Engine would convert its power in
terms of miles per hour and a Boat Engine in terms of
knots. For a Race Car Engine, you might wish to express
the optimal ratio of the nitroglycerine required for the
fuel mix, but not for the Family Car Engine.
- Each kind of part may have more than one instance in the
- For example, a car may have four wheels.
- Relationships may have parts or be parts themselves.
- For example, when one person calls another on the
telephone, the people are related by a composite
relationship containing receivers, switches, wires, and
the various connections.
The following computational services are useful under this
- Creation of parts
- When a composite object is instantiated, all the parts
are created according to their assigned types and are
linked together according to the connections in the
composite model. For example, when a Car is created, an
Engine object can be instantiated along with its
associated Wheel object. The is powered by relationship
is also established between the Engine and Wheel objects.
When a relationship is itself a composite, two or more
objects are chosen to be related. Then, all the parts of
the relationship are instantiated and connections
established as for composite classes. In addition,
connections are also created from the newly instantiated
parts to the original objects being related.
Using the telephone example above, once two people are
found for the relation, the various receivers, switches,
and so on are instantiated and linked together. Finally,
connections are made from some of the newly instantiated
parts to the two people.
- Destruction of parts
- When a composite instance is deleted, all the parts may
be deleted along with their connections to each other.
This is a special case of the propagation of operations,
- Maintenance of connections
When a part is removed from a whole, it should be
disconnected from the other parts. For example, removing
an engine from a car disconnects it from the wheels.
- Composite inheritance
- When a composite class is subtyped, its subtypes inherit
the part structure of their supertypes. For example, the
user of a GUI window might want to make a similar window
with a few controls added. They can make a subclass of
the composite class, which will inherit its composite
model to the subclass. New part structures can be added
to the subtyped window. Even when no additional parts
are added, aspects of the existing parts may be
restricted in the subtype. For example, trucks have
engines because vehicles do, but they may be restricted
to having heavy-duty engines. [See
- Subtyping of part types
- When a type of part is used in more than one composite,
it may be connected to different things in each
composite. For example, engines may be used in both cars
and submarines. They power wheels in one case and a
propeller in the other. How shall we model the Engine
object type in this case? Two options are:
The advantage of the first is that it interoperates well
with diagrams normally used to model object types, as
illustrated in Figure 1. The user can see on the diagram
the constraints of exactly what connects to what. The
disadvantage is that the context-based subtypes, called
qua-types (qua-types are subtypes that are added to
support the functionality required for context-based
properties-but not necessarily required by the user for
any other purpose), increase the complexity of diagrams
- Since we do not know how engines will be used when
we define the Engine object type, it is subtyped
for cars and submarines-with the Powers
association restricted to Wheel and Propeller,
- Make a Powerable Thing object type that is related
to Engine and subtyped into Wheel and Propeller.
The advantage of the second technique is that the
diagrams are less complex. The user sees only that
engines power some things shown as the subtypes of
Powerable Thing. The disadvantage is that
context-independent supertypes, such as Powerable Thing,
need to be created for every connection of every reusable
Computational services can alleviate the difficulties of
both alternatives: context-based subtypes or
context-independent supertypes can be created
automatically as the composite model is specified. The
user can choose to hide them in the diagrams. The user
can decide for each connection which technique to use.
- Invariant parts
- Sometimes parts cannot be removed from a composite object
without destroying the object. For example, a car may
still be a car if its engine is removed, but not if its
frame is removed. We are calling these parts invariant.
When an invariant part is removed from a composite
object, the object is deleted, without deleting any of
the other parts. For example, when the frame is removed
from a car, the car object is deleted, leaving the
engine, wheels, and so on. Or, if one of the people who
composes a marriage is removed, that marriage must also
- Propagation of operations
- An operation that applies to a composite instance may
apply to all its parts. For example, this would include
operations such as Move, Turn, and Sink. In other words,
if the whole is moved, so are its parts. Parts deletion,
above, is another example.
- Accessibility of internal parts
- When defining a composite, some of the parts may not be
accessible for connection to the outside. For example,
the pistons are not accessible to the outside of the
car-only within the engine. However, the gas tank and
brake pedal are. Parts, then, can be labeled to indicate
whether or not they are accessible outside the composite.
Composite classes with the above services are a natural extension of
inheritance. Inheritance means a class can describe the attributes
and operations of its instances, including those of its subtypes.
Composition means that a class can describe the part structure of
its instances, including those of its subtypes. Inheritance means
that each newly created instance has its attributes and operations
set up by the class, through constructors, memory allocation, and so
on. Composition means that each newly created instance has its part
structures set up, according to the composite model.
If we try to diagram composites without using a shorthand for
qua-types, the diagrams can become unwieldy. For example, Figure 1
shows a diagram using compositional relationships along with
ordinary relationships. (The unmarked lines are ordinary
relationships.) The user is forced to diagram the qua-types
explicitly. Engine is qua-typed for its different uses in Cars and
Submarines. Axles are subtyped because only the front receives
power in a Car. Wheels are then subtyped according to the Axle.
Submarines use different Engines and are also qua-typed. The
complexity of the diagram in this small example grows each time a
new composite is expressed.
One technique for simplifying the diagram in Figure 1 is illustrated
in Figures 2 and 3, where the user relates the parts as necessary
within the context of a Car or a Submarine. For example, Figure 2
depicts some of the basic parts required for a Car. The figure
presents the qua-types not as rectangles, but in parentheses above
their respective supertypes. For instance, while Engine is
presented as a rectangle, its Car Engine qua-type is declared in
parentheses above the Engine rectangle. In this context, the powers
and drives relationships are assumed to associate the qua-types.
Figure 3 employs this same technique for Submarine.
The diagramming technique in Figure 2 presents composition without
the specialized qua-types. Instead, the qua-type is indicated in
parentheses above the object type that it specializes-reducing
diagram complexity. A tool supporting compositional diagrams can
automatically make these notations as the types are added to the
diagram. For example, when the user asks to edit the composition
structure of a Car, a diagrammer appears showing the part types and
their connections. If the user adds a part by selecting a type, say
Radio, the type appears with a notation indicating that the context
is Car, where radios are installed in a way peculiar to Cars. Users
can choose whether they want their part types to be automatically
subtyped, as described in the section called Subtyping of Part
Types. The tool can allow a compositional diagram to be brought up
from a normal object type diagram, by a menu item to examine the
composite structure of an object type.
The advantage of the above notation is that it indicates to the user
that the compositional structure resides in an object type. Thus,
all of the type-based services are available, such as part
instantiation, part-type subtyping, and inheritance of composite
structure. The technique presented in the Unified Method [Booch, 1995]
focuses the user on instances. This downplays the possibility
of type-based services and may have resulted from the authors of the
Unified Method wishing to simplify composition diagramming. Perhaps
such an approach can be supplemented by notations or tool support
that relate it to the type services.
Bock, Conrad, and James Odell, “A Foundation
for Composition,” Journal of Object-Oriented Programming,
7:6, October, 1994, pp. 10-14.
Booch, Grady, and James Rumbaugh, Unified Method for Object-Oriented
Development, documentation set version 0.8, Rational Software
Martin, James, and James J. Odell, Object-Oriented Methods: A
Foundation, Prentice Hall, Englewood Cliffs, NJ, 1995.
Odell, James, “Six Different Kinds of Compositions,”
Journal of Object-Oriented Programming, 6:8, January, 1994, pp. 10-15.
Return to Bock Online
If you have any comments on this page or problems, contact
Conrad Bock (conrad dot bock at nist dot gov)