Software Description Specification

Group 6Tony Meteiver, Kyle Hertel, Andrei Vajiac

Introduction

General Purpose

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

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.

Scope

The proposed system has two primary functions:Varying tiers of user access:Client access – allows the user to view their

personal accountLender access – allows the user to view/modify all

accountsAdmin access – allows the user to add/remove

Lender accountsThese tiers of access are hierarchical, meaning that

each level can perform the tasks of the levels below it.

Scope

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.

Data Description

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.

 

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.

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.

Architecture Design

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.

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.

3.5 Architecture Diagram

4.0 Detail Design

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.

4.1.2 Access • private tablenameo variable that stores the table name ; may well be dropped shortly• private conno variable that stores the active connection to db from connection class• private num_recordo 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 resultset and the number of row affected as well. True if successfulexecution of query False otherwise.

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

4.1.4 User • protected usernameo variable that stores the user name of the current logged in user• protected clearanceo variable that stores the user type of the current logged in user• protected userido 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_paymento sorts by last payment• protected sortby_uido sorts by uid

(continued on next slid

• protected sortby_balance_remaining ()o sorts by remaining balance• public function Login()o controls login functionality; if the login is not successful it sets anerror 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 theappropriate 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 confirmpaymento confirms payment• protected confirmorDenyo confirms or Denies an app• protected lookupuido looks up uid

4.1.5 UserClearenceOne• function UserClearenceOne ()o CONSTRUCTOR: Class constructor.• protected ViewmyRecordso view only their records• protected applyo application process 4.1.6 UserClearenceTwo• function UserClearenceTwo ()o CONSTRUCTOR: Class constructor.• protected ViewanyRecordso view any records• protected appstatuso application status• protected editcontactanyo change contact info 

4.1.7 UserClearenceThree• function UserClearenceTwo ()o CONSTRUCTOR: Class constructor.• protected ViewanyRecordso view any records• protected appstatuso application status• protected editanyvariableo edit any variable

5.0 Database Design

5.1 Entity Relationship Diagram

6.0 Software Interface Description

6.1 External Machine InterfacesThis program assumes the user has access to a web browser on a computer with an internet or intranet connection. 6.2 External System InterfacesThe 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 InterfaceThe 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.