Before a single brick is laid, an architect draws a blueprint: a floor plan, an elevation, a wiring diagram. Nobody argues that the blueprint is the house — but try building a house without one and see how the plumbers and electricians get along. Software is no different. A medium-sized system has hundreds of moving parts and a team of people who each hold a slightly different picture of it in their head. Left to words alone, those pictures drift apart, and the drift only surfaces when the code refuses to fit together.

Modelling is the act of drawing that blueprint for software: a picture of the system's pieces and how they relate, made before and while you build, so the whole team can point at the same thing and agree. The most widely used notation for these pictures is UML — the Unified Modeling Language, a standard set of shapes and lines for describing software visually. It is not a programming language and it does not run; it is a shared vocabulary of diagrams that a designer in Berlin and a coder in Bangalore will both read the same way.

One system, several views

A house needs more than one drawing because a floor plan and a wiring diagram answer different questions. UML works the same way: it offers a family of diagram types, each capturing a different view of the same system. Three earn their keep on almost every project, and they are the three we will learn here:

• Class diagrams — the structure: what kinds of thing exist, what data and behaviour each has, and how they are wired to one another. This is the static skeleton.
• Use-case diagrams — the scope: who uses the system (the actors) and what goals they can accomplish with it. This is the outside view, told in the user's language.
• Sequence diagrams — the behaviour over time: for one particular scenario, which objects send which messages to which, and in what order. This is the story of a single interaction unfolding.

Structure, scope, behaviour. Get comfortable reading these three and you can read the design of almost any object-oriented system at a glance.

Use-case diagrams: who wants what

The gentlest place to start is the outside. A use-case diagram shows the system as a box, the people (and other systems) who interact with it as stick-figure actors standing outside the box, and each thing an actor can accomplish as an oval use case inside it. A line joins an actor to every use case they take part in.

For a library system, a Member can borrow a book, return a book and search the catalogue; a Librarian can add a new book and register a member. Notice what this diagram deliberately leaves out: no code, no data types, no algorithms — just who wants what. That is exactly its value. You can put it in front of a customer who has never programmed and they can tell you "you forgot that a member also needs to pay a fine" before anyone has wasted a day building the wrong thing.

Class diagrams: the shape of the code

The class diagram is where UML meets the code you already know. Each class becomes a rectangle split into three compartments, stacked top to bottom:

• the name of the class;
• its attributes — the data each object holds (its fields);
• its operations — the methods each object can perform.

A box on its own is just a class. The power comes from the lines between the boxes, each of which means a specific kind of relationship:

• Association — a plain line: two classes simply know about each other. A Member is associated with the Books they have borrowed.
• Generalization (inheritance) — a line with a hollow triangle pointing at the parent: "is a kind of". A Book is a LibraryItem; so is a DVD. The triangle always points to the more general class.
• Composition — a line ending in a filled diamond at the "whole": a strong "part of" where the part cannot outlive the whole. A Library is composed of its Shelfs — destroy the library and the shelves go with it.

The figure below models a slice of a library. Step through it: first the parent class every item shares, then a Book that specialises it, then the generalization triangle that ties them together.

Read it back into code and the mapping is exact: the box name is the class name, the middle compartment is the fields, the bottom is the methods, and the hollow triangle is class Book extends LibraryItem. That tight correspondence is why class diagrams are the most-drawn UML diagram of all — a good one is practically the code, minus the typing.

Sequence diagrams: the story of one interaction

A class diagram tells you what the pieces are; it says nothing about what happens when someone actually borrows a book. That story — one scenario, playing out step by step — is what a sequence diagram captures.

Each participating object gets a lifeline: a labelled box at the top with a dashed vertical line dropping down from it. That vertical line is time — earlier at the top, later further down. A message from one object to another is a horizontal arrow between their lifelines, and because the arrows sit at descending heights, reading top to bottom replays the interaction in order. A solid arrowhead is a call ("do this"); a dashed arrow is the return ("here's the result").

Here is "a member borrows a book", told as a sequence. Step through the messages and watch the call travel across the objects and the answers come back.

The same three objects appear in the class diagram, but here we see them collaborate: the request flows left to right as calls, and results flow back as returns. If a class diagram is a cast list, a sequence diagram is a single scene of the play.

Why modelling pays off

Diagrams are cheap to draw and cheap to throw away; code is expensive to write and expensive to rip out. Modelling exploits that gap. A design flaw that would cost a week to unpick in code costs thirty seconds to spot and erase on a whiteboard. And because everyone reads the same standard shapes, a UML sketch is a communication tool: it lets a team argue about the design — before the design has hardened into something painful to change.