FDU

Online Banking
Final Project
Nicholas Mitricka and Vaibhav Patel
Problem Statement......................................................................................................4
Analysis Model............................................................................................................5
Scenario - Login.....................................................................................................................5
Scenario - AddPayee..............................................................................................................9
Scenario - SchedulePayment................................................................................................11
Scenario - ModifyPayment...................................................................................................13
Scenario - DeletePayment....................................................................................................16
Scenario - DeliverPayment...................................................................................................17
Use Case - Login...................................................................................................................19
Use Case - AddPayee...........................................................................................................20
Use Case - SchedulePayment...............................................................................................21
Use Case - ModifyPayment..................................................................................................23
Use Case - DeletePayment...................................................................................................24
Use Case - DeliverPayment..................................................................................................25
Sequence Diagrams – Login.................................................................................................26
Sequence Diagrams – AddPayee..........................................................................................27
Sequence Diagrams – SchedulePayment..............................................................................28
Sequence Diagrams – ModifyPayment................................................................................29
Sequence Diagrams – DeletePayment.................................................................................30
Sequence Diagrams – DeliverPayment.................................................................................31
State Diagram - Account......................................................................................................32
State Diagram – Customer...................................................................................................32
State Diagram – Payment....................................................................................................33
State Diagram – Payee.........................................................................................................33
Class Diagram......................................................................................................................34
Object Diagram....................................................................................................................35
Class Details.........................................................................................................................36
System Design............................................................................................................37
Design Goals........................................................................................................................37
Subsystem and Software Architecture.................................................................................37
Deployment Diagram...........................................................................................................38

1|Page
 Access Control.....................................................................................................................38
Strategies for Global Control................................................................................................39
Boundary Use Case..............................................................................................................39
Object Design.............................................................................................................40
Design Pattern Strategy.......................................................................................................40
Interface Specifications – Invariants....................................................................................41
Interface Specifications – Preconditions..............................................................................42
Interface Specifications – Post conditions............................................................................43

2|Page
Problem Statement
During a person’s normal life, they accumulate some amount of bills that

need to be paid on a monthly basis. Therefore, people are required to obtain

numerous letters in the mail, write out checks, mail checks, etc. This can cause

confusion, late fees, and an exuberant amount of wasted paper. Solutions to

these issues are provided by many banks to customers that have a savings

and/or checking account.

Bank customers are writing out physical checks that can cause a person

large amounts of confusion. Due to this confusion, there is a possibility of

payments not being sent on time, payments being sent to the wrong payee and

writing checks for more than what is in their checking account. Therefore,

customer’s need a system that will allow them to:

 Add payees under their account

 Schedule payments to be send to the added payee

 Ability to modify or delete the payment before it is delivered

 Automatically deliver the payment to the requested payee

3|Page
Analysis Model
Scenario - Login

Scenario Name :Login

Participating Action Instance Bill:Customer
Flow Of Events 1. Bill activates the “Login” function of the system
by going to the login page
2. Bill enters “[email protected]” as his user name
3. Bill enter “123Bill” as his password
4. Bill clicks on the button labeled “login”
5. System displays “Welcome Bill” message

Scenario Name :Login

Participating Action Instance Bill:Customer
Flow Of Events 1. Bill activates the “Login” function of the system
by going to the login page
2. Bill enters “[email protected]” as his user name
3. Bill enter “123Billlll” as his password
4. Bill clicks on the button labeled “login”
5. System displays “Incorrect User Name or
Password”

Scenario Name :Login

Participating Action Instance Bill:Customer
Flow Of Events 1. Bill activates the “Login” function of the system
by going to the login page
2. Bill enters “[email protected]” as his user name
3. Bill enter “” as his password
4. Bill clicks on the button labeled “login”
5. System displays “Missing information. Please fill
in the required field”

4|Page
Scenario Name :Login
Participating Action Instance Bill:Customer
Flow Of Events 1. Bill activates the “Login” function of the system
by going to the login page
2. Bill enters “[email protected]” as his user name
3. Bill enter “23232323” as his password
4. Bill clicks on the button labeled “login”
5. System displays “Account has been locked due to
incorrect password”

