UML Dependencies and Associations

Dependency in UML

The most general relationship between two packages, classes, or objects is dependency, which is shown by a dashed arrow:

Strictly speaking, A depends on B is changes to B might necessitate changes to A. This is a bit stronger than UML dependency because it implies transitivity.

A better reading is A depends on B if A references B. This is a bit too weak because A might reference B in some implicit way.

Perhaps the simplest way around this is to say A depends on B is that A uses B.

Examples:

The gui package might contain a class such as CustomerView that depends on the Customer class, which belongs to the business package. We also say that gui imports from business or that business exports to gui.

The CustomerView class may have a method called display that expects a Customer object as input:

class CustomerView {
   void display(Customer c) { ... }
   ...
}

A CustomerView object may contain a pointer to a Customer object.

Associations

Association and generalization are special types of dependencies.

Associations represent relationships between the objects of one class and the objects of another.

For example, the relationship:

Teacher X teaches Student Y

Can be represented by an association connecting the Teacher class to the Student class:

Some modeling tools allow us to specify the direction of an association:

This helps to distinguish it from the inverse relationship:

Student Y is taught by Teacher X

Besides an optional name, an association has to endpoints: end1 and end2.

An endpoint has six major properties:

end1.name

end1.visibility

end1.isNavigable

end1.aggregation

end1.multiplicity

end1.participant

In addition, there are several minor properties:

end1.ordering

end1.targetScope

end1.changability

end1.qualifiers

Endpoint Participant, Name, and Visibility

In the teaches association end1 might be the end connected to the Teacher class and end2 the end connected to the Student class. Therefore:

end1.participant = Teacher

end2.Participant = Student

The value of end1.name is the name used by end2.participant to refer to end1.participant. By default, it is the name of the participant, but this can be overridden:

The visibility of an endpoint is one of:

public = global visibility = +

protected = subclass visibility = #

package = package visibility = ~

private = class visibility = -

In our example both endpoints have private visibility.

Multiplicity

Suppose we pick a particular teacher, Professor Smith. How many students does he teach? In other words, how many student objects can be substituted for Y in the sentence:

Teacher Professor Smith teaches Student Y.

Conversely, if we pick a particular student: Bill Ding, how many teacher can he have? How many teacher objects can be substituted for X in the sentence:

Teacher X teaches student Bill Ding.

Multiplicity allows us to specify this. Let's assume that a Teacher has between 20 to 30 students in a term, and that a student has exactly five teachers. We can represent this in UML as follows:

If a teacher had 20 or 30 students, then we could write:

If a teacher had zero or more students, then we could write:

If a teacher had one or more students, then we could write:

Navigability

Does a teacher need to know the identity of his students? Do students need to know the identity of their teachers?

More specifically, given an object representing a teacher in some database, should we be able to generate a list of all of that teacher's students?

Given an object representing a student, should we be able to generate a list of that student's teachers?

If a teacher needs to know his students, for example to generate a grade roster, then the student end of the teaches association should be navigable. (end2.isNaviagable = true).

Graphically, this is shown by a barbed arrowhead:

Warning: If both ends are navigable, some modeling tools suppress both arrowheads!

Self Associations

Of course self associations are common:

Links

Just as objects are instances of classes, links are instances of associations:

We can think of links as representations of pointers.

 

Implementing Associations

Like attributes, associations also map to fields:

class Person {
   private Person spouse;
   // etc.
}

Assume some application needs to associate a home and business phone to each person in a database.

Here's one way to represent this in UML:

In this case we would provide Person with an array of two phones:

class Person {
   private Phone[] phones = new Phone[2];
   // etc.
}

But which one is business and which one is home?

We can solve this problem using two associations:

Here's the implementation:

class Person {
   private Phone home;
   private Phone office;
   // etc.
}

A company can have many employees and many share prices (i.e., the price of one share at the close of trading):

Usually "many" is implemented as a Java Collection:

class Company {
   private Collection<Employee> employees;
   private Collection<SharePrice> sharePrices;
   // etc.
}

Of course Collection is just an interface. This interface can be implemented as a set, multi-set, ordered set, or list. More on this later.