BANKING SYSTEM DESIGN DOCUMENT CEN5011 - Advanced Software Engineering Fall Term - 2004.
-
Upload
ruby-nichols -
Category
Documents
-
view
219 -
download
2
Transcript of BANKING SYSTEM DESIGN DOCUMENT CEN5011 - Advanced Software Engineering Fall Term - 2004.
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 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
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.