21-May-15Software Engineering1 Use Case Analysis.

Apr 18, 2023 Software Engineering 1

Use Case Analysis


Use Cases in UML

UML provides a graphical representation for use cases called the use case diagram.

A Use Case Model consists of:– a use case diagram,– use case descriptions, …


Use Case Diagram - Example

Use Case Diagram: illustrates a set of use cases for a system.

Process sale

PaymentAuthorization

service

Manage securitySystem administrator

Cashier Handle returns

Process rental <<actor>>Tax calculator

Manage users

<<actor>>Accounting

system


ExtendsUse the extends relationship when you have a use case that is similar to another use case but does a bit more.

•In this example the basic use case is Capture deal.• In case certain limits for a deal are exceeded the additionaluse case Limits exceeded is performed.


Extends (2) Extensions are used instead of modeling every

extra case by a single use case. Extensions are used instead of creating a

complex use case that covers all variations. How do you address case variation?

• Capture the simple, normal use case first.• For every step in that use case ask: “What could go

wrong here?“• Plot all variations as extensions of the given use

case.


Uses(includes)

The uses relationship occurs when you have a chunk of behavior that is similar across several use cases.


Uses and Extends The similarities between extends and uses

are that they both imply factoring out common behavior from several use cases to a single use case that is• used by several other use cases or• extended by other use cases.

Apply the following rules:• Use extends, when you are describing a

variation on normal behavior.• Use uses when you want to split off repeating

details in a use case.


Actors and Use cases


More on Use Cases

Narrate use cases independent of implementation

State success scenarios (how do you determine the success of a use case).

A use case corresponds to one or more scenarios.

Agree on a format for use case description

Name a use case starting with a verb in order to emphasize that it is a process. “verb + noun phrase” (Buy Items, Enter an order, Reduce inventory)


More on Use Cases

Use cases drive the whole development process. Use cases are not object-oriented. Use cases represent an external view of the

system. Use cases should be written and named at the

domain level in requirements. Adjust the granularity of your use cases

according to the complexity of the individual problem you are working on, bearing in mind that• too many use cases can be overwhelming while• too few use cases may hide important details.


More on Use cases Use cases force one to look at exceptional as well as

normal behavior.– helps us to surface hidden requirements

Use cases can help formulate system tests.– “Is this use case built into the system?”

Use case templates facilitate interviewing and reviews.

Ease an iterative development lifecycle– levels of precision for a use case by refinement

Support an incremental development lifecycle– E.g. “Foobar” Release 1: use cases 1-20;

“Foobar” Release 2: use cases 1-29.


More on Use Cases Use Simple Grammar (active voice)

– GOOD “1. Actor requests System for rum-flavored popcorn.”

– BAD “1. The System was requested by the Actor for some of the rum-flavored variety of popcorn.”

Avoid "if" statements. Factor out into “alternative flows” instead.

Look for ways that each step in the basic flow can fail.

– a single step may have several alternatives

13

Summary One method to identify use cases is actor-based:

- Identify the actors related to a system or organization.- For each actor, identify the processes they initiate or participate in.

A second method to identify use cases is event-based: - Identify the external events that a system must respond to. - Relate the events to actors and use cases. The following questions may be used to help identify the use

cases for a system:- What are tasks of each actor ?- Will any actor create, store, change, remove, or read information in the

system ?- What use cases will create, store, change, remove, or read this

information ?- Will any actor need to inform the system about sudden, external

changes ? - Does any actor need to be informed about certain occurrences in the

system ?- Can all functional requirements be performed by the use cases ?

How it Fits TogetherPreliminary Investigation

Report

Prototypes

Budget, Schedule

Requirements Specification

Use-Case Diagram

Draft Conceptual Model

Use-Casesa. All High Levelb. Some Expanded

Glossary (data dictionary)


Exception handling

Document exception handling or branching

What is expected of the system when a “Buy Item” fails ?

What is expected of the system when a “credit card” approval fails ?


A sample Use Case

Use case: Buy ItemsActors: Customer, CashierDescription: A customer arrives at a checkout with

items to purchase. The cashier recordsthe purchase items and collects payment.On completion the customer leaves with items.


Developing a Use Case Ask yourself these questions:

- What are the main tasks or functions that are performed by the actor?

- What system information will the actor acquire, produce or change?

- Will the actor have to inform the system about changes in the external environment?

- What information does the actor desire from the system?

-Does the actor wish to be informed about unexpected changes?


Use Case Description

It includes– How the use case starts and ends– The context of the use case– The actors and system behavior described

as intentions and responsibilities– All the circumstances in which the primary

actor’s goal is reached and not reached– What information is exchanged


Ranking Use Cases Use some ordering that is customary to your

environment Example: High, Medium, Low Example: Must have, Essential, Nice to have

Useful when deciding what goes into an increment

POST example: Buy Items - High Refund Items - Medium (Why?) Shut Down POST terminal - Low


Ranking the Use cases The developers should consider the architectural

risk. Do not omit use cases which later cause you to do a lot of

rework to fit them in. Concentrate to the use cases which are technologically

most challenging.

The developers should be aware of the schedule risks.

“I’m pretty sure I know how long it will take.” “I can estimate the time only to the nearest man-month.” “I have no idea.”


Use Cases vs. Feature Lists

Feature Lists: “the system shall…” More traditional approach Less preferable for user-oriented s/w

Only mention function, not flow If flows are written elsewhere, then

redundant = hard to maintain in parallel High-level feature lists are okay

Include in Vision document “executive summary of use cases”


Format – Example (Fully Dressed)

