Notes: 004 – Use Cases
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
1 Use Cases
Read Chapters 7 and 8 of Using UML
Issue: How do we systematically capture requirements?
 Just asking stakeholders will produce random coverage of a domain.
 Use Cases Centric approach provides a mechanism for systematically capturing large related
segments of domain requirements from the users’ perspective in the form of scenarios. Most
stakeholders know how they interact or will interact with a system, or what needs a system must
satisfy.
 By capturing large related chunks of specification, we are less likely to miss significant parts than
we would be by dealing with individual requirements.
 If we have the large chunks it is easy to fill in the missing gaps.
Use Cases modeling helps in more than four ways
1. Capturing requirements
2. Planning iterative development
3. Validating systems
4. Verifying systems
Developed by Ivar Jacobson
1.1 Use Case Model/Diagram and Scenarios
The use case centric approach is composes of diagrams and scenarios.
 Use Case Scenarios are short stories written in a specific format that define how the system is
used. Sometimes these are called use case flows.
 Diagrams provide an abstraction of how uses cases interact with each other and the users of the
system
1.1.1
Use Case Diagram
Two components , Actors and Use Cases. See Figure 7.2 on page 94
Actors:
 Represented by stick people in the model
 Someone or something that the system interacts with. Can be a person, another system, but
generally NOT a group.
 Has a role in or with the use case
 Identifying human actors:
o Don’t specify individuals, but the roles they play in the domain
 Example: don’t use Bubba, but use Bubba’s role as a Bank Customer.
o Roles – each unique actor role is represented by an Actor even if the different roles are
played by the same individual.
 Non-human actors: allows abstraction of other systems that interact with our system. This
simplifies the model, in that we don’t need to get into the details of other systems.
©2011 Mike Rowe
Page 1
02/06/2016 6:01 PM
Notes: 004 – Use Cases
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
Use Case
 Represented by an oval in the model.
 A use case represents a sequence of actions or steps a system performs that yields an observable
result of value to a particular actor.
 An action is a procedure that is invoked when an actor provides a signal to the system or when
the system is triggered (example a time out occurs). An action is atomic – it is performed entirely
or not at all.
 Use verb phases to name Use Cases (WithdrawMoney, CheckoutBook, OrderPizza, EatLunch,
TakeOutTheGarbage, etc.) Do not use nouns (Withdrawal, Book Checkout, Pizza Order, Lunch, …)
 Scope of a Use Case can be controlled by the following guidelines:
 An observable result of value – an actor should not need to perform several use cases to
achieve something useful.
o This provides guidance for keeping the level of granularity high enough.
o Example1: Entering one’s PIN in an ATM machine does not provide something
meaningful to the actor, an ATM Bank Customer who is withdrawing money.
o Example2: Taking a picture with a camera ( aiming, focusing, clicking the button) is
at a good level in that it produces something of value for the Actor, whereas just
clicking the button of the camera (alone) is not sufficient.
 A particular actor – forces the value of a use case to be relevant to a specific user or small
class of users.
o This provides guidance for keeping the level of granularity low enough.
o Example: A Use Case should not include all transactions of an ATM machine
(WithdrawMoney, PayBills, PayLoan, BuyStocks, …) as most Actor instances will
never use all of these use cases.
Use Case Diagram:
 A use case diagram relates the actors and use cases for a system or subsystem.
 Actors are connected to Use Cases by non-directed lines.
 Earlier versions of Use Cases used directed lines in order to show participation – receive
benefit, provide signals, etc.
 One way of developing Use Cases:
1. The list of Use Case titles that your team has developed are the starting point for further
development.
2. Next, you identify the actors (roles) for each of the use cases. Identify all actors that need to
use (interact with) a use case or receive benefit from it.
o Alternatively, you can identify all of the actors and then identify the use cases with which
they interact. Note the book suggests this method.
 Identifying the users for a use case should be easy (if it's not, watch out we may have a bad use
case!)
 Identifying non-human actors is trickier
o What's an external system? keyboard? Internet? Another Computer?
o Alternative sets to include:
 include all external systems that this system must get data from or supply data to
©2011 Mike Rowe
Page 2
02/06/2016 6:01 PM
Notes: 004 – Use Cases
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
include those which initiate a contact
include those which get value from the contact
o Why exclude most some non-human actors?
 end up analyzing portions that are well outside scope
 example: for an ATM the posting payments to customer accounts at a bank. We
should not go this deep, just use the main bank and not go deeper.
For future planning:
o Assess how much each actor needs a particular use case.
o Identify any known risks associated with each use case.
o Provide a first rough estimate of cost to implement each use case.
o This will help prioritize the Use Cases. This will help in sorting out what is or is not
needed in Phase I or Iteration I of the Project. Do the most needed first. Which use cases
would the user most want to see early?
o May want to start early on the more risky use cases to allow time to work things out.
May help to identify which real people are associated with each actor. This can help with
elaborating use case flows. Go to the individuals to get their perspective on a use case.
System boundaries – a big system can be subdivided into subsystems. Rectangular boxes, UML
Packages, are used to separate the subsystems of use cases.
Once this is done, one can start elaborating the use cases (see Use Case Flow of events below).
Look at library system in the book, page 94.
 List the Use Case Titles: ReserveBook, BorrowCopyOfBook, ReturnCopyOfBook,