Scenario Name :Login

Participating Action Instance Bill:Customer
Flow Of Events 1. Bill activates the “Login” function of the system
by going to the login page
2. Bill enters “[email protected]” as his user name
3. Bill enter “23232323” as his password
4. Bill clicks on the button labeled “canceled”
5. System displays “Login Canceled”

Scenario Name :Login

Participating Action Instance Sue:Employee
Flow Of Events 1. Sue activates the “Login” function of the system
by going to the login page
2. Sue enters “[email protected]” as his user name
3. Sue enter “1234Suse” as his password
4. Sue clicks on the button labeled “login”
5. System displays “Welcome Sue!”

5|Page
Scenario Name :Login
Participating Action Instance Sue:Employee
Flow Of Events 1. Sue activates the “Login” function of the system
by going to the login page
2. Sue enters “” as his user name
3. Sue enter “1234Suse” as his password
4. Sue clicks on the button labeled “login”
5. System displays “Missing information. Please fill
in the required field”

Scenario Name :Login

Participating Action Instance Sue:Employee
Flow Of Events 1. Sue activates the “Login” function of the system
by going to the login page
2. Sue enters “[email protected]” as his user name
3. Sue enter “suse12141234” as his password
4. Sue clicks on the button labeled “login”
5. System displays “Incorrect password or user
name.”

Scenario Name :Login

Participating Action Instance Sue:Employee
Flow Of Events 1. Sue activates the “Login” function of the system
by going to the login page
2. Sue enters “[email protected]” as his user name
3. Sue enter “aaaaae” as his password
4. Sue clicks on the button labeled “login”
5. System displays “Account locked due to incorrect
password”

6|Page
Scenario Name :Login
Participating Action Instance Sue:Employee
Flow Of Events 1. Sue activates the “Login” function of the system
by going to the login page
2. Sue enters “[email protected]” as his user name
3. Sue clicks on the button labeled “canceled”
4. System displays “Login Canceled”

7|Page
Scenario - AddPayee

Scenario Name :AddPayee

Participating Action Instance Bill:Customer
Flow Of Events 1. Bill activates the “Add a Payee” function of the
system by clicking on the button “Add a Payee.”
2. Bill enters “Capital One” as the payee’s name
3. Bill enters “123 Washington Drive” as the
Address 1
4. Bill enters “Baton Rouge” as the city
5. Bill selects “LA” as the state
6. Bill enters “70801” as the zip code
7. Bill enters “800-555-555” as the phone number
8. Bill enters “000074458785” as the account
number
9. Bill clicks “Add Payee” button to submit
information
10. The Systems shows “Payee has been added
Successfully”

Scenario Name :AddPayee

Participating Action Instance Bill:Customer
Flow Of Events 1. Bill activates the “Add a Payee” function of the
system by clicking on the button “Add a Payee.”
2. Bill enters “Capital One” as the payee’s name
3. Bill enters “123 Washington Drive” as the
Address 1
4. Bill enters “Baton Rouge” as the city
5. Bill enters “70801” as the zip code
6. Bill enters “800-555-555” as the phone number
7. Bill clicks “Add Payee” button to submit
information
8. The Systems shows “Unsuccessful due to
incorrect or missing information”
9. System will reinitiate the “Add a Payee”
function, with the information that Bill just
entered highlighting the issue.

Scenario Name :AddPayee

Participating Action Instance Bill:Customer

8|Page
Flow Of Events 1. Bill activates the “Add a Payee” function of the
system by clicking on the button “Add a Payee.”
2. Bill enters “Capital One” as the payee’s name
3. Bill enters “123 Washington Drive” as the
Address 1
4. Bill enters “Baton Rouge” as the city
5. Bill selects “LA” as the state
6. Bill clicks “Cancel” button
7. The Systems prompts to confirm cancelation
8. Bill clicks yes
9. System displays that the function has been
canceled.

