## A More Complete Model of Relations and Their Implementation Part IV: Aggregation

James J. Odell

Journal Of Object-Oriented Programming Vol 11, No 5, September 1998

## Introduction

All modeling languages address relations and their implementation--but to varying degrees of completeness. This is the last of four articles on more complete models of relations and their implementation. In this one, we show that relations can be parts of an aggregate and can be aggregates themselves. We also explain how the implementation of aggregate objects and relations can be simplified by specializing both from the same type. Finally, we discuss new services that can be provided by aggregates that have relations as parts. Employing intuitive examples and a precise nonmathematical technique, we provide a model of aggregation that is closer to everyday meaning, thereby facilitating the transition from concept to implementation.

## Relations and Aggregation

A loose definition everyone can agree on is that relations connect objects. For example, marriage can be modeled as a relation between two people. Or, gift giving can be modeled as a relation between three objects: the giver, the recipient, and the gift. A particular instance of a relation, such as a single marriage between two particular people, is called a tuple (or a link in UML terminology). It is widely understood that aggregation is a kind of relation. For example, an engine and its car participate in a relation that can be classified or marked as an aggregate [1]. However, most methods omit the following uses of relations in aggregation:
1. Relations as parts of an aggregate.

For example, a car is more than a collection of parts. It also requires that the parts be related in particular ways: the engine must power the transmission, and so on. The way parts are connected is as important to the specification of an aggregate as the parts themselves. For this reason, the relations between parts should also be modeled as parts. So an aggregate may have two kinds of parts: those that are objects and those that are relations.

2. Relations as aggregates.

For example, when two people talk with each other on the phone, the relation between them is much more than just a single link: phones must be connected to hardware in the building, that hardware be connected to other machinery outside the building, and so on. For this reason, some relations should be modeled as aggregates. So there are two kinds of aggregates: those that are objects and those that are relations.
Using relations as parts or as aggregates is a natural consequence of treating them as first-class objects [2]. When relations are used only as a generalization of aggregation, as in the UML and most methods, we have a standard part hierarchy (Fig. 1).

Figure 1. Standard part hierarchy (cardinalities omitted for simplicity).

Such part hierarchies are a useful summary of aggregation. However, they cannot be translated to a complete implementation, because they do not model the connections between parts at each level of the hierarchy. When relations are used as parts of an aggregate, a part hierarchy has "cross-links" between the objects at each level of aggregation, as shown in Fig. 2. This figure extends UML notation to show that instances of an association (link) can be part of an object of some class. Here, for example, each instance of CAR consists of an engine, transmission, and a powers link that relates the engine and transmission. Or to put it another way, engines, transmissions, and their powers links are parts of cars. This model represents the most common way people think of aggregation--as component-integral aggregation [3, 4].

Figure 2. Part hierarchy with relations as parts.

The second use of relations in aggregation is when relations have parts. As a special case, a relation might have only relations as parts; that is, it resembles a "cable." For example, Fig. 3 shows two companies related in a JOINT DEVELOPMENT relation, which is an aggregate of the various relations between departments of each company. All parts of this relation aggregate are also relations.

Figure 3. Aggregate relation with only relations as parts.

Relations can have object parts as well. For example, the reader familiar with automobile assembly might have noticed in Fig. 2 that an important part is missing: the clutch, which controls power transfer between the engine and the transmission. This omission is remedied in Fig. 4. The clutch is part of the POWERS relation between ENGINE and TRANSMISSION, as are the relations between CLUTCH and the parts of ENGINE and TRANSMISSION. The aggregate relation in this example has both objects and relations as parts. Although POWERS has only one object part, aggregate relations in general can have many object parts as well as many relation parts, as in the telephone example mentioned above.

Figure 4. Aggregate relation with both objects and relations as parts.

## Unifying Aggregate Objects and Relations

Aggregate objects and aggregate relations have many similarities--and only one difference. An aggregate relation has relation parts that connect objects inside the aggregate to other objects outside the aggregate. In contrast, the relation parts of an aggregate object only connect those objects inside the aggregate. For example, compare the aggregate object in Fig. 2 and the aggregate relation in Fig. 4. The CAR aggregate object has only one relation part, that is, the POWERS relation. It connects only objects that are parts of CAR, for example, the engine and transmission. By comparison, the aggregate relation of Fig. 4 has two relation parts, both of which connect an object part of the relation, that is, the clutch, to objects outside the relation, the crankshaft and gears.

Since aggregate objects and relations are so similar, any software designer trained in the benefits of reuse would want to implement them under a common supertype. This supertype is an entity that can be either an aggregate object or relation simply by eliminating or adding relation parts that connect objects inside the aggregate to those outside. When this general aggregate supertype is specialized to aggregate objects, a constraint is added that its relation parts may only connect those objects within the aggregate. When the general aggregate type is specialized to aggregate relations, a constraint is added that at least one relation part must connect an object inside the aggregate to an object outside (see Fig. 5).

Figure 5. Common supertype for aggregate objects and relations.

In addition to the engineering benefits of putting shared structure in a supertype, there are also benefits to analysis and design as a scientific study. This is because we generally consider a science more advanced if it can order phenomena under one concept. For example, in the domain of physics we can completely order colors according to the wavelength of light, such as red, orange, yellow, and so on. This is an advance over the earlier partial ordering of colors by a painter's color wheel, which in turn is an advance over the even earlier and more partial categories of "warm" and "cool" colors.

