Bank Sim Bank Account Management Simulator

By James Collett

Prepared for GlobalLeafs.com Wednesday 17th April 2002

User Documentation Contents

Overview Of System Overview To Running System Quick-Start Guide To Running System Key Features System Security

Overview Of System
The purpose of the program is to simulate a networked Banking System or Bank Account Management System. The primary facilities and capabilities which the program offers include:

Creating new accounts Accessing existing accounts Depositing and withdrawing money Setting overdraft limits

The program simulates, and allows for the manipulation of three types of bank account:

Current Accounts Savings Accounts (called Platinum Accounts) Student Accounts

Current Accounts do not support an overdraft limit. Platinum and Student Accounts do support an overdraft limit. The program does not facilitate interest rates and does not calculate interest. The program does not implement any account security (such as a PIN number) to prevent access to existing accounts. The program allows access to accounts, given a valid and existing account number.

(A detailed description and specification of the system is included in the Technical Documentation.)

Overview To Running System

The system consists of two programs: Bank Server program Bank Client program

The Server program represents a central banking system, and the Client program represents a terminal or teller machine at an individual (or peripheral) branch. The system requires both the Server and the Client to be running concurrently one cannot be used without the other. The primary objective of the simulator is to demonstrate a communication system between the Client and the Server, and not to demonstrate a complete range of facilities which a Bank may offer (such as PIN numbers or interest rates). The Server should be launched first, and will wait for the Client. The Client should be launched second, and will establish a connection with the Server. The Client and Server may both be run on the same computer. Alternatively, they may run on two networked computers. If the Client is to run on a different computer to the Server, then the Client must have security permission (authorisation) to connect to the Server computer.

Please refer to System Security for more information.

The system allows for multiple concurrent Clients to be run and connected to a single Server. The system makes use of a mutually-exclusive account locking mechanism to prevent concurrent Clients from accessing the same account at the same time.

Quick-Start Guide To Running System

The Server should be launched first by executing the file BankServer_RUN.bat. The Server will initially display text output similar to this: Server's address is 127.0.0.1 Server listening on port 1333 The Server does not require any intervention once it has been launched. The Client should be launched by executing the file BankClient_RUN.jar. The Client will display a graphical output, which includes a Configuration Tab and an Operation Tab: Server IP address: Server TCP port: Client nickname: localhost 1333 Alpha

Above: Client Configuration Tab Account number: Account name: Account created on: Transaction amount: Present balance: Overdraft limit: Above: Client Operation Tab The Configuration Tab must be completed first by entering the correct Server IP address, correct Server TCP port, and an arbitrary client nick name. The Client does not attempt to connect to the Server until a account number has been entered, and only attempts to connect when an account number is entered. If the connection is NOT successful, then the Client will display an error message. If the connection is successful, then the Client will prompt the user to create the first new account (current account, platinum account, or student account). After creating the account, the Client will display the information for that account. This information includes the present balance, and overdraft limit, (except for current accounts which do not support an overdraft limit). Withdraw Deposit

The account number field (cell) is a lookup field and controls which bank accounts information is displayed on screen.
The Client remains connected to the Server until the account number field is cleared, and only disconnects when the account number field is cleared.

Key Features
When a new account is created (as described on previous page), the new account name defaults to the account number; the opening balance defaults to zero; and the overdraft limit defaults to zero, (except for current accounts which do not support an overdraft limit). The account name, opening balance and overdraft limit may be set individually after the new account has been created. The account number must be an integer. The transaction amount and overdraft limit must both be decimal numbers. Any invalid input will result in an error message, and the program will roll back to the previous value. The transaction amount should be positive (or zero), and the overdraft limit should be a negative (or zero), however the program will automatically correct badly-signed values, without an error message.

System Security
The system consists of two programs: Bank Server program Bank Client program

The Client and Server may both be run on the same computer. Alternatively, they may be run on two networked computers. IF the Client is to be run on a different computer to the Server, then the Client must have security permission (authorisation) to connect to the Server computer. By default, clients do not have permission to connect to servers, (except for servers running on the same computer). To add permission, it is necessary to modify the .java.policy file located on the CLIENT machine. This file is located in the USER.HOME directory, which is normally c:\windows on a single-user Windows 95 computer. It is necessary to add a line to this file, similar to
permission java.net.SocketPermission "foo.bar.net:1024-", "connect,resolve";