ExtendLoan, BorrowJournal, ReturnJournal, UpdateCatalog, BrowseForBook,
ReturnBooksToShelf, PurchaseNewBooks, InventoryBooks, PutBookOnReserve,
BarrowReserveBook, ReturnReserveBook, CheckOutCD, ReturnCD, …
 Identify Actors for each use Case:







1.2 Use Case (Flow of Events or Scenarios)





Capture the details of WHAT a use case should do. Use cases can replace low-level requirements
or augment low-level requirements by showing how they function altogether.
A scenario defines a process from the user’s point of view.
Written in concise steps from a user’s / actor’s perspective.
Domain terms must be consistently defined in the project glossary.
Example: Withdraw Money from an ATM (Note: I have capitalized Actor Names)
1. The use case begins when the Client inserts an ATM card.
2. The System reads the information on the ATM card
3. The System validates the information read from the ATM card.
4. The System prompts for PIN.
5. The Client enters PIN.
6. The System validates PIN.
7. The System asks which operation the Client wishes to perform.
8. The Client selects “Cash withdrawal”
9. The System prompts for the amount to withdraw.
©2011 Mike Rowe
Page 3
02/06/2016 6:01 PM
Notes: 004 – Use Cases
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
10. The Client enters amount
11. The System displaces account types (“checking”, “saving”, “credit”) and requests the
Client select one for withdrawal
12. The Client selects the account type
13. The System communicates with the ATM network to validate account ID, PIN, and
availability of the amount requested.
14. The System asks the Client whether he/she wants a receipt.
15. The System asks the Client to withdraw the card. (This is a security measure to ensure
that Clients do not leave their cards in the machine.)
16. The Client withdraws the card.
17. The System dispenses the requested amount of cash.
18. The System prints a receipt.
19. The Client pulls out the receipt.

There are various paths through this use case based on
o Input from the Client: (can cancel at anytime, want a receipt, which account, etc.)
o Internal state of the System: (out of paper for receipt, too little cash in ATM, etc.)
o Time-outs and errors: (System may cancel transaction on a timeout for Client action,
network response, repeated wrong PIN, bad ATM card, etc.)
o Each instance, represents unique path, and is called a Use Case Scenario. The set of all
scenarios is a use case (class).
o Sunny Day Scenario – term used to refer to the primary, everything goes smooth, path
through a use case.
o Rainy Day Scenario – any path that deviates from the “sunny day”.
 EX: paper jam in the ATM machine. Machine is out of money. Non-valid PIN entered, etc.
What do we do under these exception cases?
1.2.1 Scope of a use case


What is too little and what is too much for a single use case.
o We could combine all ATM transactions into a single use case (Withdraw, Deposit,
Transfer, Pay Loan, etc.).
 This would provide multiple observable results for an actor, therefore not a good
idea.
 Also, subclasses of actors may never use all of these transactions. Has anyone
used the Pay Loan use case?
 This is too large!
o We could break the Withdraw use case into multiple use cases, Read Pin, Validate Pin, but
each of these alone do not provide an observable of result of any real value to any actor.
 This is too small.
o Focus on finding things of value that a system provides to its actors
How detailed should the steps be?
o Until there is agreement among stakeholders (users, testers, designers, developers, etc.)
with respect to what a use case means.
©2011 Mike Rowe
Page 4
02/06/2016 6:01 PM
Notes: 004 – Use Cases
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design


Organization of Use Cases – Some huge systems may have 1000’s of use cases.
 Biggest system I worked on probably approached around 5,000 use cases.
 There were about 50 subsystems each with about 100 use cases.
o Use Case Package – in larger systems one needs to group similar use cases together to
help people access and analyze them. Systems, Subsystems, Subsubsystems, … seem to
provide natural container boundaries.
 Usually a good size range in package will have from 5-20 Use Cases.
 Packages can contain other Packages.
o Subflows – A main use case may be subdivided into several (alternative) subflows. This is
generally done when the same set of steps is common to multiple main use cases. The
concept is similar to a reusable function/procedure in a programming language.
 UML 1.3 – had two constructs for subflows, Uses and Extends .
 Uses – common steps that are ALWAYS executed in one or more use
cases. Simply done for reuse of common concepts (code, doc, tests, …).
EX: StartATM_Session, “ReadCard”, and “EnterAndValidatePIN” are
common to all ATM functions (Withdraw, Deposit, Transfer, PayLoan, etc.).
We could make a Uses use case of “UserAuthentication”.
 Extends – common steps that are CONDITIONALLY executed in one or
