AUInterface Design,

Use Case Scenarios,Test Cases

& Project Issues

Professor J. Alberto Espinosa

Business Analysis & Data Design ITEC-630 Fall 2008

2

Objectives

Discuss interface design issues Discuss instance scenarios Discuss test cases Briefly discuss non-functional requirements Discuss project issues

3

Interface Design

4

A DefinitionInterface: “The place at which independent and often unrelated systems meet and act on or communicate with each other” – Webster dictionary

Software

Network

Software

Hardware UserSystem

5

ATM System

Customer

Bank Manager

ATM Service Rep

Customer Accounts System

Withdraws Funds

Makes Deposits

Manages Account

Inquires CustomerActivity

Monitors ATMStatus

Replenishes Cash

Upload CustomerTransaction

Data

Use Case Diagram w/o Interfaces

6

Use Case Diagram w/Interfaces #1ATM System

Customer

Bank Manager

ATM Service Rep

Customer Accounts System

Withdraws Funds

Makes Deposits

Manages Account

Inquires CustomerActivity

Monitors ATMStatus

Replenishes Cash

Upload CustomerTransaction

Data

WithdrawalInterface

Deposit Interface

AccountManagement

Interface

Customer ActivityInquiry Interface

ATM StatusMonitor Interface

CashReplenishment

Interface

CustomerAccounts System

Interface

7

Use Case Diagram w/Interfaces #2

ATM System

Customer

Bank Manager

ATM Service Rep

Customer Accounts System

Withdraws Funds

Makes Deposits

Manages Account

Inquires CustomerActivity

Monitors ATM Status

Replenishes Cash

Upload CustomerTransaction Data

Customer Interface

Customer Activity Inquiry Interface

ATM Status Monitor Interface

Cash Replenishment

Interface

Customer Accounts System

Interface

8

Use Case Diagram w/Interfaces #3

ATM System

Customer

Bank Manager

ATM Service Rep

Customer Accounts System

Withdraws Funds

Makes Deposits

Manages Account

Inquires CustomerActivity

Monitors ATM Status

Replenishes Cash

Upload CustomerTransaction Data

Withdrawal Interface

Deposit Interface

Account Management

Interface

Customer Activity Inquiry Interface

Cash Replenishment

Interface

Customer Accounts System

Interface

ATM Monitoring Interface

9

List of Interfaces

Interface Name Actor

Funds Withdrawal User

Funds Deposit User

Account Management User

Customer Activity Inquiry User

ATM Status Monitor User

Cash Replenishment User

Customer Accounts System System

10

If the actor is a user: The interface captures how the user interacts

with the system

If the actor is a system: The interface will contain the program

commands our system needs to interact with that external system

11

Each Interface Has:

A name A set of “operation signatures” indicating:

– which data to “get” from the actor with the operation (i.e., Get UserId, Name, etc.)

– Which data to “return” to the actor when the operation is complete

A storyboard (for user interface only): visual illustration of the sequence of screen designs to complete these operations

12

Example of Operation Signatures: Funds Withdrawal Interface

Get data from card magnetic tapeGet pass code from customer

Get customer transaction selection(user selects withdrawal)

Get account type for withdrawal Get amount to withdraw Return cash, or Return error message to customer Return thank you message to customer

13

A User Interface Can Be For: Input into the system by the user for

data entry or to query information from the system

A display output (on screen or other output device) by the system to the user

A printed output (on a printer or other output device)

14

Diagramming the Interface: with “Storyboards”

User interfaces can be diagrammed as “storyboards”

A storyboard is a series of drawings that depict how the system looks at the start of the operation and after each significant change to the look of the interface

Is like a sequence of screenshots that follows the use case execution sequence

15

Organization of a Storyboard

Storyboard Sequence

16

Bad Interface Design:

17

What to Include in an Interface Design Specification A list of all the interfaces between actors and use cases