(where foo.bar.net is the server IP address.) If a Client attempts to connect to a Server without permission, then a security error (Access Control Exception) will occur.

Technical Documentation Contents

Program Description Security Identification Protocol (SIP) Bankaccount Universal Retrieval Protocol (BURP) Account Locking Specification BURP (Bankaccount Universal Retrieval Protocol) Specification

Bank Account Class Structure Server Class Structure Server / Database Interface Client Class Structure Test Strategy and Test Results

Program Description
The purpose of the program is to simulate a networked Banking System or Bank Account Management System. The primary functions and capabilities which the program offers are:

Create new account Access existing account Change account name Deposit and withdraw money Set overdraft limit

The program provides a Graphical User Interface (GUI), to allow these functions to be carried out, and provides a Bank Account Database to store account information. The GUI and the Database are suited and intended to be run remotely, on separate connected computers. To facilitate this, a communication mechanism has been established between the GUI and the Database. The communication mechanism consists of a client, a server, and a protocol:

GUI

Client

Server

Database

The client and server implement two bespoke communication protocols:

SIP (Security Identification Protocol) BURP (Bankaccount Universal Retrieval Protocol)

Security Identification Protocol (SIP)

The purpose of the Security Identification Protocol is to ensure that a connecting client and connecting server are compatible with each other, and to prevent dialog (or conversation) between incompatible clients and servers. As soon as the client connects to the server, it must immediately send 87654321 to identify itself. If the server does not receive 87654321, it must close the connection without attempting to reply. If the server does receive 87654321, it must immediately reply to the client with 12345678 to identify. If the client does not receive 12345678, it must close the connection without attempting further dialog. As soon as both parties have identified themselves, the dialog (or conversation) continues. The client sends its nickname to the server, in UTF format, to complete the S.I.P. procedure.

Bankaccount Universal Retrieval Protocol (BURP)

The purpose of the Bankaccount Universal Retrieval Protocol is to enable the client to request account information from the server; enable the server to send account information to the client; and enable the client to inform the server of any changes to account information. The account information includes:

Account number Account name Account created on date Present balance Overdraft limit Account status Overdraft status

Transmitted as integer (32 bit) String (UTF) String (UTF) double (64 bit) double (64 bit) String (UTF) String (UTF)

The account status contains a description of the account type (platinum, etc) and a description of whether the account is new or existing. For example New Current Account or Existing Student Account. The overdraft status provides a description of the overdraft situation. For example Balance is presently 100.00 above overdraft limit.

(A detailed description of the Bankaccount Universal Retrieval Protocol is included over page.)

Account Locking Specification

The system allows for multiple concurrent clients to be run and connected to a single server. The system makes use of a mutually-exclusive account locking mechanism to prevent concurrent clients from accessing the same account at the same time. When a client terminates (normally or abnormally), an exception error is thrown on the server thread. The server thread is responsible for unlocking accounts (if any locked), during handling the exception error. No additional graceful mechanism is required on the server to unlock accounts when clients terminate. However, the server must GUARANTEE that accounts will be unlocked when clients terminate. If a client already has an account locked, and client requests to lock (or create & lock) another account, then If the request is successful, the first lock is automatically relinquished. If the request is not successful, the first lock is retained.

BURP (Bankaccount Universal Retrieval Protocol) Specification

Client requests Lock existing account Client sends to server Account number * Server responds Either, fail (account does not exist) Or, fail (account presently locked by another client) Or, OK Server sends to client If OK, then: type (current, platinum, student) account name account created on date present balance overdraft limit (if applicable) If OK, then as above Server echoes new account name back to client (Server does not attempt to prevent any withdraw or deposit) (Server does not attempt to prevent large overdraft limits) TEST (Yes Im here!!) Server calculates new balance Server echoes new balance to client Server echoes new overdraft limit back to client

1)

2) 3) 4) 5) 6)

