You are on page 1of 28

3.2 Software Design Specification Document 3.2.1 Introduction 3.2.1.

1 Goals and Objectives Developing the system for Local Government Units, is an attempt to make the process more suitable, easier, more organize and efficient. There are many goals for which the system is developed such as: 1. Standardized web page 2. Ease of use 3. Efficient 4. Less complexity 5. Costs less The system can store payment and collection details for unlimited number of payers or people. Payment and Collection System has a database that maintains the information of Fees, Collection, and Deposit information. Designing and making a standardized web page using Java programming language, the software application will run on most computer web browsers. In addition, a centralized database will be connected to the Internet that will allow the employees to easily share more information over the Internet. It can be an ease of use having a centralized database. The system can perform many operations such as payment of miscellaneous fees, collection of payment, deposits and many other operations by having the system. That makes it less complexity because of less paper work and faster productivity. Furthermore it can store a large of data for the different functions of the system. It can track the payments details of the payer in a very efficient way. 3.2.1.2 Statement of Scope The system allows the handling of payers, fees, and employees records. The payer is identified by a unique identifier. In additional, the system allows

generating of issuance of receipt for the payers, daily collection report, disbursement report, and cash receipts journal. Major Inputs: Payor name, gender, height, status, date of birth, place of birth, contact no, TIN no, occupation, citizenship, street, purok, municipality, barangay Payment details Fund information Fees description Daily collection Deposit Issuance of Receipt Processing Functionalities Function Payer information entry Fund information entry Fees information entry Tracking of payment details Recording of daily collection Receipts generating Recording of deposits Priority Essential Essential Essential Essential Essential Essential Essential

Outputs Daily collection report, cash receipts journal, disbursements report, and disbursement voucher.

3.2.1.3 Software context This Payment and Collection System is very efficient, which maintains database of payers, fees, funs, collection, deposit and payers payment detail. In this system the proponents use Java and MySQL for the database connectivity. Searching in the database is fast. 3.2.1.4 Major Constraints The system is to run with MySQL. Therefore the system should be properly connected to the server to access the database. The system should be good enough to perform all the actions fast for example; it is recommended that the RAM should be no less than 256 MB. 3.2.2 Data Design 3.2.2.1 Internal Data Structure There are no data structures available to the internal software architecture. When the add or update button is pressed the information typed on the text fields are directly stored for add or update. For accessing and viewing any table the date is fetched directly from ERP to the java database object is displayed directly on the screen. For report printing there are meaningful names for the storage of different values and the report can be printed. 3.2.2.2 Global Data Structure The only kind of data available globally to the whole system is the database itself stored in MySQL. After the connection any data stored can be fetched, updated, or deleted. For broad information of the database stored refer to section 2.4 of the document.

3.2.2.3 Temporary Data Structure The Payment and Collection System does not use any intermediate temporary files of its own. As data is being stored in an ERP system all the intermediate data it being stored by ERP until the command commit is being executed in the SQL query application. Hence no intermediate files or data structures are used. 3.2.2.4 Database Description Below are mentioned all tables, their corresponding attributes and a small description of each. Table Name: taxpayer Attributes: taxpayer id, first name, middle name, last name, gender, height,

status, date of birth, place of birth, contact no, TIN no, occupation, citizenship, street, purok, municipality, baangay Description: It holds all the general information of all payers. The primary key of this table is taxpayer id.

Table Name: user Attributes: user id, username, password, usertype, status Description: It holds all the general information of all users. The primary key of this table is user id.

Table Name: fee Attributes: fee id, fee name, cost, status, validity, created, updated, purpose Description: It holds all the general information of all fees. The primary key of this table is fee id.

Table Name: fund Attributes: fund id, fund code, description Description: It holds all the general information of all funds. The primary key of this table is fund id.

Table Name: official receipt Attributes: or no, begin series, end series, transaction id Description: It holds the begin series and end series for a particular official receipt. The primary key for the official receipt to avoid duplication is or no. transaction id is also the foreign key of the table official receipt.

Table Name: deposit Attributes: deposit no, fund id, collection id Description: The primary key for the official receipt to avoid duplication is or no. Transaction id is also the foreign key of the table official receipt.

Table Name: order of payment Attributes: OP no, taxpayer id, date, amount, fee id, type of payment Description: The purpose of this table is for the final assessment of payment from RPTS and BPLS. The primary key for order of payment to avoid duplication is OP no. Transaction id, taxpayer id, and fee id are also the foreign keys of the table order of payment.

