OOSAD Final Project

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 3
Executive Summary of the proposed system 4
Baseline Project Plan 5
Project Overview 5
Deliverables 9
Project Management 10
Project Estimates 12
Project Resource Requirements 12
Software and Hardware Requirement 12
Estimated Costs 13
Feasibility Analysis 13
Use Cases 16
Object Model (Class Diagram) 22
Sequence Diagrams 23
Proposed System Design Architecture 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
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
Baseline Project Plan:
1. Project Overview
1.1 Introduction
Distributed Accounts Receivable System (DARES) Project is taken up to re-

engineer 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
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
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-by-
account 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
platform. XYZ looses support for the Mainframe O/S at the end of the
year.
2. Get off the Mainframe at the end of year 2010.
3. Develop the DARES application in-house
4. 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.
5. The project life cycle will be in compliance with XYZ SDLC
6. Take advantage of synergies with other RCO applications (e.g. BILLS)
on the new platform.
Page 7 of 28
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
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
- Users are the Banks interface.

- This module interfaces with the Banks to receive customer
checks routing number to DARES A/R system.
E. Application of payment module
- Users are Revenue and Credit Operations users.
- This module allows application of payments to invoice.
F. Transaction Details module
- This module allows users to respond to customer inquiries.
G. Interest module
- This module allows RCO analyst to assess interest charges on
an account-by-account basis.
H. Customer statements module
- Users are RCO analysts.
- This module generates customer statements.
I. G/L and Reconciliation
- This module interfaces with the general ledger.
J. 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.
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
TEAM MEMBER ORGANIZATIO RESPONSIBILITY

N
Page 11 of 28
Jim Woo IT Finance Director

Sudip Pal IT Project Mgr., Business Analyst
Jason Durham IT Technical Lead, Bus. Analyst
Gary Carter IT Architect, Domain Expert
Doreen Lee IT Developer, Server Side Lead
Winston Hill IT Developer, GUI side Lead
Ricardo Young IT Developer, Server side
Richard Thomas IT Developer, Server side
Evelyn Peters IT Developer, GUI side
Grace Richmond IT Data Migration/Legacy MARS
Sanjay Gupta IT DBA
AA RCO Project Owner

BB RCO Client Director – Operations
CC RCO Client Director – Reporting
DD RCO Client Manager – Operations
EE RCO Client Manager – Reporting
FF RCO Client Contact - Analyst
4. Project Estimates
Key Project milestones relative to project start are as follows:
Project Milestones Target Date
Page 12 of 28
Project start 6/1/2009

RPF Completed by XYZ systems Analyst 8/21/2009
RFC issued by Financial Management 10/20/2009
Proposals due at XYZ Inc. 11/19/2009
Vendor Presentations 11/25/2009
Vendor evaluation completed by XYZ 12/5/2009
Vendor contract negotiation started 12/10/2009
Vendor contract negotiations completed 12/15/2009
Vendor starts Work on DARES project 1/5/2010
Project completion 1/5/2012
5. Resource Requirements – Team and Support Resources

The following personnel resources are required to complete this project:
Personnel Resource Types Quantity

Project Manager (XYZ assigned) 2
Business Analyst (Vendor Assigned) 1
Technical Architect (Vendor Assigned) 1
Database Administrator (XYZ Assigned) 2
JAVA Developers (XYZ (2) & Vendor assigned (3)) 5
Subject Matter Experts (XYZ ) – RCO personnel 6
Total Personnel Resources 17
6. DARES Software and Hardware Environment
Software Environment
Software Product/Release Comments
Operating System Red Hat Linux 5.2 snowbird
Database Oracle 10g thor (Solaris 10)
Application Software Java JDK 1.5.0_17
Application Server WebLogic 11g
Development Env. IntelliJ, Apache ANT
Modeling Rational Rose 2003
Page 13 of 28
Source Code control PVCS