For each interface (any actor – user or external system):– Indicate whether the actor is a user (human actor) or an external

system– Prepare a list of operation signatures detailing all the data that is

passed to/from the system before each operation and the data that is returned from/to the system after each operation

For users (human actors only):– Indicate when/if operations are taking place for data input, display

outputs or printed outputs– Prepare a storyboard for all screen input/output displays and printouts– Design the visual interface for all screen input/output displays and

printouts

For external system actors (only):– Indicate when/if operations are taking place to input or output data

from/to the system

18

General Quality Attributes of a User Interface Design Ease of use Intuitive use and navigation Consistency across screens Simplicity – e.g., no clutter, no information overload, no

busy graphics Exit/cancel options for users Forgiving Businesslike appearance Readable and good color contrast Reference sites:

Cornell Univ: http://ergo.human.cornell.edu/ahtutorials/interface.htmlVirginia Tech: http://www.edtech.vt.edu/edtech/id/interface/Carnegie Mellon: http://www.usernomics.com/user-interface-design.html

AUUse Case Scenarios

20

Instance Scenarios• Are examples (i.e., paper prototypes) of how a Use Case will

execute in a given situation• Per UML 1.3: “performance of a Use Case, initiated by a

message instance by an instance of an actor”• They may represent a path (sunny day or rainy day) in the Use

Case Flow of Events• Or specific instance within one of these paths• Experienced analysts prefer to keep Use Cases simple with low

level of detail, so that they are easy to understand.• And complement them with instance scenarios that can help

explore and gain more detailed insights into the Use Cases• They are particularly useful in modeling exceptions• Best candidates for instances: extreme values, exception

conditions, and borderline conditions

21

Instance Scenarios

Use Case InstanceScenarios

UC 101

UC 101-IaInput Parameters

Output Parameters

UC 101-IbInput Parameters

Output Parameters

UC 101-IcInput Parameters

Output Parameters

Conditions

Conditions

Conditions

22

Example:Use Case

Use Case ID UC-100

Use Case Withdraw Funds

Actors (P) Customer

Description Customer logs in, selects withdraw funds, enters amount, gets cash

Pre-conditions Welcome screen is on

Flow of Events 1.Customer slides card in and out2.Machine prompts customer for password3.Customer enters password4.System authenticates customer5.System presents user with a choice menu6.Customer selects Withdraw Funds option7.System asks customer to select account8.Customer selects account9.System asks customer for amount to withdraw10.Customer enters amount11.System dispenses cash and prints receipt12.System logs customer out

Post-conditions Welcome screen is back on

Alternative Flows

customer may not have sufficient funds; machine may not have enough cash

Etc.

23

Example:InstanceScenario

Use Case ID UC-100-IS1

Use Case Withdraw Funds

Instance Name Attempt to withdraw with no funds in the account

Description Customer logs in, selects withdraw funds, enters amount, but does not get cash due to insufficient funds.

Input Parameters

Withdrawal of $300 requested from checking account; there are only $100 available in the account’s balance

Instance Flow 1.Customer slides card in and out2.ATM prompts customer for password3.Customer enters the correct password4.The system authenticates the customer and presents menu choice5.The customer selects the Withdraw Funds option6.System prompt customer to select account7.The customer selects checking account8.System asks for amount to withdraw9.The customer enters $30010.Inquire account balance – return $10011.Display message about insufficient funds12.Print statement of account balances13.Prompt customer to (a) withdraw a different amount or (b) exit14.If (a), go back to step 6

Output Parameters

A printout with account balances

Environmental Conditions

ATM machine has cash

24

Submit Loan Request

Evaluate Loan Request

Request Info on Loan Program

Enter Credit References

Generate Approval Letter

Generate Loan Agreement

Book New Loan

Loan Submission and Origination (see slide 9)Using an Activity Diagram to Model Use Case Sequence

Begin Loan Origination

Proceed to Loan Account Maintenance

