Overview of This Lesson

This lesson introduces you to class relationships and why they're important. We begin examining class relationships by looking at dependency and association.

Intro To Class Relationships

Class relationships define how various classes and kinds of classes are related to each other. For example, there is a special relationship between a class called Flower and a class called Rose: A Rose is a type of Flower. There is a different kind of relationship between the classes Student, Course and Textbook. A Student uses a Textbook; a Course has a Textbook. Defining these relationships help us understand how objects in a program work together and communicate with each other.

Although the information can vary from one source to another, there are generally considered to be 5 types of class relationships:

• Dependency
• Association
• Aggregation
• Composition
• Inheritance

In this lesson we'll focus on dependency and association, and the next few lessons will talk about Aggregation and Composition and Inheritance.

Depicting Relationships in UML

We use different kinds of UML diagrams to show classes/objects and their relationships to each other.

Object diagrams show the relationships and interactions between the objects in a program.

In an object diagram, the classes are represented by rectangles that have the class name written inside, and some conventions even underline the class names. Some will also include specific object variable names used in a specific program, and might even include the attributes for that object and their values.

Examples

A class diagram shows the different characteristics of one or more classes and their relationships to each other.

The relationships in an object diagram or class diagram are shown by using different styles of lines and arrows between the classes. Sometimes it is also necessary to show cardinality or multiplicity information. These two terms refer to the same thing: the arithmetical relationship between the classes. For example, a library will be associated with many library items and many patrons, and a library item can only be loaned to one patron at a time. Examples of cardinality are:

We sometimes also use labels on a diagram to show activity that takes place between classes/objects.

In the above diagram, we see that there is activity taking place between the two classes: Students are taught by teachers, and teachers teach students.

Along with special lines, and sometimes text labels, we can accurately depict each of the different types of class relationships.

Dependency

In a dependency relationship, one class uses the services of another. The class that is being used is referred to as the supplier, and the class that is using the supplier is referred to as the client. Any changes to the structure or behaviour of the supplier class affects the client. This is sometimes called a "uses" relationship (e.g. "The Account class uses the Customer class"). This is also a short-term relationship: once the client object has finished using the services of the supplier object, the supplier object is no longer needed.

An example of dependency could be the relationship between an ATM class and an Account class: The Account class contains information about a customer account at a bank, such as customer number and account balance:

public class Account {
private String acctId;
private double balance;

public Account() { ... }
public Account(String id, double balance) { ... }
public void setAcctId(String id) { ... }
public String getAcctId() { ... }
public void setBalance(double balance) { ... }
public double getBalance() { ... }
}

An ATM object is used by a customer to access their account and withdraw or deposit funds:

public class ATM {
private String location;
public ATM() { ... }
public ATM(String location) { ... }
public void logInCustomer(Account custAccount) { ... }
public void performTransaction(Account custAccount) { ... }
public void logOutCustomer(Account custAccount) { ... }
}

The customer needs to be able to log into the ATM, so perhaps the ATM class has a logInCustomer() method that accepts the Account object for that particular customer. In this case, the ATM account uses the Account object when it wants to log in a particular customer. Once the customer has finished their transaction and logged out, the Account object is no longer needed.

In programming, we often code a dependency relationship when we:

• Pass the supplier object into a method in the client object, as we see in the ATM/Account example.
• Create an instance of the supplier class in the client class's methods so that we can use the supplier class methods. For example, the ATM class's performTransaction() method might create an instance of the Calendar class so it can use the Calendar class methods to get the current date and add it to the transaction information.
• Note that if ClassA contains a data member of ClassB, that is not a dependency between ClassA and ClassB (yes, ClassA is dependent on ClassB, but this is a more specific kind of relationship, such as Aggregation or Composition).

Dependency in UML

Dependency is shown with a dashed line connecting the client class to the supplier class. There should be an arrow on one end that points from the client to the supplier.

Dependency is such a common relationship that many class diagrams don't actually show every dependency that exists in a system because the diagram would be too cluttered. Instead, diagrams will show only those dependencies that are important. For example, many classes would use the String class, but you wouldn't see the String class on most class diagrams.

Another example: say you have a Vending Machine that accepts Coins:

public class VendingMachine {
private String location;
private String owner;
public void enterPayment(Coin[] coins) { ... }
public void giveChange(Coin[] coins) { ... }
}

public class Coin {
private double value;
private String type;   
...
}

In the above example, the VendingMachine uses Coins. The VendingMachine depends on Coins, but the Coins don't depend on the VendingMachine.

Association

An associative relationship occurs between classes that are connected because one class "is part of" another class. Another common phrase is that one class "has/has a(n)" other class. Usually there is some kind of activity taking place between the two classes. It is a stronger form of dependency than the actual Dependency relationship.

For example, in a course registration system with Students and Professors, a Student is taught by a Professor, and a Professor teaches a Student. There is an association relationship between Student and Professor. Also, a Professor "has" several Students, and a Student can "have" several Professors.

Classes in an associative relationship are independent in that they each have their own life cycle: each object is created and deleted independently, without creating/deleting the other object. Furthermore, the "part class" can be "part of" more than one "container class" and vice versa.

For example, a Student can be taught by many Professors and a Professor teaches many Students; deleting a Student doesn't cause the deletion of a Professor and vice versa, just as creating a Student doesn't require the creation of a Professor and vice versa. A Student can be taught by more than one Professor, and a Professor can teach several different Students.

An associative relationship is implemented in code via the state of the "container" or "owner" class: association between ClassA and ClassB occurs when ClassB is part of the state of ClassA. In other words, ClassA contains an instance variable of the type ClassB. In a bi-directional association, both ClassA and ClassB are part of each others' state, as in the Student/Professor example below:

Example: the Student class could contain a list (e.g. array) of Professors, and the Professor class could contain a list (e.g. array) of students:

public class Student {
private String firstName;
private String lastName;
private Professor[] professors;
}
public class Professor {
private String firstName;
private String lastName;
private Student[] students;
}

Association relationships also include cardinality or multiplicity. Cardinality refers to the number of elements/occurrences. For example, one Album has many Songs, and one Song can belong to many Albums (if the artist releases the song on more than one album or the song is part of some other compilation album). This would be a "many-to-many" association relationship. Another example: a Course is taught by one Professor and a Professor teaches many Courses. This is a "one-to-many" relationship.

Another common way to program association is to create a class that bridges the relationship. For example, A Course class could be created that represents Courses taken by Students and taught by Professors. Then the Student and Professor classes would each contain an instance variable representing the list (array) of Course objects being taken/taught:

public class Student {
private Course[] courseList;
    public void registerCourse(Course c) {}
}

public class Professor {
    private Course[] courseList;
}

public class Course {
    private String courseCode;
    private String title;
    private double creditValue;
}

The interesting thing about this option is that it now creates new relationships between Student and Course, and Professor and Course. These would be referred to as Aggregation/Composition, which are just specific forms of Association.

Association in UML

Association is shown with a solid line. Example: