Software Description Specification

1. Software Description Specification Group 6 Tony Meteiver, Kyle Hertel, Andrei Vajiac

2. Introduction

3. Upon completion of this project, a user-friendly, interactive mortgage system will have been implemented to manage the lending accounts for the people who apply for one through the Martha Stockton Greengage Foundation. This foundation, instated upon Martha Stockton Greengage’s death, was left one billion dollars with the intent of assisting young married couples who were looking to buy their first home. The software itself will be comprised of two parts; both a client-side and lender-side interface will be available to view and modify accounts, respectively. General Purpose

4. In essence, the final implementation must not only be able to efficiently manage many client accounts and provide an interface to each client through which they can access their own account information, but also provide an interface for the lenders themselves to be able to access and modify any account in the database. General Purpose

5. The proposed system has two primary functions: • Varying tiers of user access: • Client access – allows the user to view their personal account • Lender access – allows the user to view/modify all accounts • Admin access – allows the user to add/remove Lender accounts • These tiers of access are hierarchical, meaning that each level can perform the tasks of the levels below it. Scope

6. Account Management: • This part of the system will be implemented to manage all of the different mortgage accounts for the clients. It will need to be a database that has the ability to access, store, and modify its contents quickly and efficiently. The Account Management will have to work hand-in-hand with the different tiers of user access to change what is viewable by the client, the lender, and finally the admin. Scope

7. Data Description

8. Connection- • A connection through means yet to be determined will be required to access the database or to begin the application process. • Access- • Gives users of sufficient clearance the ability to view users profiles. Different levels of clearance will allow for different functionality including query searches, manual account closings, and individual user account status lookup.

9. Session- • This gives the user the options they have. And in turn bars the user from making changes that are beyond their clearance. • User- • This data object is a key feature as it will determine per individual account what clearances any given user has at any given time. This will also hold all user functions.

10. UserClearenceOne- • Inherits User. Lowest level of clearance can only view the individual profile that the account name is associated with. • UserClearenceTwo- • inherits User. Standard level of clearance generally should be issued to employees of the foundation. Will allow account name to view any profile however has limited ability to edit information. • UserClearanceThree- • Inherits User. Top level of clearance, generally given to top level administrators. With this variation of account name the user may change all variables of any given profile.

12. Architecture Design

13. 3.1 Architecture Overview • This software system will use the normal internet application with 3-tierd architecture. All system data will be stored on a system database, (this is the database layer). We will use an application layer to run all the system functionality. The access layer is run from any remote terminal capable. • 3.2 Database Layer • Within the database layer, we will have a MYSQL database, which could be handled locally or remotely. Limiting factor being the type of network the system is run from. The only way to get access to the database is by going through the apache server within the application layer.

14. 3.3 Application Layer • The software functionality and operations will be handled though a php5 capable Apache web server. Depending on system network and security settings, the web server can being ran remotely or locally. Since this application layer is completely independent from the database layer, they do not have to be run from the same sever, but can be. • 3.4 Access Layer • To access this system, one must have a network capable computer with a connection to the internet via a web browser. This system is compatible with Windows, Linux and Mac machines. The access can go two ways, depending on what the user wants. They can either have it setup on their own network so it can only be accessed by computers on that network, or they can have it as a fully web capable web application. In our case, we will use the ladder of the two because of the security that has been implemented in the design with the user name and password.

15. 3.5 Architecture Diagram

16. 4.0 Detail Design

17. 4.1 Class Member Functions and Details • 4.1.1 Connection • • private host • o variable that stores the host name of the database • • private user • o variable that stores the database username • • private password • o variable that stores the database password • • function Connection() • o CONSTRUNCTOR: parameters passed in order to store necessary • values to connect to the desired db with username and password. • • public function Connect() • o Establishes a connection with the database. • • public function Close() • o Closes the database connection.

18. 4.1.2 Access • private tablename o variable that stores the table name ; may well be dropped shortly • private conn o variable that stores the active connection to db from connection class • private num_record o variable that stores the number of records affected by any query • function Access(tablename) o CONSTUCTOR: initiates the table name and this class's connection • public function Result() o gets the result set created by any query • public function Error() o gets the any error that occurs during any query execution • public function search(key: string) o runs any query that is passed to it and stores the result in the result set and the number of row affected as well. True if successful execution of query False otherwise.

19. 4.1.3 Session • function Session() o CONSTRUCTOR: Initiates a session. • public function session_clearance() o Gets the username from sessiont • public function SessionID() o gets user type from sessiont • public function getSessionDetail() o gets user id from sessiont • public function getSessionAction() o gets current action from sessiont • public function setSessoinDetail($uid,$utype,$uname) o sets necessary variables to establish a session • public function time() o checks up time

20. 4.1.4 User • protected username o variable that stores the user name of the current logged in user • protected clearance o variable that stores the user type of the current logged in user • protected userid o variable that stores the user id of the current logged in user • protected balance_remaining () o gets remaining balance • protected balance_paid() o gets balance paid • protected sortby_last_payment o sorts by last payment • protected sortby_uid o sorts by uid (continued on next slid

21. • protected sortby_balance_remaining () o sorts by remaining balance • public function Login() o controls login functionality; if the login is not successful it sets an error flag to true. If login is successful it sets the loggedin flag to true. • public function Update() o gets the posted form and makes the query and send it to the appropriate function in the dataaccess class. • public function getUesrType() o gets the user type, or the staff level • public function drawLogin() o draws the GUI of form for system login • public function Logout() o logs the user out and destroys all session data • protected confirmpayment o confirms payment • protected confirmorDeny o confirms or Denies an app • protected lookupuid o looks up uid

22. 4.1.5 UserClearenceOne • function UserClearenceOne () o CONSTRUCTOR: Class constructor. • protected ViewmyRecords o view only their records • protected apply o application process 4.1.6 UserClearenceTwo • function UserClearenceTwo () o CONSTRUCTOR: Class constructor. • protected ViewanyRecords o view any records • protected appstatus o application status • protected editcontactany o change contact info

23. 4.1.7 UserClearenceThree • function UserClearenceTwo () o CONSTRUCTOR: Class constructor. • protected ViewanyRecords o view any records • protected appstatus o application status • protected editanyvariable o edit any variable

24. 5.0 Database Design

25. 5.1 Entity Relationship Diagram

26. 6.0 Software Interface Description

27. 6.1 External Machine Interfaces This program assumes the user has access to a web browser on a computer with an internet or intranet connection. 6.2 External System Interfaces The system will require access to an address repository to check the validity of the addresses in the database. Also, a connection to a credit checking program should be used to help determine how much money should be approved for a specific client. These functionalities are not currently included in the software, and may be implemented later. 6.3 Human Interface The user will input their information into a login interface, and will be connected to their user account. From there, they can access/modify their own personal and contact information, view their loan information (if applicable), view their loan information, and modify other accounts as allowed by their Admin/Superuser status.