7.1 Introduction to Association

As is typical within the object-oriented community, one needs to be careful with vocabulary. The same term can imply different things to different developers. In the behavioral-driven methodologies, such as those proposed by Wirfs-Brock et al., Booch, and Jacobson [9,7,3,4], the general overview is that designers first find classes and their protocols. This implies that the first relationship application designers find is the uses relationship. During design they refine some of these uses relationships into containment relationships and then examine the domain for inheritance hierarchies. At the end of this process, it is possible to find some classes that are related but the relationship is not uses, containment, or inheritance. If such a relationship exists, it is called an association.

In the data-driven methodologies, such as the one proposed by James Rumbaugh [12] et al., the general overview is that designers find classes, followed by associations between those classes. Many of these associations are then refined into uses, containment, or inheritance relationships. Those that cannot be refined to one of these three fall into a category called simple associations. Within this chapter, our use of the word "association" will correspond to a relationship between two classes which is not uses, containment, or inheritance. In short, the association relationship will be defined as a catch-all relationship between classes which cannot be refined to one of the three main relationships that we have discussed previously, namely, uses, containment, and inheritance.

What is the relationship between the car in your driveway and the name of the company that manufactured it? What about the relationship between the car in your driveway and the company that manufactured it? The first question is easier to answer than the second. The name of the company that manufactured your car is an attribute of your car. It is important to note that it is a more important attribute than other car attributes like color, mileage, and vehicle identification number. The latter three attributes hold descriptive information concerning the car class. They are often called descriptive attributes. The car manufacturer, on the other hand, provides access to an entire object (of the class CarManufacturer) that exists elsewhere in your domain. This type of attribute is called a referential attribute. We can say that the name of the company that manufactured your car is a referential attribute of the car.

What about our second question: "What is the relationship between the car class and the car manufacturer class?" Is this relationship inheritance? No, because your car is not a special type of car manufacturer, and car manufacturers are not special types of cars. What about containment? No, your car is not contained in a car manufacturer (it is in your driveway), nor does your car contain a car manufacturer. What about a uses relationship? This is a possibility. If the car sends a message to the car manufacturer or the car manufacturer sends a message to the car, then there is a uses relationship between the two classes. For the sake of argument, let us state that neither class sends a message to the other class. What is the relationship between the two classes? We can say that the car is "made-by" the car manufacturer. This is not very precise within the realm of the object-oriented paradigm. Notice that it is not one of the three standard object-oriented relationships (uses, containment, inheritance), yet there is some relationship between the two classes. This is an example of the association relationship.

There are several types of association relationships: one-to-one, one-to-many, many-to-one, many-to-many. In addition, the relationship can be required or optional. There are two main methods of implementing these associations: the use of a referential attribute and the use of a third-party class. The first method is the most popular for designing one-to-one or many-to-one required associations. The second method is the most popular for designing all others. Either method can be used in all cases, but one is generally easier to implement for a given association type. We will examine both implementations.