Associations
Classes do not operate well on their own. In fact, if you have classes that have no sort of association with another class, I suggest you revisit the design of your application. That is not to say that it cannot happen, however. There are three main types of association that we are concerned with:
- Generalisation
- Composition
- Aggregation
These three types describe how the class is part of, or formed out of, another classes.
When dealing with many classes, you can show the associations of the classes by just showing its name without showing its attributes or operations. This is useful when dealing with big diagrams.
Generalisation
The generalisation relationship is often described as “a kind of” relationship. That is, one class is a kind of another class. This is shown using an arrow, similar to those of use cases.
The arrow points towards the base class, that is, the class from which the derived class inherits its attributes. In your class diagrams, you will have the class with its complete information, along with the generalisation, as seen below. Of course you can have multiple classes inheriting from a single class.
Should you make use of polymorphism, all methods that override those in the base class should be indicated again in the derived class.
This shows that all the attributes and methods from the User class (username, password, email, validate(), and sendEmail()) will all be available in the Clerk class as well!
Though it is technically possible to indicate how one class derives from multiple base classes, most programming languages does not support this ability. Unless you’re crazy, and programming in raw C, of course.
Here you can see that three classes all derive (inherit) from the User class, namely: Lecturer, Assistant, and Student. Some things to note is that the Lecturer class does not have any special methods of its own (although it might have set- and get-methods). Also, note that the logStudent method in Assistant requires a Student object as a parameter – that shouldn’t come as a surprise to you that it works.
Composition & Aggregation
The next types of relationships are composition and aggregation. Both indicate that one class is “part of” or “composed” of another class. However, they differ in one instance: whether the contained class is owned or used by the parent class.
- Composition: Class A owns Class B. Class B is dependant on and cannot exist without Class A. Also classed a strong association.
- Aggregation: Class A uses Class B. Class B is independent, and can exist without Class A. Also called a weak association.
For the sake of completeness, and allowing you to find it easily in the index, let’s see how they’re drawn.
Composition
Composition is indicated using a filled diamond, as shown in below.
This strong association means that ClassB cannot exist without ClassA. For example, if a ClassA ceases to exist, then ClassB will cease to exist.
Aggregation
The second type, aggregation, is indicated using a clear diamond, as shown below.
This weak association means that ClassB is independent and will exist without ClassA. For example, if a ClassA ceases to exist, then ClassB will continue to exist.
In the next figure you can see that a Project has a manager (of type Employee) and tasks (of type Task). If the Project ceases to exist, the tasks for the project will also cease to exist. But, if the Project ceases to exist, the employee will still continue to exist. Unless they execute a manager who made the project fail…
Although this diagram might look confusing at first will all the different types of relationships, let’s look at it class by class.
Let’s start with the User class. From this class Lecturer, Assistant, and Student are derived. In other words: Lecturer, Assistant, and Student are specialisations of User.
Next the Module class. It is composed of the Practical. If the Module ceases to exist, the practicals will also cease to exist.
Lecturer, Assistant, and Student are also part of Module. No, I cannot just show an aggregation with User, because they all perform different roles. However, if the Module ceases to exist, all three types of users will still exist.