Object Oriented System Analysis and Design

Y52.3530.FA09 Prof. Sam Sultan Term Paper

Submitted on: October 23, 2009 Submitted by:
Sudipendra N Pal Gary Carter Jason Durham

Term Paper: Group 7

Chapter Index

Cover letter of the proposed DARES system Executive Summary of the proposed system Baseline Project Plan Project Overview Deliverables Project Management Project Estimates Project Resource Requirements Software and Hardware Requirement Estimated Costs Feasibility Analysis Use Cases Object Model (Class Diagram) Sequence Diagrams Proposed System Design Architecture 23 13 13 16 10 12 12 12 5 9 5

3 4

22

25

Term Paper: Group 7

Y52.3530: OBJECT ORIENTED SYSTEMS ANALYSIS AND DESIGN

Cover letter of the proposed DARES system:
Sudipendra N. Pal, Jason Durham, Gary Carter The legacy MARS A/R application of company XYZ will be migrated off of the Mainframe system and onto a UNIX platform. This is the strategic production platform at company XYZ. This task has been assigned to IT Analysts Sudip, Jason and Gary of company XYZ. We are proposing a 3-tier application system architecture. The proposal is to have a Java web client frontend interfacing with a Java Enterprise server as the middle tier and an ORACLE database server as the backend server. The new A/R application will be called DARES – Distributed Account Receivable System – and will be designed using Object Oriented techniques without regard to the underlying physical platform. The various components of the system will be designed as Business Objects. The Analysts, having completed the requirements gathering, will concentrate on the Object Oriented analysis and model of the system and will deliver the following: • • • •

A Baseline Project Plan, including feasibility analysis Use cases Object model (class diagrams) Sequence diagrams A proposed system design architecture

Page 3 of 28

Y52.3530: OBJECT ORIENTED SYSTEMS ANALYSIS AND DESIGN

Executive Summary of proposed system
The purpose of the Distributed Accounts Receivable System (DARES) Project is to re-engineer the existing MARS A/R application, designed in Mainframe Systems, to a distributed UNIX platform with added capabilities and enhanced user-interfaces. At the end of the current year, support for the MVS 370 Operating System on the Mainframe will no longer be available. This can adversely affect operations of the MARS Account Receivable application. The MARS Account Receivable application is a critical application in the revenue stream of company XYZ. The accounting for Landline and Cell phone customers are processed on this system. This application receives and process customer payments from 6 U.S banks across the country. It is also responsible for creating invoices for telephone customers and applying payments to customer accounts. MARS keeps a history of customer transactions. Added functionality includes charging customer interest, generating statements, creating aging reports, etc. Since O/S support will no longer be available for the Mainframe system, on which MARS application runs, this application must be migrated to another platform. The proposed platform is a distributed UNIX environment. The UNIX platform was chosen as the strategic production platform sometime ago by company XYZ. The management of the MARS A/R application would like the new A/R system to have all functionality and key features of the current MARS A/R application. The new system must be able to interface with the billing systems, BILLS and INVS, and also the BANK and G/L systems. In addition, the new proposed system should have a user-friendly interface preferably using a thin client and scalable in terms of features and report generation. The Senior Accounts Receivable executive management of company XYZ has asked 2 senior IT analysts, Sudipendra N. Pal and Jason Durham, to manage the overall project of re-engineering the MARS A/R application to the UNIX platform. Sudip and Jason will bring in subject matter expert, Gary Carter as part of the IT Management team that will be responsible for transforming the MARS A/R application to the distributed UNIX platform.

Page 4 of 28

Y52.3530: OBJECT ORIENTED SYSTEMS ANALYSIS AND DESIGN

Baseline Project Plan:
1. Project Overview
1.1 Introduction
Distributed Accounts Receivable System (DARES) Project is taken up to reengineer and upgrade an existing MARS A/R (Accounts Receivable) application, designed on the Mainframe System, to a distributed UNIX platform with added capabilities and enhanced user-interfaces.