more use cases. Done primarily to simplify the flow of scenarios. EX: what
processing shall be done when user enters a bad PIN 3 times. OR. Adding
the non-standard telephone services (CallWaiting, CallForwarding) to a
standard 2-party call.
 UML 1.4 – has three constructs for subflows; Inclusion, Extension,
Generalization/Specialization
 Inclusion – is the same as Uses, common steps that are ALWAYS executed
in one or more use cases. The flow of a use case is incomplete if the
Inclusion is not present.
 Extends – non-standard processing – the EXTENDS of UML 1.3. The point
at which an extends attaches to another Use Case is called the “Extension
Point”
 Generalize/Specialize – modifications of a use case to suit a more
specialized function. The steps are generally the same as a class of use
cases, but there may be more attributes involved. Also,
generalize/specialize can be applied to Actors.
 Non-functional Requirements – requirements that relate to concurrency,
performance, reliability are generally not covered by use cases. This is why we
may need System Level requirements to cover this aspect.
Validation – “Walking a use case”. Stakeholders act out the use case flows to determine
whether they are valid.
1.3 Use Case Scenarios/Flows Rules of Thumb
Effective Use of Language in Use Cases, By Kendall Scott
©2011 Mike Rowe
Page 5
02/06/2016 6:01 PM
Notes: 004 – Use Cases
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
http://www.requirementsnetwork.com/sites/requirementsnetwork.com/files/Effective%20Use%20of%20Language%20in%20Use%20Cases
.pdf

Use active voice, and speak from the actor’s perspective
o “ The customer selects the item”
 NOT “The item is selected by the customer” // this is passive voice

Use present tense
o “The customer selects the item.”
 NOT “The customer shall select the item” // future tense
 or “The customer selected the item” // past tense
o Often times we use the future tense for requirements – see future tense above.

Express your text in the form of “call and response.”
o The text should reflect the fact that the actor performs some action(s) and the system
responds accordingly
o “The System prompts for a PIN.” (CALL) and
o “The Client enters a PIN.” (RESPONSE)

Keep the use case short
o The use case should address one functional requirement, or perhaps a small set of
requirements, and do it in a way that is obvious to anyone who reads it.
 Note that we may be using Use Cases rather than writing requirements and that
we are using “one functional requirement” as a unit of measure rather than a
concrete entity.
o Each use case should be a small, mobile unit that lends itself to possible reuse in other
contexts.

Establish the initial context
o You have to specify where the actor is, and what he or she is looking at, at the beginning
of the use case. There are two ways to do this.
1. The first way involves specifying the context as part of the first sentence/step:
“The Accountant enters his or her user ID and password on the System Login
page,”
2. The second way involves defining a precondition: “The Accountant is looking at
the System Login page” or “The system is displaying the System Login page.”
 Don’t do both and be consistent from use case to use case.

Make sure that each use case produces at least one obvious result of value to one or more
actors, even if that result is negative.
o A use case can’t just end floating in space—something measurable has to happen. Of
course, this is generally some positive result: “The actor is logged in to the system,” “The
system creates an Order,” “The system generates a report.”
©2011 Mike Rowe
Page 6
02/06/2016 6:01 PM
Notes: 004 – Use Cases
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
o Some like to specify this as a postcondition – don’t do it in both the last step of a use case
and in a postcondition (this would be redundant).

Write your alternate courses “rainy day scenarios” the same way you write your basic course,
except of course that alternates have the word “if.”
o Signal the presence of an alternate course involves using words such as “validates”,
“verifies”, “ensures”, or “checks”.
 “The system verifies that the credit card number the Customer entered matches
one of the numbers it has recorded for that Customer,” – this begs the question
“Well what happens if the verification fails?”
 “If the system does not match the entered credit card number to any of its stored
values, then it displays an error message and prompts the Customer to enter a
different number.”

Simplify, simplify, simplify.
o “If a (sober) person off the street can’t read this and understand it right off the bat in 30
seconds, there’s something wrong with it.”
o “Right off the bat” means that your reader should not be slowed down by unfamiliar
acronyms, unclear jargon, sloppy verbiage, or, especially, Using Big Words Where Little
Words Will Do Just Fine Syndrome.
o Rowe’s version, “Should be simple enough for your grandmother to understand”

End goal of Use Cases
o This is a device to capture requirements in ways that the people building the system will
understand and be able to run with. It’s a means to an end, not the end in itself
o Use cases are the input artifact for many other process tasks: Design, Coding, Test
Generation, Documentation, Maintenance, … Consider what information is necessary to
complete these future project tasks.
1.4 Possible Problem with Use Cases (according to Stevens)


