Class Relationships

To design classes, you need to explore the relationships among classes. The common relationships among classes are association, aggregation, composition, and inheritance. This section explores association, aggregation, and composition.

Association

Association is a general binary relationship that describes an activity between two classes. For example, a student taking a course is an association between the Student class and the Course class, and a faculty member teaching a course is an association between the Faculty class and the Course class. These associations can be represented in UML graphical notation, as shown in Figure below.

This UML diagram shows that a student may take any number of courses, a
faculty member may teach at most three courses, a course may have from five to sixty students, and a course is taught by only one faculty member. An association is illustrated by a solid line between two classes with an optional label that describes the relationship. In Figure above, the labels are Take and Teach. Each relationship may have an optional small black triangle that indicates the direction of the relationship. In
this figure, the direction indicates that a student takes a course (as opposed to a course taking a student).

Each class involved in the relationship may have a role name that describes the role it plays in the relationship. In Figure above, teacher is the role name for Faculty.

Each class involved in an association may specify a multiplicity, which is placed at the side of the class to specify how many of the class’s objects are involved in the relationship in UML. A multiplicity could be a number or an interval that specifies how many of the class’s objects are involved in the relationship. The character ***** means an unlimited number of objects, and the interval m..n indicates that the number of objects is between m and n, inclusively. In Figure above, each student may take any number of courses, and each course must have at least five and at most sixty students. Each course is taught by only one faculty member, and a faculty member may teach from zero to three courses per semester.

In Java code, you can implement associations by using data fields and methods. For example, the relationships in Figure above may be implemented using the classes in Figure below.

The relation “a student takes a course” is implemented using the addCourse method in the Student class and the addStudent method in the Course class. The relation “a faculty teaches a course” is implemented using the addCourse method in the Faculty class and the setFaculty method in the Course class. The Student class may use a list to store the courses that the student is taking, the Faculty class may use a list to store the courses that the faculty is teaching, and the Course class may use a list to store students enrolled in the course and a data field to store the instructor who teaches the course.

There are many possible ways to implement relationships. For example, the student and faculty information in the Course class can be omitted, since they are already in the Student and Faculty class. Likewise, if you don’t need to know the courses a student takes or a faculty member teaches, the data field courseList and the addCourse method in Student or Faculty can be omitted.

Aggregation and Composition

Aggregation is a special form of association that represents an ownership relationship between two objects. Aggregation models has-a relationships. The owner object is called an aggregating object, and its class is called an aggregating class. The subject object is called an aggregated object, and its class is called an aggregated class.

An object can be owned by several other aggregating objects. If an object is exclusively owned by an aggregating object, the relationship between the object and its aggregating object is referred to as a composition. For example, “a student has a name” is a composition relationship between the Student class and the Name class, whereas “a student has an address” is an aggregation relationship between the Student class and the Address class, since an address can be shared by several students. In UML, a filled diamond is attached to an aggregating class (in this case, Student) to denote the composition relationship with an aggregated class (Name), and an empty diamond is attached to an aggregating class (Student) to denote the aggregation relationship with an aggregated class (Address), as shown in Figure below.

In Figure above, each student has only one multiplicity—address—and each address can be shared by up to 3 students. Each student has one name, and a name is unique for each student.

An aggregation relationship is usually represented as a data field in the aggregating class. For example, the relationships in Figure above may be implemented using the classes in Figure below. The relation “a student has a name” and “a student has an address” are implemented in the data field name and address in the Student class.

Aggregation may exist between objects of the same class. For example, a person may have a supervisor. This is illustrated in Figure below.

In the relationship “a person has a supervisor,” a supervisor can be represented as a data field in the Person class, as follows:

public class Person {
// The type for the data is the class itself
private Person supervisor;
...
}

If a person can have several supervisors, as shown in Figure below (a), you may use an array to store supervisors, as shown in Figure below (b).

Since aggregation and composition relationships are represented using classes in the same way, we will not differentiate them and call both compositions for simplicity.