Skip to content

UML class diagram

Design question 2: What parts make up the system?

For OOP: classes, attributes, methods and relationships.

What it explains and when it is useful

A UML class diagram shows the classes in an object-oriented program: their attributes and methods with visibility and types, and the relationships between classes with multiplicities.

When to use it: Solutions written in an object-oriented way (Java, C#, Python classes, Swift). Show the classes that matter to your design, not every library class.

Worked example

Illustrative: PracticePal is a fictional project used throughout this guide.

Alternative version. The main PracticePal is procedural (see the structure chart). This diagram shows how the same design would look written in an object-oriented style, for example in Java.

UML class diagram for an object-oriented version of PracticePal: Student, Booking, Room, Waitlist and BookingService with attributes, methods, associations and multiplicitiesStudent- id : int- name : String- email : String- passwordHash : String+ checkPassword(p : String) : bool+ bookingsInWeek(w : Date) : intBooking- id : int- start : DateTime- status : Status- loud : bool+ checkIn(now : DateTime) : bool+ cancel() : void+ overlaps(b : Booking) : boolRoom- code : String- loudAllowed : bool- neighbours : Set<Room>+ isNeighbour(r : Room) : bool+ isBlocked(t : DateTime) : boolWaitlist- room : Room- slotStart : DateTime- queue : Queue<Student>+ join(s : Student) : int+ offerNext() : StudentBookingService- MAX_PER_WEEK : int = 3- db : Database+ book(s : Student, r : Room, t : DateTime, loud : bool) : Booking+ cancel(b : Booking) : void+ releaseNoShows(now : DateTime) : int10..*makes0..*1for0..*neighbours10..*a waiting list holds a queue of students (aggregation: hollow diamond at the whole)«uses»«uses»
Classes for an object-oriented PracticePal.

Scroll sideways to see the whole diagram.

Notation and legend

Symbol or partMeaning
Three-part boxClass name; attributes; methods
- / +private / public (# = protected)
Underlinedstatic (belongs to the class, not each object)
LineAssociation; numbers are multiplicities (1, 0..*)
Hollow diamondAggregation, at the whole (a Waitlist holds Students that exist without it)
Filled diamondComposition (parts die with the whole)
Hollow triangleInheritance, at the parent
Dashed arrow «uses»Dependency: uses another class without storing it

Design decisions it communicates

A diagram earns marks when you explain the decisions it shows. In PracticePal's documentation these would each be one sentence:

  • BookingService holds the rules, so Booking objects stay simple data with behaviour about themselves (checkIn, overlaps).
  • MAX_PER_WEEK is static: one limit for all bookings.
  • Room keeps a set of neighbours, which is the graph used for the noise rule.

Common mistakes

  • Drawing database tables and calling them classes (no methods = probably an ERD).
  • Leaving out multiplicities.
  • Diamonds at the wrong end.
  • Listing every getter and setter instead of meaningful methods.
Often confused with: ERD. An ERD models stored data: entities, attributes, keys and cardinality. A class diagram models code: classes with methods, visibility and relationships such as inheritance. A Booking table and a Booking class can both exist, drawn differently.

Checklist for your own version

Ticks are saved in this browser only, so you can use the list while you draft.