Use cases and UML

Why it matters

User stories are great for planning work in small pieces, but they can hide the big picture: who interacts with the system at all, and how one goal flows step by step, including what happens when things go wrong. Use cases and UML diagrams give you that picture. Many systems analyst roles and certification exams expect you to read and draw them.

UML in one paragraph

The Unified Modeling Language (UML) is a standard set of diagram types maintained by the Object Management Group. It has more than a dozen diagram types, but analysts mostly use a few: use-case diagrams (who does what with the system), activity diagrams (the flow of a process or use case), and sometimes sequence and class diagrams. You do not need to master all of UML; you need to draw these few correctly enough that others read them the same way.

Use-case diagrams

A use-case diagram shows the scope of a system and the actors that use it.

• Actor (stick figure): a role outside the system that interacts with it. It can be a person (Member, Librarian) or another system (Email service).
• Use case (oval): a goal an actor achieves with the system, named verb-noun: "Book room", "Cancel booking".
• System boundary (rectangle): everything inside is the system you are building.
• Association (line): which actor takes part in which use case.
• include (dashed arrow labelled <<include>>): a use case that always runs as part of another. "Book room" includes "Check availability".
• extend (dashed arrow labelled <<extend>>): optional behaviour added under a condition. "Join waiting list" extends "Book room" when no room is free.

Riverside Library, in text form:

[ Room Booking System ]
  Member     --- (Check availability)
  Member     --- (Book room)        (Book room) ..<<include>>..> (Check availability)
  Member     --- (Cancel booking)
  Librarian  --- (Cancel booking)
  Librarian  --- (Manage rooms)
  (Book room) --- Email service     (sends the confirmation)
  (Join waiting list) ..<<extend>>..> (Book room)

The diagram is deliberately simple. Its job is to answer "what is in scope and who is involved?" on one page.

Use-case descriptions

The detail lives in a written use-case description. A practical template:

Use case:        UC-02 Book room
Primary actor:   Member
Preconditions:   Member is signed in
Trigger:         Member chooses a free slot
Main flow:
  1. Member selects a room, date, start and end time.
  2. System checks the slot is free and no longer than 2 hours.
  3. System shows a summary.
  4. Member confirms.
  5. System saves the booking and sends a confirmation email.
Alternate flows:
  2a. Slot overlaps an existing booking:
      System shows the conflicting booking and suggests the next free slot.
      Use case returns to step 1.
  2b. Booking longer than 2 hours:
      System explains the limit. Returns to step 1.
  5a. Email service unavailable:
      Booking is saved; the system retries the email later.
Postconditions:  Booking is stored and visible to librarians.

The alternate flows are where analysts earn their keep. Each one is a question somebody would otherwise answer differently on their own.

Activity diagrams

An activity diagram shows the flow of steps, decisions and parallel work. It looks like a flowchart with a few extras:

• Initial node (solid black dot) and final node (dot inside a circle).
• Action (rounded rectangle).
• Decision and merge (diamond) with guards in square brackets: [slot free], [slot taken].
• Fork and join (thick bar): actions that happen in parallel.
• Partitions (swimlanes) for who does each action.

The main flow of "Book room" as an activity diagram:

(start) -> Select room and time -> Check slot
   <decision>
     [slot taken]    -> Show conflict and next free slot -> back to Select room and time
     [too long]      -> Explain 2-hour limit            -> back to Select room and time
     [ok]            -> Show summary -> Confirm
   == fork ==
      Save booking            Send confirmation email
   == join ==
(end)

Activity diagrams and BPMN maps look similar. A common split: BPMN for business processes across an organisation, UML activity diagrams for the behaviour of one use case inside a system.

Use cases or user stories?

They are not rivals. Use cases suit work where the flow is long, rules are complex or several systems are involved, and where an organisation needs a stable description to test against or to hand to a supplier. User stories suit planning work in small slices on an agile team. Many analysts use both: a use-case diagram and a few use-case descriptions give the big picture and the tricky alternate flows, and each flow is then split into stories for the backlog. For example, UC-02 Book room might become one story for the main flow, one for the overlap rule (2a) and one for the email retry (5a), each with Given/When/Then criteria taken straight from the description.

Common mistakes

• Use cases that are steps, such as "Click Save" or "Enter date". A use case is a goal.
• Actors inside the boundary. Actors are always outside the system.
• Overusing include and extend until the diagram becomes a puzzle. Use them sparingly.
• Only the main flow. The alternate flows are the point.
• No guards on decisions, so readers cannot tell which way the flow goes.

Quick recap

• UML is a standard notation; analysts mainly use use-case and activity diagrams.
• Use-case diagrams show scope and actors; descriptions hold main and alternate flows.
• Activity diagrams show the flow, with guarded decisions, forks and swimlanes.
• Name use cases as goals, keep actors outside the boundary and write the alternate flows.

Try it

Open the Do tab and draw a use-case diagram and an activity diagram for your own system.