Use Cases SE343 Notes

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 Dont specify individuals, but the roles they play in the domain
Example: dont use Bubba, but use Bubbas 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.
2011 Mike Rowe
Page 1
09/19/2011 12:00 PM

Use
Non-human actors: allows abstraction of other systems that interact with our
system. This simplifies the model, in that we dont need to get into the details
of other systems.
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 ones 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.
2011 Mike Rowe
Page 2
09/19/2011 12:00 PM

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
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:
o
2011 Mike Rowe
Page 3
09/19/2011 12:00 PM

1.2 Use Case (Flow of Events or Scenarios)
Capture the details of WHAT a use case should do. Use cases can replace lowlevel requirements or augment low-level requirements by showing how they
function altogether.
A scenario defines a process from the users point of view.
Written in concise steps from a users / actors 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.
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.
2011 Mike Rowe
Page 4
09/19/2011 12:00 PM

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.
Organization of Use Cases Some huge systems may have 1000s 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.
2011 Mike Rowe
Page 5
09/19/2011 12:00 PM

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
http://www.requirementsnetwork.com/sites/requirementsnetwork.com/files/Effective%20Use%20of%20Language
%20in%20Use%20Cases.pdf
Use active voice, and speak from the actors 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.
2011 Mike Rowe
Page 6
09/19/2011 12:00 PM

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.
Dont 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 cant just end floating in spacesomething 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.
o Some like to specify this as a postcondition dont 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?
2011 Mike Rowe
Page 7
09/19/2011 12:00 PM

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 cant read this and understand it right
off the bat in 30 seconds, theres 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 Rowes 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. Its 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 users 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.
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
09/19/2011 12:00 PM

2 Systematic Development of Use Cases

Start with a casual format and successively refine them into a more formal (dressed
up) style. The projects 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.
ACTOR
Bank_Clerk
ATM_Custom
er
ATM_other
BanksCustom
er
ATM_Custom
er
ATM_Machine
2011 Mike Rowe
Task-Level Goal List

Task-Level Goal
Priorit Trigger
y
Produce ATM cards
User selected
WithdrawMoney
2
User selected
(ourBankCustomer)
WithdrawMoney
3
User selected
(anotherBanksCustome
r)
CheckMoneyMarketAcc 3
User selected
ount balance
RunBuiltInTest (BIT)
1
Timer,
transactions,
Page 9
Within
Scope**
NO
YES
YES
YES
Maintenanc
e
subsystem
09/19/2011 12:00 PM

ATM_Machine
ATM_Custom
er
AuthorizeATM_Custome 1
r
Open new bank
accounts
Transactions
User selected
Security
subsystem
NO
...
** 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.
Actor
ATM_Customer
(ourBankCustomer
)
ATM_Customer
(anotherBankCusto
mer)
2011 Mike Rowe
Use Case Brief

Goal
Brief
WithdrawMoney
An authorized ATM_Customer specifies the
(ourBankCustom amount of money they wish to withdraw
er)
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.
WithdrawMoney
The ATM machine makes electronic contact
(anotherBankCus with another bank to authorize that the
tomer)
ATM_Customer 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
Page 10
09/19/2011 12:00 PM

ATM_Machine
will they receive a loan.

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 instance
the printer is not needed for withdrawing
money).
RunBuiltInTest
(BIT)
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 ATMs home bank computers,
the home bank computers are linked to other banks 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.
O ur Bank
A n o th e r B a n k 's
C u s to m e r
A T M M a c h in e
use cases
O u r B a n k s A T M C u s to m e r
A T M C o m m L in k
O th e r B a n k s
C en tral B an k
C o m p uter
o th er
ap p licatio n s
O u r B a n k 's C u s t o m e r
2011 Mike Rowe
Page 11
09/19/2011 12:00 PM

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.
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
09/19/2011 12:00 PM

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 Customers 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
2011 Mike Rowe
Page 13
09/19/2011 12:00 PM

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 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 engineers name/ customers name
o Revised: Who and when engineers name
2011 Mike Rowe
Page 14
09/19/2011 12:00 PM

o Revisions Reviewed: Who and when engineers name
o Signed Off: Who and when customers name
...
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
09/19/2011 12:00 PM

Detailed Entity Table
Entity / Type
Description
Customer
A person with an account at the bank
Attributes
Definition
Sensiti
ve
No
Type
Length
firstName
The first name of the

Customer
The last name of the
Customer
Social Security Number
A drivers license number
Text
25
No
Text
25
Yes
Yes
Text
Text
9
12
No
Text
Yes
Money
11.2
dateOfBirth
PIN
State that issued drivers

license
Upper borrowing limit for this
Customer
Date of birth of the Customer
Personal Identification Number
Yes
Yes
YYYYMMDD
nnnn
motherMaiden
Mothers Maiden name
Yes
Text
numeri
c
text
Relationships
marriedTo
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.
lastName
SSN
driversLicenseNu
mber
driversLicenseSta
te
creditLimit
parrentOf
accountsOf
accountIssurance
Max
Entity / Type
Spouse
Description
A person to whom a Customer is
married.
Attributes
Definition
firstName
lastName
SSN
driversLicenseNu
mber
driversLicenseSta
te
The first name of the Spouse

The last name of the Spouse
Social Security Number
A drivers license number
2011 Mike Rowe
State that issued drivers

