A User-Level Model of Composition

Conrad Bock
James J. Odell

Reprinted from
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

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:

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.

User Model

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 applications.

Computational services

The following computational services are useful under this compositional model:

Extending inheritance

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 Corporation, 1995.

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)