Create (& lock) new account (current, platinum, student) Change account name Pre-requisite: account locked Withdraw or Deposit Pre-requisite: account locked Change overdraft limit Pre-requisite: account locked TEST (Are you there?)

Account number * Type (current, student, etc) New account name Transaction amount * New overdraft limit *

Either, fail (account already exists or already locked) Or, OK

* Client is responsible for validating numerical items (account numbers, transaction amounts, overdraft limits) before sending to server.

Bank Account Class Structure

A total of five bank account classes have been created, as listed below:

BaseAccount

CurrentAccount OverdraftAccount PlatinumAccount StudentAccount

The BaseAccount class contains the member variables and methods that will be common to all types of bank account: int getAccountNumber() String getAccountName() double getBalance() String getCreatedDate() void setAccountName(String newName) void deposit(double amount) void withdraw(double amount) The OverdraftAccount class extends the BaseAccount by adding additional variables and methods that will be common to all accounts with an overdraft facility: double getOverdraft() boolean isWithinLimit() void setOverdraft(double newOverdraft) The CurrentAccount class does not support an overdraft facility, and is derived from the BaseAccount. The PlatinumAccount and StudentAccount classes do have overdraft facilities, and these two classes are descendants of the OverdraftAccount class. Any changes made to the BaseAccount class will affect the inherited behaviour of all the types of bank account. Any changes made to the OverdraftAccount will affect the behaviour of all accounts with an overdraft facility. The reasons why the bank account classes have been set up like this, is so that a variable of type BaseAccount can refer to (or point to) an object of any type of bank account (that has been derived from the BaseAccount parent class).

Server Class Structure

The server has been built from three classes: BankServer BankServerSlave BankServerDatabase

BankServer
HAS-A HAS A HAS-A

BankServer Slave
(THREAD) HAS-A

BankServer Database
(COMMUNAL)

HAS-A

BankServer Slave
(THREAD)

present HAS-A Client account Socket

HAS A

HashMap

presentHAS-A Client account Socket

The BankServer object runs in its own thread context, and is responsible for listening for and accepting new TCP/IP connections by using the ServerSocket.accept() method. The server is designed to support multiple clients, and spawns a new ServerSlave for EACH connection. The server is suited to be run from the MS-DOS prompt. The default TCP port used is 1333. This can be configured by supplying a valid port as a command-line argument.

Each BankServerSlave object runs in its own thread context, and is responsible for managing (i.e. conversing with) one client Socket. The BankServerSlave implements both SIP (Security Identification Protocol) and BURP (Bankaccount Universal Retrieval Protocol). The BackServerSlave is responsible for unlocking any presently locked account if the remote client requests another account. The BackServerSlave is responsible for unlocking any presently locked account if the remote client disconnects or terminates.

The BankServerDatabase object is instantiated once only, is communal, and is shared by all BankServerSlave threads. The BankServerDatabases HashMap stores Account objects (as defined on previous page). The BankServerDatabase is responsible for handling requests for existing accounts and requests for new accounts. The BankServerDatabase is responsible for locking successfully requested accounts. The BankServerDatabase GUARANTEES that if two BankServerSlaves request the same account at the same time, than one BankServerSlave will be successful and the other BankServerSlave will not. An algorithm showing the interfacing between BankServerSlave and BankServerDatabase is shown over page.

Server / Database Interface

An algorithm showing the interfacing between BankServerSlave and BankServerDatabase is shown below:
ServerSlave asks Database IF account exists Database returns either YES or NO to ServerSlave If YES exists: ServerSlave requests existing account from Database Either, successful: Database locks account Database returns account to ServerSlave (ServerSlave uses account) (ServerSlave unlocks account when finished) Or, fail: Database returns NULL to ServerSlave (account presently locked)

If NO exist:

ServerSlave requests create new account Either, successful:

(current, student, etc)

Database creates and locks account Database returns account to ServerSlave (ServerSlave uses account) (ServerSlave unlocks account when finished)

Or, fail:

Database returns NULL to ServerSlave (account has been created)

Client Class Structure

The client has been built from three classes: BankClientGUI BankClient BankClientSlave

BankClient
HAS-A IS-A HAS A

