In the real world, objects have relationships -- associations to other objects. The relationships between objects are important because they help us to define how objects interact with each other. For example, students take courses, professors teach courses, criminals rob banks, politicians kiss babies, and captains command starships. Take, teach, rob, kiss, and command are all verbs that define associations between objects. You want to identify and document these relationships, so that you can gain a better understanding as to how objects interact with one another.
The Unified Modeling Language (UML) distinguishes between three different types of relationships between objects: association, aggregation, and composition. An association is a simple relationship between two objects without any additional implications. Aggregation is a narrower type of association that represents "is part of" relationships between two objects, such as the fact that an item is part of an order. Composition is a strong form of aggregation where the "whole" is completely responsible for its parts and each "part" object is only associated to the one "whole" object, for example an airplane is composed of wings and a fuselage.
Not only must you identify the relationship(s) between classes, you must also describe the relationship. For example, it's not enough to know that students take seminars. How many seminars do students take? None, one, or several? Furthermore, relationships are two-way streets: not only do students take seminars, but seminars are taken by students. This leads to questions like: How many students can be enrolled in any given seminar, and is it possible to have a seminar with no one in it? The implication is that you also need to identify the cardinality and optionality of an association. Cardinality represents the concept of "how many," whereas optionality represents the concept of "whether you must have something."
It is important to note is that the UML chooses to combine the concepts of optionality and cardinality into the single concept of multiplicity. However, my experience is that significant value exists in considering the two concepts in isolation: For each direction of an association there is value in asking whether the association must exist (optionality) and how many could possibly exist (cardinality)? For example, consider the "teaches" association between professors and seminars. I would ask:
- Must a professor teach a seminar? Or is it possible that some professors don't do any teaching?
- How many seminars could a single professor teach?
- Must a seminar be taught by a professor? Or is it possible that someone who isn't a professor could teach a course?
- How many professors are potentially needed to teach a single seminar?
When you model relationships in UML class diagrams, you show them as a thin line connecting two classes, as you see in Figure 1. Relationships can become quite complex; consequently, you can depict two things about them on your diagrams. Figure 1 shows the common items to model for a relationship. You may want to refer to The Unified Modeling Language Reference Manual (see Resources) for a detailed discussion, including the role and cardinality on each end of the relationship, as well as a label for the relationship. The label, which is optional, is typically one or two words describing the relationship. The multiplicity of the relationship is labeled on either end of the line, one multiplicity indicator for each direction (Table 1 summarizes the potential multiplicity indicators you can use). At each end of the relationship, the role -- the context that an object takes within the relationship -- may also be indicated.
Table 1. UML multiplicity indicators
| Indicator | Meaning |
| 0..1 | Zero or one |
| 1 | One only |
| 0..* | Zero or more |
| 1..* | One or more |
| n | Only n (where n > 1) |
| 0..n | Zero to n (where n > 1) |
| 1..n | One to n (where n > 1) |
As you can see in Figure 1, aggregation is indicated using a hollow diamond and composition is indicated with a darkened diamond, both of which are at the end of the association line nearest the "whole" object.
Figure 1. Notation for modeling relationships on UML class diagrams
Introduction to implementing relationships
Relationships are maintained through the combination of attributes and
methods. The attributes store the information necessary to maintain the
relationship and methods keep the attributes current. For example, the
Student class of Figure 2 would potentially have an attribute called
takes. It may have an array, which is used to keep track of the Seminar
objects the student is currently taking. The Student class might also
have methods such as addSeminar and removeSeminar to add and remove
seminar objects into the array. The Seminar class would have a
corresponding attribute called students and methods called addStudent
and removeStudent to maintain the relationship in the opposite
direction. All of this has a significant implication: because attributes
and methods are inherited, associations are too.
In Figure 2, the unidirectional association "holds" between Employee
and Position would be easier to implement because you only need to
traverse it in one direction: from Employee to Position. Therefore,
Employee would have an attribute called position and methods, called
something like setPosition and getPosition to maintain the
association. There would be nothing added to Position because there is
no need for position objects to collaborate with employee objects,
therefore, there is no added code to maintain the association in that
direction.
Figure 2. Examples of simple relationships
When you are modeling, the common style is to assume the attributes and
methods exist to maintain associations (you don't need to show them on
your diagrams). You should consider setting naming conventions for these
attributes and methods. I typically use the role name or the class name
for the attribute name and method names, such as addAttributeName and
removeAttributeName for many associations, and setAttributeName and
getAttributeName for single associations when I'm writing the source
code, but this will be the topic of future articles.
- Building Object Applications That Work by Ambler, S.W. New York: Cambridge University Press, 1998.
- The Object Primer 2nd Edition by Scott W. Ambler. New York: Cambridge University Press, 2001.
- The Unified Modeling Language Reference Manual by James Rumbaugh, Grady Booch, and Ivar Jacobson. Reading, MA: Addison-Wesley Longman, Inc., 1999.
- The Elements of Java Style by Vermeulen, A., Ambler, S.W., Bumgardner, G., Metz, E., Misfeldt, T., Shur, J., & Thompson, P. New York: Cambridge University Press, 2000.
Scott W. Ambler is President of Ronin International, a consulting firm specializing in object-oriented software process mentoring, architectural modeling, and Enterprise JavaBeans (EJB) development. He has authored or co-authored several books about object-oriented development, including the recently released The Object Primer 2nd Edition, which covers, in detail, the subjects summarized in this article. He can be reached at scott.ambler@ronin-intl.com and at his Web site at www.ambysoft.com.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
Spring, JRuby, and Ajax development is easier with WebSphere Application Server - a smart Java 5 and J2EE Web services-based application server.
- Try: The no-charge WebSphere Application Server Community Edition is a pre-integrated, lightweight Java 5 application server built on Apache Tomcat and other best-of-breed open source software such as OpenEJB, Apache Axis, and Apache Derby.
- Article: The article leverage the Spring Framework and the WebSphere Application Server to improve your J2EE project productivity.
- Tutorial: See how the free WebSphere Application Server and XML can improve the efficiency of your JRuby on Rails and Ajax development.
- Buy: WebSphere Application Server - Express
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
