1 Nitaxe

Uml Use Case Diagram Case Study

UML Use Case Diagram Examples

Here we provide some examples of UMLuse case diagrams.

Examples of business use case diagrams

  Airport check-in and security screening business model

Purpose: An example of a business use case diagram for airport check-in and security screening.

Summary: Business use cases are Individual Check-In, Group Check-In (for groups of tourists), Security Screening, etc. - representing business functions or processes taking place in an airport and serving needs of passengers.

  Restaurant business model

Purpose: Two alternative examples of business use case diagram for a Restaurant - external and internal business views of a restaurant.

Summary: Several business actors having some needs and goals as related to the restaurant and business use cases expressing expectations of the actors from the business.

Examples of system use case diagrams

  Ticket vending machine

Purpose: Show that ticket vending machine allows commuters to buy tickets.

Summary: The ultimate goal of a Commuter in relation to our ticket vending machine is to buy a ticket. We have a single Purchase Ticket use case, as this vending machine is not providing any other services. Ticket vending machine is a subject of the example use case diagram. Commuter and Bank are our actors, both participating in the Purchase Ticket use case.

  Bank ATM UML use case diagrams examples

Purpose: Describe use cases that an automated teller machine (ATM) or the automatic banking machine (ABM) provides to the bank customers.

Summary: Customer uses a bank ATM to check balances of his/her bank accounts, deposit funds, withdraw cash and/or transfer funds (use cases). ATM Technician provides maintenance and repairs to the ATM.

  Point of sales (POS) terminal

Purpose: An example of use cases for a Point of Sale (POS) Terminal or Checkout in a supermarket.

Summary: Checkout use case involves Customer, Clerk and Credit Payment Service actors and includes scanning items, calculating total and taxes, and payment use cases. This is an example of a large and complex use case split into several smaller use cases.

  e-Library online public access catalog (OPAC)

Purpose: List top level use cases for e-Library online public access catalog.

Summary: Patrons of a library can search library catalog online to locate various resources - books, periodicals, audio and visual materials, or other items under control of the library. Patrons may reserve or renew item, provide feedback, and manage their account.

  Online shopping use case diagrams

Purpose: Provide top level use cases for a web customer making purchases online.

Summary: Web customer actor uses some web site to make purchases online. Top level use cases are View Items, Make Purchase and Client Register.

  Credit card processing system

Purpose: Define major use cases for a credit card processing system (credit card payment gateway).

Summary: The merchant submits a credit card transaction request to the credit card payment gateway on behalf of a customer. Bank which issued customer's credit card is actor which could approve or reject the transaction. If transaction is approved, funds will be transferred to merchant's bank account.

  Website administration

Purpose: Website management or administration UML use case diagrams example.

Summary: Website Administrator actor could manage user groups, users, user sessions, and logs. Help Desk staff uses a subset of functions available to the Website Administrator.

  Hospital Management

Purpose: Describe major services (functionality) provided by a hospital's reception.

Summary: This UML use case diagram example shows actor and use cases for a hospital's reception. Hospital Reception subsystem or module supports some of the many job duties of a hospital receptionist. Receptionist schedules patient's appointment and admission to the hospital, collects information from the patient by phone and/or upon patient's arrival to the hospital.

For the patient that will stay in the hospital ("inpatient") she or he should have a bed allotted in a ward. Receptionists might also receive patient's payments, record them in a database and provide receipts, file insurance claims and medical reports.

  Radiology diagnostic reporting UML use case diagram example

Purpose: Radiology diagnostic reporting UML use case diagram example for Simple Image and Numeric Report (SINR) IHE Radiology Integration Profile.

Summary: In the initial stage of diagnostic reporting, a reading physician records a diagnosis by generating a draft DICOM Structured Report (SR) object. Report Creator actor transmits that DICOM SR object to the Report Manager. External Report Repository Access actor is a gateway to obtain other enterprise department reports, such as Laboratory and Pathology, from within the Imaging department.

  Software Protection and Licensing

Purpose: Use case diagram example shows some simplified view of software licensing use cases supported by Sentinel EMS Application.

Summary: Sentinel License Development Kit (Sentinel LDK) is a Software Digital Rights Management (DRM) solution by SafeNet Inc. that delivers strong copy protection, protection for Intellectual Property (IP), and secure and flexible licensing. The Sentinel EMS application handles three major workflows - license planning, order processing and production, and activation of trial software.

Marking System -- Inception Phase

We will examine a marking system as a case study for part of the UP model. A project description is:

Faculty need a system to record grades and generate a grade report. A student's mark is composed of weighted work items. The weight is the percentage that the work item contributes to the final grade. Work items include assignments, midterms, projects, and finals. Some of the work items can be joint efforts. The system should allow mark entry by the faculty member and any assigned markers. The students should be able to access their grades. The Banner student registration system provide the class list.

Inception Phase -- Risk Analysis

Any project should consider the risk factors that can affect the project. A risk that has been identified can be addressed.

Some risk factors associated with any software product development are:

  • competition,
  • choice of technologies,
  • market trends,
  • time to market.

This factors will not play a role in the marking system project in this course. However the following should be considered:

  • project member's experience with the problem,
  • project member's experience with the implementation technologies,
  • resources available.

