Why draw before you type?
Lesson 1 of 6
1Why draw before you type?
A diagram is not decoration for a report, it is a question answered. This part fixes which question each diagram answers, and when drawing is a plain waste of time.
What the picture shows: Each question has its diagram: who uses the system, what exists in it, who calls whom, and what the steps are.
Map of this part
The concepts in order, click any one to jump to it:
Two ways into the same idea
Before building a house you draw its plan, but you do not draw everything: you draw the rooms to ask "is there enough space?" and the pipes to ask "where does the water go?". Each drawing answers one question. A drawing that answers no question you need is wasted time however pretty it is.
Each UML diagram answers a different question: use cases "who wants what", classes structure and multiplicity, sequence the order of messages, activity the steps and decisions. Draw when a mistake in code would cost more than the drawing, and stop when the drawing no longer changes a decision.
Required fundamentals
Classes and objects
You know a class is a template and an object an instance of it. Nothing more is needed to start.
Paper, or a drawing tool
Draw by hand first. A tool makes a diagram pretty; paper makes it right faster.
A small real system
You will model a simple library. Any system you know works, what matters is knowing its rules.
Core concepts
A standard drawing language, not a programming language: an agreed set of symbols so two engineers read the same diagram the same way without a spoken explanation. That is all it is, and it is enough.
Each diagram answers exactly one question. Who uses the system and why? → use case. What things exist and how do they relate? → class. Who calls whom, in what order? → sequence. What are the steps and decisions of a process? → activity. If you cannot write the diagram's question in one line, do not draw it.
Structural photographs a still moment: what exists and how it connects. Behavioural photographs time: what happens and in what order. The commonest mistake is trying to cram time into a structural diagram.
Not documentation, but catching contradictions early. One relationship line forces the question “can this exist with no owner?”, and that question is a thousand times cheaper on paper than in a database holding real data.
A diagram proves no correctness, measures no performance and settles no disagreement about priorities. And whoever draws twenty diagrams before writing a line is not planning, they are postponing.
How it works
Diagram 1, The two UML families: the still and the moving, each with its own question
Diagram 2, One decision before every drawing: does it answer, and does it change a decision?
| The question | The diagram | Part here |
|---|---|---|
| Who uses the system and why? | Use case | 2 |
| What things exist and how do they relate? | Class | 3 |
| Who calls whom, in what order? | Sequence | 4 |
| What are a process's steps and decisions? | Activity | 4 |
| How do we store all of it? | Data models | 5 and 6 |
The exercise: from the librarian's words to a model
The system we will build across the first four parts: a small library. The rules, gathered from “the librarian” in four sentences:
- A member borrows a copy of a book, not the book itself.
- One copy is with one member at a time, or with nobody.
- A member borrows at most 5 copies, and may not borrow while overdue.
- A book may be in the library with no available copy, and is still a book.
| What the librarian said | What it means in the model |
|---|---|
| “A member borrows a book” | A member borrows a copy of a book |
| “We have that book” | A book is a bibliographic record, possibly with no available copy |
| “Five books” | Five copies on loan at one time |
| “They are overdue” | They have at least one loan past its due date |
Myth vs. reality
| The myth | The reality |
|---|---|
| “UML is an old programming language.” | It is not a programming language at all, it is drawing notation. Notation does not age. |
| “Diagrams are documentation written after the code.” | A diagram after the code is documentation; a diagram before it is a decision. The second is what saves money. |
| “Draw every diagram for every system.” | Draw the diagram that has a question you cannot answer. The rest is work with no buyer. |
| “A beautiful diagram is a good diagram.” | A good diagram makes the reader ask a specific question. Beauty exposes no contradiction. |
| “Multiplicity is a detail we add later.” | Multiplicity *is* the business rule: “1”, “0..5” and “*” are three completely different systems. |
Try it yourself
The client said: “every project has one manager, and a manager may run several projects”. Which diagram answers this?
Because the sentence describes what exists and how it connects, with specific numbers: Project → Manager with multiplicity 1, Manager → Projects with 0..*. That is a structural question, not a temporal one; activity and sequence describe time.
You cannot write a diagram's question in one line. What do you do?
The vagueness is not missing detail in the drawing, it is missing clarity in the question. Adding detail or beauty hides the vagueness rather than resolving it.
Quick review flashcards
Check your understanding
1. In one sentence: what is the difference between a diagram before the code and one after it?
The one before is a decision: it can change what you write, so correcting it costs an eraser. The one after is documentation: it describes what was written, so correcting it costs a rewrite. Both are useful, but the first is what saves money.
2. Explain in detail the bug we caught in the library example.
The librarian said “a member borrows a book”, so had we drawn the relationship between Member and Book, the question “is the book on loan?” would have no answer once the library holds three copies: one out and two on the shelf. The correct relationship is to Copy, because a copy is the thing that can be physically held and be with exactly one person. The general lesson: a noun in the client's speech is not always a class in the model.
3. (Spot the bug) A colleague drew a class diagram with an arrow labelled “then it sends an email”. What is wrong?
They put time into a structural diagram. A class diagram describes what exists and how it connects; it has no concept of “then”. Order belongs in a sequence or activity diagram. The tell-tale sign is always the same: words like “then”, “after” and “first” appearing on relationship lines.
4. The client says “the system must be fast”. Do you draw?
No. That is not a sentence a diagram answers: it contains no question about structure and none about order, only an unmeasured goal. The right step is to turn it into a number and a bar (“the member page loads in under 300 ms for 95% of requests”) and then measure. After measuring, drawing may earn a role, in part six specifically.
5. (Decision) Your team asks for “complete UML documentation” of an existing system that works fine. Your answer?
Ask: who is the reader, and what question can they not answer today? If the reader is a new engineer, what is needed is one or two diagrams: a component overview and a sequence diagram of the most important operation. “Complete documentation” is a large job that rots quickly, because the code changes and the drawing does not. Diagrams nobody asks a question of become silently wrong, which is worse than their absence.
Resources for this part
Sorted by kind: start with the official docs when you want the precise reference, or with an article or video when you want the explanation first.
Resources for this lesson
Grouped by type. Start with the official docs for precision, or an article or video for the explanation.
Articles2
Done with this lesson?
Sign in to save your progress.