Use Case: Primary Actor: Stakeholders & Interests: Preconditions: Postconditions (Success Guarantee): Main Success Scenario (or Basic Flow): Actor Action System Responsibility 1. This use case begins with... 2. The system does this 3. The actor does this Extensions (or Alternative Flows): Special Requirements: Technology & Data Variations List: Frequency of Occurence: Open Issues:


Use Case Example Use case name: Login Goal: Authenticate user Precondition: System is ready Postcondition: User is logged in Actors: User Triggering event: User requests login Description: User supplies username and password. If

the username is known and the password is valid, the user is logged in.

Alternatives: 1) User name is not valid: Retry getting user name up to three times, then report failure, record error, and wait one minute before allowing next login.2) Password is not valid: Retry getting password up to threetimes, then report failure, records error and wait one minute beforeallowing next login.


Use Case Example Use Case: Deposit Money Scope: Bank Accounts and Transactions System Level: User Goal Intention in Context: The intention of the Client is to deposit

money on an account. Clients do not interact with the System directly; instead, for this use case, a Client interacts via a Teller. Many Clients may be performing transactions and queries at any one time.

Primary Actor: Client Basic Flow:

1. Client requests Teller to deposit money on an account, providing sum of money.


Contd…2. Teller requests System to perform a deposit, providing deposit

transaction details.3. System validates the deposit, credits account with the

requested amount, records details of the transaction, and informs Teller.

Alternative Flows:

3a. System ascertains that it was given incorrect information:3a.1. System informs Teller; use case continues at step 2.

3b. System ascertains that it was given insufficient information to perform deposit:

3b.1. System informs Teller; use case continues at step 2.

26

Each use case may include all or part of the following: Title or Reference Name - meaningful name of the UC Author/Date - the author and creation date Modification/Date - last modification and its date Purpose - specifies the goal to be achieved Overview - short description of the

processes Cross References - requirements references Actors - agents participating Pre Conditions - must be true to allow execution Post Conditions - will be set when completes normally Normal flow of events - regular flow of activities Alternative flow of events - other flow of activities Exceptional flow of events - unusual situations Implementation issues - foreseen implementation problems

Use Case Description

27

Example- Money Withdraw Use Case: Withdraw Money Author: ZB Date: 1-OCT-2004 Purpose: To withdraw some cash from user’s bank account Overview: The use case starts when the customer inserts

his credit card into the system. The system requests the user PIN. The system validates the PIN. If the validation succeeded, the customer can choose the withdraw operation else alternative 1 – validation failure is executed. The customer enters the amount of cash to withdraw. The system checks the amount of cash in the user account, its credit limit. If the withdraw amount in the range between the current amount + credit limit the system dispense the cash and prints a withdraw receipt, else alternative 2 – amount exceeded is executed.

Cross References: R1.1, R1.2, R7

28

Example- Money Withdraw (cont.) Actors: Customer Pre Condition:

The ATM must be in a state ready to accept transactions The ATM must have at least some cash on hand that it can

dispense The ATM must have enough paper to print a receipt for at

least one transaction Post Condition:

The current amount of cash in the user account is the amount before the withdraw minus the withdraw amount

A receipt was printed on the withdraw amount The withdraw transaction was audit in the System log file

29

Example- Money Withdraw (cont.)

Typical Course of events:

Actor ActionsActor Actions System ActionsSystem Actions

1. Begins when a Customer arrives at ATM1. Begins when a Customer arrives at ATM

2. Customer inserts a Credit card into ATM2. Customer inserts a Credit card into ATM 3. System verifies the customer ID and status3. System verifies the customer ID and status

5. Customer chooses “Withdraw” operation5. Customer chooses “Withdraw” operation 4. System asks for an operation type4. System asks for an operation type

7. Customer enters the cash amount7. Customer enters the cash amount 6. System asks for the withdraw amount6. System asks for the withdraw amount

8. System checks if withdraw amount is legal8. System checks if withdraw amount is legal

9. System dispenses the cash9. System dispenses the cash

10. System deduces the withdraw amount from 10. System deduces the withdraw amount from accountaccount

11. System prints a receipt11. System prints a receipt

13. Customer takes the cash and the receipt13. Customer takes the cash and the receipt 12. System ejects the cash card12. System ejects the cash card

30

Example- Money Withdraw (cont.)

Alternative flow of events: Step 3: Customer authorization failed. Display an

error message, cancel the transaction and eject the card.

Step 8: Customer has insufficient funds in its account. Display an error message, and go to step 6.

Step 8: Customer exceeds its legal amount. Display an error message, and go to step 6.

Exceptional flow of events: Power failure in the process of the transaction

before step 9, cancel the transaction and eject the card


Exercise Example: Home Security System

(SafeHome) Project Brief (provided at the start of the

project):- Build a micro-processor based home security system

that will protect against and/or recognize a variety of undesirable situations such as illegal entry, fire and flooding.

- The product will use appropriate sensors to detect each

situation, can be programmed by the homeowner andwill automatically telephone a monitoring agency whennecessary.


Actors and Interactions Actor:

- homeowner (the user)- sensors (devices attached to the system)- monitoring and response subsystem (central station

that monitors SafeHome) Interactions:

- Enters a password to allow all other interactions. This password needs to be validated by the system

- Inquires about the status of a security zone which relies on the status of a combination of sensors

- Inquires about the status of a sensor- Presses the panic button in an emergency- Activates/deactivates the security system

21-May-15Software Engineering1 Use Case Analysis.

Documents

Transcript of 21-May-15Software Engineering1 Use Case Analysis.