DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING 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.
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, Student 002 2013/10/25 Database and Data Structure sections added, minor updates to previous text 3.0 Data Structure section added, minor updates and refactoring in other areas Student 002 2013/11/15 1
Table of Contents 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.2.1 Component Testing Strategy... 7 3.3 Database Interface... 7 3.3.1 Component Testing Strategy... 7 3.4 Design & Integration of Data Structures... 7 3.4.1 Component Testing Strategy... 8 3.5 Changes & Refactoring... 8 4. Bibliography... 9 2
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 OOP Object Oriented Programming SQL Structured Query Language UML Diagram Unified Modeling Language Diagram XML Extensible Markup Language 3
2. Overall Design Description 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. 4
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. 5
3.2 Class/Entity Model 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. Figure 2: UML Diagram 6
3.2.1 Component Testing Strategy 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. 3.3.1 Component Testing Strategy 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 designed to support three different orderings of data based on a given comparator and parameters. The three supported orderings include sort by total value in descending order, sort by last name then first name of portfolio owners, and sort by portfolio managers by broker level and then name. Ordering of the ADT is done upon insertion and is maintained rather than updated or imposed. The linked list ADT developed is generically parameterized allowing it to be implemented by objects beyond just portfolios. The linked list is composed of a head node and tracks current size. The head 7
node maintains the generic item itself and provides a means of pointing to the next item in the 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. 3.4.1 Component Testing Strategy 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 8
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 9