1.2 DARES Project Description
The Mainframe Account Receivable System (MARS), currently running on an IBM 370 computer at company XYZ, manages the revenues received from XYZ telephone customers. The phone customers are of two types, landline customers and wireless customers. When customers’ payments are received by company XYZ, in response to invoices, the finance department of company XYZ uses the MARS Account Receivable system to track payments and apply payments to invoices. The CRM system is an interface into 2 billing systems, BILLS and INVS, supplying data to these systems. The MARS system also receives invoices (with details) from 2 separate billing applications, BILLS and INVS. Additionally, this accounts receivable system receives customer payments from 6 banks where customers mail their payment checks. Payments from the banks are automatically assigned to the customer account. The MARS system at company XYZ is being rewritten to run in a distributed UNIX environment. This new project will be called DARES – Distributed Accounts Receivable System. Company XYZ is loosing Operating system support for the mainframe at the end of the year. Also, a distributed system will provide more flexibility in terms of accessing the A/R application and is a cheaper solution. Additionally, the Object Oriented design of the DARES A/R application will allow more efficiency in the maintenance of the application. During the rewrite, some enhancements will be added to the DARES application to support changes in the core business model. The DARES team anticipates some more enhancements during the elaboration phase of the project.

Page 5 of 28

Y52.3530: OBJECT ORIENTED SYSTEMS ANALYSIS AND DESIGN

1.3 Project Background
Overview XYZ Inc. needs to replace its’ existing accounts receivable application that runs a mainframe with an application that runs on a UNIX platform. The accounts receivable system on the UNIX platform will provide the same functionality as the Mainframe A/R system. The new A/R system will be developed in-house at XYZ Inc. Revenue Billing Customer billing is processed at XYZ through the BILLS and INVS billing applications. These billing applications also receive customer information (name, address, etc) from a sales contact application, CRM. BILLS’ is used to bill landline customers whereas INVS bills wireless customers. The BILLS’ and INVS applications interface with the MARS A/R application and transfer all invoices to MARS at the end of every month. These invoices are reconciled by the MARS application administrator. Payments Received Customers send payments for invoices to 6 banks located through out the U.S. The Banks automatically deposit these payments into XYZ’s bank accounts. The banks then send an interface of the deposit information with the customer check routing number to XYX’s MARS A/R system. Based on a predefined routing mapping table, payments from the banks are automatically identified to the customer A/R account. The MARS system records the transaction into an internal database. Payment Application The revenue analyst at XYZ Inc., using supporting documentation sent by the customer, applies received payment(s) against one or more outstanding invoice(s) on the customer A/R account. This is the main function of the MARS application. Application of payment(s) to invoice(s) is performed on an invoice to invoice basis and not on total customer A/R balance. The MARS application provides full online functionality to the analyst. It allows the analyst to credit customer accounts, and investigate discrepancies (over/under payments). The analyst is also able to use MARS to correct erroneous invoices, split and consolidate invoices, enable write-offs, classify invoices etc. These functions have been developed and tailored to facilitate the task of payment application and reconciliation.

Page 6 of 28

Y52.3530: OBJECT ORIENTED SYSTEMS ANALYSIS AND DESIGN
G/L Interface and Reconciliation Procedures The MARS system needs to keep transaction details to allow Revenue and Credit Operations (RCO) analysts to respond to customer inquiries such as “what invoices did you apply check # 1234 to?”. MARS application interfaces with the general ledger. Customer account balances are rolled forward monthly and reconciliation is performed between MARS Aged Trial Balance Reports and the General Ledger to verify accuracy of accounts receivable balances. The MARS system performs a daily system level self test. This ensures the integrity of all system level and customer level account balances. Interest Calculation The MARS application automatically generates interest charges on customer account balances. The analyst can asses interest charges on an account-byaccount basis or on an invoice-by-invoice basis. Detailed interest invoices are produced whenever interests are assessed to a customer. Application Security Entitlements are applied to users of the MARS systems. The level of entitlement depends on job responsibilities. Access to customer accounts is limited to only those individuals responsible for managing and maintaining those accounts.

1.4 Project Goals, Scope, and Impact
The DARES project would offer the Revenue and Credit Operations the same functionality currently available in the MARS A/R application, MARS Miscellaneous and NEWS applications. DARES should be built in compliance with the current technical standards of the XYZ Information Technology department. Project Goals:

1. Re-engineer the MARS A/R application from the Mainframe to the UNIX
2. 3. 4. platform. XYZ looses support for the Mainframe O/S at the end of the year. Get off the Mainframe at the end of year 2010. Develop the DARES application in-house Build a complete replacement system using current state technology. The architecture will be 3-tier using a backend ORACLE database, a middle tier WEB application and a Web client as the front-end running on a PC platform. The project life cycle will be in compliance with XYZ SDLC Take advantage of synergies with other RCO applications (e.g. BILLS) on the new platform.

