Ooad 02 Uml UseCases
Ooad 02 Uml UseCases
Ooad 02 Uml UseCases
Use-Cases: an Example
My system
register
Administrator
create new course
Instructor
delete offering
actors
use cases
A use case gathers the scenarios related to the (primary) actors goal Actors are the people and/or computer systems that are outside the system under development (SuD)and interact with it:
Primary actor a stakeholder who requests that the system deliver a goal Supporting/secondary actor an external system against which the SuD has a goal
Actors
An actor is an entity that is outside of the system Actors will interact with the system: an actor will often request the system to perform some actions on behalf of the actor an actor may also receive responses from the system An actor plays a role in the use of the system the name given to an actor is usually the role name: for example, an actor who is a Person will usually be called a User, Operator, Administrator, or something like that each role might be treated as a different actor in the use cases
Goals
A goal is a result that one of the actors wants to achieve Example goals: An administrator wants to add a new user to the system A pilot wants to land a plane A customer wants to file a claim on an insurance policy A service person wants to file a trouble report
Scenarios
A scenario is a little story it is an outline of some expected sequence of events A scenario is used to convey the fundamentals of how things work It usually includes at least one actor Each actor can make requests of the system or respond to system activity
Yes.
That will be $7.40. Here is $10. Thanks. Here are your stamps and your change.
Identifying actors
An Automated Teller Machine (ATM) permits customers to withdraw money from their accounts, make deposits, and check their account balances. The ATM machine communicates with a computer system in the banks central office to validate passwords and account information. The ATM is serviced on a regular basis by bank employees, to collect deposit envelopes and to load in more cash and receipt paper. Question: who are the actors in this system?
ATM
Scenario - Example
A scenario is a little story It describes one possible course of events:
Customer puts ATM card into machine and types password System validates the card and password System prompts the customer for a transaction type and amount Customer selects withdraw $100 from checking System checks with the central bank make sure customer has sufficient funds System dispenses the cash, returns card, and prints receipt System asks customer if he/she would like another transaction
Tables informal text Structured templates one popular example (A. Cockburn) Structured (semi-formal) DOORS template
Graphical formats:
UML Use Case diagrams capturing the system boundary, use cases(names), actors, channels and use case relationships UML Sequence Diagrams (also known as message sequence charts, MSC) to represent scenarios
Object Oriented Analysis & Design
one important thing that is not included in the description of each step of a scenario: how the operation is performed (this is left for the design phase) Important style points: each step in the scenario must have a subject (either the system or an actor is performing the step) no passive or impersonal voice allowed (e.g., the results are displayed)
Postal clerk
Alternative format for a scenario: UML Sequence Diagram (also known as Message sequence chart) Note: the scenario explains what happens but not how it happens (that will be in the design)
Sell me a ticket Prompt for lucky number Number choice Prompt for $1 Insert $1 Dispense ticket
from some failures, the system can recover from other failures, the use case will fail
Variations
A variation is a way to avoid scenario explosion A variation is a list of alternatives that is tied to a specific line of a scenario Each variation could turn into a lower-level scenario An example variation (for the post office scenario):
1. Item is a. stamps b. postage on an item that the customer is mailing c. postage due on an item that the customer is receiving d. post office box rental e. mugs, t-shirts, and other Postal Service merchandise 6. Payment is a. ______________ b. ______________ c. ______________
Main scenario: 1. Customer asks for an item 2. Postal clerk acknowledges customer request, checks if the requested item is available 3. Postal clerk asks the Customer if there will be anything else in this transaction 4. Customer indicates that they dont want anything else 5. Postal clerk determines the price of the requested items and tells the customer 6. Customer pays 7. Postal clerk gives the Customer the items and change
Extensions
An extension is a short scenario that branches off from another scenario Extensions are used to describe recovery actions when something goes wrong extensions might rejoin the main scenario or extensions might just terminate because the goal cant be achieved An example extension (for the post office scenario):
2a. Item is not available: 2a1. Postal clerk looks for an equivalent item 2a2. If an equivalent item is found, the Postal clerk asks customer if the equivalent item is OK
Main scenario: 1. Customer asks for an item 2. Postal clerk acknowledges customer request, checks if the requested item is available 3. Postal clerk asks the Customer if there will be anything else in this transaction 4.
Chunks
A chunk is a sub-scenario - a sequence of messages that appears in several scenarios for one or more use cases. A chunk is a scenario that addresses a specific subgoal
for example: logging in, searching for a specific product, etc.
They are the subroutines of the use case family They may express some common user interface subscenarios Alistair Cockburn calls them subfunctions (but we dont want to think of them as associated with low-level code)
check balance
Bank Employee service ATM
Employee
Security Guard
test alarm
Repair Person
boundary/interface
actor
persons & roles
control
entity
passive objects data stores
extends
make an interview
extends
variation of a use-case points to the standard use-case
uses
produce a SRS
anybody
clerk
traveler
book a flight
uses
clerk extends Pay a bill
prepare-travel
Object Oriented Analysis & Design
Sub-functions under water not a real user goal: these scenarios describe common suboperations
uc-1
uc-2 uc-3 uc-4
uc-4.1 uc-4.2
Object Oriented Analysis & Design
Customer
Administrator
Repair person
Step 4: Review the use cases with customer (or customer surrogate)
Step 7: Internal review review the scenarios and failure branches with testers, developers, project managers Ongoing: make links to other requirements, update use case model as needed define the business rules and non-functional requirements (in text documents, with links to the use case model) add new use cases and new scenarios for new actors and goals; new variations for existing use cases
Object Oriented Analysis & Design
Architecture
make better architectural decisions use the high-runner, high-priority scenarios to assess candidate architectures
Project management
use cases can help to plan an iterative development process
Test
update the tests as the requirements change
Object Oriented Analysis & Design
Architects: benefit from using the most important failure scenarios to evaluate the architecture Development managers: iterative and incremental development can start with the high-priority use cases focus on the scenarios that deliver the maximum value to customers Developers: code inspections can narrow the focus on the most important scenarios Testers: integration and system tests are guided by the use cases
Object Oriented Analysis & Design
Use cases are usually about 1/3 of the total volume of requirements The use cases are supplemented by other kinds of requirements information
Business Rules: conditions, policies, and conventions Operational Profiles: how many scenarios Architectural Requirements: -ilities (reliability, usability, performance)
Business Rules BR1. Each employee has a unique identification number. BR2. Each open-door request is logged. Operational Profiles OP1. During the busy hour (8-9am), the system should be able to handle 500 open-door requests (UC1 sunny-day). OP2. The test alarm use case will be executed every weekend. Architectural Requirements AR1. Maximum time to process an open-door request is 15 seconds. AR2. No more than 5 minutes downtime per year.
References
Books:
Alistair Cockburn, Writing Effective Use Cases Daryl Kulak and Eamonn Guiney, Use Cases: Requirements in Context Steve Adolph and Paul Bramble, Patterns for Effective Use Cases Kurt Bittner and Ian Spence, Use Case Modeling
Web sites:
http://www.usecases.org http://agilealliance.org http://members.aol.com/acockburn http://members.aol.com/acockburn/papers/usecases.htm
Extra ...
Summary
Industry data:
Use cases improved developer productivity by 40% (DaimlerChrysler) 35% increase in developer productivity at Merrill Lynch achieved through: Tool-based Requirements Management and Use cases
Useful books
Writing Effective Use Cases by Alistair Cockburn Patterns for Effective Use Cases by Steve Adolph and Paul Bramble Use Case Modeling by Kurt Bittner and Ian Spence