Use Case Diagrams

Based on Chapter 6
Bennett, McRobb and Farmer
Object Oriented Systems Analysis
and Design Using UML
4th Edition, McGraw Hill, 2010
© 2010 Bennett, McRobb and Farmer 1
 In This Lecture You Will Learn:
•  The purpose of use case diagrams
•  The notation of use case diagrams
•  How to draw use case diagrams
•  How to write use case descriptions
•  How prototyping can be used with use
case modelling

© 2010 Bennett, McRobb and Farmer 2

 Drawing Use Case Diagrams
•  Purpose
–  document the functionality of the system from
the users’ perspective
–  document the scope of the system
–  document the interaction between the users
and the system using supporting use case
descriptions (behaviour specifications)

© 2010 Bennett, McRobb and Farmer 3

Notation of Use Case Diagrams

Communication Use case

association

Change a client
contact

Staff Contact

Actor System or subsystem boundary

(Subject)

© 2010 Bennett, McRobb and Farmer 4

Notation of Use Case Diagrams
•  Actors
–  drawn as stick people with a name
–  the roles that people, other systems or
devices take when communicating with a
particular use case or use cases
–  not the same as job titles or people
•  people with one job title may play the roles of
several actors
•  one actor may represent several job titles

© 2010 Bennett, McRobb and Farmer 5

Notation of Use Case Diagrams
•  Use cases
–  drawn as ellipses with a name in or below
each ellipse
–  describe a sequence of actions that the
system performs to achieve an observable
result of value to an actor
–  the name is usually an active verb and a noun
phrase

© 2010 Bennett, McRobb and Farmer 6

Notation of Use Case Diagrams
•  Communication associations
–  line drawn between an actor and a use case
–  represent communication link between an
instance of the use case and an instance of
the actor

© 2010 Bennett, McRobb and Farmer 7

Notation of Use Case Diagrams
•  Subjects (subsystems)
–  drawn as a rectangle around a group of use
cases that belong to the same subject
–  in a CASE tool, use cases for different
subjects are usually placed in separate use
case diagrams

© 2010 Bennett, McRobb and Farmer 8

Notation of Use Case Diagrams
•  Dependencies
–  Extend and Include relationships between use
cases
–  shown as stereotyped dependencies
–  stereotypes are written as text strings in
guillemets: «extend» and «include»

© 2010 Bennett, McRobb and Farmer 9

Notation of Use Case Diagrams
•  Extend relationship
–  used when one use case provides additional
functionality that may be required in another use
case
–  there may be multiple ways of extending a use
case, which represent variations in the way that
actors interact with the use case
–  extension points show when the extension occurs
–  a condition can be placed in a note joined to the
dependency arrow (Note that it is not put in square
brackets, unlike conditions in other diagrams.)

© 2010 Bennett, McRobb and Farmer 10

 Extend relationship

Check campaign
budget
extension points
Summary print

«extend» Condition {print

option selected}
extension point:
Campaign
Summary print
Manager
Print campaign
summary

© 2010 Bennett, McRobb and Farmer 11

Notation of Use Case Diagrams
•  Include relationship
–  used when one use case always includes the
functionality of another use case
–  a use case may include more than one other
–  can be used to separate out a sequence of
behaviour that is used in many use cases
–  should not be used to create a hierarchical
functional decomposition of the system

© 2010 Bennett, McRobb and Farmer 12

 Include Relationship

Assign staff to «include»

work on a Find campaign
campaign

Campaign
Manager

© 2010 Bennett, McRobb and Farmer 13

Notation of Use Case Diagrams
•  Generalization
–  shows that one use case provides all the
functionality of the more general use case and
some additional functionality
–  shows that one actor can participate in all the
associations with use cases that the more
general actor can plus some additional use
cases

© 2010 Bennett, McRobb and Farmer 14

 Record
completion
of an advert

Staff
Contact Change a
client
contact

Assign
individual staff
to work on a
campaign Assign staff to
work on a
Campaign campaign
Manager Assign team of
staff to work on
a campaign

© 2010 Bennett, McRobb and Farmer 15

 Use Case Descriptions
•  Can be a simple paragraph
Assign staff to work on a campaign
–  The campaign manager wishes to record
which staff are working on a particular
campaign. This information is used to
validate timesheets and to calculate staff
year-end bonuses.

© 2010 Bennett, McRobb and Farmer 16

 Use Case Descriptions
•  Can be a step-by-step breakdown of
interaction between actor and system

Assign staff to work on a campaign

Actor Action System Response
1. The actor enters the client name. 2. Lists all campaigns for that
client.
3. Selects the relevant campaign. 4. Displays a list of all staff
members not already allocated
to this campaign.
5. Highlights the staff members 6.Presents a message confirming
to be assigned to this campaign. that staff have been allocated.

Alternative Courses
Steps 1–3. The actor knows the campaign name and enters it directly.

© 2010 Bennett, McRobb and Farmer 17

 Use Case Descriptions
•  Many projects use templates
–  name of use case
–  pre-conditions
–  post-conditions
–  purpose
–  description
–  alternative courses
–  errors

© 2010 Bennett, McRobb and Farmer 18

 Behaviour Specifications
•  Rather than (or as well as) using text, a
use case can be linked to another diagram
that specifies its behaviour
•  Typically a Communication Diagram, a
Sequence Diagram, a State Machine or
more than one of these

© 2010 Bennett, McRobb and Farmer 19

 Drawing Use Case Diagrams
•  Identify the actors and the use cases
•  Prioritize the use cases
•  Develop each use case, starting with the
priority ones, writing a description for each
•  Add structure to the use case model:
generalization, include and extend
relationships and subsystems

© 2010 Bennett, McRobb and Farmer 20

 Prototyping
•  Use case modelling can be supported with
prototyping
•  Prototypes can be used to help elicit
requirements
•  Prototypes can be used to test out system
architectures based on the use cases in
order to meet the non-functional
requirements

© 2010 Bennett, McRobb and Farmer 21

 Prototyping
•  For user interface prototypes,
storyboarding can be used with hand-
drawn designs

© 2010 Bennett, McRobb and Farmer 22

 Prototyping
•  User interface prototypes can be
implemented using languages other than
the one that the system will be developed
in
Campaign Selection Campaign Selection Campaign Selection

Holborn Motors Holborn Motors Holborn Motors

Client: Client: Client:
Lynch Properties Lynch Properties Lynch Properties
Yellow Partridge Yellow Partridge
Yellow Partridge Yellow Partridge
Yellow Partridge
Zeta Systems Zeta Systems Zeta Systems

Spring Jewellery Campaign 2003 Spring Jewellery Campaign 2003

Campaign: Campaign: Spring Jewellery Campaign 2004 Campaign: Spring Jewellery Campaign 2004
Spring Jewellery Campaign 2005 Spring
Spring Jewellery
Jewellery Campaign
Campaign 2005
2002
Summer Collection 2004 Summer Collection 2004

OK Quit OK Quit OK Quit

Dialogue initialized. User selects Client. Campaigns User selects Campaign.

listed.

© 2010 Bennett, McRobb and Farmer 23

 Summary
In this lecture you have learned about:
•  The purpose of use case diagrams
•  The notation of use case diagrams
•  How to draw use case diagrams
•  How to write use case descriptions
•  How prototyping can be used with use
case modelling

© 2010 Bennett, McRobb and Farmer 24

 References
•  Jacobson et al. (1992)
•  Rosenberg and Scott (1999)
•  Cockburn (2000)
(For full bibliographic details, see Bennett,
McRobb and Farmer)

© 2010 Bennett, McRobb and Farmer 25