BANKING SYSTEMDESIGN DOCUMENT

CEN5011 - Advanced Software EngineeringFall Term - 2004

TEAM MEMBERS

Jing Zhang

Wei Peng

Erliang Zeng

Ramakrishna Varadarajan

Xiaosi Zhou

Fernando Farfán

DOCUMENT TOPIC EXPOSITOR

SDD Introduction

Design Goals

Current Software Architecture

Fernando

Proposed Software Architecture

Overview

Subsystem Decomposition

Jing

Hardware/Software Mapping

Persistent Data Management

Access Control And Security

Ramakrishna

Global Software Control

Boundary Conditions

Subsystem Services

Xiaosi

ODD Introduction

Object Design Trade-offs

Interface Documentation Guidelines

Wei

Packages

Class Interfaces

Erliang

TODAY’S OUTLINE

INTRODUCTION

PURPOSE OF THE SYSTEM

• Re-engineer the Current System.

• Bringing new technology to theexisting one.

• Adding new capabilities such as new Internet Banking interface for the customers

DESIGN GOALS I

Dependability criteria:• ROBUSTNESS• RELIABILTY• SECURITY

Cost criteria:• DEPLOYMENT COST• UPGRADE COST• ADMINISTRATION COST

DESIGN GOALS II

Maintenance criteria:1. EXTENSIBILTY

2. MODIFIABILITY

3. READABILITY

End User criteria:1. UTILITY

2. USABILITY

CURRENT SOFTWARE ARCHITECTURE

• Mainframe: AS400

• Several terminals attached to it.

• =>Limited the bank’s expansion.

• Other products on the market implement all their operations and functionalities over Client/Server architecture.

PROPOSED SOFTWARE ARCHITECTURE

Overview Client/Server architecture Add new functionalities and improve

the existing banking systems TCP/IP network to interconnect all the

branch offices to the host servers.

SUBSYSTEM DECOMPOSITION

Five Subsystems– User Management Subsystem– Account Management

Subsystem– Transaction Management

Subsystem– Storage Subsystem– Database Subsystem

SUBSYSTEM DECOMPOSITION

UserManagementAccountManagement TransactionManagement

Storage

Database

Subsystem Decomposition with Classes

UserManagement

AccountManagement

TransactionManagement

Storage

Database

Person

SysAdmin User

BankOfficer BankTeller

Transaction

AccountCustomer

HARDWARE/SOFTWARE MAPPING

• Web-based Internet Banking platform.

• The Branch Employees will access the system through the bank’s TCP/IP private network

• The Customers will access through the World Wide Web.

• The system will run over the UNIX operating system, specifically over Solaris Version 3.2.5.

HARWARE/SOFTWARE MAPPING

• The programming language used to develop this product will be Java, using JSP for the web interface.

• We have selected My SQL Version 4.1 as the Database Management System, and we will use JDBC drivers to connect the Java components to it.

• The Banking System consists of three independent components: Web Browser, Bank System Server and Database Server.

UML DEPLOYMENT DIAGRAM

aPC:PC

:UnixHost

:UnixHost

:Explore

:UserMangement

:AccountManagement

:TransactionMangement

:Storage

:Database

PERSISTENT DATA MANAGEMENT

• Entity objects are persistent data objects that needs to be tracked down by the system

• The persistent data objects of our system are: Person ( includes SysAdmin, Customer, Bank

Officer and Bank Teller) , Account and Transaction

• This persistent information will be stored in a Relational Database Management Subsystem (RDBMS). We have selected My SQL as the DBMS.

ACCESS CONTROL AND SECURITY

USING CAPABILITY LIST:

1. A capability associates a (class, operation) pair with an actor.

2. We have created capability lists for all actors of the system

3. More compact representation

4. Global access Table – wastes space as there are more empty cells

CAPABILITIES OF A BANK TELLER

CLASS OPERATION

Function Select menu ManageTransactions(),updateLogin(),Login().

Account Deposit(),Transfer(),Withdraw().

Transaction Select Menu Create().

Withdraw Form Create(), submit().

Deposit Form Create(), submit().

Transfer Form Create(), submit().

Manage Transactions Report

Create(),Print(),dismiss().

Transaction Create().

Person Update()

Login form Create(), submit().

Update Login Form Create(), submit().

GLOBAL SOFTWARE CONTROL

• Procedure-driven control , Why? - web-based services - example: web server waits for requests from the web browser. Upon receipt of a request, the web server processes and dispatches it to the appropriate web page

BOUNDARY CONDITIONS

The following activities define the boundary conditions

- Starting - Shutdown

SUBSYSTEM SERVICES

• Five Subsystem

- User Management Subsystem

- Account Management Subsystem

- Transaction Management Subsystem

- Storage Subsystem

- Database Subsystem

SUBSYSTEM SERVICES

• User Management Subsystem create login update login login• Account Management Subsystem create account update account close account

SUBSYSTEM SERVICES

• Transaction Management Subsystem deposit withdraw transfer check balance check transactions • Storage Subsystem• Database Subsystem

OBJECT DESIGN Introduction

•Contents

•From Non-functional requirement

•Web-based graphical user interface

Object design trade-offs

• build vs. buy

• delivery time vs. functionality

• modifiability vs. response time

• information hiding vs. efficiency

Interface documentation guidelines– Classes are named with singular nouns or noun

phrases, with each word beginning with a capital letter.

– All class instances will be named with a similar convention, but with lowercase initial lettering for the first word

– Methods are named with verb phrases; fields and parameters are named with noun phrases.

– Error status is returned via return values in the form of an integer variable.

– Each class prototype will be included at the top of the header file before implementation of that class, and each class’ full interface information will be specified in comments with the prototype.