Projecte - Use case diagram

Modeling system behavior from the user's perspective

A use case is a structured description of a system’s behavior as it responds to requests from external actors, aiming to achieve a specific goal. It is used to define and validate functional requirements: a list of actions or event steps that define the interactions between a role and a system to achieve a goal.

An actor can be a human or another external system.

A use case diagram describes how a system works from the perspective of those actors.

A software system only delivers value if it does what users expect of it.

Restaurant example:

Introduction

The use case diagram is a technique for defining the functional requirements of a system — it represents every action/function the system can perform.

It must identify:

• The actors that participate
• The set of actions carried out by the system
• Each action must produce an observable result

It says what the system does, not how it does it.

Professional context

In a professional team, use cases sit between the business and the code:

• A business analyst or product owner drafts use cases together with the client during requirement-gathering meetings — they describe the system in language the client understands.
• A junior developer reads them at the start of a sprint to understand what to build before opening the editor; the use case becomes the contract between “what was requested” and “what was delivered”.
• A QA engineer uses the basic flow and the extensions as the input for acceptance tests — every extension is a test case waiting to be written.
• A tech lead uses the list of goals to estimate effort and split work across the team.

When you join a company, you will often find use cases hidden inside Jira / Linear tickets, Confluence pages, or README files. Recognising them and writing them well is a hireable skill — it shows you can communicate with non-technical stakeholders, not just write code.

Actors

A use case defines the interactions between external actors and the system under consideration to accomplish a goal. Actors must be able to make decisions, but need not be human — an actor might be a person, a company or organization, a computer program, or a computer system (hardware, software, or both).

Actors are always stakeholders, but not all stakeholders are actors. Some stakeholders never interact directly with the system, even though they have the right to care how it behaves — for example the owners of the system, a company’s board of directors, or regulatory bodies such as a tax authority. Those are stakeholders, not actors.

A single person may also be represented as different actors when playing different roles. User “Joe” could play the role of Customer when using an ATM to withdraw cash from his own account, and the role of Bank Teller when using the same system to restock the cash drawer on behalf of the bank.

Actors are often working on behalf of someone else. Writing “sales rep for the customer” or “clerk for the marketing department” makes it explicit that the user of the system is acting for someone else: the user interface and security clearances should be designed for the sales rep and the clerk, while the customer and marketing department are the roles that care about the results.

A stakeholder may play both an active and an inactive role. A Consumer is both a mass-market purchaser (not interacting with the system) and a User (an actor actively interacting with the product). A User in turn is both a normal operator (using the system for its intended purpose) and a functional beneficiary (a stakeholder who benefits from the use of the system). When user “Joe” withdraws cash from his account, he is operating the ATM and obtaining a result on his own behalf.

When looking for actors, consider:

• The stakeholders of the system
• The primary and supporting (secondary) actors of each use case
• The system under design (SuD) itself
• The internal actors — the components of the system under design

Example: hospital

Actors are the users who interact with the system and perform actions that affect the information system:

• Administrator
  • Register a patient in the system
  • Assign a doctor to a patient
• Doctor
  • Diagnose a patient’s illness
  • View diagnosis
• Patient
  • View diagnosis

In UML, use cases represent the interactions of those actors with the system. Here a Doctor is also a Patient (specialization), so they inherit the patient’s use cases:

Example: Minesweeper

Which actors do we identify in a Minesweeper game?

• The player

What are the system boundaries?

• They are drawn as a rectangle around the actions. They delimit the actions performed by actors within the scope of the system.

Which actions / use cases do we identify in Minesweeper?

• Start a game
• Uncover a cell (a cell cannot be re-covered once uncovered)
• Mark a cell
• Unmark a marked cell

Which relationships are established between actors and actions?

Easy in this case because there is only one actor, so only one kind of relationship is possible.

Use case specification

The use case model is more than the diagrams above — it must also include a use case specification.

A specification should provide:

• Name / title of the use case
• Description: how it begins and which event triggers it
• Actors: actors participating in the use case
• Preconditions: state the system must be in before executing
• Postconditions: state the system must be in after executing
• Main event flow: interaction between actors and the system under normal conditions
• Alternative event flows: interaction under exceptional conditions

Example

Main event flow

1. The client inserts the card into the ATM
2. The ATM asks for the PIN
3. The client enters the PIN
4. The ATM verifies the PIN
5. Once the PIN is validated, the ATM asks for the amount to withdraw
6. The client enters the amount to withdraw
7. The ATM checks whether the client has enough balance and whether the ATM has enough cash
8. If both conditions hold, the ATM updates the client’s account, logs the operation and returns the cash and the card

Alternative event flows

• 1, 3, 6 — The client cancels the operation. The ATM returns the card.
• If the PIN is incorrect and the client has not used the three attempts, the system goes back to step 2.
• If the PIN is incorrect and the client has used the three attempts, the ATM invalidates the card.
• 7 — If the client does not have enough available balance, the system shows an “insufficient funds” warning.

Cockburn-style example: Edit an article

The following uses a slightly modified version of the Cockburn template. Notice that there are no buttons, controls, forms, or other UI elements in the basic flow — only user goals, subgoals, and intentions are expressed at every step. This keeps the requirement specification clear and maximizes the flexibility of the design and implementation.

Use case: Edit an article Primary actor: Member (registered user) Scope: a Wiki system Level: user goal (sea level) Brief: The member edits any part (the entire article, or just a section) of an article they are reading. Preview and change comparison are allowed during editing.

Stakeholders

• (omitted)

Postconditions