Inception Phase Deliverable

  • Project Description
  • Risks

After writing the project description and performing risk analysis, we are in the middle of the inception phase. We still need to refine what is inside the system and what is outside the system. Also, the system's main use cases did to be considered.

The system includes:

  • software, hardware, user roles
  • tasks needed to build the system: planning, scheduling, documentation

Identifying System Boundaries

  • users are not in the system (i.e., they are outside)
  • constructed software is inside

The boundary is defined by identifying the actors and the use cases.

  • actors: entities that interact with the system
  • use cases: the functions of the system


Actors are anything that interacts with the system. Actors have goals that the system satisfies.

  • people (students, faculty, markers)
  • other software (banner student registration system)
  • hardware devices (point of sales terminals)
  • data stores (databases)
  • networks (wifi, bluetooth, ethernet, 3g cell networks)
  • time (passage of time tells the system to do something)

Actors are external to the system.

An actor is a role that the external entity plays and not the entity.

Bob can be a customer and an employee of a company.

A student can take a class and mark for another class.

Of course, more than one entity can fill a role. In object-oriented programming terms, an entity is an object and their role is the class the object belongs.

Larman informally defines an actor as an something with behaviour, such as a person (their role), computer system, or organization.

Identifying Actors

Actors can be identified by the following questions.

  • Who uses the system?
  • Who installs the system?
  • Who starts the system?
  • Who maintains the system?
  • Who shuts down the system?
  • Who uses the system?
  • Who handles security for the system?
  • What other systems use the system?
  • Who gets information from the system?
  • Who provides information to the system?
  • Does anything happen based on time?

Naming Actors

  • noun or adjectival noun phase
  • reflect roles (instructor vs me)
  • specific, meaningful

UML - Unified Modeling Language - Actors

UML is the standard notation used to document the deliverables in a software development project. We will use the UML standard (the syntax) in this course. Actors are drawn as stick people with a label defining the role.

An actor is something with behaviour, such as a person (their role), computer system, or organization.

UML - Unified Modeling Language - Use cases

Preliminary use cases are identified during the inception phase.

"A use case is a behavior of the system that produces a measurable result of value to an actor." Informally, use cases are stories of using a system to meet gaols.

"Use cases describe the things actors want the system to do." For example,

  • enter grades,
  • order an item from a company,
  • search for an item,
  • add an album description to the stored collection.

Many use case arise from providing a feature that allows an actor to achieve a goal.

Questions to identify use cases

  • What functions will the actor want from the system?
  • Which actors create, modify the information?
  • Does the system notify an actor about internal changes to the system?
  • Which external events affect the system, which actor informs the system?

Common use cases to consider

  • startup
  • shutdown
  • diagnostics
  • installation

Naming use cases

  • use user terminology
  • verb-noun form (record-grades)
  • may contain adjectives and adverbs
  • reflect objective of main actor
  • not tied to implementation
  • use strong verbs that are meaningful and specific
  • avoid weak verbs (process, input, output, ... )

Good examples:

  • bill customer
  • edit student information
  • generate grade report

Bad examples:

  • output data
  • process information
  • validate input

Actors in Grade Report System

teaches class
marks work items
takes course
Banner Student Registration System
data base of registered students

The actors can be examined using the sample use case questions to identify any use cases.

Are there any problems with the above definitions for the actors?

Outline of use cases for grade report system


  • record marks
  • create marking scheme
  • modify marks
  • modify marking scheme
  • generate grade report
  • review marks


  • record marks
  • modify marks
  • create student information
  • modify student information


  • review marks
  • request mark change


Use cases in UML

Use cases are drawn as ovals with the name of the use case inside the oval.

The arc (link) indicates that the instructor (actor) interacts with the record mark use case. A system use case diagram includes all of the actors and use cases.

Reviewing use cases and actors

  • Is each use case used by at least one actor?
  • Is each actor used in at least one use case?
  • Has the verb-noun naming convention been used?
  • Can any of the use cases be combined?
  • Can any of the actors be combined?
  • Can any of the use cases or actors be dropped?
  • Does a use case attempt to do too much?

    • How long does the use case take?
    • How many actors are involved?

Grade Report Use Case Diagram Review

Upon review of the modify marks and record marks, we decide that these use cases should be combined. The same holds true for modifying and creating marking schemes?

What about the student info use cases, what are they not combined? Are there any other use cases that can be combined?

What about the startup, shutdown, and installation use cases?

If the use case diagram has too many use cases and actors, we should divide the uses cases into functionally separate groups.

Project scope

  • What gets done?
  • When do the development tasks occur?
  • What are the priorities of the requirements:
    • must have
    • should have
    • could have
    • would be nice
  • What are the resource needed?

The identified tasks should be divided amongst the developers.

Inception Phase Deliverables

  • Project description
  • Risk analysis
  • Use case diagram
  • Description of actors and use cases

Inception Phase - Elaboration Phase

At the end of the inception phase, we have either decided that the project is viable and can continue to the elaboration phase or we have cancelled the project. During the elaboration phase we will:

  • expand each use case,
  • refine the architecture
  • develope a construction plan
  • optionally: prototype high risk tasks

Leave a Comment


Your email address will not be published. Required fields are marked *