®
IBM Software Group
Mastering Requirements Management
with Use Cases
Module 10: Structure the Use-Case Model
1
Objectives
Š Simplify the maintenance of the
requirements without sacrificing clarity or
comprehension for stakeholders.
ƒ Structure the use-case model.
ƒ Define and describe the relationships between
use cases.
• Include, Extend, Generalization
ƒ Describe concrete and abstract use cases.
ƒ Define actor generalizations.
ƒ Describe concrete and abstract actors.
2
Where Are We in the Requirements Discipline?
3
Manage Change: Activities and Artifacts
4
Structure the Use-Case Model
Š What is model structuring?
ƒ Factoring out parts of use cases
to make new use cases.
Š Why structure the use-case
model?
ƒ Simplify the original use cases.
• Make easier to understand.
• Make easier to maintain.
ƒ Reuse requirements.
• Share among many use
cases.
5
Relationships Between Use Cases
Š Include
«include»
Š Extend
Š Generalization
«extend»
WP5:
Structuring the Use-Case
Model
6
What Is an Include Relationship?
Š A relationship from a base use case to an
inclusion use case.
Š The behavior defined in the inclusion use case
is explicitly included into the base use case.
Inclusion
«include»
Base
7
Include Relationship: RU e-st Example
Get Quote
Execute
Trade
«include»
«include»
Trading
Customer
Identify Customer
RUCS7:
Structured UseCase Reports
«include»
Other Use Case
Identify Customer Use Case
1. Log on
2. Validate logon
3. Enter password
4. Verify password
A1: Not valid logon
A2: Wrong password
A3: ...
Get Quote Use Case
1. Include “Identify Customer”
to verify customer’s identity
2. Display options. Customer
selects “Get Quote”
3. ...
8
Execution of an Include Relationship
Š Fully executed when the inclusion point is
reached.
Base
Use Case
Use-Case
Instance
Included
Use Case
9
Why Use an Include Relationship?
ƒ Factor out behavior common to
two or more use cases.
Inclusion
«include»
Base
?
hy
W
• Avoid describing same behavior
multiple times.
• Assure common behavior remains
consistent.
ƒ Factor out and encapsulate
behavior from a base use case.
• Simplify complex flow of events.
• Factor out behavior not part of
primary purpose.
10
What Is an Extend Relationship?
Š Connects from an extension use case to a
base use case.
ƒ Insert extension use case’s behavior into base
use case.
ƒ Insert only if the extending condition is true.
ƒ Insert into base use case at named extension
point.
Base
«extend»
Extension
11
Extend Relationship: RU e-st Example
RUCS4:
Structured UseCase Reports
Trading Customer
Get Quote
«extend»
«extend»
Get Expert
Predictions
Get News
Expert Quote
System
News System
12
Extend Relationship: RU e-st Example (cont.)
Get Quote Use Case
Basic Flow:
1. Include “Identify Customer”
to verify customer’s identity.
2. Display options.
3. Customer selects “Get
Quote.”
4. Customer gets quote.
5. Customer gets other quotes.
6. Customer logs off.
A1. Quote System unavailable
…
Extension Points:
The “Optional Services”
extension point occurs at Step 3
in the Basic Flow and Step A1.7
in Quote System Unavailable
alternative flow.
Get News Use Case
This use case extends the Get Quote
Use Case, at extension point
“Optional Services.”
Basic Flow:
1. If Customer selects “Get News,” the
system asks customer for time
period and number of news items.
2. Customer enters time period and
number of items. The system
sends stock trading symbol to
News System, receives reply, and
displays the news to the customer.
3. The Get Quote Use Case continues.
A1: News System Unavailable
A2: No News About This Stock
…
13
Execution of an Extend
Š Executed when the extension point is
reached and the extending condition is true.
Use-Case
Instance
Base
Use Case
Extension
Point
Extension
Use Case
14
Why Use an Extend Relationship?
Š Factor out optional or
exceptional behavior.
Base
«extend»
Extension
ƒ Executed only under certain
conditions.
ƒ Factoring out simplifies flow of
events in base use case.
ƒ Example: Triggering an alarm.
Š Add extending behavior.
ƒ Behavior developed
separately, possibly in later
version.
15
Concrete Versus Abstract Use Cases
A use case is
either concrete or
abstract.
Abstract use cases (A & D):
• Do not have to be complete.
• Exist only for other use cases.
• Are never instantiated on their
own.
A
«include»
B
C
«extend»
Concrete use cases (B & C):
• Have to be complete and
meaningful.
• Can be instantiated on
their own.
D
16
Hint:
Cover up all
abstract use
cases and you
should still be
able to
understand the
main purpose of
the system.
Why Wouldn’t You Structure The Model?
Inclusion
«include»
ƒ The solution is harder to see
when the use case gets
fragmented.
• Functionally decompose the
requirements.
• Decrease understandability.
• Increase complexity.
• Increases effort for reviewers,
implementers and testers.
• Not all stakeholders are
comfortable with the format.
Base
«extend»
Extension
Child
t?
o
n
y
h
W
ƒ The use-case model looks like
a design.
17
What Is Actor Generalization?
Š Actors may have common characteristics.
Š Multiple actors may have common roles or
purposes interacting with a use case.
Parent
Child 1
Child 2
18
Actor Generalization: Hospital Example
Š Parent: Medical Worker
Schedule
Operation
Š Children: Doctor, Nurse,
Aide
Doctor
Nurse
ƒ Medical Worker can read
charts
ƒ Doctor, Nurse, and Aide
can read charts
Medical
Read Chart
Worker
Aide
19
Why Use Actor Generalization?
Parent
Child 1
Child 2
Š Simplify associations
between many actors
and a use case.
Š Show that an instance of
a child can perform all
behavior described for
the parent.
Š Represent different
security levels.
20
Abstract Versus Concrete Actors
Š An abstract actor contains the
common part of the roles.
Medical
Worker
ƒ It cannot be instantiated itself.
ƒ Example:
• No person is hired to be a
Medical Worker.
Š A concrete actor can be
instantiated.
Doctor
Nurse
ƒ Example:
• Lauren is a Doctor.
• Daniel is a nurse.
21
Use-Case-Modeling Guidelines
Š Notations to use and not use.
ƒ For example, whether to use generalization
relationships.
Š Rules, recommendations, style issues, and
how to describe each use case.
Š Recommendations for when to start
structuring the use cases (not too early).
RUCS11: UseCase Modeling
Guidelines
22
Discussion: Structuring the Use-Case Model
Š How should we structure the use-case
model for our class project?
ƒ Include relationships?
ƒ Extend relationships?
ƒ Actor generalizations?
23
Review: Relationships in the Use-Case Model
to
from
generalization
communicates
communicates
«include»
«extend»
generalization
24
Checkpoints for Use Cases
Š For an included use case: does it make
assumptions about the use cases that
include it? Such assumptions should be
avoided so that the included use case is not
affected by changes to the including use
cases.
Š Are there some optional requirements that
are not part of the standard product
requirements? If so, you model this with an
extend-relationship to the other use case.
9
25
Review: Structure the Use-Case Model
1. Why might you decide to structure your use-case
model?
2. When is an extend-relationship used?
3. When is an include-relationship used?
4. What is an abstract actor?
A concrete actor?
An abstract use case?
A concrete use case?
26
Summary (1 of 2)
Š Build the right system right by using a
process to define and manage
requirements to meet the customer’s needs.
Š Effective problem analysis helps avoid the
“Yes, but…”
Š Elicitation helps you understand your
stakeholders’ needs.
Š Use features and a use-case model to gain
agreement with the customer on the
definition of the system.
27
Summary (2 of 2)
Š Increase your chances to deliver on time
and on budget by managing scope
throughout the lifecycle of the project.
Š A use-case model of requirements helps
refine the system definition to drive design,
test, and user documentation.
Š Requirement attributes and traceability help
you manage change and avoid “scope
creep.”
28
MRMUC Handouts
WP 1: The Five Levels of Requirements Management
Maturity
WP 2: Features, Use Cases, and Requirements, Oh
My!
WP 3: Using the RUP to Evolve a Legacy System
WP 4: Generating Test Cases from Use Cases
WP 5: Structuring the Use-Case Model
WP 6: ACRE: Selecting Methods For Requirements
Acquisition
29
Other Sources of Information
Š Rational Unified Process®
Š Other courses
Š Essentials of Rational Unified Process®
ƒ Essentials of Rational® RequisitePro®
• Web-based or Instructor-led training
ƒ Mastering Business Modeling with the UML
Š Web sites
ƒ Rational’s corporate site: www.rational.com
ƒ Rational Developer NetworkSM: www.rational.net
Š Books and articles about requirements
management
ƒ See Reference list
30