6.3 Checking Associations

The multiplicities of associations must be checked to ensure a complete and correct understanding of the relationship in the domain. To do so, consider the number of possible instances that can participate in the relationship.

6.3.1 Conditionality

As an example, consider the association between senators and senate seats. Each state in the United States has two senate seats, each of which can be occupied by one person at a time. However, a senate seat could be unoccupied due to the death or resignation of a senator. Hence, although a senate seat is normally occupied, it is not required that a senate seat is always occupied.

The multiplicity of the association between a Senate Seat and a Senator at the Senator end is therefore 0..1.

Contrast this with executive positions in government. A given U.S. state has exactly one governor, elected or acting, at any particular time (because that is how the laws in all the states work). A given person can be the governor of only one state at any time (again, because of law: The governor has to be a resident of the state he governs and he can be a resident of only one state at a time).

The multiplicity of the association between Governor and State is therefore 1..1 at both ends.

The definition of the association imposes referential onstraints to ensure that the data in the system is consistent with the model and consistent with itself. The referentials integrity constraints require any implementation based on this model to account for the following:

• If a state (or governor) is to be removed from the system, the corresponding governor (or state) must also be removed.

• If a state (or governor) is to be added to the system, the corresponding governor (or state) must be added.

When building a model, you must check the conditionality of associations against the rules and policies in the domain under study.

Exactly how these constraints are enforced is a topic taken up in several places, notably Chapter 11: Synchronizing Objects.

6.3.2 Capturing the Correct Classes and Roles

Consider the associations as shown in Figure 6.3 (page 84):

Publisher PRODUCES AND MARKETS Book

Customer PURCHASES Book

Is Book a specification or the actual tangible thing? The association with Publisher clearly has a specification nature, while the association with Customer certainly refers to a particular tangible instance of the purchase made by a Customer. This problem becomes apparent when we try to answer, "Where do I capture the price that an individual customer paid?" or "Where do I put the notion that a customer bought a certain quantity?"

The purpose of modeling is to reveal these subtle and important distinctions before they turn into bugs. Here we have a case in which two different associations with the same class view the class differently. This indicates a uniformity problem with the Book class itself. A solution is to abstract a separate class to represent the instance of the Book purchased by the Customer, as seen in Figure 6.4.

Figure 6.4. Separate Classes for Book Product and Order

In Figure 6.4, we replaced the single Book class with BookProduct and Order. One is now clearly the specification class and the other is the tangible thing. The additional class provides other benefits: We can now record the actual sale price of the book, the quantity purchased, and the date of the purchase.

Interaction between multiplicity and class definition.

The association between Order and Customer is unconditional: A Customer must have purchased a copy of a Book, and a copy of a Book must be sold to a Customer. This is based upon how we choose to define the classes: A Customer does not come into existence until a purchase is made.

If we instead choose to have prospective customers (who have purchased nothing) loaded into our system, then the multiplicity of the association and the definition of Customer would both be different, as depicted in Figure 6.5.

Figure 6.5. Conditional Associations between Customer and Book Purchase

More specific class names.

One way to express the precise meaning of the association is to add adjectives to the class name. For example, we can replace Customer with ActiveCustomer to distinguish those customers who have purchased books from lurkers who might visit the site but never purchase anything.

By saying ActiveCustomer, we've qualified what it means to be a customer and improved the model. You may be thinking, "Neat trick, but is that how the real world works?" Again, this is good practice for evaluation of the association. A significant part of the analysis process is to determine which things are part of the domain and which are not. Are any other types of customers included in this domain? How are their characteristics and behavior different from ActiveCustomers?

6.3.3 Multiple Associations

Sometimes there can be two or more associations between the same two classes. Each real-world association needs to be modeled individually.

Different roles.

Consider the situation depicted in Figure 6.6.

Figure 6.6. Multiple Associations between Classes

Each of these associations has a related, but different, meaning. While it is certainly the nominal case that the same Tenant both RENTS and LIVES IN an apartment, we can have people who live in an apartment who are not the tenants officially listed on the apartment's lease. There are other situations: A parent rents an apartment for a child; the principal tenant informally sublets the apartment to others. In all cases, the populations of associated instances do not have to be the same.

Different time.

Models may also contain multiple associations between the same two classes when the different associations represent different time scopes. The most common is the current vs. history pattern seen in Figure 6.7, in which one association captures a current transaction and a second association captures a historical set of transactions.

Figure 6.7. History Pattern

Both associations R7 and R8 are necessary because the store needs to track all the credit card charges, including those that were declined, rejected, or canceled. One association captures the historical information regarding all the charges ever attempted:

Can we model the history pattern in Figure 6.7 with a single association and a boolean attribute paysForBook that captures which one of the attempted charges is the one that actually paid for the book?

While this approach seems to "save associations," it also hides an important fact inside some conditional logic that distinguishes the one charge instance that pays for the book from all the others. It is better to expose the fact as a separate association on the model.

The purpose of modeling associations is to capture rules in the domain, so don't "save" them.

Credit Card Charge ATTEMPTS TO PAY FOR Order

while the other captures the approved charge that actually pays for the order:

Credit Card Charge ACTUALLY PAYS FOR Order

Finding multiple associations.

When we see an association like this one:

does this association mean IS CURRENTLY TRAVELING ON, IS SCHEDULEDTO TRAVEL ON, or AT SOME TIME TRAVELED ON?

Since a person can only be traveling on one airplane at a time, IS CURRENTLY TRAVELING ON has multiplicity:

but IS SCHEDULED TO TRAVEL ON and AT SOME TIME TRAVELED ON have a many multiplicity:

We suggest writing the most descriptive verb phrases for the associations, as well as writing detailed association descriptions. As you write the descriptions and note these concerns, you're doing exactly the right thing in checking the association. Perhaps the multiplicity is wrong, perhaps the association is improperly formed, perhaps the class names are ambiguous, perhaps there are multiple associations hiding behind a single line.

Multiple associations form loops.

Note that whenever you have multiple associations between the same two classes, you have a relationship loop and therefore need to model properly the constraints between those associations. Section 8.4: Association Loops discusses this issue in detail.