Creating Use Case for On-line Purchase System (OLP)

Order Items
Shipping
Process Order
Update Stock
(A2)
(A3)
<<include>>
Registration
Get Payment
By Road By Air
Create Order
Billing
<<include>>
<
<
in
c
lu
d
e
>
>
<<include>>
U1
U2
Manger
U3
U5
U6
U7
U9
U10
U
11 U
12
Inventory
System
Check In
<
<
e
x
te
n
d
>
>
[o
p
tio
n
=
n
e
w
]
U4
(A
12
) Staff
(A1)
(A
11
)
Customer
Other



Use case diagram for OLP

Order Items
Shipping
Process Order
Update Stock
(A2)
(A3)
<<include>>
Registration
Get Payment
By Road By Air
(A
12
)
Create Order
Billing
<<include>>
[delete]
<
<
in
c
lu
d
e
>
>
<<include>>
U1
U2
Manger
U3
U5
U6
U7
U9
U10
U
11 U
12
Inventory
System
Check In
<
<
e
x
te
n
d
>
>
[o
p
tio
n
=
n
e
w
]
U4
Staff
(A1)
(A
11
)
Customer
Other
Delete Order
<<extend>>
U8



Use case diagram of OLP with Delete Order


Use case: Order Items
Scenario 1: Option is new
Prompt for Registration
Call Registration // Extend Registration use case
Display registration status
Exit
Scenario 2:Option is login
Call Check In // Include Check In use case
Alternative 2.1: Login is valid
Prompt for Item Details
Call Create Order // Include Create Order use case
Display order status
Exit
Alternative 2.2: Login is invalid
Display login fail
Exit






Use case: Registration
Scenario 1: Customer is a staff member
Select customer type as staff.
Get data for a customer as staff.
Check the validity of the staff customer.
Alternative 1.1: Disqualify the validity of a staff
Message Registration fail.
Alternative 1.2: Qualify the validity of a staff
Check for already registered customer.
Alternative 1.2.1: Registration exist
Message Registration fail.
Alternative 1.2.1: Registration does not exist
Message Registration successful.
Create a new customer c.
Update record with c.
Scenario 2: Customer is other than staff
Select customer type as other.
Get data for a customer as other.
Check for already registered customer.
Alternative 2.1: Registration exist
Message Registration fail.
Alternative 2.2: Registration does not exist
Message Registration successful.
Create a new customer c.
Update record with c.



Use Case Template: Documenting Use Cases in the Use Case Model
Use cases are documented in the use case model following a use case template. The structure of
the use case template is shown below.

Use Case Template
Use Case Name Each use case is given a name.
Summary A brief description of the use case, typically one or two sentences.
Actors This section names the actors in the use case. There is always a primary
actor who initiates the use case. In addition, there may be secondary actors
who also participate in the use case.
Preconditions One or more conditions that must be true at the start of use case; for
example, the ATM machine is idle, displaying a welcome message.
Description The bulk of the use case is a narrative description of the main sequence of
the use case, which is the most usual sequence of interactions between the
actor and the system. The description is in the form of the input from the
actor, followed by the response of the system. The system is treated as a
black box, that is, dealing with what the system does in response to the
actors inputs, not the internals of how it does it.
Alternatives Narrative description of alternative branches off the main sequence. There
may be several alternative branches from the main sequence. For example,
if the customers account has insufficient funds, display apology and eject
card.
Postcondition Condition that is always true at the end of the use case if the main sequence
has been followed; for example, customers funds have been withdrawn.
Dependencies This optional section describes whether the use case depends on other use
cases, that is, whether it includes or extends another use case.
















Example:
Use Case Name
Borrow Book
Summary
This use case describes how a library user selects and then borrows a book
from the library.
Actors
Borrower
Preconditions
None
Description
1. The user selects the search function from the main menu.
2. The system displays the search form.
3. The user enters the title of a book (possibly using wild-cards).
4. The library system presents a list of all matching books
5. The user selects a book.
6. The system displays the detail view for this book.
7. The user selects borrow from the menu for this book.
8. The user is already logged in. The system issues a message to the
archive that the book is reserved for the user.
Alternatives 1
3.1 The user enters the name of the author.
3.2 The user selects the author from an author list.
3.2.1 The user clicks on select author.
3.2.2 The system displays a selection list of all authors.
3.2.3 The user selects an author from the list.
Alternatives 2
4.1 There are no matches to the query.
4.2 The system returns to the main screen.
Alternatives 3
8.1 The user is not logged in.
8.2 The user logs in as described in Log in.
Postcondition
The user is registered as the borrower of the book in the library system.
Dependencies
Log in


Use Case Name Log in
Summary
This use case describes how a library user logs into the system to prove his
identity.
Actors Borrower
Preconditions None
Description
1. The user selects log in from the main menu.
2. The system asks the user for his login name.
3. The user enters his login name.
4. The system asks the user for his password.
5. The user enters his password.
6. The system verifies login and password. They are ok.
7. The system logs the user on.
Alternatives 1
6.1 The combination of login and password is not valid.
6.1.1 If the number of retries is not exceeded, repeat the use case from
step 2.
Postcondition
The user is logged in.
Dependencies None
Practice: ATM System