9|Page
Scenario - SchedulePayment

Scenario Name :SchedulePayment

Participating Action Instance Bill:Customer
Flow Of Events 1. Bill activates the “SchedulePayment” function of
the system by clicking on the link
“SchedulePayment” in the functionality window
2. Bill selects “Chase”
3. Bill then enters “$200”
4. Bill selects “Checking 12341234”
5. Bill selects “4/14/2010”
6. System displays “Estimated Delivery Date” as
“4/17/2010"
7. Bill Selects “Single Payment”
8. Bill clicks the submit button
9. System displays entered data for verification
10. Bill clicks accept
11. System displays “Payment Scheduled
Successfully”

Scenario Name :SchedulePayment

Participating Action Instance Bill:Customer
Flow Of Events 1. Bill activates the “SchedulePayment” function of
the system by clicking on the link
“SchedulePayment” in the functionality window
2. Bill selects “Chase”
3. Bill then enters “$200”
4. Bill selects “Checking 12341234”
5. Bill selects “4/12/2009”
6. System displays “Date range invalid. Please
select a date in the future”
7. Bill Selects “4/12/2010”
8. System displays “Estimated Delivery Date” as
“4/17/2010"
9. Bill Selects “Single Payment”
10. Bill clicks the submit button
12. System displays entered data for verification
13. Bill clicks accept
11. System displays “Payment Scheduled
Successfully”

10 | P a g e
Scenario Name :SchedulePayment
Participating Action Instance Bill:Customer
Flow Of Events 1. Bill activates the “SchedulePayment” function of
the system by clicking on the link
“SchedulePayment” in the functionality window
2. Bill selects “Chase”
3. Bill then enters “$200”
4. Bill selects “Checking 12341234”
5. Bill selects “4/14/2010”
6. System displays “Estimated Delivery Date” as
“4/17/2010"
7. Bill Selects “Recurring Payment”
8. System prompts for frequency and ending date
9. Bill Enters “Monthly”
10. Bill enters “3 payments”
11. Bill clicks continue button
12. Bill clicks the submit button
13. System displays entered data for verification
14. Bill clicks accept
15. System displays “Payment Scheduled
Successfully”

Scenario Name :SchedulePayment

Participating Action Instance Bill:Customer
Flow Of Events 1. Bill activates the “SchedulePayment” function of
the system by clicking on the link
“SchedulePayment” in the functionality window
2. Bill selects “Chase”
3. Bill then enters “$200”
4. Bill selects “Checking 12341234”
5. Bill selects “4/14/2010”
6. System displays “Estimated Delivery Date” as
“4/17/2010"
7. Bill clicks the cancel button
8. System displays payment schedule canceled.

11 | P a g e
Scenario - ModifyPayment

Scenario Name :ModifyPayment

Participating Action Instance Bill:Customer
Flow Of Events 1. Bill activates the “ModifyPayment” function of the
system by clicking on button “Modify Payment”
2. System will show list of all payments done by Bill’s
account which have delivery date after today’s date
3. Bill click on payee’s name “Chase” to modify request
in payment for “Chase”
4. Bill changes amount to 120.34$ in “Payment
Amount” Box and click “Continue” button
5. System ask Bill to confirm this Modify Payment
transaction
6. Bill clicks “Submit” button to confirm
7. System displays “The amount for Chase was
modified to 120.34$” message

Scenario Name :ModifyPayment

Participating Action Instance Bill:Customer
Flow Of Events 1. Bill activates the “ModifyPayment” function of
the system by clicking on button “Modify
Payment”
2. System will show list of all payments done by
Bill’s account which have delivery date after
today’s date
3. Bill click on payee’s name “Chase” to modify
request in payment for “Chase”
4. Bill changes date to 4/19/2010 in “Delivery Date”
calendar and click “Continue” button
5. System ask Bill to confirm this Modify Payment
transaction
6. Bill clicks “Submit” button to confirm
7. System displays “The delivery date for Chase was
modified to 4/19/2010” message