Use Case centric approach will end up with a non-object oriented system. The author states
that developers may rush to develop the use cases, which are procedural in nature, without
bothering to develop objects. This leads to code that is difficult to maintain.
o My opinion, this is more of a process problem and this situation is just as likely to occur with
straight requirements.
There is a danger of mistaking design for requirements. Use case flows are generally written as
very concrete procedures from a user’s perspective. Requirements engineers may not consider
better ways of providing the same or better functionality.
o My opinion, this is no different from capturing straight requirements. Use Cases flows can
often help stakeholders see better procedures. Use cases have been used for non-software
systems to optimize people organizations, factories, etc. Until a process is modeled, it is hard
to optimize it.
©2011 Mike Rowe
Page 7
02/06/2016 6:01 PM
Notes: 004 – Use Cases
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design


Author approach of specifying actors and then their needs may result in missing critical
requirements.
o My comment, sometimes it is also useful to start with use case titles (features) and then
identify actors.
The approach one takes may depend on how well you know a domain. If you know a domain, it
may be better to start with Use Case titles.
©2011 Mike Rowe
Page 8
02/06/2016 6:01 PM
Notes: 004 – Use Cases
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
2 Systematic Development of Use Cases
Start with a casual format and successively refine them into a more formal (dressed up) style. The
project’s needs determine what is formal enough. (The following material is from Cockburn, A., Writing
Effective Use Cases, Addison-Wesley, 2004 – this is a great book with lots of practical ideas on Use Case
centric development.)
2.1 Task-Level Goal List – Step One
1. Identify actors,
2. Identify goals of each of the actors in the form of short verb phrases,
 ATM_Customer – Withdraws money
 ATM_Customer – Checks money market account balance
 ATM_Machine – Runs built in test (BIT)
 ATM_Machine – Authorizes the ATM_Customer
 ...
3. Optionally one may add another column indicating what triggers an event/goal. For instance Run
build-in-test may be triggered by an ATM_Customer starting any kind of transaction, and also
periodically trigged by a timer (once an hour maybe).
4. Once a sizable number of goals have been defined, it is beneficial to prioritize them. Users and
Requirements engineers arrive at priority. The priority may relate to a development release or
iteration.
5. Optionally, may also want to add a column that indicates whether a goal is within the scope of a
project. Or for large systems we may define to which subsystem the use case is belongs.
Task-Level Goal List
Priority
ACTOR
Task-Level Goal
Bank_Clerk
ATM_Customer
ATM_Machine
Produce ATM cards
WithdrawMoney
(ourBankCustomer)
WithdrawMoney
(anotherBanksCustomer)
CheckMoneyMarketAccount
balance
RunBuiltInTest (BIT)
ATM_Machine
AuthorizeATM_Customer
ATM_Customer
Open new bank accounts
ATM_other
BanksCustomer
ATM_Customer
©2011 Mike Rowe
Page 9
2
User selected
User selected
Within
Scope**
NO
YES
3
User selected
YES
3
User selected
YES
1
Timer, transactions, Maintenance
subsystem
Transactions
Security
subsystem
User selected
NO
1
Trigger
02/06/2016 6:01 PM
Notes: 004 – Use Cases
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
...
** For large Systems, use the subsystem name for the “Within Scope” col.
The Task-Level Goal list can be very useful in:
 Defining the scope of your current project,
 Planning multiple iterations.
o For planning iterative phases, we can also concentrate on high priority goals first.
o Sometime it makes sense to do some lower priority items first because they will make
other items easier to implement/test/ …
 All stakeholders can quickly see the candidate goals for the system and negotiate priorities. . .
2.2 Use Case Briefs (not formal attire) – Step Two
A use case brief is the next step. It consists of a couple (2 to 6) sentences, which describe the use case
behavior. It includes only the most import activities and failures. In addition to getting agreement on
what is important for a use case, a brief can also help initial estimates of effort. They can also be useful
in selecting COTS components at this early stage.
Use Case Brief
Goal
Brief
WithdrawMoney
An authorized ATM_Customer specifies the amount of
(ourBankCustomer)
money they wish to withdraw from one of their
accounts. They receive the money, deduct this
amount from their balance, and print a receipt. If they
do not have enough money in their account, under
some circumstances they may be able to receive a
loan.
ATM_Customer
WithdrawMoney
The ATM machine makes electronic contact with
(anotherBankCustomer) (anotherBankCustom another bank to authorize that the ATM_Customer
er)
can withdraw a specified amount of money from one
of their accounts. They receive the money, deduct
this amount from their balance, and print a receipt. If
they do not have enough money in their account,
under NO circumstances will they receive a loan.
ATM_Machine
RunBuiltInTest (BIT)
The ATM machine runs the BIT to determine the
functionality of all the ATM subsystems. The ATM
machine runs the BIT on both a configurable time
schedule and at the beginning of each customer
transaction. The results of the BIT determine which
transactions are allowed. Some subsystems need not
be functional for some of the transaction types (for
Actor
ATM_Customer
(ourBankCustomer)
©2011 Mike Rowe
Page 10
02/06/2016 6:01 PM
Notes: 004 – Use Cases
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
instance the printer is not needed for withdrawing
money).
2.3 Design Scope – Step Three
Defines the context for our system. It sometimes is called a context diagram. An ATM consists of all of
the software and hardware in the box. The box is linked to a communications network, the network is
linked to the ATM’s home bank computers, the home bank computers are linked to other bank’s
computers and so on.
 This helps explicitly define the scope of the system for all stakeholders.
 It is also useful in identifying and defining which subsystem of a large subsystem a use case
