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
owns a valid policy
3. Insurance company assigns agent to
examine case
4. Agent verifies that all details are within
policy guidelines
6. Claimant exits system 5. Insurance company pays claimant
© B. Henderson-Sellers 1999-2003 NM5.14
7
Simplified use case template
System under discussion: <name>
Use case name: <name>
Version number: <#>
Summary: <one sentence description>
Actors: <name list>
Goal:
Pre-conditions:
Main Success Path: <#n> <description of step n>
Extensions/Alternatives/ <#n> <z> <description of extension z
Exceptions/Variations: relating to main use case path step n
Post-conditions
© 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