Transcript Group3-DD
BANKING SYSTEM DESIGN DOCUMENT CEN5011 - Advanced Software Engineering Fall Term - 2004 TEAM MEMBERS Jing Zhang Wei Peng Erliang Zeng Ramakrishna Varadarajan Xiaosi Zhou Fernando Farfán TODAY’S OUTLINE DOCUMENT SDD ODD TOPIC EXPOSITOR 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 Introduction Object Design Trade-offs Interface Documentation Guidelines Wei Packages Class Interfaces Erliang INTRODUCTION PURPOSE OF THE SYSTEM • • • Re-engineer the Current System. Bringing new technology to the existing 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. 2. 3. EXTENSIBILTY MODIFIABILITY READABILITY End User criteria: 1. 2. UTILITY 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 AccountManagement UserManagement Storage Database TransactionManagement Subsystem Decomposition with Classes UserManagement Person SysAdmin User AccountManagement BankOfficer BankTeller Customer Account Storage TransactionManagement Transaction Database 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 :UnixHost aPC:PC :Explore :UserMangement :AccountManagement :TransactionMangement :Storage :UnixHost :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(),up dateLogin(),Login(). Account Deposit(),Transfer(),Withd raw(). 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.