5. 6.

Page 7 of 28

Y52.3530: OBJECT ORIENTED SYSTEMS ANALYSIS AND DESIGN
7. Assemble a diverse team in IT that can adapt to various roles required to complete project on schedule. Project Scope: Includes:

1. Creating new J2EE application on UNIX distributed platform to replace
the existing MARS A/R mainframe application: a. New application must retain all features of the of current MARS A/R mainframe application. b. Design legacy MARS invoices, screens, and statements as Business Objects. c. Create DARES Application interface into the BILLS landline billing system, retaining all existing features of the current BILLS interface. d. Create DARES Application Interface into the INVS cell phone billing system, retaining all existing features of the current INVS interface. e. Create Application Interface into CRM application. f. Retain Bank interface for payment input. g. Retain G/L interface output. 2. Enhancements negotiated in elaboration phase. 3. Business Objects Reports Does not include: 1. Any major changes to the current functionality. 2. New system interfaces. Impact:


New DARES A/R application will allow XYZ to completely migrate away from the mainframe at a cost savings of $400,000 annually. Support for the Mainframe will be eliminated. Object Oriented design of the DARES application will allow greater efficiencies in its maintenance. Added upgrades to the DARES application will meet current business needs of the A/R department.


Page 8 of 28

Y52.3530: OBJECT ORIENTED SYSTEMS ANALYSIS AND DESIGN

1.5 Complexities
The complexity of the project is considered medium for the following reasons: • • Web technology is widely used and a lot of the required functionality for DARES A/R application can be implemented with re-usable code. Agile methodologies will be used in the development process. Iterative development will provide working versions of the application that have a subset of the total number of required features. This will provide constant feedback from to customers and developers. Additionally, people with the required skill sets will be selected for the job. The more complex part of DARES project will be the data conversion from VSAM to ORACLE. Data migration will require: 1. Extracting the legacy data into tables mirroring the VSAM structure. 2. Creating mapping tables to transform data. 3. Transform data into the new structure and format. 4. Load migrated data into the new DARES application. 5. Prove the accuracy of the load using reports through automated and manual audits. 6. Repeat the process as needed.

2. Deliverables
The DARES application will contain the following modules:
A. CRM module - Users are the CRM interface. - This module interfaces with the CRM application to receive and store customer information (name, addresses, etc). - All “in scope” features present in the legacy MARS CRM module will be included in this new module. B. BILLS module - Users are BILLS interface. - This module interfaces with the BILLS application to receive invoice details of land line customers. - Contact Management extensions will be added to support additional attributes. C. INVS module - Users are the INVS interface. - This module interfaces with the INVS application to receive invoice details of cell phone customers. D. BANK module

Page 9 of 28

Y52.3530: OBJECT ORIENTED SYSTEMS ANALYSIS AND DESIGN
Users are the Banks interface. This module interfaces with the Banks to receive customer checks routing number to DARES A/R system. Application of payment module - Users are Revenue and Credit Operations users. - This module allows application of payments to invoice. Transaction Details module - Users are Revenue and Credit Operations users. - This module allows users to respond to customer inquiries. Interest module - Users are Revenue and Credit Operations users. - This module allows RCO analyst to assess interest charges on an account-by-account basis. Customer statements module - Users are RCO analysts. - This module generates customer statements. G/L and Reconciliation - This module interfaces with the general ledger. User Access Maintenance Module - Users are Internal Business Staff. - This module provides for maintaining appropriate access for the various types of users of the DARES system. -

E. F. G.

H. I. J.

Documentation for the on going development of DARES will be provided.

3. Project Management
This project has an aggressive schedule. The project schedule will be monitored and updated on a weekly basis. Project team status meetings will be held every Tuesday at 2pm. and minutes will be available the following Wednesday. All project documentation will be available on-line at http://projects.dares.xyz.com.

Comparative Analysis
A project team was organized to perform a buy vs. build analysis for the DARES A/R application. The team consisted Jim Woo, Director of Finance at XYZ, Sudip Pal and Jason Durham, two senior IT analysts at XYZ. After meeting with leading application vendors, it was determined that an off the shelf solution could not meet the requirements of the DARES application. It was decided to develop the application in-house.

Project Team

