BANKING SYSTEM SYSTEM DESIGN DOCUMENT

Group #3 Members Jing Zhang Wei Peng Erliang Zeng Ramakrishna Varadarajan Xiaosi Zhou http://www.cs.fiu.edu/~xzhou001 Fernando Farfán TABLE OF CONTENTS

1. INTRODUCTION .............................................................. .... 2 1.1. PURPOSE OF THE SYSTEM ................................................... ..... 2 1.2. DESIGN GOALS .......................................................... ......... 2 1.3. DEFINITIONS, ACRONYMS AND ABBREVIATIONS ............................... 3 1.4. REFERENCES .............................................................. ........ 3 1.5. OVERVIEW.................................................................

....... ...... The bank still uses an obsolete...........7.......................... with more than 50 branch offices and serving more than two hundred thousa nd clients......................... GLOBAL SOFTWARE CONTROL .............. CURRENT SOFTWARE ARCHITECTURE ...... SUBSYSTEM SERVICES ...... ......................Introduction 1........................................ 4 3....... PROPOSED SOFTWARE ARCHITECTURE ......1.......... SUBSYSTEM DECOMPOSITION ............................... 5 3.... 4 2......................................................... 11 4..... 8 3....... ..3.. 4 3.........4...... ...1....................... HARDWARE/SOFTWARE MAPPING .. 10 3............... ACCESS CONTROL AND SECURITY ... ............ 1 1 5........................................ 4 3............................ OVERVIEW............. 8 3.................... ....... GLOSSARY .......... 14 BANKING SYSTEM – System Design Document 1 1... 6 3.......... terminal-oriented banking system that has ............................5................... BOUNDARY CONDITIONS ..........6........2.................... PERSISTENT DATA MANAGEMENT ........ Purpose of the system The Requesting Bank is a banking institution with services in South Flor ida.

2. due to telecommunication l imitations. bringing new technology to the existing one. Based on the nonfunctional requirements. • Readability: The system has to be readable enough to assure its modifiability.limited the operation expansion and growth. • Traceability of requirements: The code should be easy to be mapped to specific requirements. the following design goals will have to be achieved in order to qualify the system as successful: Dependability criteria: • Robustness: The system has to be robust enough to manage any invalid input from the users. Maintenance criteria: • Extensibility: The system must support that new functionalities can be added. high system maint enance costs. The purpose of this Banking System will reengineer the current s ystem. • Administration cost: The system must have a low administration cost. but such expansion will be unreachable if the bank does not count with a new system strong enough to suppor t the expected high volume operations. • Modifiability: The system has to be highly modifiable. • Security: The system security is one of the most important nonfunctional requirements. The new administration’s strategic plan for the next five years focuses on a statewide coverage expansion. both for bank employees and customers. in order to achieve a cost effective database migration. The new system will also support the customers operations through its web-banking interface. poor or inexistent support from some product vendors. • Reliability: The system has to perform the Banking operations with no errors or discrepancies. lack of interactivity between users and system. BANKING SYSTEM – System Design Document 2 Cost criteria: • Deployment cost: The system has to be easy enough to have a cheap training cost. and adding new capabilit ies such as the new internet banking interface for the bank’s customers. • Upgrade cost: The new system implementation has to deal with the former legacy system. as well as a very expensive learning curve for the new users. so the Information Technology Department of the bank can maintain it. . 1. • Usability: The system will be designed in a user-friendly fashion. End user criteria: • Utility: The system has been conceived specifically to support the bank employee’s work. Design goals The design goals represent the desired qualities of Banking System and provi de a consistent set of criteria that must be considered when make design deci sions.

describing the current situati on of the banking system. in charge of attending the customer’s transactions. due to the high costs of operations. They have an AS400 mainframe that provides all the services to the branch office’s terminals. and the difficulty of fun ctionality of the system. to improve the usability of the system. acronyms and abbreviations Bank Teller: The bank employee attending behind the windows.5. but are not limited to. All the applications running in the branch offices will be implemented with web-based front ends. Definitions. Section 4 presents the sub systems services. opening new accounts.Proposed Software architecture 3.Current Software architecture The current system is based on a Mainframe with several terminals attache d to it. Section 3 presents the proposed software architecture. but will renew the technology of the current system. 2. Other products on the market implement all their operations and functionalitie s over Client/Server architecture. focusing on the subsystem decomposition. System Administrator: The system maintainer. hardware and so ftware mapping and the persistent data management.4. Overview This document is organized as follows: Section 2 presents a brief o verview of the current software architecture. as well as updating and closing existing accounts. in charge of creating usernames for bank employees. by adding new f unctionalities and improving the existing one. as well as t . Bank Officer: The bank employee in charge of the direct customer service . based on TCP/IP networks. This typical Client/Server architecture has limited the bank’s expansion.1. Customer: The account holder who uses the bank services.1. the lack of hardware and software maintenance in some cases. Her duties include. such as deposits and withdrawals. 1. Overview This project has the goal of implementing a reengineering to the current banking system.3. References • • Problem Statement Requirements Analysis Document BANKING SYSTEM – System Design Document 3 1. 3. such as a TCP/IP network to interconnect all the branch offices to the host servers. The improvements will be basic ally the integration of more modern technologies. usi ng either Windows Applications or web-based interfaces to communicate the cli ents with the main hosts. It will be implemented using the Client/Server archite cture.