12 | P a g e
Scenario Name :ModifyPayment
Participating Action Instance Bill:Customer
Flow Of Events 1. Bill activates the “ModifyPayment” function of
the system by clicking on button “Modify
Payment”
2. System will show list of all payments done by
Bill’s account which have delivery date after
today’s date
3. Bill click on payee’s name “Chase” to modify
request in payment for “Chase”
4. Bill changes date to 4/19/2010 in “Delivery Date”
calendar and changes amount to 120.34$ in
“Payment Amount” Box and click “Continue”
button
5. System ask Bill to confirm this Modify Payment
transaction
6. Bill clicks “Submit” button to confirm
7. System displays “The delivery date and payment
amount for Chase was modified to 4/19/2010
and 120.34$” message

Scenario Name :ModifyPayment

Participating Action Instance Bill:Customer
Flow Of Events 1. Bill activates the “ModifyPayment” function of
the system by clicking on button “Modify
Payment”
2. System will show list of all payments done by
Bill’s account which have delivery date after
today’s date
3. Bill click on payee’s name “Chase” to modify
request in payment for “Chase”
4. Bill changes date to 1/19/1988 in “Delivery Date”
calendar and click “Continue” button
5. System ask Bill to confirm this Modify Payment
transaction
6. Bill clicks “Submit” button to confirm
7. System displays “Invalid date” message

13 | P a g e
Scenario Name :ModifyPayment
Participating Action Instance Bill:Customer
Flow Of Events 1. Bill activates the “ModifyPayment” function of
the system by clicking on button “Modify
Payment”
2. System will show list of all payments done by
Bill’s account which have delivery date after
today’s date
3. Bill click on payee’s name “Chase” to modify
request in payment for “Chase”
4. Bill changes amount to 000.00$ in “Payment
Amount” Box and click “Continue” button
5. System ask Bill to confirm this Modify Payment
transaction
6. Bill clicks “Submit” button to confirm
7. System displays “Invalid Payment Amount”
message

Scenario Name :ModifyPayment

Participating Action Instance Bill:Customer
Flow Of Events 1. Bill activates the “ModifyPayment” function of
the system by clicking on button “Modify
Payment”
2. System will show list of all payments done by
Bill’s account which have delivery date after
today’s date
3. Bill click on payee’s name “Chase” to modify
request in payment for “Chase”
4. Bill changes amount to XXX$ in “Payment
Amount” Box and click “Continue” button
5. System ask Bill to confirm this Modify Payment
transaction
6. Bill clicks “Cancel” button to abort
7. System displays “No modification done for
Chase” message

14 | P a g e
Scenario - DeletePayment

Scenario Name :DeletePayment

Participating Action Instance Bill:Customer
Flow Of Events 1. Bill activates the “DeletePayment” function of
the system by clicking on button “Delete
Payment”
2. System will show list of all payments done by
Bill’s account which have delivery date after
today’s date
3. Bill click on payee’s name “Chase” to delete
request in payment for “Chase”
4. System ask Bill to confirm this Delete Payment
transaction
5. Bill clicks “Submit” button to confirm
6. System displays “The payment for Chase is
deleted” message

Scenario Name :DeletePayment

Participating Action Instance Bill:Customer
Flow Of Events 1. Bill activates the “DeletePayment” function of
the system by clicking on button “Delete
Payment”
2. System will show list of all payments done by
Bill’s account which have delivery date after
today’s date
3. Bill click on payee’s name “Chase” to delete
request in payment for “Chase”
4. System ask Bill to confirm this Delete Payment
transaction
5. Bill clicks “Cancel” button to abort
6. System displays “The payment for Chase is not
deleted” message

15 | P a g e
Scenario - DeliverPayment

Scenario Name :DeliverPayment

Participating Action Cal1:Calendar
Instance
Flow Of Events 1. System activates the “DeliverPayment” function
on 4/17/2010 for Account Number “12341234”
2. System gets information for payments need to be
delivered on 4/17/2010 for Account Number
“12341234”
Payee=”Chase”
Amount=200$
3. System gets payee Account Number from its
database
Payee=”Chase”
Account Number=”87654321”
4. System transfer Payment Amount from
“12341234” to “87654321”
5. System sends message “Payment done
successfully to Chase for amount 200$ by
AccNo:12341234 on 4/17/2010” to Account
Number “12341234” email

