27.1. Association Classes

The following domain requirements set the stage for association classes:

• Authorization services assign a merchant ID to each store for identification during communications.

• A payment authorization request from the store to an authorization service needs the merchant ID that identifies the store to the service.

• Furthermore, a store has a different merchant ID for each service.

Where in the UP Domain Model should the merchant ID attribute reside?

Placing merchantID in Store is incorrect because a Store can have more than one value for merchantID. The same is true with placing it in AuthorizationService (see Figure 27.1).

This leads to the following modeling principle:

In a domain model, if a class C can simultaneously have many values for the same kind of attribute A, do not place attribute A in C. Place attribute A in another class that is associated with C. For example: A Person may have many phone numbers. Place phone number in another class, such as PhoneNumber or ContactInformation, and associate many of these to Person.

The above principle suggests that something like the model in Figure 27.2 is more appropriate. In the business world, what concept formally records the information related to the services that a service provides to a customer?—a Contract or Account.

The fact that both Store and AuthorizationService are related to ServiceContract is a clue that it is dependent on the relationship between the two. The merchantID may be thought of as an attribute related to the association between Store and AuthorizationService.

This leads to the notion of an association class, in which we can add features to the association itself. ServiceContract may be modeled as an association class related to the association between Store and AuthorizationService.

In the UML, this is illustrated with a dashed line from the association to the association class. Figure 27.3 visually communicates the idea that a ServiceContract and its attributes are related to the association between a Store and AuthorizationService, and that the lifetime of the ServiceContract is dependent on the relationship.

Guidelines

Guidelines for adding association classes include the following:

Clues that an association class might be useful in a domain model: An attribute is related to an association. Instances of the association class have a life-time dependency on the association. There is a many-to-many association between two concepts, and information associated with the association itself.

The presence of a many-to-many association is a common clue that a useful association class is lurking in the background somewhere; when you see one, consider an association class.

Figure 27.4 illustrates some other examples of association classes.