Multiple Use Case Scenarios – e.g., new loan process

AUTest Cases

26

TestingEnsuring that the system performs as required

Test types: UNIT TESTING:

Ensure that each part of the system work well individually SYSTEM TESTING:

Ensure that all the parts work well together REGRESSION TESTING:

Ensure that new software work well with the existing software ACCEPTANCE TESTING: By users and/or clients

Methods: BLACK BOX TESTING: Testing if the system does what is

supposed to, without inspecting the internals of the system CLEAR BOX TESTING: Inspecting and testing the internals of

the system (opening the black box)

Test cases are useful for

27

Test Cases• Each Use Case should have a “test suite”

associated with it• Each test case in the suite represent a path in

the Use Case Flow of Events• Ideally, each path should have a test case

(difficult with large complex systems)• Pay attention to borderline conditions

(e.g., customer withdraws maximum allowable cash, customer withdraws all funds available), which is usually where software fails

28

Prompt for password

Enter password

PasswordCorrect?

Welcome screen is on

Yes

Third miss?No

Yes

No

Retain card

Notify user

Authenticate user

Present menu choice

Select wthdraw funds

Select amount

Enoughfunds?

Yes NoNotify User

Enoughcash inATM?

No

YesNotify User

Notify ATM Service

Update Balance

Dispense Cash

Log Out

Welcome screen is on

Test SuiteExample:Withdraw CashUse Case

Path 1

Path 2

Path 3

Path 4

Path 5

A

S

E

E

SE

SE

S

S

A

A

S

S

SESE

SE

S

E

E

A = Input or other action from an ActorS = An action performed by the systemE = An exception (e.g., conditional flow)

29

Test Cases

Use Case Test Suite

UC 101

UC 101- Path 1Pre-conditions

Post-conditions

UC 101- Path 2Pre-conditions

Post-conditions

UC 101- Path 3Pre-conditions

Post-conditions

30

Example:Test Case for Path 2

Use Case ID UC-100-Path 2

Use Case Withdraw Funds

Actors (P) Customer

Description Customer logs in, selects withdraw funds, enters amount, customer has fund, ATM has no cash

Pre-conditions Welcome screen is on

Flow of Events A1. Customer slides card in and outS1. Machine prompts customer for passwordA2. Customer enters passwordS2. System authenticates customerS3. System presents user with a choice menuA3. Customer selects Withdraw Funds optionS4. System asks customer for amount to withdrawA4. Customer enters amountS5. System verifies that customer has fundsS6. System checks cash in ATM machineE1. ATM has no cash SE1. Notify customer SE2. Notify ATM serviceS7. Logout customer

Post-conditions Welcome screen is back on

Alternative Flows

Etc.

AUDocumentation

32

Documentation• Use cases map directly to events that users will be

engaged in• And to events in which external systems will interact with

the system• So Use Cases can be used as the base to provide

documentation for users• And for the interface with external systems• These documentation can be written to mirror Use Case,

but perhaps with more user-friendly language, or• In the case of external system interfaces, with more

technical language that relates to that system (e.g., TCP/IP connection, accounting system, etc.)

AUProject Issues

34

The System Project and the UP

35

The Project Plan It is based on iterations, per the UP Define the iteration length Develop a domain model early Analyze, design, build, integrate, and test often Estimate how many (fixed-length) iterations

you will need for construction Decide the order in which things will be built

based on Use Case priorities Try to build the core functionality of the product

early (or at least prototype it)

36

Estimating Project Effort Estimate the number of lines of code (LOCs)

– Difficult to estimate upfront– Depends on the software language used– Not great for object-oriented systems & CASE tools

Constructive Cost Model (COCOMO)– A popular method– Effort estimation based on LOCs estimated– Same difficulties as with LOCs estimation

Use Case Points (UCP)– Similar to function points, but based on Use Case metrics