16 | P a g e
Scenario Name :DeliverPayment
Participating Action Instance Cal1:Calendar
Flow Of Events 1. System activates the “DeliverPayment” function
on 4/17/2010 for Account Number “12341234”
2. System gets information for payments need to
be delivered on 4/17/2010 for Account Number
“12341234”
Payee=”Chase”
Amount=200$
3. System gets payee Account Number from its
database
Payee=”Chase”
Account Number=”87654321”
4. System transfer Payment Amount from
“12341234” to “87654321”
5. System sends message “In sufficient balance to
do Payment to Chase for amount 200$ by
AccNo:12341234 on 4/17/2010” to Account
Number “12341234” email

17 | P a g e
Use Case - Login

Use case Name Login

Participating Actor Initiated by Customer and Employee
Flow of Events 1. A customer activates the “login” function by accessing
the URL in the boundary object web browser.
2. Control object LoginControl is created
3. LoginControl creates boundary object loginPage
4. loginPage prompts user to enter username and
password
5. User enters all prompted information
6. LoginControl gets the entered username and
password, create entity object Customer, and invokes
the login method
7. Result of method returned to LoginControl
8. LoginControl creates boundary object MsgWindow
9. MsgWindow displays “Welcome [username],”
“Incorrect username or password,” “Login canceled by
user,” or “Account locked due to incorrect login
attempts.”
Entry Conditions Actors have navigated to the login URL via their browser.
Exit Conditions Actors have successfully logged into the system; actors have
been denied access due to incorrect attempts exceeded and
account has been locked;
Quality Requirements Data entry request should be displayed on a webpage;
System recognition message should be displayed in less than
3 seconds; Entered data should be done securely; all fields
must contain data

18 | P a g e
Use Case - AddPayee

Use case Name AddPayee

Participating Actor Initiated by Customer
Flow of Events 1. A customer activates the “Add a Payee” function displayed in a
Menu Bar
2. An object of AddPayeeControl is created.
3. Control creates RetreivePayeeWindow boundary object.
4. RetreivePayeeWindow prompts the user to enter:
a. Payee Name
b. Address 1
c. Address 2
d. City
e. State
f. Zip
g. Phone Number
h. User’s account number with Payee
5. User enters all of the information that is being prompted for input.
6. The RetreivePayeeWindow gets the required information and
creates a Payee object and invokes the AddPayee operation
7. The AddPayeeControl receives system acknowledgement and
creates ResultMessageWindow
8. The AddPayeeControl tells the ResultMessageWindow to display:
a. “Payee Added,”
b. “Information Missing or Incorrect”
i. AddPayeeControl creates CorrectPayeeWindow
ii. AddPayeeControl prompts user to correct / input
missing information via CorrectPayeeWindow
c. or
1. AddPayeeControl creates
CancelPayeeWindow
ii. prompts user if cancel is correct via
CancelPayeeWindow
iii. User selects yes
iv. AddPayeeControl gets users selection
v. AddPayeeControl tells ResultMessageWindow to
display “Operation Canceled
Entry Conditions Actors are logged into the system
Exit Conditions Actors have successfully added a payee account; Actors cancel
Quality Data entry request should be displayed on a webpage; System recognition
Requirements message should be displayed in less than 3 seconds; Entered data should

19 | P a g e
 be done securely

Use Case - SchedulePayment

Use case Name SchedulePayment

