Financial Management System

(1)

UNIVERSITY OF NEBRASKA—LINCOLN

Financial Management

System

CSCE 156 – Computer Science II Project

Student 002 11/15/2013 Version 3.0

The contents of this document describe the object-‐oriented software design for the new financial management system built for DCH Financial Group.

(2)

Revision History

Version Description of Change(s) Author(s) Date

1.0 Initial draft of this design document Student 002 2013/09/15 2.0 Updated diagrams, ER Diagram added,

Database and Data Structure sections added, minor updates to previous text

Student 002 2013/10/25

3.0 Data Structure section added, minor

updates and refactoring in other areas Student 002 2013/11/15

(3)

Revision History ... 1

1. Introduction ... 3

1.1 Purpose of this Document ... 3

1.2 Scope of the Project ... 3

1.3 Definitions, Acronyms, Abbreviations ... 3

1.3.1 Definitions ... 3

1.3.2 Abbreviations & Acronyms ... 3

2. Overall Design Description ... 4

2.1 Alternative Design Options ... 4

3. Detailed Component Description ... 4

3.1 Database Design ... 4

3.1.1 Component Testing Strategy ... 5

3.2 Class/Entity Model ... 6

3.3 Database Interface ... 7

3.4 Design & Integration of Data Structures ... 7

3.5 Changes & Refactoring ... 8

4. Bibliography ... 9

(4)

1. Introduction

This is the Software Design Description for the Financial Management System designed for DCH Financial Group. It outlines the technical design of the application that is being developed to replace their aging AS4000 green-‐screen system which is used for portfolio and asset management.

1.1 Purpose of this Document

The purpose of this document is to describe the design techniques of the new system. It covers failures and successes, testing methodology, and implementation strategies. This document also outlines the MySQL database and its relationship to the newly developed Java application.

1.2 Scope of the Project

The Java-‐based financial management system developed for DCH Financial Group is designed to replace their aging financial management system. It is designed to manage portfolios of various assets for their customers. These financial assets include deposit accounts, stocks, and private investments. The new system is also designed to incorporate DCH Financial Group’s proprietary risk management business practices.

1.3 Definitions, Acronyms, Abbreviations

1.3.1 Definitions

Deposit Account – FDIC insured accounts

Stocks – investment accounts that consist of a number of share of a particularly traded stock Private Investments – investment accounts that represent investments in private enterprises Omega – a DCH Financial Group proprietary risk measurement

APY – annual percentage yield or annual rate of return

Portfolio Risk – weighted risk (omega) measure of the a collection of assets Broker – portfolio managers

1.3.2 Abbreviations & Acronyms

ADT – Abstract Data Type

API – Application Programming Interface ER Diagram – Entity-‐Relationship Diagram JDBC – Java Database Connectivity

(5)

In keeping with the OOP paradigm for this application development the use of unique classes is

essential. Relevant data, methods, and functionality are built into respective classes based on designing good encapsulation enforcement. The current primary classes include: Person, Address, Asset, Portfolio, PortfolioReport, PortfolioData, and DataParser.

The Asset class is made abstract and from it three asset subclasses are created. These subclasses include Stock, Deposit_Account, Private_Investment. Furthermore, the Person class has a subclass called Broker which maintains a “Broker is-‐a Person” relationship.

The overall goal of the development of these classes is to promote reusability and proper abstraction. This goal is reached via the implementation of the classes and subclasses outlined above.

2.1 Alternative Design Options

Alternative design options considered in the development of this application:

• Omitting the Address class and folding that functionality into the Person class • Omit the Asset class altogether and have each (current) subclass be standalone • Omit the DataParser class and load/parse text files in the main class

• Create a class called Name to control any methods related to getting and setting names

3. Detailed Component Description

Classes are used to represent instances of given objects. Object creation is handled by constructor methods in the respective classes via provided data. The provided data values are encapsulated and belong to the class they were used to create. By default, all member variables of classes are set to private so that variable interfacing is handled by getter and setter methods contained with the parent classes.

3.1 Database Design

The ER Diagram presented in Figure 1 represents the application’s database schema. This diagram denotes the primary tables with their respective fields and relationships to other tables in the schema. The database schema is loosely based on the Java class entities presented in the application. Careful planning was done to enforce separation of distinct tables and ensure encapsulation of proper information into their respective, distinct tables.

(6)

Figure 1: ER Diagram

3.1.1 Component Testing Strategy