1. PIN Validation
2. Query Account
3. Withdraw Money
4. Transfer fund









































Use Case: Withdraw Funds

Use Case Name: Withdraw Funds
Summary: Customer Withdraws a specific amount of funds from a valid bank account.
Actor: ATM Customer
Precondition: ATM is idle, displaying a Welcome message.
Description:
1. Customer inserts the ATM card into the Card Reader.
2. If the system recognizes the card, it reads the card number.
3. System prompts customer for PIN number.
4. Customer enters PIN.
5. System checks the expiration date and whether the card is lost or stolen.
6. If card is valid, the system then checks whether the user-entered PIN matches the card
PIN maintained by the system.
7. If PIN numbers match, the system checks what accounts are accessible with the ATM
card.
8. System displays customer accounts and prompts customer for transaction type:
Withdrawal, Query, or Transfer.
9. Customer selects Withdrawal, enters the amount, and selects the account number.
10. System checks whether customer has enough funds in the account and whether daily
limit has been exceeded.
11. If all checks are successful, system authorizes dispensing of cash.
12. System dispenses the cash amount.
13. System prints a receipt showing transaction number, transaction type, amount
withdrawn, and account balance.
14. System ejects card.
15. System displays Welcome message.

Alternatives:

If the system does not recognize the card, the card is ejected.
If the system determines that the card date has expired, the card is confiscated.
If the system determines that the card has been reported lost or stolen, the card is
confiscated.
If the customer entered PIN does not match the PIN number for this card, the system re-
prompts for the PIN.
If the customer enters the incorrect PIN three times, the system confiscates the card.
If the system determines there are insufficient funds in the customers account, then it
displays an apology and ejects the card.
If the system determines the account number is invalid, then it displays an error message
and ejects the card.
If the system determines the maximum allowable daily withdrawal amount has been
exceeded, it displays an apology and ejects the card.
If the ATM is out of funds, the system displays an apology, ejects the card, and shuts
down the ATM.
If the customer enters cancel, the system cancels the transaction and ejects the card.

Postcondition: Customer funds have been withdrawn.


Use Case: Query Account

Use Case Name: Query Account.
Summary: Customer receives the balance of a valid bank account.
Actor: ATM Customer
Precondition: ATM is idle, displaying a Welcome message.
Description:
1. Customer inserts the ATM card into the card reader.
2. If the system recognizes the card, it reads the card number.
3. System prompts customer for PIN number.
4. Customer enters PIN.
5. System checks the expiration date and whether the card is lost or stolen.
6. If card is valid, the system then checks whether the user-entered PIN matches the card
PIN maintained by the system.
7. If PIN numbers match, the system checks what accounts are accessible with the ATM
card.
8. System displays customers accounts and prompts customer for transaction type:
Withdrawal, Query, or Transfer.
9. Customer selects Query, enters account number.
10. System reads account balance.
11. System prints a receipt showing transaction number, transaction type and account
balance.
12. System ejects card.
13. System displays Welcome message.

Alternatives:
If the does not recognize the card, the card is ejected.
If the system determines that the card date has expired, the card is confiscated.
If the system determines that the card has been reported lost or stolen, the card is
confiscated.
If the customer-entered PIN does not match the PIN number for this card, the
system re-prompts for the PIN.
If the customer enters the incorrect PIN three times, the system confiscates the
card.
If the system determines the account number is invalid, it displays an error
message and ejects the card.
If the customer enters Cancel, the system cancels the transaction and ejects the
card.

Postcondition: Customer account has been queried.










Use Case: Transfer Funds

Use Case Name: Transfer Funds
Summary: Customer transfers funds from one valid bank account to another.
Actor: ATM customer
Precondition: ATM is idle, displaying a Welcome message.
Description:

1. Customer inserts the ATM card into the Card Reader.
2. If the system recognizes the card, it reads the card number.
3. System prompts customer for PIN number.
4. Customer enters PIN.
5. System checks the expiration date and whether the card is lost or stolen.
6. If card is valid, the system then whether the user-entered PIN matches the card PIN
maintained by the system.
7. If the numbers match, the system checks what accounts are accessible with the ATM
card.
8. System displays customer accounts and prompts customers for transaction type:
Withdrawal, Query, or Transfer.
9. Customer selects Transfer, enters amount, from account and to account.
10. If the system determines that the customer has enough funds in the from account, it
performs the transfer.
11. System prints a receipt showing transaction number, transaction type, amount transferred,
and account balance.
12. System ejects card.
13. System displays Welcome message.

Alternatives:
If the system does not recognize the card, the card is ejected.
If the system determines the card date has been expired, the card is confiscated.
If the system determines the card has been reported lost or stolen, the card is
confiscated.
If the customer-entered PIN does not match the PIN number for this card, the
system re-prompts for the PIN.
If the customer enters the incorrect PIN three times, the system confiscates the
card.
If the system determines that the from account number is invalid, it displays an
error message and ejects the card.
If the system determines that the to account number is invalid, it displays an error
message and ejects the card.
If the system determines there are insufficient funds in the customers from
account, it displays an apology and ejects the card.
If the customer enters cancel, the system cancels the transaction and ejects the
card.

Postcondition: Customer funds have been transferred.