Function Points (FP)– Estimating effort based on what the software does, not LOCs– Every software function (e.g., a display, report, a data store)

has a function count– Then adjusted to function points based on complexity factors

37

Use Case Points (UCP) (Rational Software – a new way of estimating effort) Count Actors and multiply by their weight:

– 1 for a simple actor (an external system with a well defined interface)

– 2 for an average actor (an external systems with less defined interface or a person using a simple interface)

– 3 for a complex actor (people using a more complex graphical interface)

Count Use Cases and multiply by their weight– 5 for simple Use Cases (3 transactions or less)– 10 for average Use Cases (4-7 transactions)– 15 for complex (more than 7 transactions)– A transaction is a set of Use Case steps performed

entirely or not at all (i.e., number of paths) Unadjusted Use Case Points (UUCP) Adjust for complexity and environmental factors

38

Calculate the Technical Complexity Factor (TCF)Factor Description Weight

Rating0: Irrelevant5: Essential

WeightedRating

T1 Distributed system 2

T2 Response performance objectives 1

T3 End-user efficiency 1

T4 Complex internal processing 1

T5 Code must be reusable 1

T6 Easy to install 0.5

T7 Easy to use 0.5

T8 Portable 2

T9 Easy to change 1

T10 Concurrent 1

T11 Secure 1

T12 Access to 3rd parties 1

T13 User training facilities 1

TFactor = Sum of weighted ratings

TCF = 0.6 + (0.01 * TFactor)

39

Calculate the Environmental Factor for the Team (EV)

Factor Description WeightRating0: none

3: average5: expert

WeightedRating

F1 Familiar with Rational UP 1.5

F2 Application experience 0.5

F3 Object-oriented experience 1

F4 Lead analyst capability 0.5

F5 Motivation 1 0: none5: highest

F6 Stable requirements 2 0: unstable5: very stable

F7 Part-time workers -1 0: none5: all

F8 Difficult programming language -1 0: easy5: hardest

EFactor = Sum of Weighted ratings

EV = 1.4 + (-0.03 * EFactor)

Use Case Points (UCP) = UUCP * TCF * EV

40

FYI Only: Function Points (FP) The traditional way of estimating effort Count:

– Number of user inputs– Number of user outputs– Number of user inquiries– Number of files– Number of external interfaces

Function Count = weight these counts based on their complexity and add them up

Function Points (FP) = adjust for other complexity factors

41

Function Count (FC)

Item Description Count x

Weight

=Weighted

CountSimple Avg Complex

Number of user inputs 3 4 6

Number of user outputs 4 5 7

Number of user inquiries 3 4 6

Number of files 7 10 15

Number of external interfaces 5 7 10

Total Weighted Function Count (FC)

42

Complexity Factor (CF) and Function Points (FP)Factor Description

Rating0: Irrelevant5: Essential

F1 Reliability and backup recovery

F2 Data communications

F3 Distributed processing

F4 Performance

F5 Operate on existing system

F6 On-line data entry

F7 Data entry over multiple screens

F8 Master files updated on-line

F9 Complex inputs, outputs, files & inquiries

F10 Complex internal processing

F11 Code needs to be reusable

F12 Need conversion and installation

F13 Multiple installations of the system

T14 Easy to change and use

Complexity Factor (CF) = sum of ratings

Function Points (FP) = FC x (0.65 + 0.01 x CF)

43

Estimate Effort and Cost from Experience

Project UCP’s FP’s LOCsEffort

(Person-Days

Cost per Person-

Day

TotalCost

ATM System 60.22 45.22 xx 362 $1,200 $434,400

Loan Processing System 82.34 53.21 xx 443 $1,200 $531,600

Order Processing System 95.20 65.22 xx 563 $1,200 $675,600

Point of Sale System 110.65 78.44 xx 615 $1,200 $738,000

Etc.

……… ….. ….. …. …. ….. ….

New project (est.) 134.30 108.77 xx xx $1,200 xx