UML Class Diagrams

Why UML?

Unified Modeling Language (UML) class diagrams are a visual notation for describing the static structure of an object-oriented system. They show classes, their contents, and the relationships between them. For Tripos purposes, you do not need perfect UML syntax, but you must be able to communicate class structure and relationships clearly in diagrammatic form.

The Class Box

A UML class is drawn as a rectangle divided into three compartments:

Visibility Markers

UML Symbol	Java Keyword	Meaning
+	public	Accessible from anywhere
-	private	Accessible only within the class
#	protected	Accessible within the package and by subclasses
~	(default/package-private)	Accessible within the package

Field Notation

visibility name : type

Examples:

- balance : double
+ PI : double
# name : String

For static members, underline the entry (or use {static} annotation). For abstract members, use italics or {abstract}.

Method Notation

visibility name(parameter : type, ...) : returnType

Examples:

+ deposit(amount : double) : void
+ getBalance() : double
- validate() : boolean

Relationship Types

UML defines several relationship types, each with a distinct notation:

Association (plain line)

A general relationship between two classes. Drawn as a solid line. Can be annotated with a label, role names, and multiplicity.

Directed Association (arrow)

Shows that one class knows about another but not necessarily vice versa:

Aggregation (hollow diamond)

A “has-a” relationship where the contained object can exist independently of the container. The hollow diamond is on the container side:

Books can exist without the library. If the library is destroyed, the books survive (conceptually).

Composition (filled diamond)

A stronger “has-a” relationship where the contained object’s lifecycle is tied to the container. The filled diamond is on the container side:

An engine is part of a car. If the car is destroyed, the engine is destroyed with it (conceptually — in Java, this means the containing object holds the only reference).

Inheritance / Generalisation (hollow triangle arrow)

An “is-a” relationship. The arrow points from the subclass to the superclass:

Realisation / Implementation (dashed hollow triangle)

A class implementing an interface:

Dependency (dashed arrow)

A “uses” relationship — one class uses another as a parameter, return type, or local variable, but does not hold a lasting reference:

Multiplicity

Numbers at the ends of associations indicate how many instances participate:

Notation	Meaning
1	Exactly one
0..1	Zero or one (optional)
* or 0..*	Zero or more
1..*	One or more
n	Exactly n
n..m	Between n and m inclusive

One order contains zero or more items; each item belongs to exactly one order.

Abstract Classes and Interfaces

Abstract class names are written in italics. Interface names are written in italics with the «interface» stereotype (guillemets):

Complete Example

A banking system in UML:

A BankAccount has zero or more Transaction objects (aggregation). SavingsAccount is a subclass of BankAccount (inheritance).

Tripos Advice

For exam questions that ask you to draw a class diagram:

1. Start with the class boxes — name and key fields/methods are sufficient; you do not need to list every member
2. Add relationship lines between classes that interact
3. Label relationships with multiplicity where it is important to the question
4. Show inheritance and interface implementation arrows clearly
5. Use visibility markers for fields that are relevant to the question’s concerns about encapsulation

You will not lose marks for minor UML syntax variations (solid vs dashed line thickness, exact arrowhead shapes). You will lose marks for missing relationships, wrong multiplicities, or incorrectly showing a “has-a” as an “is-a” (or vice versa).