UML: Class Diagrams

Agenda

Where we are: from behaviour to structure

We have built the two behavioural views: the use case diagram (who uses the system and what they can do) and the activity diagram (how one use case flows). The class diagram is the first structural view: the fixed cast of objects the behaviour acts on.

What a class diagram is, and when to draw it

A class diagram is used when developing an object-oriented system model to show the classes in a system and the associations between them. An object class is a general definition of one kind of system object; an association is a link saying two classes are related. In early analysis, objects represent things in the real world: a patient, a prescription, a doctor, a book.

A class diagram at a glance

Before any details, here is a complete class diagram for a small library. Do not decode every symbol yet, the rest of the deck explains each labelled part. Keep returning to this picture: everything that follows is a piece of it.

Where the classes come from: three design approaches

Before any class is drawn you decide how to decompose the system. Adel's notes name three classic strategies; analysis-level class modelling usually blends them, but it helps to know which one you are leaning on.

Reading a class out of the other diagrams

A single class box has three compartments, and each maps to something you have already produced. This is the bridge from the behavioural views to the structural one.

Anatomy of a class box, in full notation

Three compartments: name (top), attributes (middle), operations (bottom). Every attribute and operation carries a visibility marker; attributes and parameters carry a type after a colon.

The visibility markers

The marker sits before the member name and records a design decision: who is allowed to touch this member. One BankAccount class shows all five at once.

How visibility actually works

Two clarifications make the markers click. Both are exactly how Java, C#, C++ and UML define visibility.

class BankAccount {
  - balance: Money                          // private to the class

  + transferTo(other: BankAccount, amt) {
       this.balance  = this.balance  − amt
       other.balance = other.balance + amt   // LEGAL: 'other' is a BankAccount too
  }
}

class StatementPrinter {                     // a different class
  + print(a: BankAccount) {
       a.getBalance()   // OK, getBalance() is public
       a.balance        // COMPILER ERROR, balance is private to BankAccount
  }
}

Analysis classes vs design classes

An analysis class abstracts one or more classes (and sometimes subsystems) of the eventual design. It models the problem domain, not the solution.

Finding the classes: data-driven noun-verb analysis

The standard recipe (Shlaer and Mellor, late 1980s): identify the data first, group it into classes, then attach behaviour. It keeps the model grounded in the requirements rather than the developer's imagination.

1. Read the requirements and underline every noun and noun phrase; collect them as candidate classes.
2. Discard the inappropriate candidates (next slide), promoting some to attributes.
3. Identify every verb and verb phrase; these are candidate operations.
4. Assign each operation to the class responsible for it.

Which nouns to keep, which to discard

Worked example: the Library, noun analysis

Adel's running example. Underline the nouns in the requirement text, then sift them.

Which nouns become classes, and the judgement calls

Noun-verb analysis gives candidates, not answers. For each one you argue keep, reject, or it depends, and the reasoning matters more than the verdict. Reasonable modellers differ on the rows marked “debatable”.

First-cut analysis class model

The kept nouns become boxes. At this stage they are just named classes; the verb analysis then fills in operations, and the associations come next.

Relationships between classes

Relationships are connections between modelling elements: they describe how objects work together and act as a sanity check on the model. Four kinds carry almost all the weight.

Associations: direction and naming

Name an association with a verb phrase and read it in a direction. Navigability (the arrowhead) says which way access and flow can travel.

Associations in detail: roles, reflexive links, and instances

An association line can say more than “these two are related”. It can name the role each end plays, and a class can even be associated with itself.

Multiplicity (cardinality)

Multiplicity on an association end answers: how many instances of this class can take part in the relationship at one time?

Generalisation (inheritance)

When one class is a more specific kind of another, draw a generalisation: a solid line with a hollow triangle pointing at the parent. The child inherits the parent's attributes, operations and associations, and adds its own.

Aggregation and composition (part / whole)

Both say one class is built out of others. They differ in the lifetime of the part: the diamond sits at the whole.

Association classes

When an attribute belongs to the relationship rather than to either class, put it on an association class: a class box joined to the association line by a dashed link, sharing the association's name.

A second domain: the MHC-PMS (patient records)

Adel's other running example, from Sommerville's mental-health-care patient management system. It shows a different shape: one central, attribute-rich class, Consultation, that anchors the whole model.

Dependency, data types and enumerations

Two more notations from richer diagrams. A dependency (dashed open arrow) is a transient "uses" link, weaker than an association. Stereotypes in guillemets label a class's kind.

What makes a good analysis class

A short checklist that reviews look for. Most weak class models fail on cohesion or coupling.

• Its name reflects its intent. Prescription tells you what it is; Manager or Helper tells you nothing.
• It is a crisp abstraction of one specific element of the problem domain, not several.
• It has a small, defined set of responsibilities, one reason to change.
• High cohesion: it holds only the attributes and operations that genuinely belong together; unrelated ones lower cohesion.
• Low coupling: it has only the associations it truly needs; accidental links raise coupling and spread change.

Cohesion: high versus low

Shown, not told. The class on the left does four unrelated jobs; the one on the right does one, with the rest moved to their own classes.

Patient
  + name, dateOfBirth
  + register()
  + sendReminderEmail()    // messaging
  + generatePdfReport()    // reporting
  + connectToDatabase()    // persistence
  + calculateInsurance()   // billing

Patient
  + name, dateOfBirth
  + register()
  + updateContact()

// the rest moved out, to:
NotificationService, ReportGenerator,
PatientRepository, InsuranceCalculator

Object diagrams: a snapshot of instances

Where a class diagram shows the types, an object diagram shows specific instances and the links between them at one moment, a snapshot. Object names are underlined, in the form name : Class.

Back to back: one system, three views (1 of 4)

The three diagrams are not separate exercises. Take a single description and watch the same words drive the use case diagram, then the activity diagram, then the class diagram.

View 1 – the use case diagram: who, and what

Back to back: one system, three views (2 of 4)

Pick one use case, Borrow copy of a book, and unpack how it flows. Each action is a verb the system or an actor performs; the swimlanes record who does each.

Back to back: one system, three views (3 of 4)

This is the diagram from the opening “at a glance” slide, now read against the description. The nouns are classes; the data they hold are attributes; the use cases and activity actions are operations; the noun-verb pairings are the associations.

Back to back: one system, three views (4 of 4)

The traceability map. Every diagram element should be answerable to a phrase in the description – this table is how a reviewer, or you, checks that nothing was invented and nothing was dropped.

Where class diagrams earn their place

Common pitfalls

• Attributes drawn as classes. "Title", "ISBN", "status" are attributes of a class, not classes of their own.
• The omnipotent class. A "SystemManager" that does everything signals analysis stopped too early; split it by responsibility.
• Generalisation where association is meant. Use is-a only for genuine specialisation; "has-a" and "part-of" are association and aggregation.
• Missing multiplicity. An association end with no multiplicity hides a business rule; always state both ends.
• Aggregation everywhere. If lifetime is not tied, it is a plain association; if it is, prefer composition.
• Mixing analysis and design. Full method signatures, types and infrastructure classes belong to the design-level diagram, not the first cut.

How to build one, and what comes next

Sources: A. Taweel, COMP433 Ch.4 lecture notes; Sommerville, Software Engineering 10th ed.; Booch et al.; Shlaer & Mellor. Companion: COMP433_Ch4_UML_System_Modelling_Companion.html.