The different subsystems should have a loose coupling. At BANKING SYSTEM – System Design Document 4 the same time. providing a common interface to the other three high-level subsystems. AccountManagement UserManagement TransactionManagement Storage Database Figure 1: Subsystem Decomposition BANKING SYSTEM – System Design Document . on the use cases and the The decomposition shows the existence of the following subsystems: • User Management Subsystem • Account Management Subsystem • Transaction Management Subsystem • Storage Subsystem • Database Subsystem The Database subsystem will be implemented by the Relational Databa se Management System (RDBMS) used to store the persistent data.o optimize the computational resources of the main hosts. 3. The Storage subsystem will encapsulate the database.2. The system will be decomposed based different actors we have defined. Subsystem decomposition During the subsystem decomposition of the Banking System we divide the syste m into smaller subsystems with a strong coherence. this architecture allows the system to scale the server co nfiguration according to the needs of the bank.

and the customers will access through the World Wide Web.33. 3.5 UserManagement Person SysAdmin AccountManagement BankOfficer Customer Account User BankTeller Storage TransactionManagement Transaction Database Figure 2: Subsystem Decomposition with classes 3. . The branch employees will access the system through the bank’s TCP/IP private network. The web server will run over Apache Web Server Version 1. according to the expansion goals of the bank. Hardware/Software mapping The banking system will be web-based.3. which can be reached in the next 5 years.2. The proposed main host will be a Sun Microsystems Sun Fire E2900 Server.5. It has been chosen due to its ability to scale up to 12 servers. specifically over Sola ris Version 3. The functionality wil l all be performed in the main host. BANKING SYSTEM – System Design Document 6 The system will run over the UNIX operating system. and will be accessed through TCP/IP networks by all the users. both for the banking users and for the customer access through the internet banking platform.

and we will use JDBC drivers to connect the Java components to it.1 as the Database Management System.4. BankSys temServer and DatabaseServer. We have selected MySQL Version 4.The programming language used to develop this product will be Java. using JSP for the web interface. Persistent data management Based on the Requirement Analysis Document. The Banking System consists of three independent components: WebBrowser. we have identified the following Entity objects as persistent data objects: . The following UML deployment diagram illustrates the software mapping for Banking System. aP C : P C : U ni x H os t :E x p l o r e : U s e r M angem ent hardware/ : A c c ount M anagem ent : T r ans ac t i onM angem ent :S to r a g e : U ni x H os t : D at abas e Figure 3: Package and Deployment Diagram Deleted: <sp> BANKING SYSTEM – System Design Document 7 3.

