n the first article
in this series, we explained the concept of associations in UML and showed how to implement them. This article takes that knowledge one step further and explains the UML association class and its implementation. The implementation examples are again written in Java, but you can translate them to another programming language easily. The code examples are all completely generated by the UML/OCL tool called Octopus, which can be downloaded from http://www.klasse.nl/english/research/octopus-intro.html
. The code examples themselves can be downloaded here
or from the link in the left-hand column.
Association Classes and Their Meaning
After reading our earlier article you might think that implementing an ordinary association is already plenty complicated, but the UML has more in store for us in the form of an association class.
Last time, we compared a normal association, one without an association class attached, to a marriage. Any two objects that are linked through an association are "married." This comparison still holds for association classes. So we are going to explore the concept of associations using the model shown in Figure 1.
|Figure 1. One to One: A monogamous marriage as an association class.|
The model shows that Man
instances can be married to Woman
instances, and this relationship is an instance of another class called Marriage
. This is what an association class really means: It upgrades a normal association to a class that can be instantiated. Thus the relationship itself can be treated as an object.
A reason for upgrading the association to an association class, could be that you wish to keep information that is specific to the association itself but not to either of the partners. For instance, if you want to keep the date and place that the marriage was celebrated, neither the Man nor the Woman class is a good place to store the information. This information should be stored as attributes in the Marriage class. Each instance of this class would have its own values for the attributes.
The association class is a complete class. Besides the fact that it can be instantiated, it may have operations, attributes, and associations of its own. For instance, the Marriage class can have an association with the church in which the ceremony was held, or with the person that performed the marriage service. Figure 1 shows the latter. The model does not provide a gender-neutral Person class, so for the sake of the example we have arbitrarily made this officiant a man.
The ABACUS Rules for Association Classes
In our previous article we explained that normal associations have a number of characteristics, which we have dubbed the ABACUS rules. The ABACUS rules all hold true in the case that an association is upgraded to an association class. We'll go through the rules again briefly to see how their application differs from the normal associations.
- Awareness: Both objects are aware of the relationship between them. They know about each other, but they also know about the association class instance that represents their relationship.
- Boolean existence: If the partners agree to end the relationship, it is dissolved completely. When an association class is involved, this means that either the association class instance exists and holds references to both partners, or the instance does not exist at all. You cannot have an association class instance that holds a reference to just one of the partners.
- Agreement: Both objects have to agree with the relationship. This is similar to the normal association.
- Cascaded deletion: If one of the partners is deleted, the link is dissolved as well. Using an association class this mean that the instance of the association class is deleted along with everything else.
- USe of role names: An object may refer to its partner using the role name provided with the association: "my husband" or "my wife". But the object may also refer to the instance of the association class that represents the relationship. Because the UML does not allow you to define your own names for doing this, the name of the association class is being used for this purpose.
Association Class Instances: One to One Links
An important thing to know about association classes is that an instance of an association class always relates one instance of the class at the one end with one instance of the class at the other end. No matter what the multiplicities at both ends, an association class instance represents a one-to-one link (see Figure 2).
|Figure 2. Polygamous Marriage: We need two instances of the association classone to collect the unique data of each union.|
In Figure 2
Mary is married to both John and Bob. Both marriages could have taken place on a different day, in a different place, with a different preacher. Therefore, there should be two instances of the association class representing the two marriages, each with its own values for the attributes and associations. Beside, if one of the two marriages were to break up, only the one instance representing the failed marriage should be removed.
Most association class instances can be uniquely identified by the instances of the two classes that they relate. The one marriage in the example is the unique link between John and Mary, and the two marriage uniquely relates Bob and Mary. There can be no two instances of Marriage that relate the same two objects. An exception to this is when both the ends are marked <bag> or <sequence>. As you may remember from the last article this means that the type of the association end is a collection that may hold the same element more than once. In that case there may be more than one instance of Marriage that relates John and Mary. If you need to uniquely identify association class instances in this case, you need to add an attribute to the Marriage class that has a unique value over all Marriage instances. If there is no explicit need for unique identification, normal object identity will suffice.