Page 10 of 28

Y52.3530: OBJECT ORIENTED SYSTEMS ANALYSIS AND DESIGN
TEAM MEMBER ORGANIZATIO N RESPONSIBILITY

Page 11 of 28

Y52.3530: OBJECT ORIENTED SYSTEMS ANALYSIS AND DESIGN
Jim Woo Sudip Pal Jason Durham Gary Carter Doreen Lee Winston Hill Ricardo Young Richard Thomas Evelyn Peters Grace Richmond Sanjay Gupta IT IT IT IT IT IT IT IT IT IT IT Finance Director Project Mgr., Business Analyst Technical Lead, Bus. Analyst Architect, Domain Expert Developer, Server Side Lead Developer, GUI side Lead Developer, Server side Developer, Server side Developer, GUI side Data Migration/Legacy MARS DBA

AA BB CC DD EE FF

RCO RCO RCO RCO RCO RCO

Project Owner Client Director – Operations Client Director – Reporting Client Manager – Operations Client Manager – Reporting Client Contact - Analyst

4. Project Estimates
Key Project milestones relative to project start are as follows: Project Milestones Target Date

Page 12 of 28

Y52.3530: OBJECT ORIENTED SYSTEMS ANALYSIS AND DESIGN
Project start RPF Completed by XYZ systems Analyst RFC issued by Financial Management Proposals due at XYZ Inc. Vendor Presentations Vendor evaluation completed by XYZ Vendor contract negotiation started Vendor contract negotiations completed Vendor starts Work on DARES project Project completion 6/1/2009 8/21/2009 10/20/2009 11/19/2009 11/25/2009 12/5/2009 12/10/2009 12/15/2009 1/5/2010 1/5/2012

5. Resource Requirements – Team and Support Resources
The following personnel resources are required to complete this project: Personnel Resource Types Project Manager (XYZ assigned) Business Analyst (Vendor Assigned) Technical Architect (Vendor Assigned) Database Administrator (XYZ Assigned) JAVA Developers (XYZ (2) & Vendor assigned (3)) Subject Matter Experts (XYZ ) – RCO personnel Total Personnel Resources Quantity 2 1 1 2 5 6 17

6. DARES Software and Hardware Environment

Software Environment
Software Operating System Database Application Software Application Server Development Env. Modeling Product/Release Red Hat Linux 5.2 Oracle 10g Java JDK 1.5.0_17 WebLogic 11g IntelliJ, Apache ANT Rational Rose 2003 Comments snowbird thor (Solaris 10)

Page 13 of 28

Y52.3530: OBJECT ORIENTED SYSTEMS ANALYSIS AND DESIGN
Source Code control Reporting Bug Tracking PVCS Business Objects Jira

6.1 Hardware Environment
The middle tier Web server will run on a LINUX server (snowbird). The database will run on a Solaris 10 server (thor). The client will be delivered to the user’s desktop via Java WebStart.

7. Estimated Costs
Expense Labor Internal External Hardware Software Other Total $500,000 $300,000 $225,000 $75,000 $20,000 $1,120,000 $500,000 $300,000 $225,000 $75,000 $20,000 $1,120,000 Year 1 Budget Year 2 Budget

8. Feasibility Analysis
The DARES project was estimated to take 2 years to complete. It was estimated that the project will have a one time cost of $2.24 million spread out evenly over the 2 year development phase. Beginning in the 3rd. year, the DARES project will have a recurring expense of $20,000 per year for additional Oracle licenses. Upon rollout of the application in year 3, company XYZ will no longer need the mainframe computer at a saving of $400,000 per year. Assumptions: • • • • The maximum life for the application is 10 years All benefits and costs are received/expensed at the end of each year For the one-time implementation cost $1,120,000 is expensed at the end of year 1, and $1,120,000 at the end of year 2. Assume a discount rate of 5%.

Page 14 of 28

Y52.3530: OBJECT ORIENTED SYSTEMS ANALYSIS AND DESIGN

Please refer to Feasibility Analysis spreadsheet below for details of the Feasibility study.

Page 15 of 28

Y52.3530: OBJECT ORIENTED SYSTEMS ANALYSIS AND DESIGN

