Home > Articles > Programming > Java

Java Reference Guide

Hosted by

Toggle Open Guide Table of ContentsGuide Contents

Close Table of ContentsGuide Contents

Close Table of Contents

Class Relationships

Last updated Mar 14, 2003.

Defining classes and an inheritance hierarchy is interesting, but you need to define how those classes relate to one another if you are going to solve a real business problem. UML defines several different types of relationships, but they come in three main flavors:

  • Aggregation
  • Composition
  • Association

Aggregation and composition define a “has-a” containment relationship. They are closely related, but the main difference comes in the notion of ownership. In a composition relationship we say that one object owns another object. For example, a car owns its engine, a library owns books, and a store owns a sign.

An aggregation relationship is similar to a composition relationship in that an object contains another object, but the object does not own the other object. Many times the difference will be evident by the life-cycle of its objects: if you destroy a car, its engine will be destroyed, if you close a library, its books will be sent away, and if a store closes, it's sign will be thrown in the trash. In this example, the engine, the books, and the sign only exist if the containing object exists. To illustrate how an aggregation may exist, consider that a driver sits in a car to drive it. The driver is contained by the car, but when it comes time to send the car to the junkyard, the driver will simply buy another car. This is an aggregation because the driver exists outside of the life-cycle of the car.

A composition is represented in UML as a line between the two objects with a filled-in diamond on the object that contains the other object. An aggregation is represented in UML as a line between the two objects with a hollow diamond on the object that contains the other object. Both relationships are depicted in figure 1.

Figure 1. Composition vs Aggregation

In figure 1, the Car class contains the Engine class as a composition. Likewise, the Car class contains the Driver class as an aggregation.

Associations define non-containment relationships between objects. Associations define multiplicities in their relationships of form:

  • One-to-One
  • One-to-Many
  • Many-to-One
  • Many-to-Many

These relationships are best described with an example. Figure 2 shows four classes that define each of the aforementioned relationships.

Figure 2. Associations with multiplicities

There are four classes in figure 5:

  • Article: contains article information such as a title , content, and links to resources
  • Summary: contains an article summary
  • User: users, which are authors of an article
  • Comment: comments that users can leave about the article

Associations are defined as straight lines between classes with their multiplicities defines at the end of each line (called an association end.) Note that each association end can have a name, such as “authors” and “comment”. The relationships in figure 2 can be read as follows:

  • One-to-One: an article can have a single summary, denoted by the name “summary” and a summary can summarize a single article, denoted by the name “article”
  • One-to-Many / Many-to-One: an article can have zero or more comments, denoted by the name “comments”, but a comment can only be able one article, denoted by “article”
  • Many-to-Many: an article can be written by one or more author, denoted by the name “authors”, and a user can write zero or more articles, denoted by the name “articles”

The multiplicities are specified using the notations:

  • 1: there is one, and only one, instance at the end of the associations
  • 0..1: there can be zero or one instance at the end of the association
  • 0..*: there can be zero or more instances at the end of the association
  • 1..*: there must be at least one, but there can be many instances at the end of the association

Most of the time, the multiplicities will logically flow from your understanding of the domain you are modeling.

While we have not defined any attributes or methods on these classes, it might be useful to look at the code that ArgoUML generates from this class diagram. Listings 1, 2, 3, and 4 shows the generated code for the Article, Comment, User, and Summary classes, respectively.

Listing 1. Article.java

import java.util.Vector;

public class Article {

    public Summary summary;
    /**
   * 
   * @element-type Comment
   */
  public Vector  comments;
    /**
   * 
   * @element-type User
   */
  public Vector  authors;
}

Listing 2. Comment.java

public class Comment {

    public Article article;

}

Listing 3. User.java

import java.util.Vector;

public class User {

    /**
   * 
   * @element-type Article
   */
  public Vector  articles;

}

Listing 4. Summary.java

public class Summary {

    public Article article;

}

We can make the following observations about the generated code:

  • The Article class has a one-to-one association with Summary class, so it contains a single reference to it
  • The Article class has a one-to-many association with the comment class, so it maintains a collection of comments
  • The article class has a many-to-many relationship with authors, so it maintains a collection of articles

The other relationships are similarly modeled. Another observation that you have probably already made is that the code generation is very primitive: it uses Vectors, which should be replaced by Lists, and it does not use generics. But the code should point you in the right direction, or give you a starting point for building your classes.