Table Name: collection Attributes: collection no, or no, user id, payee name, check no, Description: The purpose of this table is for the recording of daily collection. The primary key for collection to avoid duplication is collection no. Or no and user id are also the foreign keys of the table collection.

Table Name: deposit check Attributes: deposit no, bank account, branch, amount Description: The purpose of this table is for the recording of deposit checks to a certain bank account. Deposit no is the foreign key of the table deposit.

Table Name: deposit cash Attributes: deposit no, denom, pesos, total Description: The purpose of this table is for the recording of all deposit cash. Deposit no is the foreign key of the table deposit.

3.2.3 Architecture and Component Level-Design 3.2.3.1 Architectural Diagram The Architectural context diagram for the software is shown below. As it is clear from the diagram, various actors are admin, teller and disbursing officer which use the system. The subordinate systems that will be used by the software are the database (MySql) and Java. MySqlConnector is required to connect java to database. Maintenance system is super ordinate, which needs the software for testing and maintenance purposes. Figure 3.2.3.1.1 Architectural Diagram

Figure 3.2.3.1.2 Architectural Context Diagram

Call and Return Architecture Figure 3.2.3.1.3 Call and Return Architecture

3.2.3.2 Description of Components 3.2.3.2.1 Component Payor The component payor contains the class Payor. It contains the attributes, which are the basic data of the parent of a child. It contains the functions, which sets all the related data into and out of the database. The class payor contains the data members and functions, which are unique to the payors payment details. The responsibilities of this component is to declaring variables of the basic data of the payor and implementing functions which set data in the database and retrieve from the database. 3.2.3.2.1.1 Interface description of the Component Payor The component payor has an interface with the class person from whom it inherits attributes and functions. The person class

has attributes, which are the basic data common to payor class and employee class and functions to set this data into the database and retrieve from the database. The attributes common for payor and employee are declared in this interface and the functions related to these attributes to set and get from the database are defined in this class. The attributes and operations which are unique to the payor are declared and defined in the component class. 3.2.3.2.1.2 Algorithmic description of Component Payor Component Payor; The intent of this component is to set the basic payor data into the database and get data from the database. Start Declare variables of the basic data Set the basic data of the payor in the database Get the data from the database End 3.2.3.2.1.3 Design class hierarchy Figure 3.2.3.2.1.3.1 Component Payor Design Class Hierarchy

3.2.3.2.2 Component Employee 3.2.3.2.2.1 Processing narrative of Component Employee

The component Employee consists of the class Employee. It contains the attributes, which are the basic data of the employee of the childcare center. It contains the functions, which sets all the related data into in and out of the database. The class Employee contains the data members and functions, which are unique to the employee. The responsibility of this component is to declare variables of basic data of the employee and implementing functions which set data in the database and retrieve from the database.

3.2.3.2.2.2 Interface description of Component Employee

The component Employee has an interface with the class person from which it inherits attributes and functions. The person class has attributes, which are the basic data common to parent class and employee class and functions to set this data into the database and retrieve from the database. The attributes common for parent and employee are declared in this interface and the functions related to these are unique to the employee are declared and defined in the component class.

3.2.3.2.2.3 Algorithmic description of Component Employee

The intent of the component Employee is to set basic data of Employee into database and get the data from the database Start Declare variables of the basic data of the Employee Set values into the database

Get the data from the database End

3.2.3.2.2.4 Design Class Hierarchy

Figure 3.2.3.2.2.4.1 Component Employee Design Class Hierarchy

3.2.3.2.2.5 Restrictions/Limitations This component can only be called when the user requires the data of the payor.

3.2.3.2.3 Component Teller 3.2.3.2.3.1 Processing Narrative of the Component Teller

The component Teller consists of the class Teller. It contains the attributes, which are the basic responsibilities of the teller in the Treasurers office of LGUs. It contains the functions to set the related data into and out of the database. It contains the

data members and functions to process payors payment information. The component would have access to the basic data of the payor. The responsibility of this component is to verify and update the payment information of payor.

3.2.3.2.3.2 Interface description of Component Teller

The component Teller has an interface with the class Payor and the class Employee. As the Teller is an Employee it has access to the Employee class and inherits the attributes and functions of that class through the interface. Using this interface the basic data of the teacher can be set into the database and get from the database in this interface and the functions related to these attributes to set and get from the database are defined in this class.