belongs.
 It also helps define which interfaces need to be defined
 For larger system, we represent each subsystem as a block and specify which use cases belong to
each subsystem.
Our Bank
ATM Machine
Another Bank's
Customer
use cases
Our Banks ATM Customer
ATM Comm Link
Other Banks
Central Bank
Computer
other
applications
Our Bank's Customer
2.4 Produce a detailed Use Case Diagram – Step Four
From the Use Case Briefs and the Use Case Context Diagram produce a detailed Use Case Diagram
showing all of the Actors and Use Cases within the scope of the system. Use Packages to organize these
use cases into logical Subsystems, subsubsystems, …
This diagram will continue to be modified as the next step is performed, as in step five you will find
opportunity to <<includes>> and <<extends>> subflows.
©2011 Mike Rowe
Page 11
02/06/2016 6:01 PM
Notes: 004 – Use Cases
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
2.5 Use Case Flows or Scenarios – Step Five
There are many formats used to specify the detail flows of use cases. Generally, the format is based on
the level of formality needed for the particular project. The Style and Form are generally refined based
on project and company needs.
Here is an example of a formal Use Case – once again, not All Fields are necessary for all projects.
©2011 Mike Rowe
Page 12
02/06/2016 6:01 PM
Notes: 004 – Use Cases
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
Label : UC_WdMonOC
TITLE : Use Case: WithdrawMoney(our customer) : Withdraw money from ATM (our bank customer)
PRIMARY ACTOR: ATM customer (CUSTOMER)
SECONDARY ACTOR(s): ATM machine (ATM)
GOAL IN CONTEXT: ATM customer receives funds from an ATM machine
SCOPE: {{Subsystem Name if this were a bigger system}}
LEVEL: main/detail, extends/includes
STAKEHOLDERS and INTERESTS:
ATM customer (CUSTOMER): desires money, desires security of access to his/her account
BANK: desires authentication that customer is a bank customer and has funds to cover withdrawal;
desires that ATM machine remains secure.
PRECONDITION: Our bank customer must have ATM card
TRIGGER: User starts transaction by inserting an ATM card
MAIN SUCCESS SCENARIO:
1. Customer inserts ATM card.
2. ATM runs BIT.
3. ATM reads information on the card.
4. ATM validates information on the card.
5. ATM displays prompts for PIN.
6. Customer enters PIN.
7. ATM validates PIN by checking a MD5 hash.
8. ATM displays prompt asking “Which operation do you want to perform?”
9. Customer selects “Cash withdrawal”
10. ATM displays prompt for amount to withdraw.
11. Customer enters amount
12. ATM displays prompt requesting from which account to withdraw.
13. Customer selects the account type (checking, saving, credit).
14. ATM communicates with the ATM network to authorize user by validating account ID,
PIN, and availability of the amount requested.
15. The ATM displays prompt asking the Customer whether he/she wants a receipt.
16. ATM asks the client to withdraw the card.
17. Customer withdraws the card. (This is a security measure to ensure that Customers do
not leave their cards in the machine.)
18. ATM sends a message over the ATM Comm link to the main bank computer commanding
that the amount to be dispensed is deducted from the Customer’s account.
19. ATM dispenses the requested amount of cash.
20. ATM prints receipt.
21. The use case ends.
EXTENSIONS: (Note: often extensions are complex. You will want to define the entry level
condition here and reference the label for the Extension Use Case following the entry condition.)
2a. If BIT fails ATM displays “out of order message” to user and sends message to main bank
©2011 Mike Rowe
Page 13
02/06/2016 6:01 PM
Notes: 004 – Use Cases
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
computer requesting service. (see UC_RequestService)
4a. If ATM cannot validate information on card the ATM displays message that indicates bad card
and halts scenario. (see UC_RejectCard)
7a. If ATM cannot validate PIN the ATM keeps the card, displays a message that indicates PIN
failure, and then halts scenario. (see UC_RejectPin)
11a. If the ATM does not have sufficient funds to cover withdrawal, a message indicating this and
the maximum amount that can be funded is displayed to the CUSTOMER and then the Scenario
is restarted at step 9.
14a. If the Customer does not have sufficient funds, but has more than $20, the ATM displays the
maximum amount the user can withdraw and the Scenario is restarted at step 9.
14b. If the Customer has less in their account than the minimal amount that the machine can
fund, then the ATM displays a message indicating this and the Scenario is halted after the card is
ejected.
15a. This step is performed only if there is paper left to print the receipt.
20a. Receipt is printed only if Customer requests one.
Inclusions:
2a. RunBIT the BIT will be run for each transaction and includes: UC_CheckPower,
UC_CheckPrinter, UC_CheckTamper, UC_CheckMoney, UC_CheckCommLink, …
4a. AuthenticateUserCard checks the information on the card against bank records to make sure
the user has an account from which they may perform a transaction.
...
ISSUES and TBDs:
a. Maximum withdrawal amount
b. Minimum withdrawal amount
c. Timeout interval for canceling session.
d. Maximum number of withdrawal transactions per 24 hour period.
e. . . .
TRACING TO SYSTEM-LEVEL REQUIRES:
R-Security-023
R-Security-064
...
RELATED USE CASES:
UC_Deposit
KNOWLEDGE SOURCE: where did the information come from like: Bobob the bank VP in charge of
nickels.
REQUIREMENTS ENGINEER: Bertha
REVISION HISTORY:
o Created: Who and when
o Reviewed: Who and when engineer’s name/ customer’s name
o Revised: Who and when engineer’s name
o Revisions Reviewed: Who and when engineer’s name
o Signed Off: Who and when customer’s name
...
©2011 Mike Rowe
Page 14
02/06/2016 6:01 PM
Notes: 004 – Use Cases
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
2.6 Collecting Data Requirements
It is often useful to collect data requirements as we develop our use cases. Historically data dictionaries
contained information about the type, range, relationships and usage of data in a system. We may want
to consider modifying this approach. Keith Matthews (2006) published a set of ideas in the
Requirements Network Group
http://www.requirementsnetwork.com/user_registration?destination=trackerlite that with a little
modification (by me) seems to provide good utility. This new approach contains two different sets of
tables.
2.6.1 Detailed Entity Table
While we are capturing use case flow, it is generally also a good time to capture details about data
entities. This will help all stakeholders come to a common understanding of the data entities and the
relationships among the entities. Below are data that might be useful to capture at this time.
Category
Information Categories
Entity
Name, Definition, Notes, Volumetrics, Attributes, Relationships
(Associations), Specific Business Rules, .......
Name, Definition, Notes, Cardinality, Data Type, Length, Precision,
Volumetrics, Value Domain, Minimum, Maximum, Calculation,
Specific Business Rules, Default Value, Order, Security Considerations,
.......
Name, Entities it relates, Cardinalities, Navigability, .......
Attributes
Associations
If a lot of the above information would be useful for a project, a database of spreadsheet would be the
suitable mechanism for maintaining it. Below is a simple example using a table to maintain a few of the
information categories.
©2011 Mike Rowe
Page 15
02/06/2016 6:01 PM
Notes: 004 – Use Cases
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
Detailed Entity Table
Entity / Type
Customer
Attributes
firstName
lastName
SSN
driversLicenseNumber
driversLicenseState
creditLimit
dateOfBirth
PIN
motherMaiden
Description
A person with an account at the bank
Definition
The first name of the Customer
The last name of the Customer
Social Security Number
A drivers license number
State that issued drivers license
Upper borrowing limit for this
Customer
Date of birth of the Customer
Personal Identification Number
Mother’s Maiden name
Sensitive
No
No
Yes
Yes
No
Yes
Type
Text
Text
Text
Text
Text
Money
Length
25
25
9
12
2
11.2
Yes
Yes
Yes
Text
numeric
text
YYYYMMDD
nnnn
24
Relationships
marriedTo
parrentOf
accountsOf
accountIssuranceMax
Business Rule
A Customer may be married to zero or one Spouse
A Customer may be the parent of zero, one or more Child
A Customer may have one or more Accounts
A Customer is insured for up to a maximum total across all
Accounts of $1,000,000 by the F.D.I.C.
Entity / Type
Spouse
Description
A person to whom a Customer is married.
Attributes
firstName
lastName
SSN
driversLicenseNumber
driversLicenseState
dateOfBirth
PIN
dateOfBirth
motherMaiden
Definition
The first name of the Spouse
The last name of the Spouse
Social Security Number
A drivers license number
State that issued drivers license
Date of birth of the Customer
Personal Identification Number
Date of birth of the Customer
Mother’s Maiden name
Relationships
marriedTo
parrentOf
Business Rule
A Spouse may be married to zero or one Customer
A Spouse may be the parent of zero, one or more Child
Entity / Type
Description
©2011 Mike Rowe
Page 16
Sensitive
No
No
Yes
Yes
No
Yes
Yes
Yes
Yes
Type
Text
Text
Text
Text
Text
Text
numeric
Text
text
Length
25
25
9
12
2
YYYYMMDD
nnnn
YYYYMMDD
24
02/06/2016 6:01 PM
Notes: 004 – Use Cases
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
Child
A person who is legally classified as a dependent
of a Customer or Spouse
Attributes
firstName
lastName
schoolName
Definition
The first name of the Child
The last name of the Child
Name of the school the Child attends
or “n/a” if none
Sensitive
Yes
Yes
Yes
Type
Text
Text
Text
Length
25
25
25
We can use this table to spot
o missing relationships,
o inconsistencies – we want all use cases to use the same labels for data entities and all of the
data entities attributes, associations, … ,
o plan for a secure system – if we see some data are sensitive we know at all points that this
data must have special handling,
o possible reuse opportunities (inheritance), and
o help in reviewing knowledge with the customers.
Be wary of going too fast from analysis to design!
2.6.2 CRUD Table
A CRUD (CreateReadUpdateDelete) Table defines at a high level where (by use case) a data entity is used
and how it is used (Created, Read, Updated, Deleted). It does not get into the detail about the makeup
of each entity. There is one CRUD table per system. If we see that a data entity is missing any CRUD
stage, then it is likely that there is a gap in our use cases.
CRUD Table for a Star Wars-type computer game
Data Entity
Defense
GoldCoin
Weapon
Population
Use Cases
--Created-BuyDefense
Use Cases
--Read-DisplayScore
BuyDefense
CalculatePlanetOutput DisplayScore
BuyWeapons
Use Cases
Use Cases
--Updated---Deleted-ExecuteEngagement ExecuteEngadement
BuyWeapons
...
...
...
DisplayScore
...
BuyDefense
BuyWeapons
BuyTechnology
BuyDefense
BuyWeapons
BuyTechnology
...
...
...
In this table we list the use cases that make use of each of the data entities and how the use cases use
the entities. This table helps us keep track of the data lifecycle (creation through destruction) in a
system.
©2011 Mike Rowe
Page 17
02/06/2016 6:01 PM
Notes: 004 – Use Cases
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
2.6.3 Summary of Collecting Data Requirements
The Detailed Entity Table maintains consistency in the data entities as we discover how they are being
used and are associated.
The CRUD table helps us keep track of the use of each of the entities. This is important when we need to
react to changes. If one use case changes, it may require modifications to entities. In turn, the changes
to an entity may cascade into the other use cases that use that entity.
2.7 Relationships among use cases
This is old school Use Case Centric stuff from Jacobson circa 1998.
Preconditions:
1. Have the high-level Use Case diagram
2. Have the Use Case Work Flows (somewhat complete, more than just titles needed)
2.7.1 <<Uses>> or <<Includes>>
o Factor out common behavior from two or more main use cases
o Shown as a dashed line with an arrow pointing at the behavior that is factored out (refactoring
use cases) of the other use cases.
o The flow of an <<includes>> is ALWAYS executed. This will be a significant difference between
<<includes>> and the other factoring use cases.
o EX: Check out book and Extend loan may both use Check for reservation
Extend
Loan
<<includes>
>
Check for
Reservations
Check out
Book
©2011 Mike Rowe
<<includes>>
Page 18
02/06/2016 6:01 PM
Notes: 004 – Use Cases
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
o The Check for reservations is also included in other use cases. The steps for included use cases
are factored out of the main use cases and a notation is placed in the main use case flow to
indicate the factoring. “Then the Librarian Actor checks to see if the book is already reserved.
(See UC_CheckForReservations).
Lets identify possible inclusions in the ATM machine.
 Withdraw Money from an ATM