Company XYZ
Project: DARES Net Present Value (NPV) and Return on Investment (ROI)
Discount Rate 5% Year 1 2 3 4 5 6 7 8 9 10 11 12 Fixed Cost (A) $1,120,000.00 $1,120,000.00 Recurring Cost (B) $ $ $ 20,000.00 $ 20,000.00 $ 20,000.00 $ 20,000.00 $ 20,000.00 $ 20,000.00 $ 20,000.00 $ 20,000.00 $ 20,000.00 $ 20,000.00 Sum= Costs Total Cost (A+B) $ 1,120,000.00 $ 1,120,000.00 $ 20,000.00 $ 20,000.00 $ 20,000.00 $ 20,000.00 $ 20,000.00 $ 20,000.00 $ 20,000.00 $ 20,000.00 $ 20,000.00 $ 20,000.00 $ 2,440,000.00 Discount 0.952 0.907 0.864 0.823 0.784 0.746 0.711 0.677 0.645 0.614 0.585 0.557 NPV= PV of Cost $ 1,066,666.67 $ 1,015,873.02 $ 17,276.75 $ 16,454.05 $ 15,670.52 $ 14,924.31 $ 14,213.63 $ 13,536.79 $ 12,892.18 $ 12,278.27 $ 11,693.59 $ 11,136.75 $ 2,222,616.51 Benefits Savings PV of Benefits $ $ $ $ $ 400,000.00 $ 345,535.04 $ 400,000.00 $ 329,080.99 $ 400,000.00 $ 313,410.47 $ 400,000.00 $ 298,486.16 $ 400,000.00 $ 284,272.53 $ 400,000.00 $ 270,735.74 $ 400,000.00 $ 257,843.57 $ 400,000.00 $ 245,565.30 $ 400,000.00 $ 233,871.72 $ 400,000.00 $ 222,734.97 $ 4,000,000.00 $ 2,801,536.48

ROI=

0.260

26.05%

Page 16 of 28

Y52.3530: OBJECT ORIENTED SYSTEMS ANALYSIS AND DESIGN

Break-even Analysis
Year 1 Annual PV Benefits Cumulative Benefits Annual PV Costs Cumulative Costs Annual PV Cash Flow Cumulative NPV Cash Flow 0.00 0.00 1,066,666.67 1,066,666.67 (1,066,666.67 ) Year 2 0.00 0.00 1,015,873.02 2,082,539.68 (1,015,873.02 ) (2,082,539.68 ) Year 3 345,535.04 345,535.04 17,276.75 2,099,816.43 328,258.29 (1,754,281.40) Year 4 329,080.99 674,616.03 16,454.05 2,116,270.48 312,626.94 (1,441,654.45 ) Year 5 313,410.47 988,026.50 15,670.52 2,131,941.01 297,739.94 (1,143,914.51 ) Year 7 284,272.53 1,570,785.19 14,213.63 2,161,078.94 270,058.91 (590,293.76) Year 8 270,735.74 1,841,520.93 13,536.79 2,174,615.73 257,198.96 (333,094.80) Year 9 257,843.57 2,099,364.50 12,892.18 2,187,507.91 244,951.39 (88,143.41) Year 10 245,565.30 2,344,929.80 12,278.27 2,199,786.17 233,287.04 145,143.63 Year 11 233,871.72 2,578,801.51 11,693.59 2,211,479.76 222,178.13 367,321.76 Year 12 222,734.97 2,801,536.48 11,136.75 2,222,616.51 211,598.22 578,919.98

Break-even in year 10 Break-even in :

0.378 9.38

-> which part of the year years

Page 17 of 28

Y52.3530: OBJECT ORIENTED SYSTEMS ANALYSIS AND DESIGN

Use Cases
Use Case Diagram
The Use Case Diagram shows user interaction with the proposed system. The various actors of the Class Diagram are: 1. External Systems which includes: a. Sales Contact CRM System b. BILLS System c. INVS System 2. Customers 3. Banks 4. Users

The various use cases along with their description is shown in the following pages.

Page 18 of 28

Y52.3530: OBJECT ORIENTED SYSTEMS ANALYSIS AND DESIGN

DARES System
Makes Payment Customer «extends» Receive/Validate Customer Checks Bank

Receive Customer Info

<<include>>

<<include>>

Sales Contact CRM System Assign Payment to Customer Account <<include>>

<<include>> Receive Invoice Details External Systems [Generalized] BILLS <<include>> Apply Checks Against Invoice

<<include>> <<include>> <<include>>