Participating Actor Initiated by Customer
Flow of Events 1. Actor initiates the “SchedulePayment” functionality by
clicking a link displayed in a boundary object MenuBar.
2. A SchedulePaymentControl object is created.
3. SchedulePaymentControl creates an instance the
entity object Payee and invokes the
GetRegisteredPayee method, which returns all of the
Payee’s associated with that customer
4. SchedulePaymentControl creates boundary object
SelectionBox
5. User selects the payee name from the SelectionBox
6. SchedulePaymentControl gets the selected payee from
SelectionBox
7. SchedulePaymentControl creates boundary object
inputScreen
8. inputScreen prompts user to enter:
a. Amount to be paid
b. Which account to use
c. Date to send payment
d. Frequency of payment
9. SchedulePaymentControl gets frequency
10. If frequency = recurring,
a. SchedulePaymentControl creates inputScreen2
b. inputSceen2 prompts user to select “Monthly,
Weekly, Daily, etc”, and enter if the recurring
payment should end after some amount of
time
c. inputScreen2 returns data to
SchedulePaymentControl
11. SchedulePaymentControl then gets entered data
12. SchedulePaymentControl creates verifyWindow
13. verifyWindow displays all of the data the user
submitted
14. If user accepts, SchedulePaymentControl creates an
entity object Payment, and invokes the schdPymt
method
15. SchedulePaymentControl creates boundary object

20 | P a g e
 MsgWindow
16. MsgWindow displays “Schedule Payment Canceled” or
“Payment Successful Scheduled”
Entry Conditions Actors are logged into the system; Actor has Payees
associated with them; Actor has banking accounts that is
already known and associated with that payee.
Exit Conditions Actors have successfully scheduled a payment; actors have
canceled the functionality
Quality Requirements Data entry request should be displayed on a webpage; System
recognition message should be displayed in less than 3
seconds; Entered data should be done securely

21 | P a g e
Use Case - ModifyPayment

Use case Name ModifyPayment

Participating Actor Initiated by Customer
Flow of Events 1. Customer activates the “ModifyPayment” function by
clicking “Modify Payment” button in MainWindow.
2. Control object ModifyPaymentControl is created
3. ModifyPaymentControl creates entity object Payment
and invokes getPayment method to get all payments
that have delivery date after current date
4. ModifyPaymentControl creates
ModifyPaymentWindow
5. ModifyPaymentWindow displays returned information
from getPayment method
6. User selects payment to modify
7. ModifyPaymentControl gets selected Payment
8. ModifyPaymentControl executes getDetails method of
Payment for the selected Payment
9. ModifyPaymentControl shows editable details of
selected payment in ModifyPaymentWindow
10. User makes changes in Payment and clicks Continue
Button
11. ModifyPaymentControl gets updated Payment detials
12. ModifyPaymentControl creates ModPmtConfirm to
display options either to confirm or to cancel.
13. User can click confirm payment or cancel modify
payment button.
14. ModifyPaymentControl gets users selection
15. If confirmed, ModifyPaymentControl updates payment
16. ModifyPaymentControl create boundry object
msgWindow
17. msgWindow displays “User Canceled” or “Successfully
updated payment”
Entry Conditions Actors have login to Main Page of online banking system
Exit Conditions Actors have successfully modified the payment, or abort the
modification process by clicking “Cancel”
Quality Requirements An email giving brief detail about payment modification
should be sent to Customer’s email address, modification
process should not take more than 30 seconds.

22 | P a g e
Use Case - DeletePayment

Use case Name DeletePayment

Participating Actor Initiated by Customer
Flow of Events 1. Customer activates the “DeletePayment” function by clicking
“Delete Payment” button in MainWindow.
2. Control object DeletePaymentControl is created
3. DeletePaymentControl creates entity object Payment and invokes
getPayment method to get all payments that have delivery date
after current date
4. DeletePaymentControl creates DeletePaymentWindow, which
shows result of getPayment
5. User selects payment to delete
6. DeletePaymentControl gets user selection
7. DeletePaymentControl creates DeletePaymentConfirmWindow to
display options either to confirm or to cancel.
8. User can click confirm or cancel delete payment button.
9. DeletePaymentControl gets user’s choice
10. If user confirms , DeletePaymentControl invokes Payment’s delete
method
11. DeletePaymentControl creates boundary object msgWindow
which displays “Payment successfully deleted” or “User canceled”
Entry Conditions Actors are logged into the system
Exit Conditions Actors have successfully added a payee account; Actors cancel
Quality Data entry request should be displayed on a webpage; System recognition
Requirements message should be displayed in less than 3 seconds; Entered data should
be done securely