The model of aggregation we present here can likewise order objects and relations under a common type, according to the number of relation parts that connect objects inside the aggregate to objects outside. One end of the object-relation continuum involves pure aggregate objects, which have zero relation parts connecting objects inside the aggregate to objects outside. Next are aggregate relations that have exactly one relation crossing the aggregate boundary. Then, there are aggregate relations that have two, and so on. This ordering is not complete, because there are presumably many aggregates with the same number of outbound relations. However, the ordering is significantly more complete than exists in most object-oriented methods. The ordering is also more complete than that used in logic--which uses the arity of predicates but does not account for the parts of a relation.

## Model-based Services

Models of aggregation that include relations as parts can support services that are unavailable in other models of aggregation. These include:

1. Inheritance of relation parts.

An aggregate's part specifications are inherited by subtypes of that aggregate. For example, small cars will have engines just like any type of car. If relations between parts are also parts in their own right, inheritance among aggregate relations should also apply. For example, if engines are connected to transmissions for cars in general, then the same is true of small cars. Here is an html-based demonstration of relation-part inheritance in OOIE notation.

2. Connecting parts during instantiation.

When an aggregate type is instantiated, its parts can be instantiated according to their types. Furthermore, each new object part is connected according to relations defined by the aggregate type. For example, when the type CAR is instantiated, a new engine and transmission are also created. They are then connected by the POWERS relation as specified by the aggregate definition of CAR [5].

When an aggregate relation is used to connect aggregate objects, several things must occur. First, all the object parts of the relation are instantiated, and the connections between them are established just as for aggregate types. Furthermore, new connections are created from the new object parts to parts of the objects being linked by the aggregate relation. For example, when connecting an engine to a transmission by the POWERS relation as in Fig. 4, a new clutch is created and connections established between it and parts of the engine and transmission, namely, their crankshaft and gears respectively.

3. Maintaining connections between parts.

When a part is removed from an aggregate, it can be disconnected from the other parts automatically. For example, when an engine is removed from a car, it can be disconnected from the transmission. Likewise, if a part is added to an aggregate, it can be connected to the other parts according to the relation parts defined for the aggregate. For example, when an engine is put back in a car, it can be connected to the transmission.
The above services are natural extensions to standard object typing. An object type describes the attributes and operations of its instances, including those of its subtypes. Likewise, aggregation with relation parts means that a type can describe the parts of its instances and how those parts are related, including those of its subtypes. Standard inheritance between object types and instances means that each newly created instance has its attributes and operations defined by its type, through constructors, memory allocation, and so on. Aggregation with relation parts means that each newly created instance has its parts created and connected together properly according to the aggregate type. Standard encapsulation means that the operations on an object type guarantee that private attributes are changed in a consistent way. Likewise, aggregation with relation parts means that the relations between parts are kept consistent as parts are added and removed from the aggregate. More detail on aggregation models can be found in our earlier articles on this topic [4, 5, 6].

## Conclusion

We have presented two common applications of aggregation that are not handled by most modeling languages, namely, those involving relations as parts and relations as aggregates. Our more complete model covers these cases by treating relations as object types, so that they can be parts and aggregates. This also allows aggregate objects and relations to be subsumed under a common supertype, thereby improving reuse and creating an ordered continuum for aggregate objects and relations. Finally, we described inheritance and constraint maintenance services based on our new models which create and maintain of connections between parts of an aggregate.

## Epilogue

This is the last of four articles on more complete models of relations and their implementation. The series suggested improvements in relation modeling based on treating relations as first-class object types and treating their instances, or links, as first-class objects. The first article showed that the usual model of relation cardinality, or multiplicity, is ambiguous because it does not distinguish the number of objects that can appear in a single link from the number of links in which the same object can participate [2]. The second article showed that the standard model of navigation across relations is incomplete because it does not cover mappings from an object to the links in which it participates and vice-versa [7]. The third article suggested that the highly overloaded term "role" can be precisely defined if it is always taken in the context of a relation. For example, wives and husbands are roles of a marriage, because they are specializations of women and men (which are the possible participants in the marriage relation) [8]. This final article extended standard models of aggregation by providing relations as parts and relations that have parts. In all these articles, innovations in relation modeling were presented by giving relations the same status as we normally give objects, in particular, by using them as participants in various other relations.

## References

[1] Rational Software, et al, UML Semantics, version 1.1, Rational Software Corporation, Santa Clara, CA, September 1997, p. 18.

[2] Bock, Conrad, and James Odell, "A More Complete Model of Relations and Their Implementation," Journal of Object-Oriented Programming, 10:3, June 1997, pp. 38-40.

[3] Winston, Morton E., Roger Chaffin, and Douglas Herrmann, "A Taxonomy of Part-Whole Relations," Cognitive Science, 11, 1987, pp. 417-444.

[4] Odell, James, "Six Different Kinds of Composition," Journal of Object-Oriented Programming, 6:8, January 1994, pp. 10-15.

[5] Bock, Conrad, and James Odell, "A User-Level Model of Composition," Report on Object-Oriented Analysis and Design, 2:7, May/June 1996, pp. 5-8.

[6] Bock, Conrad, and James Odell, "A Foundation for Composition," Journal of Object-Oriented Programming, 7:6, October, 1994, pp. 10-14.

[7] Bock, Conrad, and James Odell, "A More Complete Model of Relations and Their Implementation, Part II: Mappings," Journal of Object-Oriented Programming, 10:6, October, 1997, pp. 28-30.

[8] Bock, Conrad, and James Odell, "A More Complete Model of Relations and Their Implementation, Part III: Roles," Journal of Object-Oriented Programming, 11:2, May 1998, pp. 51-54.