1. Customer inserts ATM card.
2. ATM runs BIT.
3. ATM reads information on the ATM card.
4. ATM validates information on the ATM card.
5. ATM displays prompts for PIN.
6. Customer enters PIN.
7. ATM validates PIN.
8. ATM displays prompt asking “Which operation do you want to perform?”
9. Customer selects “Cash withdrawal”
10. ATM displays prompt for amount to withdraw.
11. Customer enters amount
12. ATM displays prompt requesting from which account to withdraw.
13. Customer selects the account type (checking, saving, credit).
14. ATM communicates with the ATM network to authorize user by validating account ID, PIN, and
availability of the amount requested.
15. The ATM displays prompt asking the Customer whether he/she wants a receipt.
16. ATM asks the client to withdraw the ATM card.
17. Customer withdraws the card. (This is a security measure to ensure that Customers do not leave
their cards in the machine.)
18. ATM sends a message over the ATM Comm link to the main bank computer commanding that
the amount to be dispensed is deducted from the Customer’s account.
19. ATM dispenses the requested amount of cash.
20. ATM prints receipt.
21. The use case ends.
Possible Inclusions
 ATM performs a BIT
 Authorize Customer
 Check printer, prompt for receipt, print receipt
 Update account balances
Already written Components:
 Inclusions may be COTS or in house developed business objects. For example: we probably have