23 | P a g e
Use Case - DeliverPayment

Use case Name DeliverPayment

Participating Actor Initiated by Calendar
Flow of Events 1. Calendar initiates the DeliverPayment functionality via
a hidden boundary object h_DeliveryObject
2. A DeliverPaymentControl object is created.
3. DeliverPaymentControl creates entity object Payment
and invokes getPayments method
4. DeliverPaymentControl creates an instance object
Payee and invokes the getPayeeInformation method,
which returns account number of the Payee associated
with that payment
5. DeliverPaymentControl invokes sendPayment method
of entity object Payment to make payment from
customer’s account to payee’s account.
6. DeliverPaymentControl receives status of
sendPayment and updates entity object Payment.
Entry Conditions A system event triggers the functionality to occur.
Exit Conditions System delivers the payment.
Quality Requirements Delivery should be done securely; An email should be send to
customer about confirmation of delivery to payee; Should be
able of deliver payment even if customer doesn’t have
sufficient balance ( remaining amount would be charged as
overdraft)

24 | P a g e
Sequence Diagrams – Login

25 | P a g e
Sequence Diagrams – AddPayee

26 | P a g e
Sequence Diagrams – SchedulePayment

27 | P a g e
Sequence Diagrams – ModifyPayment

28 | P a g e
Sequence Diagrams – DeletePayment

29 | P a g e
Sequence Diagrams – DeliverPayment

30 | P a g e
State Diagram - Account

State Diagram – Customer

31 | P a g e
State Diagram – Payment

State Diagram – Payee

32 | P a g e
Class Diagram

33 | P a g e
Object Diagram

34 | P a g e
Class Details

35 | P a g e
System Design
Design Goals

 Performance
o The system should be able to satisfy requests within 2 seconds.
o System should be able to handle a minimum of 1,000 concurrent
users
 Dependability
o System should have a 99.9% uptime.
 Cost
o The development of the system should be <$50k, excluding
hardware
 Maintenance
o Full back-ups should be taken every week
o Incremental back-ups should be taken every day
o Security audits should be conducted weekly
o Disaster recovery test should be conducted bi-annually
o Performance monitoring should be in place and necessary changes
should be identified to increase performance
 End User
o System should be intuitive
o Available functionality should be clearly identifiable
o Currency used should reflect the local currency of the customer
o Customers should be <79% satisfied with the system

Subsystem and Software Architecture

36 | P a g e
Deployment Diagram

Access Control

Customer:
(Customer, LogIn())
(Customer, UpdateCusInfo())
(Payee, Add_Payee())
(Payee, Update_Payee())
(Payee, Remove_Payee())
(Payment, Modify_Payment())
(Payment, Delete_Payment())
(Payment, View_History())
(Payment, Schedule_Payment())
(Account, Withdrawl())
(Account, Deposit())
(Access_Control, checkAccess())

37 | P a g e
Strategies for Global Control

As this online banking system is purely utilizes via the web, the main

control strategy for this will be a combination of event driven, threads and

procedure driven control. When a user initiates functionality, an event will create

a thread to execute the functionality. Depending on the type of functionality, the

resulting thread might continue in another event driven procedure or in a purely

procedural way.

Boundary Use Case

Use case Name StartUp

Participating Actor Initiated when system is activated
Flow of Events 1. System checks configuration file to determine system
settings.
2. System ensures that connection between Database
server is working
3. System checks that the web servers are online

Entry Conditions System was initially shutdown

Exit Conditions System confirms that all connections are working as required.
Quality Requirements

38 | P a g e
Object Design
Design Pattern Strategy

39 | P a g e
Interface Specifications – Invariants

40 | P a g e
Interface Specifications – Preconditions

41 | P a g e
Interface Specifications – Post conditions

42 | P a g e