info 355week #21 systems analysis ii use cases info 355 glenn booker
TRANSCRIPT
INFO 355 Week #2 1
Systems Analysis IIUse Cases
INFO 355Glenn Booker
Use Cases
As part of the activity to define functional requirements, we can capture those requirements in “use cases”
“A use case is an activity the system performs, usually in response to a request by the user” (text, 69)
INFO 355 Week #2 2
INFO 355 Week #2 3
Use Cases and OO
Though use cases are often associated with object oriented analysis, use cases are not object oriented
They could be used to help capture functional requirements for any type of system
Finding use cases
Two methods (at least) for finding use cases for a system User goal technique Event decomposition technique
To validate a draft list of use cases, the CRUD technique can be used
INFO 355 Week #2 4
User goal technique
The main idea behind this technique is to identify the types of users of a system, then determine what goals or assigned tasks each type of user has when using the system
Those goals often correspond to use cases
INFO 355 Week #2 5
User goal technique
The user goal technique is: Identify all potential users for a system (Optional) Classify users by functional
role (shipping, marketing, sales) and operational level (operational, management, executive)
Interview each user and determine what goals they have when using the system
INFO 355 Week #2 6
User goal technique
Make a preliminary list of use cases for each type of user
Look for duplicates and inconsistencies across users
Identify when multiple users need the same use case
Review completed list with users and other stakeholders for validation
INFO 355 Week #2 7
Event Decomposition
This approach looks for all events that would lead to the information system being used Each event typically leads to a use case Simplify events to ones that have a
clearly defined start and end, and achieve a clear business purpose
Those are Elementary Business Processes (EBPs) = use cases
INFO 355 Week #2 8
Event Decomposition
Focusing on events keeps attention on the macro scale purpose of the system, not internal details
Events can be External – caused by an actor Temporal – done at fixed time intervals State – triggered by an internal
condition, e.g. low inventory
INFO 355 Week #2 9
Event Decomposition
Focus on events that directly cause the system to be used Not prior conditions that are invisible to
the system Many important business processes do
not involve the system directly! Avoid trivial use cases (logging on)
but DO include system controls (admin functions such as backup)
INFO 355 Week #2 10
The last point differs from the text!
Event Decomposition
The event decomposition process is Identify relevant external events
For each, name a use case Identify relevant temporal events
For each, name a use case and define when it occurs
Identify relevant state events For each, name a use case
Omit trivial use cases, but keep system controls
INFO 355 Week #2 11
CRUD technique
Use this technique for verifying an existing list of use cases
Recall CRUD – create, read, update, or delete data
The goal of this technique is to verify at least one use case has been identified to perform all relevant aspects of CRUD Relevant aspects?
INFO 355 Week #2 12
CRUD technique steps
Identify major data entities for your system
For each, verify that at least one use case does each of CRUD, as appropriate to your system
Add use cases if needed Make sure data ownership is clear if
more than one application interacts
INFO 355 Week #2 13
Naming use cases
Give use cases a short name (2-4 words), starting with an action verb Track shipment Create new user Produce monthly sales report
The reason for brevity is so we can put them on a use case diagram
INFO 355 Week #2 14
INFO 355 Week #2 15
Use Case Diagram
A use case diagram summarizes all the major use cases for a system
To define a use case diagram, need: List of Use Cases Actors External Systems (if any) System Boundary (automation
boundary)
INFO 355 Week #2 16
Actors
Actors are types of users of the system – the role of someone who uses the system
Actors must interact directly with the system Interaction could be through any
mechanism – keyboard, mouse, touch screen, card reader, voice, biometric,…
INFO 355 Week #2 17
Actors
Examples of actors include Customer/Client/Patient/Patron/Donor/
Subscriber (if they interact directly) Manager (should be more specific) System Administrator Clerk Foreman
INFO 355 Week #2 18
External Systems
External systems are any non-human (generally computerized) actor which your system needs to perform one or more use cases Can be a Timer, to initiate
automatically repeating use cases Are systems you don’t control, and
are outside the scope of your system development
INFO 355 Week #2 19
External Systems
Could include systems owned by vendors E.g. a service to maintain your
online catalog Could be a custom legacy system
which isn’t being replaced E.g. an existing human resource
system, or accounting system
INFO 355 Week #2 20
System Boundary
The use case diagram includes a box to show the boundaries of your system Actors are not within the boundary External systems are not within
the boundary Box is labeled with your system’s name
(not just “System”) The use case diagram acts like a
context diagram
INFO 355 Week #2 21
Naming Use Cases
Each use case should have a brief name, typically 2-4 words
Start with a verb, and end with a noun Cancel Customer Order Place Order Validate New Customer
Number use cases sequentially
INFO 355 Week #2 22
Use Case Diagram Notation
Actors are represented by stick people, with their role below them
Use cases are represented by ovals External systems are represented
by rectangles, with “<<actor>>” before the system name “<<actor>>” is a stereotype The “<< >>” should be guillemets
INFO 355 Week #2 23
Sample Use Case Diagram
1. Process Sale
2. Handle ReturnsCashier
Payment Service
Sale Processing System<<Actor>>
Tax Calculator
<<Actor>>Accounting
System
Tip: Straight lines are easier to use!
INFO 355 Week #2 24
Use Case Diagram Notation
Lines connect actors to the use cases they can perform Hence a major purpose of the use
case diagram is to show what functions the system can perform, and who can use them
Notice there is no indication of when use cases are performed, or any of the logic behind them
INFO 355 Week #2 25
Generalization
A common concept for the use case diagram is when one actor has some special use cases, but also can do everything some other actors can A manager or supervisor can do
everything their staff can do, plus additional functions
Show this using generalization
INFO 355 Week #2 26
Notice the triangle at the top of the line between Manager and Staff This means that Manager inherits
all use cases which Staff can do (Also can use generalization in
Class diagrams) Helps keep use case diagram
simpler and easier to read
Generalization
Manager
Staff
INFO 355 Week #2 27
“Included” Use Cases
When documenting use cases, might find a clear set of activities that appears in two or more use cases
Can pull those activities out and make that an included use case In Visio, lines to an included use case
have the stereotype “<<uses>>” In other applications, stereotype is
“<<includes>>”
INFO 355 Week #2 28
The included use case is documented separately from the use cases which use it
“Included” Use Cases
Change ExistingOrder
Place Order
Sales Clerk
Validate CreditCard
«uses»
«uses»Use case
numbering and system boundary
omitted
Subsystem use case diagram
Ideally all actors and use cases should fit on one diagram
If not, it’s ok to have a separate use case diagram for each major subsystem Specify whether the diagram includes
all users (preferred) or a limited subset of them
INFO 355 Week #2 29
INFO 355 Week #2 30
Documenting Use Cases
Use cases can be documented to varying levels of detail
We’ll define two of them Casual use case documentation Detailed use case documentation
These are local terms for the level of documentation, not Cockburn’s (that’s pronounced CO-burn)
The text uses ‘Brief’ and ‘Fully developed’
INFO 355 Week #2 31
Casual Use Case Documentation
Consists of: Use case number and name Objective – A sentence to elaborate on
the main purpose of the use case Primary Actor – what actor initiates the
use case Main Success Scenario – a step-by-step
description of the events which should occur during this use case
INFO 355 Week #2 32
Detailed Use Case Documentation
Consists of: Use case number and name Objective Primary Actor Secondary Actor(s) – other actors who
play a significant role in this use case Trigger – what event forces the start of
this use case? Main Success Scenario (MSS)
INFO 355 Week #2 33
Detailed Use Case Documentation
Extensions – when performing the MSS, what other events could occur?
Extensions often include alternate methods of processing, different ways to do the same thing, and error conditions
Performance time – how long it should typically take to perform this use case
Frequency – how often will this use case be performed?
Open Issues – for scope issues, if any
INFO 355 Week #2 34
Beyond Detailed
The MSS and/or extensions should cite included use cases, where appropriate
Additional documentation is possible beyond the detailed template just given – see Cockburn’s site
INFO 355 Week #2 35
Main Success Scenario
The Main Success Scenario describes the interaction between actors and the system in order to perform a use case They are critical to write well, since
later documentation depends upon them (e.g. sequence diagrams)
See Summary of UML Diagrams handout for details on MSS writing
INFO 355 Week #2 36
Main Success Scenario
Where to begin? For most use cases, you can assume
the actor has logged into the system (if needed) and are starting at the application’s Main Menu or its equivalent
A MSS describes a use case in more detail than you would typically consider necessary
INFO 355 Week #2 37
Main Success Scenario
The MSS describes the most common way a use case will be performed successfully
If there are multiple processing options, pick the most frequent one for the MSS, and describe the rest in the Extensions
In the MSS, assume all actions will be successful; describe how to handle unsuccessful outcomes in the Extensions
The MSS is the Disney version of the use case
Extensions are the Tim Burton version
INFO 355 Week #2 38
Main Success Scenario
Typical actor activities in a MSS are: Navigate through the interface to a
defined objective “Shipping clerk navigates to the New
Shipment Screen.” Notice we didn’t say HOW they navigate,
just that it’s accomplished somehow Enter data onto an interface
“Shipping clerk enters the data for a new shipment.”
Notice every field entered is not specified
INFO 355 Week #2 39
Main Success Scenario
Describe when an actor selects something on an interface
“Dispatch manager selects the number of drivers needed.”
Indicate when an actor completes an activity, such as by submitting data
“Shipping clerk submits the new shipment data.”
This prompts the system to do something with the data
INFO 355 Week #2 40
Main Success Scenario
The only remaining type of actor action is to exit the application, which often isn’t part of a MSS (assume you can always cancel or exit from the system)
So there are few types of things an actor might do during a MSS
System actions can be much more complex
INFO 355 Week #2 41
Main Success Scenario
Typical system actions include: Create a new interface screen
“System displays Define Shipment screen.”
Change or update the contents of an existing screen
“System updates the screen to show the list of artifacts.”
INFO 355 Week #2 42
Main Success Scenario
Communicate with an external system “System gets current stock price from
NYSE.” “System emails drivers with shipment
info.” Perform an included use case
“System performs Validate Credit Card use case.”
Perform background processing “System validates new customer data.” “System computes the sales tax.”
INFO 355 Week #2 43
Main Success Scenario
Notice that the MSS includes steps which aren’t visible to the actors! Other background processing might
include “System prioritizes the list of drivers.” “System produces weekly sales
summary.” Background processing can include any
activity needed to prepare data for presenting the results to the actor
INFO 355 Week #2 44
Main Success Scenario
Finally, make sure a MSS achieves the overall objective of the use case!
“System saves new customer data.” “System updates order status.” “System deletes completed orders.”
These steps are typically performing one of the CRUD functions
INFO 355 Week #2 45
Main Success Scenario
Writing a MSS might involve making assumptions about where or how data is stored Can assume there is a place that stores
Customer Data, or Shipment Data, etc. External systems should be labeled
consistently throughout the design Can name interfaces (New Customer
Screen), but don’t design them (‘click on the submit button’ = no!)
INFO 355 Week #2 46
Main Success Scenario
Throughout a MSS, look for actions which need to be repeated
Specify in generic terms how many times steps need to be repeated For each book to be checked out, … For each driver assigned to a shipment, Repeat five times, or until login is
successful
INFO 355 Week #2 47
Extensions
Extensions, or alternate scenarios, handle when something doesn’t go normally during a use case Extensions are numbered, starting with
the MSS step from which they depart If an extension starts from step 5, the first
extension is a condition called 5.a Then the steps to respond to that
condition are 5.a.1, 5.a.2, etc. A second extension from step 5 is
condition 5.b and has steps 5.b.1, 5.b.2, 5.b.3, etc.
INFO 355 Week #2 48
Extensions Handle
So the lettered step (5.a) describes the condition under which you perform that extension
And the steps under it (5.a.1, 5.a.2, …) are the actor and system actions that follow
Optional processing steps can be an extension; the rest of the MSS isn’t affected if they aren’t used
Adding sales tax to an order Adding gift wrapping to an order
INFO 355 Week #2 49
Extensions Handle
Failure conditions – when a MSS step can’t be performed successfully
If a search yields no results If payment is insufficient Can’t connect to an external system
Alternate processing – when a MSS step can be processed differently
Handle domestic versus international orders
Handle different forms of payment
Extensions
Assume that interfaces and data transactions inside your system are successful, and won’t result in an extension, e.g. Saving or reading data locally Creating or updating interfaces
Otherwise every system step could be an extension!
INFO 355 Week #2 50