3.2.3.2.3.3 Algorithmic description of Component Teller

Component Teller The intent of the component Teller is to set basic data of Teller, verify and update payment information of payor into the database and get the data from the database. Start Update variables of payors payment details Set the data into the database Get the data from the database End

3.2.3.2.3.4 Design Class Hierarchy

Figure 3.2.3.2.3.4.1 Component Teller Design Class Hierarchy

3.2.3.2.3.5 Restrictions/Limitations

This component can only be called when the user wants to verify and update payors payment details.

3.2.3.2.4 Component Disbursing Officer 3.2.3.2.4.1 Processing Narrative of Component Disbursing Officer

The component disbursing officer consists of the class disbursing officer. It contains the attributes, which are the basic responsibilities of the disbursing officer in the Treasurers Office of LGUs. It contains the functions to set the related data into and out of the database. It contains the data members and functions to prepare and monitor the disbursement voucher.

3.2.3.2.4.2 Interface Description of Component Disbursing Officer

The component disbursing officer has an interface with the class Payor, class Employee and class Teller. As the disbursing officer is an Employee it has access to the Employee class and inherits the attributes and functions of that class through the interface. Using this interface the basic data of the disbursing officer can be set into the database and get from the database in this interface and the functions related to these attributes to set and get from the database are defined in this class.

3.2.3.2.4.3 Algorithmic Description of Component Disbursing Officer

Component Disbursing Officer The intent of the component Disbursing Officer is to set basic data of Disbursing Officer, prepare and monitor data for disbursement voucher into the database and get the data from the database. Start Declare variables of disbursement Set the data into the database Get the data from the database End

3.2.3.2.4.4 Design Class Hierarchy

Figure 3.2.3.2.4.4.1 Component Disbursing Officer Design Class Hierarchy

3.2.3.2.4.5 Restrictions/Limitations This component can only be called when the user wants to monitor and update the disbursement voucher.

3.2.3.3 Dynamic behavior for Component 3.2.3.3.1 Interaction Diagrams A sequence diagram, for each use case the component realizes, is presented. Figure 3.2.3.3.1.1 Admin Interaction Diagram

This is a sequence diagram where the use case component is the Admin. The first event, system ready, is derived from the external environment and channels behavior to an Admin object. The admin enters a password. A request lookup event is passed to system that looks up the password in the software system and returns a result to monitor. A valid password results in a password = correct event to software system which then gives access to the admin and the admin can add/update/delete the data of other employees and miscellaneous fees. And this data can be displayed on the monitor or printed from the printer up on request. Figure 3.2.3.3.1.2 Teller Interaction Diagram

This is a sequence diagram where the use case component is the Teller. The first event, system ready, is derived from the external environment and channels behavior to a Teller object. The teller enters a password. A request lookup event is passed to system that looks up the password in the software system and returns a result to monitor. A valid password results in a password = correct event to software system which then gives access to the teller and the

teller can verify and update the data of payors pa yment. And this data can be displayed on the monitor or printed from the printer up on request.

Figure 3.2.3.3.1.3 Disbursing Officer Interaction Diagram

This is a sequence diagram where the use case component is the Disbursing Officer. The first event, system ready, is derived from the external environment and channels behavior to a Disbursing Officer object. The disbursing officer enters a password. A request lookup event is passed to system that looks up the password in the software system and returns a result to monitor. A valid password results in a password = correct event to software system which then gives access to the disbursing officer and the disbursing officer can monitor and update data of disbursement vouchers. And this data can be displayed on the monitor or printed from the printer up on request.

3.2.4 User Interface Design The application has a graphical user interface, which is built completely in java. Among the variety of libraries available in java we have chosen java swing library for development as more variety of component available in it and more sophisticated techniques are available to change to appearance of those components if required in future.

3.2.4.1 Description of the User interface 3.2.4.1.1 Screen Images The GUI for the payment and cashiering system is very user friendly, easy to navigate and very easy to learn that requires only a little of understanding to use it.

Below is the detailed images and description of the GUI. The object and action s performed when you clicked them are also identified.

The first image is the login screen. The user is supposed to have a username and a password in order to login. When the user clicks the login, the user will be redirected to the main page of the system. Otherwise if the username or password is not correct, they will be notified that they entered the wrong combination of username and password.

Below is the administrator interface. This interface has only those options that are only accessible to the administrator. The GUI below is self-explanatory. The administrator is supposed to click on any available options to add, update or access them. Once clicked another GUI will appear that will have further option in any of the above button is clicked.