something for Authorize Customer.
When to stop factoring:
 If the work in factoring is more work than implementing – don’t factor.
©2011 Mike Rowe
Page 19
02/06/2016 6:01 PM
Notes: 004 – Use Cases
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
2.7.2 Advantages of Inclusions:








Can save further analysis and design work from this point on.
Only need to develop the functionality once.
Can share testing. Speeds validation walkthroughs. Only need to test it once as code.
Can share documentation, this can be significant if functionality is visible to users.
Indicates an early decision to reuse a component in particular parts. Need to pay particular
attention to this component so that the component will be suitable for both instances.
Can make the main uses cases simpler by abstracting detailed parts out.
Can help refine project plan earlier. The more and earlier reuse is identified, the less resources
are needed in the project. Estimating the efforts required for reused components is far easier
that new work!
The above are more difficult to do using a requirements only approach instead of use case
centric approach.
2.7.3 Disadvantages (according to Stevens)



Tends to push design/architecture down a functional v. OO approach. – I don’t think it does
any more than a straight requirements driven start.
o The author suggests developing the high-level object model in parallel. – I think that
this will result in some speculative work and will increase throw away work, this increases
the total work load.
Modeling incorporating inclusions is harder for non-UML skilled people to follow. – At least
there is a user perspective model to use v. no model at all (like a strict requirements only
approach).
The more complex the use case model the harder it is to maintain. – I don’t see how this is any
different with requirements based approach. If you change a requirement you must review the
changed requirement against other requirements to determine if there are conflicts, new gaps,
etc. introduced into requirements.
2.7.4 Summary of Inclusion




