Module M5

UML Use Case Diagrams

© B. Henderson-Sellers 1999-2003 NM5.1

Use case diagrams

• Graph of actors plus set of use cases
enclosed by system boundary. Associations
between actors and use cases plus
generalization between use cases.

© B. Henderson-Sellers 1999-2003 NM5.2

1
 Use case diagram
• Graph of actors plus set of use cases enclosed by system boundary.
Associations between actors and use cases plus generalization
between use cases.

Example use case System name Employee1

diagram

User

place
order

Employee2

© B. Henderson-Sellers 1999-2003 NM5.3

Use case
Namespace
metamodel
1
Interface
*
*
Attribute
* Include
*
*
Extend
Operation * UseCase

*
* Extension point
UseCase *
Instance
AssociationEnd Association
2..*

adapted from OMG, 1999

© B. Henderson-Sellers 1999-2003 NM5.4

2
 Use case notation

Actor

Use case name

© B. Henderson-Sellers 1999-2003 NM5.5

Two relationships between use

cases
1. Include - base use case explicitly
incorporates target use case
2. Extend - extending use case
augments the structure and behaviour
or base use case
Note. Notation used is a stereotyped
Dependency although these are
Relationships and NOT Dependencies
3. Generalization
© B. Henderson-Sellers 1999-2003 NM5.6

3
 Use case relationships
Generalization between actors or
between use cases
«extend» between use cases
Extend

«include» between use cases

Include
between actors and use
cases only
Association

(all inherit from Relationship metatype)

© B. Henderson-Sellers 1999-2003 NM5.7

Extending use cases

Buy Train Ticket

«extend»

Return Folded Bill

© B. Henderson-Sellers 1999-2003 NM5.8

4
 Including use cases

Print Receipt

«include» «include»

Buy Plane Ticket

Make Theatre Booking

© B. Henderson-Sellers 1999-2003 NM5.9

Generalizing use cases

Perform
book search

Perform book
search by author Perform book
search by ISBN

Perform book
search by title

© B. Henderson-Sellers 1999-2003 NM5.10

5
 Use Case Naming
• Use case names should be strong verbs e.g.
Withdraw funds; Deliver goods
• Avoid weak verbs such as “do …”, “perform
…”
• Use terms from the domain being modelled

© B. Henderson-Sellers 1999-2003 NM5.11

BUT
• Use case diagrams are NOT the same as use
cases.
• A use case is
a) more useful and
b) textual

© B. Henderson-Sellers 1999-2003 NM5.12

6
 System under discussion: the insurance company
Primary Actor: the claimant
Goal: gets paid for car
accident
Use Case
1. Claimant submits claim with substantiating data
2. Insurance company verifies claimant owns a
valid policy
3. Insurance company assigns agent to examine case
4. Agent verifies that all details are within policy
guidelines
5. Insurance company pays claimant
© B. Henderson-Sellers 1999-2003 NM5.13

Two column style for use case

Claimant Insurance
1. Claimant submits claim with company/agent
substantiating data

2. Insurance company verifies claimant

6. Claimant exits system
owns a valid policy
3. Insurance company assigns agent to
examine case
4. Agent verifies that all details are within
policy guidelines
5. Insurance company pays claimant

© B. Henderson-Sellers 1999-2003 NM5.14

7
Simplified use case template

System under discussion: <name>

Use case name:
Version number:
Summary:
Actors:
Goal:
Pre-conditions:
Main Success Path:
Extensions/Alternatives/
Exceptions/Variations:
Post-conditions
<name>
<#>
<one sentence description>
<name list>
<#n> <description of step n>
<#n> <z> <description of extension z
relating to main use case path step n

© B. Henderson-Sellers 1999-2003 NM5.15

Constructing Use case diagrams

• OPEN Technique:
– Scenario development (Use case modelling)

Remember differences between use cases and

use case diagrams

[Take care]

© B. Henderson-Sellers 1999-2003 NM5.16

8
 • Look for a) actor and b) functionality of value
(an observable result) to actor
• Actors are roles played, not people. There
may be non-human actors too.
• Use case name - atomic behaviour
• Useful for modelling context of a system (but
they do assume a system exists)

© B. Henderson-Sellers 1999-2003 NM5.17

e.g. Library system

Browser
browse

borrow
book
Borrower
extend
loan

borrow Librarian
journal

update
catalogue

© B. Henderson-Sellers 1999-2003 NM5.18

9
 • Decide on system boundary - take care
• Don’t functionally decompose
• Do in parallel to architecture. [Use-case-driven
processes can lead to fragmented
architectures]

© B. Henderson-Sellers 1999-2003 NM5.19

An
identified Close a deal
problem
Sales Clerk

Close a big
deal
Senior Agent
While a senior agent is a special kind of sales clerk and closing a big
deal is an appropriate subtype of closing a deal, the actor-use case links
now permit a sales clerk to close a big deal by polymorphic substitution of
Close a deal by Close a big deal. Not what was intended.
© Cockburn, 2000 1999-2003
© B. Henderson-Sellers NM5.20

10
 Close a deal

Sales Clerk Close a

small deal

Close a big
deal
Senior Agent

© Cockburn, 2000 1999-2003

© B. Henderson-Sellers NM5.21

• Don’t mix up requirements with candidate

designs
• Not a good way to find classes (create class
diagram and use case diagram in parallel)
• Spend time on use cases (text) rather than
use case diagrams

© B. Henderson-Sellers 1999-2003 NM5.22

11
 • Use case describes flow of events.
Concentrate on main flow.

• Use accepted/standard template e.g. from

Cockburn

© B. Henderson-Sellers 1999-2003 NM5.23

Finally, note that

A use case diagram is realized by a sequence diagram

© B. Henderson-Sellers 1999-2003 NM5.24

12
 Summary
• A use case represents a piece of functionality
• UML only supports use case diagrams i.e.
NOT use cases
• Use cases are textual and much more useful
than use case diagrams
• A use case can be realized by a sequence
diagram

© B. Henderson-Sellers 1999-2003 NM5.25

13