dismiss(). Update Account Form Create(). updateAccount(). submit(). due to its versatility. closeAccount(). amount. dismiss().• Person: Information about all the system users. Account createAccount(). transfer(). ending balance. Person Update() Login form Create(). submit(). User inherits into BankOfficer. It includes the account holde r’s information. This persistent information will be stored in a Relational Database Man agement Subsystem (RDBMS). submit(). submit(). Bank Officer CAPABILITY LIST CLASS OPERATION Function Select menu ManageAccounts(). submit(). etc. withdraw(). Bank Teller CAPABILITY LIST CLASS OPERATION . Bank Teller and Customer. Print(). Login(). high performance and integration with the other product s that constitute the new platform. Denying a capability is equivalent to denying access. submit(). • Account: Information about the bank accounts. Print(). date and time. updateLogin(). Transfer Form Create(). updateAccount(). A capability allows an actor access to an object of the class. Transaction Select Menu Create(). It includes the type of transaction. at the same time. • Transaction: Detailed information about the bank transactions performed against the accounts. Create Account Form Create(). Update Login Form Create(). submit(). Deposit Form Create(). operation) pair with an act or. average balances. Transaction Create(). closeAccount(). 3. and so on. Manage Transactions Report Create(). Access control and security The access control for the Banking system is implemented through the capabilit ies list. It inherits into System Admi nistrator and User. createAccount(). as well as balances. Withdraw Form Create(). Manage Account Menu Create(). submit().5. BANKING SYSTEM – System Design Document 8 Deposit(). This representation comes up to be more compact and efficient for the System. We have selected MySQL as RDBMS. Manage Account Report Create(). A capability associates a (class. Close Account Form Create().

Transaction Create(). Manage Transactions Report Create(). System Administrator CAPABILITY LIST CLASS OPERATION Function Select menu createLogin(). Print(). Update Login Form Create(). updateLogin(). submit(). Deposit Form Create(). Transfer(). Deposit Form Create(). Create(). dismiss(). submit(). update(). submit(). Manage Transactions Report Create(). Account Deposit(). Transaction Select Menu Create(). dismiss(). Person Create Customer Login Form Create(). Transfer Form Create(). Person Update() Login form Update Login Form Customer CAPABILITY LIST CLASS Function Select menu updateLogin(). Create Login Menu createCustomerLogin(). Withdraw(). Create Employee Login Form Create(). Print(). submit(). . submit(). Transfer Form Create(). submit(). Withdraw Form Create(). Account Deposit(). Transaction Select Menu Create(). submit(). submit(). Login form Create(). submit(). Create().Function Select menu ManageTransactions(). Person Create Customer Login Form Update() Login form Create(). print(). Create(). Withdraw(). Transfer(). Transaction Create(). BANKING SYSTEM – System Design Document 9 Login(). submit(). OPERATION ManageTransactions(). dismiss(). submit(). createEmployeeLogin(). submit(). Login(). Withdraw Form Create(). Login(). Create Login Report Create(). updateLogin(). submit().

Operations provided by this subsystem are: • createLogin() • updateLogin() • login() The createLogin() and updateLogin() services of this subsystem imp lement the print() service. Updating Login and Log-in. For example.6. submit(). The starting. thus resulting in an event-based control flow. • Installing. the web server waits for requests from the web browser . Database Sever.Subsystem services USER MANAGEMENT SUBSYSTEM: This subsystem is responsible for managing different users of the sy stem by taking care of the login information of different users. since our project is a w eb-based project. Procedure-driven control would be the one that will be suitable for our system . operations wait for user input whenever they need data from ei ther a bank employee or a customer. This subsystem uses the services of storage subsystem to store and retrieve login information. Since Banking System is web-based application.Update Login Form 3. BANKING SYSTEM – System Design Document 10 3. ACCOUNT MANAGEMENT SUBSYSTEM: . it does not need explicit installation execution. The WebBrower and DatabaseSever are off-the-shelf components and are started and shut down individually. • Starting. Boundary conditions Banking system includes four run-time components: the WebBrower.7. Global software control Create(). to allow the customer to have a backup of her o peration. TransactionManagement). The Storage is started and shut down by the BankSystemSever. It provid es functions for Creating Login. 4. System administrator and all users of the system communicate with this subsystem. AccountManagemen t. shutdown and installing of the Banking System define the bounda ry conditions. the Storage and for the second prototype. the BankSy stemSever (which include the subsystems UserManagement. Upon receipt of a request. In our system. the web server processes and dispatches it to the appropriate web page. • Shutdown. It manages the usernames and passwords of all users of the system for security purpose s.

Bank Officer is the only actor who communicates with this subsystem. checking monthly bala nce and transactions. This subsystem is responsible for getting system-related data from different subsystems and issuing DBMS-s pecific calls for information storage and retrieval. Updating an account and Closing account. Bank Officer. A Database management system (DBMS) pr ovides all the necessary functions for performing the tasks. transfer of funds. Operations provided by this subsystem are: • deposit() • withdraw() • transfer() • checkTransactions() • checkBalance() All the methods of this subsystem implement the print() service. BANKING SYSTEM – System Design Document 12 Even if the DBMS changes. STORAGE SUBSYSTEM: This subsystem is responsible for specifying a common interface for the a bove subsystems for managing data. This subsystem provides all functions for managing variety of transac tions like deposit. withdrawal. This subsystem also communicates with the storage subsystem for storing critical transaction data and uses the services of the user managem ent subsystem for authenticating the users who perform transactions. Bank teller and customer are th e actors who communicate with this subsystem.BANKING SYSTEM – System Design Document 11 This subsystem is responsible for managing user accounts. only this subsystem needs to be changed. DATABASE SUBSYSTEM: This subsystem is a typical off-the-shelf component that is responsible for st orage and retrieval of system data. to allo w the customer to have a backup of her operation. TRANSACTION MANAGEMENT SUBSYSTEM: This subsystem is responsible for managing the transactions of acc ounts. Thi s subsystem uses login services of the User Management subs ystem for authenticating the Bank Officer and also uses the storage subsys tem for storing account’s information. Operations provided by this subsystem are: • createAccount() • updateAccount() • closeAccount() All the methods of this subsystem implement the print() service. to allo w the customer to have a backup of her operation. . withou t affecting other subsystems that access this subsystem. It provides functio ns for Opening an account.

He is the one who m . creating the logins for Ba nk Employees and closing accounts if any. He also can do transactio ns if necessary. Bank Officer: A Bank officer is the term used to refer to the officer of th e Bank who takes care of opening the accounts. Bank Teller: A Bank Teller is the term used to refer the teller of the sys tem.BANKING SYSTEM – System Design Document 13 Glossary Customer: A customer is the term used for referring a Bank customer who ut ilizes the Bank services by opening an account. who performs all the customer account transactions. wi thdrawing and earning interest if any. depositing money.

akes a deposit. BANKING SYSTEM – System Design Document 14 . Administrator: An administrator is the term referring to a bank syst em maintainer who is in charge of creating usernames for bank employees and system maintenance. withdrawal or checks the account’s balance.

Sign up to vote on this title
UsefulNot useful