Transcript CIS224 Software Projects: Software Engineering and

Lecture 3
Use Case Models
(Based on Fowler (2004, Chapter 9) and
Stevens and Pooley (2006, Chapters 7 & 8))
David Meredith
[email protected]
www.titanmusic.com/teaching/cis224-2007-8.html
CIS224
Software Projects: Software Engineering
and Research Methods
1
Introduction
• A use case model describes a system from the
user’s point of view
– ‘User’ can be a person, software system or hardware
device
• Used to help with
– Requirements capture
– Planning iterations in the development process
– Validating the design of a system
• Introduced by Ivar Jacobson as a development
of scenarios
• Scenarios still exist in UML
2
Use case diagrams
• Intuitive and easy to understand so can
be discussed with customers
Borrow copy of book
• An individual use case, represented by a
named oval, is a class of task that is
supported by the system
Browse catalogue
Reserve book
Browser
• Each use case also described in detail
using text.
Extend loan
BookBorrower
Return copy of book
Add new item
Borrow journal
Dispose of old item
Return journal
Get journals bound
• Use case diagram is a summary of the
detailed information given in the use case
descriptions
• Actor represented by stick figure
JournalBorrower
Librarian
• Actor connected to use case by a line if
the actor is involved in carrying out the use
case
• System represented by box around use
3
cases
Use cases and class associations
Borrow copy
of book
is a copy of
Copy
Book
BookBorrower
•
•
•
Class Copy represents the set of all possible Copy objects
Class Book represents the set of all possible Book objects
Association “is a copy of” means that every instance of class Copy is a copy
of an instance of class Book
• BookBorrower actor represents the role of being a book borrower – in
principle, anyone or anything could be fulfilling this role in any particular
situation
• Borrow copy of book use case represents all possible scenarios with
the goal of borrowing a book – regardless of whether a book is successfully
borrowed or not
• A scenario is an instance of a use case just as an object is an instance of a
class
• Line between BookBorrower actor and Borrow copy of book use
case represents a communicates relation and means that it is possible for
someone in the role of a BookBorrower to be involved in carrying out the
use case Borrow copy of book
4
– It does NOT mean that all BookBorrowers are always borrowing books
Actors
• An actor is a representation of a user in a particular role from the
point of view of the system
• Beneficiary of a use case is an actor that benefits from the use case
being carried out
– GiftRecipient is beneficiary in Buy gift use case
• Primary actor of a use case is the actor whose goal is achieved by
carrying out the use case
– GiftBuyer is primary actor in Buy gift use case
– Other actors involved in the use case are secondary actors
• A given person might play different roles on different occasions and
therefore be represented by different actors in the use case model
• An actor usually only represents a role carried out by an external
non-human device or system when it is autonomous
– If the device or system is being operated by a human, then it is usually
the role the human is playing that should be represented by the actor
• Credit card authorization system providing services to a till system might be
represented by an actor
• Bar code scanner probably not represented by an actor since operated by
human
5
Use cases
• A scenario is an instance of a use case just as an object
is an instance of a class
– Examples of scenarios in Borrow copy of book use case
• BookBorrower presents a book and is permitted to borrow it. The
system is updated accordingly.
• BookBorrower presents a book but is refused permission to borrow
it because he/she already has the maximum number of books on
loan
• Use case usually named after the main success scenario
which is the normal successful scenario in the use case
– Other scenarios in a use case are called extensions
– Extensions may be either successful or unsuccessful
• All scenarios in a use case have the same goal
• Usually use text in third person active voice to describe
the details of a use case and its extensions
6
Using use cases for requirements
capture
•
To capture requirements using use cases we
1. Identify the users and the systems that will interact
with the system to be built
2. Identify the actors (i.e., the different roles taken by
the users when interacting with the system)
3. For each actor, find out
1. The use cases in which the actor is the primary actor or a
beneficiary
2. The other use cases in which the actor is involved
4. Find out how important each use case is to the
users
7
Using use cases for planning
•
Before producing an overall plan and cost estimation
we must have an initial list of all the use cases for the
system and
1.
2.
3.
4.
•
Note that this is so that we can carry out the
“inception” phase of the project where we produce a
high-level predictive plan, business case and feasibility
assessment
–
•
A good understanding of what each use case means
An understanding of who wants each use case and how
important it is
Knowledge of which use cases are the most risky
An idea of how long each use case will take to implement
We should not make the plan too rigid because it is bound to
change when we start doing iterative development and
presenting users with prototype systems to evaluate
When we have a “complete” initial list of use cases and
an understanding of how risky and important each is,
we can then plan which iterations will provide
8
realizations of which use cases
Choosing which use cases to
realize in the early iterations
• Should aim to realize those use cases in the
early iterations that the users have indicated are
most important
• Gibbs (1994): 25% of projects cancelled
– Need to give high priority to realising use cases that
are considered important by those who are in a
position to cancel the project!
– But remember that system must ultimately satisfy the
users’ needs
• Initial use case analysis can help with
determining whether or not the project is worth
doing at all
9
Using use cases in validation
• Validate a design by taking each use case in
turn and checking if the design supports the use
case (“walking” the use case)
• Should be a system test for each significantly
different scenario family within each case
• In Borrow copy of book, should be system
test for
– BookBorrower being permitted to borrow the book
– BookBorrower being refused permission to borrow
book because already has too many books out
10
Problems with use cases
• Danger of building system which is not objectoriented (i.e., component-based)
– Too much emphasis on use cases can cause
developers to make bad architectural decisions in the
rush to realize quickly the important use cases
• Danger of confusing design with requirements
– Users describe procedures for achieving their goals
– Developers must consider other procedures and
focus in use case analysis on identifying the users’
goals
11
Dependencies between use cases
• Two main ways in which a use case may depend
on another use case:
– A simpler use case may be included as a step within
a more complex use case
• The more complex use case depends on the simpler one
– a change in the simpler one might mean the more complex one
has to be changed too
– A use case may be an extension of another use case
• An extension is a scenario within a use case that does not
have the same outcome as the main success scenario
• Extension depends on main use case since it is defined to be
a variation on the main success scenario
12
The <<include>> relationship
Extend loan
«include»
Check for
reservation
BookBorrower
«include»
Borrow copy
of book
• Scenarios that are instances of the more complex (“including”) use case
contain subscenarios which are instances of the simpler (“included”) use
case
• More complex use case depends on the simpler use case – hence
dashed arrow with open head which indicates dependency in UML
13
Use case descriptions
• Every use case should have a detailed
use case description which is usually
written in third-person, active-voice prose
14
Use case description for
Borrow copy of book
A BookBorrower presents a copy of a book and his or
her library card at the issue desk. The system checks
that the BookBorrower is a library member and that he
or she does not already have the maximum permitted
number of books on loan. This maximum is 6 unless the
BookBorrower is a staff member, in which case the
maximum is 12. If both checks succeed, the system
checks that the copy of the book is one that can be
borrowed. If it is, then the system checks if there is a
reservation on the book (done according to the use case
Check for reservation). If there is no reservation
on the book, the system records that the
BookBorrower has the book on loan from the current
date and prompts the librarian to stamp the book with the
return date. If any of the checks fail, the BookBorrower
is refused permission to borrow the book.
15
Use case description for
Extend loan
A BookBorrower asks (either in person or by
telephone) to extend the loan of a copy of a
book. The system checks whether there is a
reservation on the copy (done according to the
use case Check for reservation). If so, the
system refuses to extend the loan. Otherwise it
records that the BookBorrower’s loan of the
copy has been extended and prompts the
librarian to stamp the book with the new return
date. If the BookBorrower is present, the copy
of the book is stamped. Otherwise, the librarian
asks the BookBorrower over the phone to write
16
the new return date in the book.
Use case description for
Check for reservation
Given a copy of a book, the system
determines whether or not the book is
reserved.
17
Benefits of the <<include>> relation
• Instance of the “write once principle”
– Identify common steps in the main use cases
and factor these out as included use cases so
that the details of these steps only have to be
defined once
• Can make use case descriptions shorter
• Helps with identifying reusable
components if included use cases are
coherent units of functionality
18
Problems with the <<include>>
relation
• Encourages functional decomposition of system
instead of an object-oriented design
– Avoid this by developing class model in parallel with
use case model
– Make sure use case reuse makes sense at the class
level
• Makes use case diagram harder to understand
for the user or customer
• Tends to blur boundary between design and
requirements
– Using <<include>>s implies that some design
decisions have been made
19
Extending a use case
Borrow copy
of book
«extend»
Refuse loan
BookBorrower
• If a use case contains two or more scenarios with quite different outcomes,
then all the scenarios apart from the main success scenario are called
extensions and are considered to be variants on the main success scenario
• It is not necessary to represent each extension on the use case diagram since
all extensions are represented within the main use case symbol
• However, you can show an extension as a separate use case by creating a
new use case oval labelled with the name of the extension, then drawing a
dashed dependency arrow from the extension to the main use case and
labelling this arrow with the keyword <<extend>> to indicate that the extension
extends the main use case
20
Generalizing an actor and a use
case
Animal
Reserve book
BookBorrower
Reserve book
by telephone
Quadruped
JournalBorrower
21
System classes that represent
actors
•
•
If a system interacts with an actor it is not unusual for
the actor to be represented by a class within the
system
Two main types of situation when this happens:
1.
When the system must store data about each instance of the
actor
e.g., library system must store data about each library member such
as name, id number, list of books borrowed
2.
When the system represents (or wraps) an external device
with an internal object and uses the interface of the object to
interact with the device
e.g., there might be a Sensor class within a home alarm system
through which the system interacts with the physical motion
sensors positioned around the house
22
Summary
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Use case model represents a system from the point of view of the users
Use case models can help with
– requirements capture
– planning the goals of iterations
– validating the design of a system and testing the completed system
Use case diagram is a summary or table of contents on the use case analysis
– each use case must also have a detailed textual description
Each use case is a class of task that is supported by the system to be built
A scenario is a particular instance of a use case with a particular outcome
All the scenarios within a single use case have the same goal
The normal successful scenario within a use case, after which the use case is named, is called
the main success scenario
The other scanarios within a use case are called extensions
Users can be humans or autonomous devices or systems that are external to the system that we
are building
An actor represents a particular role that a user might adopt when interacting with the system
A beneficiary of a use case is an actor that benefits from the use case being carried out
The primary actor of a use case is the actor whose goal is achieved by carrying out the use case
The other actors involved in a use case are called secondary actors
Important to focus on requirements when doing a use case analysis and try not to make design
assumptions
Two ways in which use cases may depend on each other:
– A simpler use case may be included within a more complicated one
– A use case may be an extension of another use case
Like classes, actors may be related by generalization, as may use cases
An actor may be represented by a class within a system if either
– the system needs to store information about instances of the actor; or
– the system interacts with an autonomous physical device via the interface of an object that 23
wraps that device