Reporting Business Objects
Bug Tracking 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 Year 1 Budget Year 2 Budget
Labor
Internal $500,000 $500,000
External $300,000 $300,000
Hardware $225,000 $225,000
Software $75,000 $75,000
Other $20,000 $20,000
Total $1,120,000 $1,120,000
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
Please refer to Feasibility Analysis spreadsheet below for details of the

Feasibility study.
Page 15 of 28
Company XYZ
Project: DARES
Net Present Value (NPV) and Return on Investment (ROI)

Discount Rate 5%
Costs Benefits
Year Fixed Cost (A) Recurring Cost (B) Total Cost (A+B) Discount PV of Cost Savings PV of Benefits
1 $1,120,000.00 $ - $ 1,120,000.00 0.952 $ 1,066,666.67 $ - $ -
2 $1,120,000.00 $ - $ 1,120,000.00 0.907 $ 1,015,873.02 $ - $ -
3 $ 20,000.00 $ 20,000.00 0.864 $ 17,276.75 $ 400,000.00 $ 345,535.04
4 $ 20,000.00 $ 20,000.00 0.823 $ 16,454.05 $ 400,000.00 $ 329,080.99
5 $ 20,000.00 $ 20,000.00 0.784 $ 15,670.52 $ 400,000.00 $ 313,410.47
6 $ 20,000.00 $ 20,000.00 0.746 $ 14,924.31 $ 400,000.00 $ 298,486.16
7 $ 20,000.00 $ 20,000.00 0.711 $ 14,213.63 $ 400,000.00 $ 284,272.53
8 $ 20,000.00 $ 20,000.00 0.677 $ 13,536.79 $ 400,000.00 $ 270,735.74
9 $ 20,000.00 $ 20,000.00 0.645 $ 12,892.18 $ 400,000.00 $ 257,843.57
10 $ 20,000.00 $ 20,000.00 0.614 $ 12,278.27 $ 400,000.00 $ 245,565.30
11 $ 20,000.00 $ 20,000.00 0.585 $ 11,693.59 $ 400,000.00 $ 233,871.72
12 $ 20,000.00 $ 20,000.00 0.557 $ 11,136.75 $ 400,000.00 $ 222,734.97
Sum= $ 2,440,000.00 $ 4,000,000.00
NPV= $ 2,222,616.51 $ 2,801,536.48
ROI= 0.260 26.05%
Page 16 of 28
Break-even Analysis
Year 1 Year 2 Year 3 Year 4 Year 5 Year 7 Year 8 Year 9 Year 10 Year 11 Year 12
Annual PV Benefits 0.00 0.00 345,535.04 329,080.99 313,410.47 284,272.53 270,735.74 257,843.57 245,565.30 233,871.72 222,734.97
Cumulative Benefits 0.00 0.00 345,535.04 674,616.03 988,026.50 1,570,785.19 1,841,520.93 2,099,364.50 2,344,929.80 2,578,801.51 2,801,536.48
Annual PV Costs 1,066,666.67 1,015,873.02 17,276.75 16,454.05 15,670.52 14,213.63 13,536.79 12,892.18 12,278.27 11,693.59 11,136.75
Cumulative Costs 1,066,666.67 2,082,539.68 2,099,816.43 2,116,270.48 2,131,941.01 2,161,078.94 2,174,615.73 2,187,507.91 2,199,786.17 2,211,479.76 2,222,616.51
(1,066,666.67 (1,015,873.02
Annual PV Cash Flow ) ) 328,258.29 312,626.94 297,739.94 270,058.91 257,198.96 244,951.39 233,287.04 222,178.13 211,598.22
Cumulative NPV Cash (2,082,539.68 (1,441,654.45 (1,143,914.51
Flow ) (1,754,281.40) ) ) (590,293.76) (333,094.80) (88,143.41) 145,143.63 367,321.76 578,919.98
Break-even in year
10 0.378 -> which part of the year
Break-even in : 9.38 years
Page 17 of 28
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
DARES System
Makes Payment
Customer «extends»
Bank
Receive/Validate
Customer Checks
Receive Customer
Info <<include>>
<<include>>
Sales Contact CRM System