Testing of the database displayed in the ER Diagram from Figure 1 is conducted by querying the database with standard and corner case queries. For Phase III of the application development, implementation and testing of the database is conducted via MySQL Workbench and subsequent queries.

The database is built upon the data provided from Phase I/II. Construction of the database from the data is built to model the form detailed in the ER Diagram. Construction of the database included dropping existing tables so that the construction of subsequent tables was according to the chosen design. Testing of the database included queries that inserted, updated, and removed select data into/from the

database.

(7)

The UML Diagram presented in Figure 2 represents the application’s classes and their functionality. Full implementation of the presented classes has been completed and tested.

(8)

Testing of the classes displayed in the UML Diagram from Figure 2 is conducted by testing file input processing. For the Phase I, the application must read in raw, loosely formatted data from two text files, process the data via the provided classes, and output to two XML documents. For Phase II, the

application must read in an addition raw, loosely formatted data from a text file, process the data via the provided classes and helper methods, and output to the standard output.

Testing of these procedures is conducted by building well-‐formatted and poorly-‐formatted data files for data processing and comparing the results to the expected output. This shows that proper interactions between input, output, and classes are being conducted.

3.3 Database Interface

For Phase IV of the application development, integration of the database into the constructed API is achieved via the use of JDBC. After the construction of the SQL database and insertion of the provided data, the application uses JDBC to load this data from the database for the creation of the application-‐ specific objects.

The application uses a driver class that loads the MySQL database via JDBC. This allows the developed application to make connections with the database for the purpose of retrieval, updating, insertion, and deletion of data. Results from retrieval queries are stored in a result set and processed accordingly by the application. As a part of the querying process, all SQL queries are designed to sanitize unwanted and malicious SQL injections. Handling of null, empty or improper data is handled within the application.

Testing of the database interface is done via comparison to the expected output. The data used for testing is the same data used in previous phases of this application development. Since the database queries are sanitized and improper data is handled within the application, component testing issues are reduced.

3.4 Design & Integration of Data Structures

Phase V, the final phase of application development, is focused on the development of a sorted Abstract Data Type (ADT) list to use as a means of object storage – specifically portfolio objects. The ADT

developed for this application is a linked list implementation. The linked list implementation was

(9)

collection. The linked list ends when a given node points to null. Insertion and deletion of nodes at given points enforces the list ordering by correctly setting the previous, inserted, and forward nodes to their correct pointers.

To assist with the usability of the ADT, additional convenience objects and methods were implemented. With respect to insertion sorting, a generically parameterized Comparator class was implemented with separate methods for a given ordering. The use of a comparator objects external to the collection’s class better enforces encapsulation and abstraction. With respect to usability of the ADT itself, an Iterator interface is implemented within the ADT to allow the use of the enhanced-‐for loops already

implemented with the financial management API.

Component testing of the implemented ADT followed the testing strategies from Phase IV. Instead of loading the portfolios from the database into Array-‐based lists, data is loaded into the linked list ADT. Since the iterable interface is implemented, all previous method calls to the portfolio collection need not be updated with exception of the input parameters. Further component testing included adding to the list (either start or end), removing items, inserting items at a given position, and clearing the list.

3.5 Changes & Refactoring

Phase I – Initial design. No changes made.

Phase II – Re-‐designed DataParser to call new methods for object-‐specific data-‐loading and parsing. Phase III – Corrected a minor error that required a Broker as part of the construction of a Person. Phase IV – Corrected the database to correctly reflect the desired foreign key references in Portfolio_Persons.

Phase V – Removed Portfolio_Persons and merged functionality into Portfolio, updated Portfolio_Assets to include proper primary key and removed unnecessary duplicate asset valuations

(10)

4. Bibliography

Eckel, B. (2006). Thinking In Java (4th Edition). Prentice Hall.

Eclipse Platform API Specification. (2011). Retrieved September 2013, from Eclipse.org:

http://help.eclipse.org/indigo/nftopic/org.eclipse.platform.doc.isv/reference/api/index.html

MySQL Workbench Documentation. (2013, November 13). Retrieved October 2013, from MySQL:

http://dev.mysql.com/doc/workbench/en/index.html

Oracle. (2011). Java Platform, Standard Edition 6 API Specification. Retrieved 2013, from Oracle: http://docs.oracle.com/javase/6/docs/api/

XStream Two Minute Tutorial. (2013). Retrieved October 2013, from XStream:

http://xstream.codehaus.org/tutorial.html