Read the requirements, then build each diagram, step by step, with every part traceable to where it came from.
Move with the arrow keys or the buttons below. Slides with a builder have their own Next / Play controls.
UML is a notation, not a method: it fixes the shapes; you decide which diagram to draw and when. In analysis, once requirements are elicited, two behavioural views are drawn first, in order, and each is read out of the one before it.
14 diagram types, 9 standard, in two groups:
History in one line: UML was unified at Rational by Booch, Rumbaugh and Jacobson and standardised by the OMG in 1997.
The first model in analysis: who uses the system and what they can do. We build it from the requirements, then detail and refine it.
<<include>>, <<extend>>, generalisation, extension pointsRead a narrative and draw a correct, fully-refined use case diagram, then write the description and scenarios behind it.
A use case diagram is usually the first model in analysis. On a single page it shows the system's actors and the tasks they perform with it, so stakeholders can confirm scope before any design.
Four symbols. Actors sit outside the boundary; use cases (verb-named ellipses) sit inside; a plain line is an association, with no arrowhead because participation is undirected.
A plain association has no arrowhead. A verb-phrase ellipse is a use case; a noun is a class, not a use case.
Read the requirements and ask four questions; each answer is an actor.
A role (usually human) that starts a use case for its own goal: Guest, Librarian, Doctor.
An external system the system depends on and calls out to: payment provider, email or SMS service, verification service.
Primary actor starts a use case for its own goal; secondary actor is the external system the system calls out to.
An actor is a role, not a person; the same person can be two actors. Name each actor with a noun. Not every use case is started by a person: time or another system can trigger one (a temporal / clock actor, e.g. a nightly report or a scheduled message).
Two complementary techniques, then a quick check.
Write the system's processes as scenarios; each interaction with the system is a candidate use case.
For each actor, ask what they need from the system, and what else they take part in for someone else's benefit.
Noun-verb analysis ties it to the text: in the requirements, nouns and roles become actors, verbs become use cases, and the noun-verb pairings become associations. Name every use case with a verb, "Borrow book", not "Book borrowing".
Name every use case with a verb. Nouns become actors; verbs become use cases.
Built one element at a time, with each actor and use case traced back to the narrative and the user requirement it came from. Use the builder's Next / Play.
| Relationship | Meaning | Arrow (dashed unless noted) |
|---|---|---|
<<include>> | The base use case always performs the included sub-task. Factor it out to avoid repetition. | base → included |
<<extend>> | An optional / conditional behaviour that fires only when a guard at an extension point holds. | extension → base |
| generalisation | One use case (or actor) is a more specific kind of another and inherits it. | solid line, hollow triangle, specific → general |
<<include>> points base → included (always performed); <<extend>> points extension → base (conditional). They go opposite ways. The tail sits on the case that "knows about" the other.
Actor generalisation, use-case generalisation, composite (multi-level) use cases, and extension points, each on a small example with a note on when to use it.
When one ellipse really stands for several tasks, draw it as a composite use case (the small grid marker) at the top level and expand it in a lower-level diagram. A deep system can add a 2nd level under a 1st-level composite, exactly how Adel decomposes Manage patient registration.
The grid marker says "described by its own diagram". Use it to keep the top level readable; do not hide weak analysis behind it, every sub-use-case must still be a real, verb-named task.
The ellipse is the index; the description is the contract the team builds against, the full template: pre-conditions, trigger, the main flow, and the alternative / exception flows. Worked example for a Library use case:
| Title | Borrow copy of a book |
| Actors | BookBorrower (primary), Librarian (primary) |
| Pre-conditions | 1. Borrower is a member. 2. Borrower is below the loan limit. |
| Trigger | Borrower asks the Librarian to borrow a copy. |
| Main flow | 1. System checks the allowance. 2. Record the loan and compute the due date. 3. Issue the copy (status → on-loan). |
| Alternative / exception | 1a. Limit reached: the loan is refused and the flow ends. 3a. Barcode unreadable: the Librarian records the problem; no copy is issued. |
| Post-conditions | On success: loan recorded, copy on-loan, loan count incremented. On failure: nothing changes. |
The main flow and each alternative / exception are the same paths you write as scenarios (next slide) and draw as the decision branches and loops of the activity diagram. One description, three consistent views.
A scenario is one specific path through a use case, with no branching. Each non-trivial use case gets at least three:
A scenario has no branching: "if X else Y" is two scenarios, not one.
Where the use case diagram says what, the activity diagram says how it flows: the order of work, the decisions, the parallel steps, and who does each. We learn the notation, then build one from a use case.
Take one use case and draw a well-formed flow: decisions closed by merges, forks by joins, every path reaching a final node.
An activity diagram unpacks how one use case flows: the order of work, the decisions that branch it, the steps that run in parallel, and which actor performs each. It answers: what happens, in what order, and who does it.
A small, fixed vocabulary. Two pairs are easy to confuse: a decision picks one branch while a fork runs all; a merge re-joins a choice while a join waits for parallel flows.
Decision = exactly one branch runs (a choice). Fork = all branches run (concurrency). This is the most common confusion.
Columns that assign each action to an actor or system. An arrow that crosses a lane boundary is a hand-off of responsibility, often where bugs hide.
Repeat (do the next item), retry (a check failed, correct and try again), and guarded exit / timeout (leave after a limit). Each is a decision that points back into the flow.
Every decision is closed by a matching merge and every fork by a matching join; an opening diamond or bar with no closing one is the most common ill-formed-flow error. And every path must reach a final node, the flow must not get "stuck".
Fork and join for steps that run at once; decision and merge for a choice. The pairing is the point: a fork is always closed by a join, and a decision by a merge. Step through the builder and watch each pair open and then close.
Now apply all of it. The Book room use case, unpacked into a flow: each step of its description lights up as the matching action appears; the description's alternative flows become the diagram's decision branches and loops, and swimlanes assign each step to the Guest, the system, or the external provider.
An activity diagram is not limited to one use case. At the business-process level it composes several use cases into a single flow. Here Book a journey runs three reservations in parallel, each its own use case, with a retry loop on the car.
Same notation, wider scope. Pick one granularity per diagram: a single use case, or a whole process, not both. The process view often drops swimlanes, the focus is order and concurrency.
The same method on a fresh scenario, both diagrams. This one also shows actor generalisation (a Senior Agent is a kind of Support Agent).
<<include>>; optional ones as <<extend>>; specialise with generalisation.Both come straight from the requirements: that traceability is the point of drawing them.