license
Page 16
24
Sensiti
ve
No
No
Yes
Yes
Type
Length
Text
Text
Text
Text
25
25
9
12
No
Text
09/19/2011 12:00 PM

dateOfBirth
PIN

Personal Identification Number
Yes
Yes
dateOfBirth
motherMaiden

Mothers Maiden name
Yes
Yes
Relationships
marriedTo
Business Rule
A Spouse may be married to zero or one
Customer
A Spouse may be the parent of zero, one or
more Child
parrentOf
Entity / Type
Child
Description
A person who is legally classified as a
dependent of a Customer or Spouse
Attributes
Definition
firstName
lastName
schoolName
The first name of the Child

The last name of the Child
Name of the school the Child
attends or n/a if none
Sensiti
ve
Yes
Yes
Yes
Text
numeri
c
Text
text
YYYYMMDD
nnnn
YYYYMMDD
24
Type
Length
Text
Text
Text
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
2011 Mike Rowe
Use Cases
Use
Page 17
Use Cases
Use Cases
09/19/2011 12:00 PM

Entity
--Created--
Defense
BuyDefense
GoldCoin
CalculatePlanetO
utput
Weapon
BuyWeapons
Populatio
n
...
Cases
--Read-DisplaySc
ore
BuyDefen
se
DisplaySc
ore
BuyWeapo
ns
DisplaySc
ore
...
--Updated--
--Deleted--
ExecuteEngage
ment
ExecuteEngade
ment
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.
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.
2011 Mike Rowe
Page 18
09/19/2011 12:00 PM

o EX: Check out book and Extend loan may both use Check for reservation
Extend Loan
<<includes>
>
Check out Book
Check for
Reservations
<<includes>>
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.
2011 Mike Rowe
Page 19
09/19/2011 12:00 PM

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
Customers 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 dont factor.
2.7.2
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
Advantages of Inclusions:
Disadvantages (according to Stevens)
Tends to push design/architecture down a functional v. OO approach.

I dont think it does any more than a straight requirements driven start.
2011 Mike Rowe
Page 20
09/19/2011 12:00 PM

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
dont 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).
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>>.
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
2011 Mike Rowe
Page 21
<<extend>>
UC_RefusesLoan
09/19/2011 12:00 PM

Back
o
o
o
to the ATM system, <<extend>> scenarios:

Refuse withdrawal (too much money withdrawn in a day)
Refuse withdrawal (user doesnt have enough money in account)
Refuse withdrawal (ATM doesnt have enough money to provide the
service)
o Refuse service because wrong PIN entered.
o ...
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
Checkout Journal
Journal Borrower
Level of a Use Case Diagram and the System Box

From: http://www.andrew.cmu.edu/course/90-754/umlucdfaq.html
2.7.5
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),
2011 Mike Rowe
Page 22
09/19/2011 12:00 PM

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 system-level box.
One useful way to think of these top-level services is as follows: if a use case
represents a top-level 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 23
09/19/2011 12:00 PM

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 24
09/19/2011 12:00 PM

Use Cases SE343 Notes

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Use Cases SE343 Notes

Transféré par

Droits d'auteur :

Formats disponibles

Notes: 004 Use Cases

CS/SE3430 / CS5430 - Object-Oriented Analysis and Design

1.1 Use Case Model/Diagram and Scenarios

Use Case Diagram

2011 Mike Rowe

Notes: 004 Use Cases

Use Case Diagram:

Notes: 004 Use Cases

2011 Mike Rowe

Notes: 004 Use Cases

1.2 Use Case (Flow of Events or Scenarios)

2011 Mike Rowe

Notes: 004 Use Cases

Scope of a use case

2011 Mike Rowe

Notes: 004 Use Cases

Extends common steps that are CONDITIONALLY

1.3 Use Case Scenarios/Flows Rules of Thumb

Use active voice, and speak from the actors perspective

Use present tense

2011 Mike Rowe

Notes: 004 Use Cases

Express your text in the form of call and response.

Keep the use case short

Establish the initial context

2011 Mike Rowe

Notes: 004 Use Cases

Simplify, simplify, simplify.

End goal of Use Cases

1.4 Possible Problem with Use Cases (according to Stevens)

Use Case centric approach will end up with a non-object oriented

2011 Mike Rowe

Notes: 004 Use Cases

2 Systematic Development of Use Cases

2.1 Task-Level Goal List Step One

2011 Mike Rowe

Task-Level Goal List

Notes: 004 Use Cases

2.2 Use Case Briefs (not formal attire) Step Two

2011 Mike Rowe

Use Case Brief

Notes: 004 Use Cases

will they receive a loan.

2.3 Design Scope Step Three

2011 Mike Rowe

Notes: 004 Use Cases

2.4 Produce a detailed Use Case Diagram Step Four

2.5 Use Case Flows or Scenarios Step Five

2011 Mike Rowe

Notes: 004 Use Cases

Notes: 004 Use Cases

Notes: 004 Use Cases

Detailed Entity Table

Name, Definition, Notes, Volumetrics, Attributes,

If a lot of the above information would be useful for a project, a database of

2011 Mike Rowe

Notes: 004 Use Cases

The first name of the

State that issued drivers

Mothers Maiden name

The first name of the Spouse

2011 Mike Rowe

State that issued drivers

Notes: 004 Use Cases