Below is the manager interface. This interface has only those options that are only accessible to the manager. The GUI below is selfexplanatory. The manager is supposed to click on any available options to add, update or access them. Once clicked another GUI will appear that will have further option in any of the above button is clicked.

Below is the teller interface. This interface has only those options that are only accessible to the teller. The GUI below is self-explanatory. The teller is supposed to click on any available options to add, update or access them. Once clicked another GUI will appear that will have further option in any of the above button is clicked.

As shown that all three interfaces for administrator, manager and teller differ in options. In that way access levels are restricted. Also all three GUI follow the same convention. Logout and exit command buttons are also provided in each interface.

When you click the print report on the menu of the administrator this will give the access to the reports generated by the system and the user can print a physical copy of that report. Also the administrator has the menu of adding a new user of the system which has to be an employee. When you click the add user on the menu of the administrator this will give the user the privilege to add a new user of the system on a different GUI. When the back button is clicked the interface will go back to menu.

When you click the print report on the menu of the manager this will give the access to the reports generated by the

system and the user can print a physical copy of that report. When you click the add fee this will give the user the privilege to add a new type of fee in a different GUI also. When the back button is clicked the interface will go back to menu.

When you click the accept payment on the menu of the teller this will give the user the privilege to add a payment to the payee and this will update their account information. When the back button is clicked the interface will go back to menu.

3.2.4.1.2 Objects and actions The above shown GUI windows consist of java swing components. The windows consist of label for displaying a text. Text fields for entering or editing text. And command buttons are used for execution procedures.

3.2.4.2 Interface Design rules Strive for consistency the developers strive for consistency of the designs that will be used on the system so that the users will not have a hard time on understanding the interfaces. Offer informative feedback For every action that is done, there is a feedback on it so that the user will know what happen on the transaction. Offer simple error handling developers design the system so the user cannot make a serious error that users cannot understand.

Permit easy reversal of actions users can undo the performed action once they made an error or mistake. Enable frequent user to use shortcuts frequent users of the system can use function keys and shortcuts so that users can easily go to their desired screen or option.

3.2.4.3 Components available

Java swing library have many components available but for now only frames, text labels, text fields and buttons are being used on the GUI. Among them only the buttons have been added to the mouse action listener. Rests have no action listener attached to them. More components may be added in the future if necessary.

3.2.4.4 UIDs description

No user interface development system has been used in the development of the Payment and Cashiering system. The system will only be used by authorized personnel and will not be available to the public.

3.2.4.5 Reports

Screen for Daily Collection Report

Screen for Cash Receipts Journal

Screen for Disbursements Report

3.2.5 Restrictions, Limitations, and Constraints

Only the administrator can delete information. Every user should have a username and password to access the system. The functions and data members of the component are called only when the user requires to manipulate the data of the component The software is to run on a system, with MySQL. Therefore the systems should be properly connected to the server to access the database. The software should be designed in such a way that the processing speed of the operations should be high The software will be used by Local Government Units. The software should display an appropriate error message when a value outside the accepted limits is entered. Other users should not be capable of deleting a type of fee whether it is categorized as an inactive transaction.

Other users should not be capable of deleting a taxpayer record with any other reasons that can lead to their extinction or unreliable consistency of transaction

3.2.6 Testing Issues Test strategy and preliminary test specification are presented in this section. The various tests to be conducted to validate the software developed are login test, daily collection report test, cash receipts journal test, disbursements report test and disbursement voucher report test.

Classes of Testing

Description

Expected software response

Performance bounds

Components to be identified

login test

This test class is The user will be The user should User defined to able to login not login if

validate whether when he enters enters a wrong the user is able to the username and username login with his password and correctly password and

username password. daily

collection This test class is The defined

test

will The user cannot Collection,

report test

to print the daily view this if not Reports permitted on the user roles

validate whether collection report the collection being daily is

displayed

or not. All the functions related to the daily class

collection

are called in this test class.

cash

receipts This test class is The defined to print

test the

will The user cannot Official Receipts, cash view this if not Reports permitted on the user roles

journal test

validate whether receipts journal the cash receipts journal is being displayed or not. All the functions related cash to the

receipts

class are called in this test class disbursements report test This test class is The defined to print test will The user cannot Deposit, Reports the view this if not permitted on the user roles

validate whether disbursements the disbursements is being displayed

or not. All the functions related to disbursements class are called in this test class . the

You might also like