Check Outstanding Invoices

<<include>> User

INVS

Update Invoice Payment Status <<include>>

Record Transaction Details

Page 19 of 28

Y52.3530: OBJECT ORIENTED SYSTEMS ANALYSIS AND DESIGN Use Case Description
Use Case Title: Actors: Stakeholders: Precondition: Trigger: Success Guarantee: Main Scenario: Extensions: Use Case Title: Actors: Stakeholders: Precondition: Trigger: Success Guarantee: Main Scenario: Makes Payment Customer, Bank Customer, Bank Customer making a payment Bank receives Customer Checks 1. Customer sends Check to Bank 2. Bank receives the check 3. Bank sends the check for validation None Receive Customer Info Sales Contact CRM System Sales Manager, Sales and Marketing Department The Customer details must be valid and up-to-date System imports Customer data from CRM System Customer Info saved in System Database 4. Sales Contact CRM System executes query of existing customers. 5. Query results are stored in database file. 6. Database file exported and imported in System database. 1. System to check for duplicate records while importing: a. Update existing records b. Prompt for number of updates 2. Add new records at the end of the table Receive Invoice Details BILLS System, NSB System Billing Department, Sales Manager The Invoice details must be valid and complete System imports Invoice data from BILLS System and NSB System Invoice Details and line items saved in the System Database 1. BILLS System executes query on outstanding Invoices. 2. Queried results are saved in a temporary database table. 3. NSB System executes query on Invoice line items for the outstanding invoices. 4. Queried results saved in a temporary database table. 5. Invoice header and details extracted from both BILLS and NSB are loaded into the System

Extensions:

Use Case Title: Actors: Stakeholders: Precondition: Trigger: Success Guarantee: Main Scenario:

Page 20 of 28

Y52.3530: OBJECT ORIENTED SYSTEMS ANALYSIS AND DESIGN
Database in two separate tables. 1. System to check for duplicate records while importing. Receive/Validate Customer Checks Banks (all 6 banks) Customers, Bank Customers should make payments only to the 6 designated Banks. Customers mail their payment checks to the Bank/s Customer Account credited 1. Customers mail their check to the Bank 2. Bank sends the check to the System 3. System receives the check and invokes another use case – “Assign payment to Customer Account” None Assign Payment to Customer Account None. Generalized, Abstract Use Case Bank, Customers 1. System must receive Customer Payment from the 6 Banks. 2. Bank account mapping table must be valid and kept up-to-date. Invoked by “Receive Customer Payments” use case Customer Account credited 1. Receives Payment from Bank 2. Receives Customer Info by invoking the Use Case “Receive Customer Info” 3. Maps Customer payment with Customer Account based on pre-defined bank account mapping table 4. Credits customer account with amount of payment received 1. Send alerts to Bank/s if Customer shows a debit balance.

Extensions: Use Case Title: Actors: Stakeholders: Precondition: Trigger: Success Guarantee: Main Scenario:

Extensions: Use Case Title: Actors: Stakeholders: Precondition:

Trigger: Success Guarantee: Main Scenario:

Extensions:

Use Case Title: Actors: Stakeholders: Precondition: Trigger: Success Guarantee: Main Scenario:

Apply checks against Invoice User Billing Department, Accounts Receivable Department Bank received payments and credited customer account. On receipt of customer payment – invokes the use case “Receive Customer Payments”. Apply checks against outstanding invoices. 1. Receives payment details and customer info

Page 21 of 28

Y52.3530: OBJECT ORIENTED SYSTEMS ANALYSIS AND DESIGN
from Use case “Receive Customer Payments” Receives Invoice Details from Use case “Receive Invoice Details” Check outstanding invoices by invoking another abstract use case “Check Outstanding Invoices” Applies received checks against one or more outstanding invoice(s) for the customer. Checks received but no Invoices found – are to be reported promptly to the Accounts Receivable and Billing Department. Checks for which the Invoice details are not found are to be kept on hold for 6 months.

2. 3. 4. Extensions: 1. 2.

Use Case Title: Actors: Stakeholders: Precondition: Trigger: Success Guarantee: Main Scenario:

Extensions:

Check Outstanding Invoices None. Generalized, Abstract Use Case Billing Department System successfully received the Invoice details from External systems (BILLS and NSB) Receive Invoice details Invoking Update Invoice Use case 1. Invokes “Receive Invoice Details” use case. 2. Receives applied payments against invoices from another use case “Apply checks against Invoice”. 3. Invokes another use case “Update Invoice” None