Can simply or provide an abstract view of the main use cases
Show common functionality among use cases
To document that we have a reuse opportunity
To document the selection of a preexisting component (COTS).
2.8 Separating variant behavior <<extend>>


If the two or more scenarios of a use case have significantly different behaviors /flows based on
circumstances we need extension(s)
<<extend>> use cases flows are NOT executed every time. Recall that this is a significant
difference between <<include>> and <<extend>>.
©2011 Mike Rowe
Page 20
02/06/2016 6:01 PM
Notes: 004 – Use Cases
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design




In the book they have a scenario in which a book barrower is refused a book check out because
(s)he has too many books checked out. We can have an <<extend>> for “Refuse loan”.
An <<extend>> is connected to the extended use case by a dashed line and an arrow pointing
back to the extended use case.
The extended use case lists the point at which the extension occurs.
The extended use case flow refers to the <<extend>> (See Refuse loan extends based check of
number of books checked out).
UC_CheckoutBook
Extension points:
UC_RefuseLoan

<<extend>>
UC_Refuses
Loan
Back to the ATM system, <<extend>> scenarios:
o Refuse withdrawal (too much money withdrawn in a day)
o Refuse withdrawal (user doesn’t have enough money in account)
o Refuse withdrawal (ATM doesn’t have enough money to provide the service)
o Refuse service because wrong PIN entered.
o ...
2.9 Generalization
o Use cases and Actors can be generalized or specialized.
o Example from library system
o Actors Journal Barrower is a specialization of a Book Barrower.
o Use Cases Checkout Journal is a specialization of Book Checkout
Checkout Book
Book Borrower
©2011 Mike Rowe
Page 21
02/06/2016 6:01 PM
Notes: 004 – Use Cases
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
Checkout Journal
Journal Borrower
2.10 Level of a Use Case Diagram and the System Box
From: http://www.andrew.cmu.edu/course/90-754/umlucdfaq.html
2.10.1 How do you know what to put in the "System" box?
The system box only appears on the top-level diagram (remember that a typical UML Use Case
description will be composed of many diagrams and sub-diagrams), and should contain use case ovals,
one for each top-level service that your system provides to its actors. Any kind of internal behavior that
your system may have that is only used by other parts of the system should not appear in the systemlevel box. One useful way to think of these top-level services is as follows: if a use case represents a toplevel service, then it should make sense for the actors who interact with it to request only that service of
your system in a single session (in whatever sense a "session" is intelligible in your system.)
What Level should a Use Case be, Example: In the diagram below we would like to represent the use
cases for a camera. Suppose we choose "Open Shutter", "Flash", and "Close Shutter" as the top-level use
cases. Certainly these are all behaviors that a camera has, but no photographer would ever pick up their
camera, open the shutter, and then put it down, satisfied with their photographic session for the day.
We must see or produce some observable benefit – “opening a shutter” by itself does nothing for the
primary actor! The crucial thing to realize is that these behaviors are not done in isolation, but are
rather a part of a more high-level use case, "Take Picture" does result in some useful goal being
achieved by an Actor. (Note that it does make sense for a photographer to "Take Picture" just once
during a session with their camera.)
©2011 Mike Rowe
Page 22
02/06/2016 6:01 PM
Notes: 004 – Use Cases
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
2.11 Interactions between Use Cases
Once relationships between use cases have been identified – it is important to understand what
information will need to flow across this interface.
©2011 Mike Rowe
Page 23
02/06/2016 6:01 PM