• Minimal guarantees: (omitted)
• Success guarantees:
  • The article is saved and an updated view is shown.
  • An edit record for the article is created by the system, so watchers of the article can be informed of the update later.

Preconditions

• The article, with editing enabled, is presented to the member.

Triggers

• The member invokes an edit request (for the full article or for a single section).

Basic flow

1. The system provides a new editor area filled with the article’s relevant content and an informative edit summary. If the member is editing a single section, only that section’s content is shown, with the section title pre-filled in the edit summary.
2. The member modifies the article’s content until satisfied.
3. The member fills out the edit summary, indicates whether to watch the article, and submits the edit.
4. The system saves the article, logs the edit event, and finishes any necessary post-processing.
5. The system presents the updated view of the article to the member.

Extensions

• 2–3a — Show preview
  • The member selects Show preview, which submits the modified content.
  • The system reruns step 1, adding the rendered updated content for preview, and informs the member that the edits have not been saved yet. Then continues.
• 2–3b — Show changes
  • The member selects Show changes, which submits the modified content.
  • The system reruns step 1, adding a diff between the current edits and the most recently saved version of the article. Then continues.
• 2–3c — Cancel the edit
  • The member selects Cancel.
  • The system discards any changes the member has made, then goes to step 5.
• 4a — Timeout — (omitted)

Advantages

In his book Writing Effective Use Cases, Alistair Cockburn lists five reasons why use cases remain valuable, even in agile development:

1. The list of goal names is the shortest summary of what the system will offer — even shorter than user stories. It also provides a project-planning skeleton, used to build initial priorities, estimates, team allocation, and timing.
2. The main success scenario of each use case is an agreement with everyone involved on what the system will basically do and will not do. It provides the context for each specific line-item requirement (e.g. fine-grained user stories) — a context that is very hard to obtain anywhere else.
3. The extension conditions provide a framework for investigating all the little, niggling things that somehow consume 80% of development time and budget. They give stakeholders a look-ahead mechanism, so issues likely to take a long time to resolve can be surfaced and pulled forward in the schedule, with answers ready when the team gets around to working on them.
4. The extension scenario fragments answer many detailed, often tricky, often ignored business questions — “what are we supposed to do in this case?” It is a thinking and documentation framework that matches the if … then … else developers already write, except done at investigation time rather than programming time.
5. The full use case set shows the investigators have thought through every user’s needs, every goal they have with respect to the system, and every business variant involved.

Generalization / Specialization

As in class diagrams, use case diagrams allow generalization/specialization both for actors and for use cases.

All users can log in. Administrator and Client are kinds of User.

Include

Indicates that one use case always uses another as part of its execution.

Extend

Indicates that a use case may optionally use another, depending on the circumstances.

Exercises

Try modelling each system before looking at the solution. Sketch on paper first — only check the diagram once you have a draft.

Meeting / chat system

Model a video-meeting application like Google Meet, Microsoft Teams, or Zoom.

Identify three actors:

• A User — joins meetings and participates.
• A Manager — schedules meetings and decides who runs them.
• A Moderator — manages the meeting while it is in progress.

Draw the diagram and list the use cases for each actor.

Show solution

Alarm clock

Model a smartphone alarm clock app. Notice that this system has two actors: the human user and the system itself, because the system is the one that triggers the alarm at the configured time.

Use the include relationship to express that triggering an alarm reuses the Program alarm and Snooze alarm use cases.

Show solution

Online bookshop

Model a small online bookshop. Identify at least two actors (a Visitor who has not signed up and a Customer who has) and use generalization to share the search books use case. The Customer should be able to Place an order and Pay an order, while a Warehouse worker should be able to Fulfil an order.

Show solution

Both Visitor and Customer can search the catalogue (shared via generalization). Only Customer can buy.

Final project: model a system you use every day

Pick one of these systems (or one you use yourself — Spotify, Strava, Instagram, your school’s intranet…) and produce a complete use case model:

• A library lending system (members borrow and return books; librarians manage stock; admins manage members).
• A food-delivery app (customers order; couriers deliver; restaurants prepare orders).
• A medical-appointments system (patients book; doctors confirm; receptionists reschedule).

Deliverable (one Markdown / MDX file with):

1. A list of actors with a one-line description of each.
2. A use case diagram in PlantUML (```plantuml block) showing every actor, every use case, the system boundary (a rectangle), and at least one <<include>> and one <<extend>> relationship.
3. A detailed Cockburn-style specification for the most important use case — name, primary actor, scope, level, brief, preconditions, postconditions, basic flow (numbered), and at least two extensions.
4. A short professional reflection (2–3 sentences): which actor did you find hardest to identify, and why? Compare the result with a real product in the same domain — what did you miss?

Save it as pages/project/use-case-final.mdx, push to your repository, and share the URL with your teacher. You can include this file in your portfolio when you start applying for internships.

Tools and further reading

In industry, use cases are rarely drawn in pure Mermaid. You will probably encounter:

• draw.io / diagrams.net — free, browser-based, native UML use case shapes. Often the team’s default.
• Lucidchart — collaborative, used in larger teams.
• Visual Paradigm and Enterprise Architect — enterprise UML modelling tools, usually mandated by big consultancies.
• PlantUML — text-based, integrates with VS Code (the PlantUML extension) and lives well inside Git.

Read once and bookmark:

• The official UML 2.5 specification by the OMG (Object Management Group) — chapter 18 covers use cases.
• Alistair Cockburn’s Writing Effective Use Cases — the canonical reference; the templates in this page are based on it.
• The Wikipedia article on Use case — many of the definitions in this page are adapted from there.