BankClientSlave
HAS A ClientSocket

AlertBox

BankClientGUI UJTextField HAS A

The BankClientGUI class defines the Graphical User Interface (i.e. the Configuration Panel and the Operation Panel). The BankClientGUI makes use of a UJTextField (or "Undo-able" JTextField) class. This class extends JTextField, by adding a rollback facility. This enables the JTextFields contents to be rolled back to the previous contents, if the current contents are invalid (in the context of the application).

The BankClient class extends BankClientGUI. It is responsible for responding to user events as they occur and in the order in which they occur. The BankClient is responsible for validating all user requests (and for invoking rollback in cases of invalid user requests). The BankClient is also responsible for informing the user if a problem occurs with the connection to the server. The GUI makes use of a general-purpose, configurable, Alert Box dialog in order to display error messages and confirmation prompts to the user.

The BankClientSlave class is responsible for managing (i.e. conversing with) the servers Socket. The BankClientSlave implements both SIP (Security Identification Protocol) and BURP (Bankaccount Universal Retrieval Protocol). The BankClientSlave encapsulates the Socket safety mechanisms away from the GUI safety mechanisms. That is, the BankClientSlave class is responsible for dealing with problems which may occur with the connection, whereas the BankClient class is responsible for dealing with problems which may result due to user events.

Test Strategy and Test Results

The test strategy must ensure that all functions of the systems are working correctly. The complete test plan consists of two sets of tests: Compile-time tests Run-time tests The compile-time tests require temporarily modifying the source code (notably _SIP.java file) in order to induce certain conditions. The compile-time tests are listed below, along with the expected results of each test: (1) (2) Client sends wrong SIP code to server (i.e. not 87654321) Server detects, reports Client did not identify, and closes connection gracefully Server sends wrong SIP code to client (i.e. not 12345678) Client detects, reports Server did not identify, and closes connection gracefully

The client-side run-time tests are listed below, along with the expected results of each test: (1) (2) (3) (4) (5) (6) Empty Server IP address, and enter account number Client reports Please choose Server IP address Empty Server TCP port, and enter account number Client reports Please choose Server TCP port Empty Client nickname, and enter account number Client reports Please choose Client nickname Invalid Server TCP port (non-numerical, <1, >65535) and enter account number Client reports Invalid TCP port Invalid or nonsense Server IP address, and enter account number Client reports Unknown Host and problem connecting to server Wrong Server TCP port, and enter account number Client reports problem connecting to server Invalid account number (non-numerical, <1) Client reports Invalid Account Number First new account number, then cancel Client temporarily connects to server, then DISCONNECTS First new account number, then create Client connects to server, and displays default account information Change account number Client displays account information Change account name (Account name changes) Invalid transaction amount (non-numerical) Client reports Invalid Transaction Amount Invalid transaction amount (negative) Client automatically converts negative value to positive value

(7) (8) (9) (10) (11) (12) (13)

The client-side run-time tests are continued below, along with the expected results of each test: (14) (15) (16) (17) Withdraw/Deposit with empty transaction amount Client ignores request Withdraw/Deposit with non-empty transaction amount Present balance changes, and overdraft status changes (if application) Invalid overdraft limit (non-numerical) Client reports Invalid Overdraft Limit Invalid overdraft limit (positive) Client automatically converts positive to negative, and overdraft status changes
SERVER CONNECTION FAILS WHILE ATTEMPTING TO

(18) (19) (20) (21) (22) (23)

change account number (to existing account) Client detects, reports Connection with server has been lost, and clears connection change account number (to non-existing account) Client detects, reports Connection with server has been lost, and clears connection create new account Client detects, reports Connection with server has been lost, and clears connection change account name Client detects, reports Connection with server has been lost, and clears connection Withdraw/Deposit Client detects, reports Connection with server has been lost, and clears connection change overdraft limit Client detects, reports Connection with server has been lost, and clears connection CONCURRENCY: Attempt to access account which is presently locked Client reports Account presently locked by another client Attempt to access account which has been unlocked Client displays account information Attempt to create same account twice First client succeeds and displays default account information Second client fails and reports Account has been created by another client

(24) (25) (26)