Assign Payment to
Customer Account
<<include>>
<<include>>
Receive Invoice <<include>>

Details
Apply Checks
External Systems [Generalized] BILLS Against Invoice
<<include>>
<<include>>
<<include>>
Check Outstanding
<<include>>
Invoices
User
Update Invoice
INVS
Payment Status
<<include>>
Record Transaction
Details
Page 19 of 28
Use Case Description
Use Case Title: Makes Payment

Actors: Customer, Bank
Stakeholders: Customer, Bank
Precondition:
Trigger: Customer making a payment
Success Guarantee: Bank receives Customer Checks
Main Scenario: 1. Customer sends Check to Bank
2. Bank receives the check
3. Bank sends the check for validation
Extensions: None
Use Case Title: Receive Customer Info

Actors: Sales Contact CRM System
Stakeholders: Sales Manager, Sales and Marketing Department
Precondition: The Customer details must be valid and up-to-date
Trigger: System imports Customer data from CRM System
Success Guarantee: Customer Info saved in System Database
Main Scenario: 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.
Extensions: 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
Use Case Title: Receive Invoice Details

Actors: BILLS System, NSB System
Stakeholders: Billing Department, Sales Manager
Precondition: The Invoice details must be valid and complete
Trigger: System imports Invoice data from BILLS System and
NSB System
Success Guarantee: Invoice Details and line items saved in the System
Database
Main Scenario: 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
Page 20 of 28
Database in two separate tables.

Extensions: 1. System to check for duplicate records while
importing.
Use Case Title: Receive/Validate Customer Checks

Actors: Banks (all 6 banks)
Stakeholders: Customers, Bank
Precondition: Customers should make payments only to the 6
designated Banks.
Trigger: Customers mail their payment checks to the Bank/s
Success Guarantee: Customer Account credited
Main Scenario: 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”
Extensions: None
Use Case Title: Assign Payment to Customer Account

Actors: None. Generalized, Abstract Use Case
Stakeholders: Bank, Customers
Precondition: 1. System must receive Customer Payment from
the 6 Banks.
2. Bank account mapping table must be valid and
kept up-to-date.
Trigger: Invoked by “Receive Customer Payments” use case
Success Guarantee: Customer Account credited
Main Scenario: 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
Extensions: 1. Send alerts to Bank/s if Customer shows a
debit balance.
Use Case Title: Apply checks against Invoice

Actors: User
Stakeholders: Billing Department, Accounts Receivable Department
Precondition: Bank received payments and credited customer
account.
Trigger: On receipt of customer payment – invokes the use
case “Receive Customer Payments”.
Success Guarantee: Apply checks against outstanding invoices.
Main Scenario: 1. Receives payment details and customer info
Page 21 of 28
from Use case “Receive Customer Payments”

2. Receives Invoice Details from Use case
“Receive Invoice Details”
3. Check outstanding invoices by invoking another
abstract use case “Check Outstanding Invoices”
4. Applies received checks against one or more
outstanding invoice(s) for the customer.
Extensions: 1. Checks received but no Invoices found – are to
be reported promptly to the Accounts
Receivable and Billing Department.
2. Checks for which the Invoice details are not
found are to be kept on hold for 6 months.
Use Case Title: Check Outstanding Invoices

Stakeholders: Billing Department
Precondition: System successfully received the Invoice details from
External systems (BILLS and NSB)
Trigger: Receive Invoice details
Success Guarantee: Invoking Update Invoice Use case
Main Scenario: 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”
Extensions: None
Use Case Title: Update Invoice Payment Status

Stakeholders: User
Precondition: Payment applied against Invoice
Trigger: Check Outstanding Invoices use case
Success Guarantee: Updating outstanding invoice with payment received.
Main Scenario: 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”
Extensions: None
Use Case Title: Record Transaction Details

