Association Classes - UML

The following domain requirements set the stage for association classes:

  1. Authorization services assign a merchant ID to each store for identification during communications.
  2. A payment authorization request from the store to an authorization service needs the merchant ID that identifies the store to the service.
  3. 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 Authorization - Service.

Figure 31.14 Inappropriate use of an attribute

This leads to the following modeling principle:

Guideline : 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 Contact lnformation, and associate many of these to Person.

Figure 31.15 First attempt at modeling the merchantID problem

The above principle suggests that something like the model in Figure 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 visually communicates the idea that a Service - Contract 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.

Figure 31.16 An association class

Figure 31.17 Association classes

Guidelines for adding association classes include the following:

Guideline : Clues that an association class might be useful in a domain model:

  1. An attribute is related to an association.
  2. Instances of the association class have a lifetime dependency on the association.
  3. 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.

All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd Protection Status

UML Topics