• A natural and useful way that users can think about composition

• Computational services that make sense from a compositional viewpoint.

• Development techniques, including a diagrammatic notation, that reflect the user viewpoint

Composition is defined as a relationship that associates a whole and its parts, in which:

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

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

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 compositional model:

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, described below.

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 html demo.]

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:

1. 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, respectively.

2. Make a Powerable Thing object type that is related to Engine and subtyped into Wheel and Propeller.

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

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

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 be deleted.

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.

References

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