Actors: User
Page 22 of 28
Stakeholders: User
Precondition: Payment applied against Invoice and Invoice updated
Trigger: User responding to customer inquiry
Success Guarantee: Informing customer(s) about the current balance on
their account with details of invoices paid and
outstanding
Main Scenario: 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.
Extensions: None.
Page 23 of 28
Object model (Class Diagrams)
Page 24 of 28
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
Sequence Diagram of use case Receive/Validate Customer Checks
Boundry Class Controller Class Boundry Class Entiry Class Entiry Class
:RecvCustChecks :RecvControl :RecvCustInfo :AssignPaymentToAccount :RecordTransaction

BANK
//sendChecks()
//receiveChecks()
//getCustomerInfo()
//assignPayment()
//updateCustomerAccount()
//recordTransaction()
Page 26 of 28
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
Router
Load Balancer
Firewall
Internet
BUSINESS LAYER DATA LAYER
PRESENTATION LAYER
RDBMS
Database
Application Server
User Cached
content Proxy J
EJB
Web Browser Servers D
(Enterprise Java Database Servers
B
Beans)
X/HTML C
CSS HTTP
Java-scripts Requests/
Java Applet Response
J
Web Server EJB D
(Enterprise Java B
[JSP] Beans) C
CMS
Database
[Servlets]
Content Management Server
FTP
Requests
FTP Server
VIEW CONTROLLER MODEL
Architecture for DARES System

Page 28 of 28

OOSAD Final Project

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

OOSAD Final Project

Hochgeladen von

Copyright:

Verfügbare Formate

Object Oriented System Analysis and

Submitted on: October 23, 2009

Term Paper: Group 7

Cover letter of the proposed DARES system 3

Executive Summary of the proposed system 4

Baseline Project Plan 5

Project Resource Requirements 12

Software and Hardware Requirement 12

Object Model (Class Diagram) 22

Proposed System Design Architecture 25

Term Paper: Group 7

Cover letter of the proposed DARES system:

Sudipendra N. Pal, Jason Durham, Gary Carter

The Analysts, having completed the requirements gathering, will concentrate

• A Baseline Project Plan, including feasibility analysis

Executive Summary of proposed system

The MARS Account Receivable application is a critical application in the

The Senior Accounts Receivable executive management of company XYZ has

Baseline Project Plan:

Distributed Accounts Receivable System (DARES) Project is taken up to re-

1.2 DARES Project Description

The Mainframe Account Receivable System (MARS), currently running on an

The MARS system at company XYZ is being rewritten to run in a distributed

1.3 Project Background

G/L Interface and Reconciliation Procedures

The MARS application automatically generates interest charges on customer

Entitlements are applied to users of the MARS systems. The level of

1.4 Project Goals, Scope, and Impact

7. Assemble a diverse team in IT that can adapt to various roles required

1. Creating new J2EE application on UNIX distributed platform to replace

a. New application must retain all features of the of current MARS

2. Enhancements negotiated in elaboration phase.

Does not include:

1. Any major changes to the current functionality.

• Support for the Mainframe will be eliminated.

• Object Oriented design of the DARES application will allow greater

• Added upgrades to the DARES application will meet current business

The complexity of the project is considered medium for the following

• Web technology is widely used and a lot of the required functionality

1. Extracting the legacy data into tables mirroring the VSAM

The DARES application will contain the following modules:

- Users are the Banks interface.

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

This project has an aggressive schedule. The project schedule will be

TEAM MEMBER ORGANIZATIO RESPONSIBILITY

Jim Woo IT Finance Director

AA RCO Project Owner

Project Milestones Target Date

Project start 6/1/2009

5. Resource Requirements – Team and Support Resources

Personnel Resource Types Quantity

6. DARES Software and Hardware Environment

Source Code control PVCS

6.1 Hardware Environment

Expense Year 1 Budget Year 2 Budget

Internal $500,000 $500,000

External $300,000 $300,000

Hardware $225,000 $225,000

Software $75,000 $75,000

Other $20,000 $20,000

Total $1,120,000 $1,120,000

The DARES project was estimated to take 2 years to complete. It was

• The maximum life for the application is 10 years