Use Case Title: Actors: Stakeholders: Precondition: Trigger: Success Guarantee: Main Scenario:

Extensions:

Update Invoice Payment Status None. Generalized, Abstract Use Case User Payment applied against Invoice Check Outstanding Invoices use case Updating outstanding invoice with payment received. 1. Receives Outstanding Invoice details from use case – “Check Outstanding Invoices”. 2. Invokes “Apply checks against Invoices” use case. 3. Updates the outstanding Invoice with payment received and changes the status from “Outstanding” to “Paid” None

Use Case Title: Actors:

Record Transaction Details User

Page 22 of 28

Y52.3530: OBJECT ORIENTED SYSTEMS ANALYSIS AND DESIGN
Stakeholders: Precondition: Trigger: Success Guarantee: Main Scenario: User Payment applied against Invoice and Invoice updated User responding to customer inquiry Informing customer(s) about the current balance on their account with details of invoices paid and outstanding 1. Customer enquires about Invoice payment/ Customer Balance. 2. Invokes “Assign payment to Customer Account” use case to find out about Customer Account balance/status 3. Invokes “Update Invoice” use case to find out about invoice details and any paid/outstanding invoices 4. Saves transaction details in database tables for management reports and archives for future use. 5. User can generate customer statements, create aging reports and charge interests against outstanding invoices. None.

Extensions:

Page 23 of 28

Y52.3530: OBJECT ORIENTED SYSTEMS ANALYSIS AND DESIGN

Object model (Class Diagrams)

Page 24 of 28

Y52.3530: OBJECT ORIENTED SYSTEMS ANALYSIS AND DESIGN

Sequence diagrams
The following sequence diagrams are for the use cases “Apply Checks” and “Receive/Validate Customer Checks”. They depict the interaction among objects in chronological order and capture the operations that must be added to the classes in the class diagrams.
Sequence Diagram of use Case Apply Checks
Boundry Class Control Class Entity Class Entity Class Entity Class Entity Class Entity Class

:User

:ApplyChecks ()

:ChkControl

:User

:Customer Payment

:Invoice Details

:Outstanding Invoice

:Record Transaction

//provide login Info

//request login

()

//verify login ()

//apply checks to invoice

()

//apply checks to invoice

()

//get payment details

()

//get invoice details

()

//get outstanding invoice //Update invoice ()

()

//record transaction

()

Page 25 of 28

Y52.3530: OBJECT ORIENTED SYSTEMS ANALYSIS AND DESIGN
Sequence Diagram of use case Receive/Validate Customer Checks
Boundry Class Controller Class Boundry Class Entiry Class Entiry Class

BANK

:RecvCustChecks

:RecvControl

:RecvCustInfo

:AssignPaymentToAccount

:RecordTransaction

//sendChecks() //receiveChecks() //getCustomerInfo()

//assignPayment()

//updateCustomerAccount()

//recordTransaction()

Page 26 of 28

Y52.3530: OBJECT ORIENTED SYSTEMS ANALYSIS AND DESIGN

Proposed system design architecture
The system design diagram depicts the 3-tier architecture design of the DARES system. The client will be delivered to the user’s desktop via Java WebStart in the presentation layer, running on a LINUX server. The Java Application server in the Business layer runs on a LINUX server and communicates with the Presentation and Data Layers via middleware EJB. The EJB communicates with JDBC for access to the data layer. The ORACLE database server runs on a SUN E-2900 server running Solaris 10 OS.

Page 27 of 28

Y52.3530: OBJECT ORIENTED SYSTEMS ANALYSIS AND DESIGN

Router
Internet

Load Balancer Firewall BUSINESS LAYER DATA LAYER

PRESENTATION LAYER

Application Server User
Web Browser X/HTML CSS Java-scripts Java Applet Cached content Proxy Servers EJB (Enterprise Java Beans) J D B C

RDBMS

Database

Database Servers

HTTP Requests/ Response Web Server [JSP] EJB (Enterprise Java Beans)

J D B C

CMS

Database

[Servlets]

Content Management Server

FTP Requests

FTP Server

VIEW

CONTROLLER

MODEL

Architecture for DARES System

Page 28 of 28

Sign up to vote on this title
UsefulNot useful