ABSTRACT

Cash management is a centralized system of managing received cash and expenditure of cash for a large group of institutions. The scenario of CMS includes all types of operations such as maintenance, management system, development, operational experience and real time information of the cash management system. This is efficient in processing of information and also automatic generation of accounting document such as receipts. This is an automated computerized application. The system support the preparation of daily operation program, data storage and management statistic such as identification of students information. The Cash management System maintains records, ledgers and files keeping the track of every student financial transactions in which everything is maintained manually. The cashier receives the amount from the students and makes the entries in the files or registers manually. The cashier gives the fee receipt after the fee is being paid and maintains a duplicate of fee receipt with him. The anomie of the college is through tuition transport, caution deposit, exam and the hostel fee. The human efforts are put forth during the accounting of information making it a time consuming process prone to errors and mistakes. Further there may be many difficulties outcome calculations consuming a lot of this involving more number of employees for a single work. The main problem can also be the lack of security such as anyone can modify, falsify, alter or vanish the information of the student. Accounting can see itself in fines and penalties if the records are lost. To overcome these sought of problems we maintain an application based system in which the bulks of data can be stored in GUI environment. The security is well maintained and time span is reduced comparatively. There is no need to search for the data manually; we can retrieve the data by the means of tables. It is faster and efficient in processing of information and automatic generation of receipts. The biggest issue or challenge is to sustain the miscellaneous account and handle the management policy matters related to cash handling for installment payment of the fees. This application

handles the installment process for the payment of the fee which does not prone to errors in accounting information. Benefits and features of the project is user friendly where security is assigned through user id and passwords supporting fast accessing of data maintenance of account details of Cash Management System

CONTENTS
CHAPTER 1 1. INTRODUCTION 1.1 Purpose 1.2 Scope 1.3 Existing System 1.4 Proposed 1.5 Modules 1.6 Application, Goal, Objective & Benefits 1.7 Requirements 1.8 Hardware Requirements 1.9 Software Requirements 1 1 1 1 1 2 2 2 3 3

CHAPTER 2 2. SOFTWARE REQUIREMENT SPECIFICATION 2.1 INTRODUCTION 2.1.1 Purpose 2.1.2 Document conventions 2.1.3 Intended Audience and Reading Suggest 2.1.4 Project Scope 2.1.5 Reference 2.2 OVERALL DESCRIPTION 2.2.1 Product perspective 4 4 4 4 4 4 5 5 5

2.2.2 Product Features 2.2.3 User Classes and Characteristics 2.2.4 Operating Environment 2.2.5 Design and Implementation Constraints 2.2.6 User Documentations 2.2.7 Assumptions and Dependencies 2.3 SYSTEM FEATURES 2.3.1 System Feature 1 2.3.2 System Feature 2 2.4 EXTERNAL INTERFACE REQUIREMENT 2.4.1 User Interface 2.4.2 Hardware Interface 2.4.3 Software Interface 2.4.4 Communication Interface 2.5 OTHER NON FUNCTIONAL REQUIREMENTS 2.5.1 Performance Requirements 2.5.2 Safety Requirements 2.5.3 Security Requirements 2.5.4 Software Quality Attributes 2.6 OTHER REQUIREMENTS

5 6 6 7 7 7 7 7 8 8 8 8 8 8 9 9 9 9 9

CHAPTER 3

3. ANALYSIS & DESIGN 3.1 BEHAVIORAL DIAGRAM 3.1.1 Use Case Diagram 3.1.2 Sequence Diagram 3.1.3 Collaboration Diagram 3.1.4 Activity Diagram

3.2 DESIGN 3.2.1 Entity Relationship Diagram 3.2.2 Class Diagram 3.3 User Interface Design 3.4 Data Dictionary 3.5 SQL Queries

CHAPTER 4 4 CONCLUSIONS 4.1 Scope for Future Enhancements APPENDIX A: List of Figures APPENDIX B: List of Tables CONCLUSION REFERENCE

CHAPTER-1
1. INTRODUCTION 1.1 Purpose: The main purpose of this software is to reduce manual errors and human efforts involved in cash management system, which is the centralized system for managing receive and cash expenditure of cash for big institutions. We can retrieve records from the database in bulk. This project is developed and designed for reducing the human efforts and manual errors using SQL, by this the user is provided with the relevant information and hence this application is authenticated and assurance is provided that the data will be confidential. Preferably, this document is a concise summary on the project and is intended to be helpful to the user, stakeholders and the developers of the software system. 1.2 Scope: Cash Management processes are pre-requisites to execute payments, collect receivables and manage liquidity. Managing the channels of collections, payments and accounting information efficiently becomes imperative in transaction volumes. This enables greater connectivity between user and the system, expanding its scope. This project in future can be enhanced to help the user to manage transactional and receivable accounts clearly. JDBC can be used for further improvising. For the Move Improved version the, Database can be web based record, can be checked anywhere and anytime on nevertheless server is running. 1.3 Existing System: The Cash management System maintains records, ledgers and files keeping the track of every student financial transactions in which everything is maintained manually. The cashier receives the amount from the students and makes the entries in the files or registers manually. The cashier gives the fee receipt after the fee is being paid and

maintains a duplicate of fee receipt with him. The anomie of the college is through tuition transport, caution deposit, exam and the hostel fee. The human efforts are put forth during the accounting of information making it a time consuming process prone to errors and mistakes. Further there may be many difficulties outcome calculations consuming a lot of this involving more number of employees for a single work. The main problem can also be the lack of security such as anyone can modify, falsify, alter or erase the information of the student. Accounting can see itself in fines and penalties if the records are lost. 1.4 Proposed: To overcome these sought of problems we maintain an application based system in which the bulks of data can be stored in GUI environment. The security is well maintained and time span is reduced comparatively. There is no need to search for the data manually; we can retrieve the data by the means of tables. It is faster and efficient in processing of information and automatic generation of receipts. The biggest issue or challenge is to sustain the miscellaneous account and handle the management policy matters related to cash handling for installment payment of the fees. This application handles the installment process for the payment of the fee which does not prone to errors in accounting information. Benefits and features of the project is user friendly where security is assigned through user id and passwords supporting fast accessing of data maintenance of account details of Cash Management System 1.5 Modules: The modules of cash management system are: Student Administrator Fee Payment

1.6 Application, Goal, Objectives & Benefits:

With the proposed system the cash management will improve by increasing efficiency and improving throughputs: User friend Security through user id and password Fast accessing of the required data Uniformity throughout the application Maintenance of details

1.7 Requirements: Hardware Operating System Software DBMS : PC with 80 GB hard disk and 512 MB RAM : Windows with MS Office : Java, JDBC, JSP : MySQL

1.8 Hardware Requirements: Processor- Intel p4 based system Processor Speed-250 MHz to 833 MHz RAM- 64 MB to 256 MB

Hard Disk- 20 GB to 80 GB Key Board- 104 keys 1.9 Software Requirements: Language- JDK Database- SQL Operating Interfaces- Windows NT/2000/XP/7/Vista

CHAPTER-2
2. SOFTWARE REQUIREMENT SPECIFICATION 2.1 INTRODUCTION 2.1.1 Purpose The main purpose of this software is to reduce manual errors and human efforts involved in cash management system, where cash management is the centralized system managing receive and cash expenditure of cash for only big institutions. We can retrieve records from the database in the bulk. This project is developed and designed for reducing the human efforts and manual errors using SQL, by this the user is provided with the relevant information and hence this application is authenticated and assurance is provided that the data will be confidential. The purpose of this document is to delineate the features of the Cash Management System in its very first software release (version 1.0). This document highlights the purpose and features of the system. Preferably, this document is a concise summary on the project and is intended to be helpful to the user, stakeholders and the developers of the software system. 2.1.2 Document Conventions This Document has tried to maintain a priority of requirements. The priority has been determined by the judgment of the author and many subject to change priority of higher level requirement are inherited by detailed requirements. The document has been short form for some commonly abbreviated terms. Title Subtitle Line spacing : Times New Roman 14(caps) : Times New Roman 14 (first letter caps) bold : 1.5 cms

Remaining text : Times New Roman 12

3.1.3

Intended Audience and reading suggestions The intended audience here is cashier, assistants and representatives of the

Management. The intended audience can be only the one who interacts with the computer, who uses the computer as user interface is cashier and assistance. This document enhances all the facilities which guide the user to sustain all the records into consideration. The goal of this document is to provide clear view of students records for the cash management system. The user can know the requirements by reading the USER REQUIREMENTS Section and can skip other sections if required. Stakeholders are the other people who are involved in developing and using this application. They are the development team and the client-side users. The development team involves both the analyst and the designer. 3.1.4 Project Scope Cash Management processes are pre-requisites to execute payments, collect receivables and mange liquidity. Managing the channels of collections, payments and accounting information efficiently becomes imperative in transaction volumes. This enables greater connectivity between user and the system, expanding its scope. This project in future can be enhanced to help the user to manage transactional and receivable accounts clearly. Underline coding and designing will be the same. Instead JDBC can be used for further improvising. For the Move Improved version the, Database can be web based record, can be checked anywhere and anytime on nevertheless server is running. 3.1.5 References [1] Grady Booch, James Rombaugh, Unified Modeling Language, Pearson publications [2] Herbert Scheldt Java, Fifth Edition

3.2 OVERALL DESCRIPTION

3.2.1 Product Perspective It will be able to manage information about the fee structure of tuition fee, transport fee, exam fee, and caution deposit. This system will manage information at various field offices in more user friendly way. User ID and passwords has been given to all the field offices so that they can enter their user into central data base. Their access to central database is restricted to their information only. 3.2.2 Product Features

General Features: 3.2.3 Maintains complete audit trials of all transactions and adjustment for better financial control. Provides current and future calculated balances for all cents accounts Provides extensive inquiry capabilities. Export account into, including checks and deposits into other programs for analysis, increasing, presentations, reports and more. Day to day operational activities like account receivables and account payables. Generation of summarized reports for management purpose. User Classes and Characteristics

Administrator: The Administrator is responsible for managing the cashier department of different branches by providing cashier id and password. The administrator takes care of student registration. Different branches of the organization have separate cashier to collect the fees administrator also develops report about the fees

Cashier: A cashier is a person who is enrolled in receive the fee / cash from the student and return the balance if exists. The cashier maintains a record of each student according to its branch and year of studying. Cashier performs two main tasks such as he takes fee amount and gives the amount as payment to other sources such as book purchase, petrol, etc. Cashier in turn takes care of college maintenance by maintaining a balance sheet of the college. The cashier notes down the paid fee and the remaining fee into the record and sustains it as money/cheque and provides a receipt.

3.2.4

Operating Environment

Cash Management system works with SQL Server. It is accessed using any of the versions of web browsers like, MS Internet Explorer, Mozilla Fire Fox, Netscape, Opera and Google Chrome. The LAN allows everyone to work on the same document and with the right software/programs everyone can see the results in real time. That is perhaps one of the most powerful aspects of a centralized server that everyone is accessing at the same time from their computers at their desks or even from their home. 3.2.5 Design and Implementation Constraints

The Unified Modeling Language (UML) is a standardized specification language for objection modeling which is used to create abstract model of a system. The system database design will be based on ER Modeling which will in turn transfer to database schema formulated using SQL DDL statements. Because of the management policies some of the data are not to be revealed keeping it as confidential which forms a conflict in audit trails. The constraints involved here are trail balance and balance chart.. 3.2.6 User Documentation Final release will be accompanied with a user guide to inform new users to use cash management system. 3.2.7 The system is user friendly. Easy to access and easily understandable. Assumptions and Dependencies It is assumed that all the systems will have the basis software and hardware, and also communication interfaces available. The system must have the internet connections with required speed. Prior to the knowledge of accounting principles and library is must.

The students data is forms a dependency from the exam branch so as to maintain a network.

3.3

SYSTEM FEATURES

3.3.1 Student registration Description and Priority This feature allows the user friendly screens to easily manipulate the records and data under it. Data storage for student photo is in the path format whereby a lot of memory and secondary Name is already saved, which optimizes the whole performance. Functional Requirements This enhances the records retrieving, updating / add / Del records and also authenticate the records with confirmation. Req # REQ-SR1 REQ-SR2 REQ-SR3 Description The user can retrieve the records Add/updating/del records Authenticating the record /data Priority [Priority = High] [Priority =Medium] [Priority = medium]

3.3.2 Cash Receipts and Payments Feature Description and Priority This features enhances all the activities by the payee and as well as the cashier. Functional Requirements Req # Description Priority [Priority = High]

REQ-CRP1 Cash Payment by the payee

REQ-CRP2 Update the receivable payments Into the records REQ-CRP3 Add / deleting the records REQ-CRP4 Provide receipt REQ-BR5 Maintaining the bills

[Priority = High] [Priority = medium] [Priority = High] [Priority = medium]

3.3.3 System Development Requirements Accountant/Cashier The primary features of the system are the Accountant/Cashier module which does transaction or modification of student entries to the system. The Accountant/Cashier features are operable by only administrator or authorized person. It consists of two sub-modules student information and fee information. Description and Priority The primary purpose of the Accountant is to perform fee transaction of a student and maintain the record in the database. The cashier maintains inflow and outflow amount of the organization. Organization collects fee and generates the receipts to the authorized person. However, it is also designed to display the list of all the types of fee that the students have to pay, including the exam fee. It also helps the accountant in classifying between various fee type of the college or the university. The software is embedded with the features of generating a transaction sheet on daily weekly or monthly bases. The data can be retrieved as on any particular day by specifying the data. Stimulus/Response Sequences Stimulus Response Stimulus Response supports Stimulus : Cashier enters the personal ID and Password. : ID and Password are validated. : Cashier selects the type of transaction to be done. : The page of selected type of transaction is opened. It even redirection of the pages. : Cashier performs the transaction.

Response intimated of Stimulus Response

: The transaction is stored in the database and the cashier is completion of the transaction. : The cashier logs out of the system. : Login page is displayed.

Functional Requirements The software must be able to carry and the service it was designers to provide. Also the product should respond to the anticipated errors condition or invalid input and handle authenticity related issues. If either of the selected entry is formed to be invalid, the system halts at the point of errors and request a valid set of entries. Req # REQ-SDR1 REQ-SDR2 REQ-SDR3 REQ-SDR4 Description Login/Logout Add/View Delete Generate Receipt Priority [Priority = High] [Priority =High] [Priority = medium] [Priority =High]

3.3.4 Login The most crucial features of the system is the login features. The security of the system is maintained by the login module. It provides access to the system to only authenticated person. The security is maintained by providing a unique ID and Password to the cashier. This ensures that only the cashier, who knows the Password, can login to the system. The ID and Password are provided to the cashier by the administration/management. Description and Priority The primary priority of the login module is to validate unique ID and Password given to the cashier. This ensures that only the cashier, who knows the Password, can

login by the system. The ID and Password are provided to the cashier by the administration/management. However, other optional constraints to view reports date, by person ID, by department etc have also been included. Stimulus and Response Stimulus select on Response Stimulus Response Stimulus Response : Accountant/Cashier enters the password ID and Password and login. : ID and Password are validation. : If wrong ID/Password is entered. : The system asks for a valid ID and Password. : If valid ID and Password are entered. : The cashier is directed towards the Home page by the system.

Functional Requirements The cashier must be an authentic person. The cashier ID and Password should be genuine in order to log into the system. Req # REQ-L1 REQ-L2 Description Login Authenticated Priority [Priority = High] [Priority =High]

3.3.5 Fee Payment Description and Priority Another feature of the system is the fee payment. There are different types of fee which are paid in the college by the student i.e. Tuition fee, Miscellaneous fee, Transport fee, Exam fee, etc. The cashier selects the type of fee that the student is paying and enters the details like the date of payment mode of payment; amount being paid saves in the database and generates the reports. Stimulus/Response Sequences Stimulus : Accountant/Cashier selects the type of fee to be paid (For e.g. Tuition fee) Response : The Tuition fee payment receipt form is displayed.

Stimulus receipt. Response receipt of

:The cashier enters the amount to be paid and selects on pay

: The fee is paid and the payment is saved in the database. The the fee is generated as a printed form.

Functional Requirements The basics functional requirement of this features is the student paying the fee and the cashier receiving the fee. Req # REQ-FP1 REQ-FP2 REQ-FP3 Description Paying the fee Update Generate receipt Priority [Priority = High] [Priority =High] [Priority =High]

3.3.6 Reports Description and Priority Report may be generated using several constraints i.e. by student ID, by date, by department, by category and by report by student ID range from the recorded data where record are fetched upon request from a periodically updated Database. The primary priority of the report module is to generate report to give an exact count of the number of student who has made a transaction with the cashier on a given instance of date or time. However, other optional constraints to view report by date, by patron ID, by department, etc have also been included. Stimulus/Response Sequences Stimulus statement button. : The cashier enters each and every transaction into the fee collection with in a particular period of time and select on the save

Response access Stimulus Response the

: The statement is recorded in the Database and the management can whenever required. : The cashier select on the print button. : The transaction statement entered is printed for forwarding it further to management

Functional Requirement The functional requirements for this feature are the printer. Req # REQ-RP1 Description View Priority [Priority = High]

3.4 EXTERNAL INTERFACE REQUIREMENT 3.4.1User Interfaces The system will be having user privileges based menu. The user will have to select the options from the given menu. The system will be entering the info into DB to generate reports. The forms will be designed to enter data. The buttons will be used to insert, retrieve or modify data. Links will be provided for the navigation of one from to another. All the screens are user friendly 3.4.2 Hardware Interfaces Internet connection System with P4 processors 512 MB RAM Network Interface Card

3.4.3 Software Interfaces As this application is web enabled and uses web applications hence we use JAVA script. The client systems with internet facility equipped with web browser will be able to access the system. We use rational Rose for designing in UML.

3.4.4 Communication Interface This project supports all the web browsers. We design simple web pages that support communication standard HTTP protocol. We use JDBC (Java Data Base Connectivity) which is directly communicated with the Server, which incorporates the Java Based Web Services.

3.5 OTHER NON-FUNCIONAL REQUIREMENTS 3.5.1 Performance Requirements Provide an efficient and fully staffed help desk from 9:00 a.m. to 5:00 p.m. Monday through Saturday. Provide timely response to all services for software relates support.

3.5.2 Safety Requirements User will be authenticated by the use of user name and unique ID. Use of Secure Socket Layer (SSL) is recommended which prevents Software safety applies to a system until it is retired. Software upgrades, updates, fixes and other changes must be analyzed for safety impacts. User manuals must describe safety related commands and data.

3.5.3

Security Requirements User will be authenticated by the use of user name and unique ID. Use of

Secure Socket Layer (SSL) is recommended which prevents only unauthorized access as all communications are encrypted, valid digital certificates are required for this at the server end and the client browser should have support for SSL. If at all the database system is hacked, we provide essential authentication and confidentiality by encrypting the code using ASCII codes for user ID and password. 3.5.4 Software Quality Attributes Scalability The ability of the system is to either handle growing amounts of work in a graceful manner or to be readily enlarged. This application is scalable as it allows any no. of legitimate users to access the application. Correctness This application facilitates the user to perform validation checks on data. Security If at all the data based system is hacked we provide essential authentically and confidentiality by encrypting the code using ASIII for user ID and Password. Reusability This application can be reused for any specific purpose such as to update / add/ delete any students record. Maintaining This application doesnt require high maintenance because the data we get its dynamically retrieved from the data base. Robustness If the connection between the user and the system is broken prior to an order being either confirmed or cancelled the system shall enable the user to recover the incomplete order.

3.6 OTHER REQUIREMENTS 3.6.1 Data Categories Requirements Description This section describes the category of data required by system because there is no actual complete data set available for use; we will produce the needed data synthetically. This data will be more formally represented in our entity relational design data model. Requirements List A list of student fee report includes o Student Name o Student ID o Branch o Year o Amount paid o Receipt No. o Balance o Date The Cash receipt of Bus fee includes o Candidate Name o Branch o Year o Cash / DD o Amount Paid o Receipt No. o Balance o Date The Cash receipt of Tuition Fee includes

o Candidate name o Branch and year o Cash / DD o Detail of Bank, Branch, DD No. Date o Payment received on A/c. of TF, BUS, CD, EF, and Others. o Receipt No. o Remarks.

CHAPTER 3 ANALYSIS AND DESIGN 3 ANALYSIS & DESIGN 3.1. BEHAVIORAL DIAGRAM: 3.1.1. Use Case Diagram: Use Case diagrams identify the functionality provided by the system (use case), the users who interact with the system (actors), and the association between the users and the functionality. Use Cases are used in the Analysis phase of software development to articulate the high-level requirements of the system .the primary goals of Use Case diagrams include: Providing a high-level view of what the system does

Identifying the users (actors) of the system Determining areas needing human computer interfaces.

Use Cases extend beyond pictorial Diagrams. In fact, text-based use case descriptions are when used to supplement diagrams, and explore use case functionality in more detail. [3]

Fig(4.4.1): Use Case Diagram of CMS 3.1.2. Sequence diagrams:

Sequence diagrams document the interactions between classes to achieve a result, such a use case. The sequence diagram lists object horizontally, and time vertically, and models these messages over time. [3]

: Student 1: 1:SubmitDetails

: Cashier

:FeeMasterDB

:T ransactionDB

:StudentDB

2: 2:VerifyDetails 3: 3:CheckDetails

4: 4:DisplayValidDetails

5: 5:RequestT ype

6: 6:SubmitT ype 7: 7:C heckType 8: 8:VerifyType 9: 9:Display/ValidT ype

10: 10:CheckAmount 11: 11:Verifybalance

12: 12:DisplayBalance/Amount

13: 13:RequestFee

14: 14:PayFee 15: 15:Processfee 16: 16:checkfeeEntry

17: 17:UpdateSucees/GenerateRecipt

18: 18:IssueReport

Fig (4.4.2(a)): Pay Fee Main Flow

: S tu d e n t

: C a s h ie r

: F e e M a s t e rD B

: T r a n s a c t io n D b

: S tu d e n tD b

1 : 1 : S u b m it D e t a il s 2 : 2 : V e r ify D e t a il s 3 : 3 : C h e c k D e t a ils

4 : 4 : D is p la y In va lid D e t a ils 5 : 5 : R e S u b m it d e t a il s

Fig (4.4.2(b)): Pay Fee Exceptional Case-1

: S tu d e n t

: C a s h ie r

: F e e m a s t e rD B

: Tra n s a c t io n D B

: S tu d e n t D B

1 : 1 ;S u b m itD e ta il s 2 : 2 : V e r ify D e t a il s 3 : 3 : C h e c k D e t a ils

4 : 4 : D is p la y V a lid D e t a ils 5 : 5 :R e q u e s tTy p e

6 : 6 : S u b m it T y p e 7 : 7 :C h e c k Ty p e 8 : 8 : V e rify T y p e

9 : 9 : D is p la y In va lid T y p e

1 0 : 1 0 : In va lid T y p e

Fig (4.4.2(c)):

Pay Fee Exceptional Case-2

: Student

: Cashier

:FeeMasterDB

:TransactionDB

:StudentDB

1: 1:SubmitDetails 2: 2:VerifyDetails 3: 3:CheckDetails 4: 4:DisplayValidDetails 5: 5:RequestType

6: 6:SubmitType 7: 7:CheckType 8: 8:VerifyType 9: 9:Display/ValidType 10: 10:CheckAmount 11: 11:VerifyBalance

12: 12:Displaybalance/Amount 13: 13:RequestFee

14: 14:PayFee 15: 15:ProcessFee 16: 16:CheckFeeEntry

17: 17:Update/NotSuccess 18: 18:NotSuccess

Fig (4.4.2(d)): Pay Fee Exceptional Case-3

: S tudent

: Cas hier

: FeeM as terDB

:Trans actionDB

: S tudentDB

1: 1:S ubm itDetails 2: 2:V erify Details 3: 3;Chec k Details 4: 4:Dis play V alidDetails 5: 5:Reques tTy pe

6: 6:S ubm it Ty pe 7: 7;c hec k Ty pe 8: 8:V erify Ty pe

9: 9:Dis play V alidTy pe

10: 10:Chec k A m ount 11: 11:V erify A m ount

12: 12:Dis play A m oun/G enerateRec ipt 13: 13:Iss ueRec ipt

Fig (4.4.2(e)): Enquiry Main Flow

: S tu d e n t

: C a s h ie r

: F e e M a s t e rD B

: Tr a n s a c t io n D b

: S tu d e n tD B

1 : 1 : S u b m it D e t a ils 2 : 2 : V e rify D e t a ils 3 : 3 : C h e c k D e t a ils

4 : 4 : In va lid D e t a ils 5 : 5 : In va l id D e t a ils

Fig (4.4.2(f)): Enquiry Exceptional Case-1

: S tu de nt

: C a s h ie r

;F eeM as te rD B

:Tra ns ac tio nD B

:S tu de ntD B

1: 1:S ub m itD eta ils 2: 2:V erify D etails 3: 3 :C he c k de ta ils 4: 4:D is p lay V alid D etails 5 : 5:R e qu es tTy p e

6 : 6 :S ub m itTy p e 7 : 7 :C he c k Ty pe 8: 8 :V erify Ty pe

9: 9:D is p lay In validTy p e

10 : 10 :Ty pe In valid

Fig (4.2.2(g)): Enquiry Exceptional Case-2

: S tudent

: Cashier

:FeeM asterDB

:TransactionDB

:S tudentDb

1: 1:S ubm itDetails 2: 2:V erifyDetails 3: 3:CheckDetails 4: 4:Dis playV alidDetails 5: 5:Reques tTy pe

6: 6:S ubm itType 7: 7:CheckType

8: 8:V erify Type

9: 9:Dis playType

10: 10:CheckA mount 11: 11:V erifyA m ount

12: 12:Disaplay InvalidInform ation 13: 13:InvalidInform ation

Fig (4.4.2(h)): Enquiry Exceptional Case-3

: Student

: Cashier

:FeeMasterDB

:TransactionDb

:StudentDB

:AccountDB

1: 1:SubmitDetails 2: 2:Verifydetails 3: 3:CheckDetails 4: 4:DisplayValidDetails 5: 5:RequestType

6: 6:SubmitType 7: 7:CheckType 8: 8:VerirfyType

9: 9:ValidType

10: 10:CheckAmountCredit 11: 11:VerifyCredit

12: 12:validAmount/DD

13: 13:AmountCredited

14: 14:UpdateAmount 15: 15:VerifyUpdate

16: 16:DisplayUpdate

17: 17:IssueRecipt

Fig (4.4.2(i)): Scholarship Main Flow

: S tu d e n t

: C a s h ie r

: F e e M a s t e rD B

: Tra n s a c t io n D B

:S tude ntD B

:A c c ountD B

1 : 1 : S u b m it D e ta ils 2 : 2 :V e rify D e ta il s 3 : 3 :C h e c k D e t a ils

4 : 4 :In va lid D e t a ils

5 : 5 :R e S u b m it D e ta ils

Fig (4.4.2(j)): Scholarship Exceptional Case-1

: S tudent

: Cashier

:FeeM asterDB

:TransactionDB

:StudentDB

:AccountDB

1: 1:S ubm itDetails 2: 2:VerifyDetails 3: 3:Chec kDetails

4: 4:Dis play ValidDetails 5: 5:Reques tType

6: 6:Subm itType 7: 7:Chec kTy pe

8: 8:V erifyType

9: 9:InvalidType

10: 10:NotAV aliadTy pe

Fig (4.4.2(k)): Scholarship Exceptional Case-2

: S tudent

: C as hier

:F eeM a s terDB

:Trans ac tionD B

:S tudentD B

:A c c ountD B

1: 1:S ubm itD etails 2: 2:V erify details 3: 3:Che c k Details

4: 4:Dis play V alidD etails 5: 5:R eq ues tTy pe

6: 6 :S ubm itTy pe 7: 7:C hec k Ty pe

8: 8:V erify Ty pe

9: 9 : V alidTy pe 1 0: 10:C hec k A m ountTy pe 11: 11:V erify C redit

12: 1 2:InvalidInform ation

13: 13:InvalidInform ation

Fig (4.4.2(l)): Scholarship Exceptional Case-3

: Student

: Cashier

:FeeMasterDB

:TransactionDB

:StudentDB

:AccountDB

1: 1:SubmitDetails 2: 2:VerifyDetails 3: 3:CheckDetails

4: 4:DisplayValidDetails 5: 5:ReuestType

6: 6:SubmitType 7: 7:CheckType

8: 8:VerifyDetails

9: 9:ValidType

10: 10:CheckAmountCredit

11: 11:verifyCredit

12: 12:DisplayValidAmount

13: 13:AmountCredited

14: 14:UpdateAmount

15: 15:VerifyUpdate

16: 16:UpdateNotSucces

17: 17:UpdateNotSucces

Fig: (4.4.2(m)): Scholarship Exceptional Case-4

3.1.3. Collaboration Diagram: Collaboration diagrams model the interaction between objects. This type of diagram is a cross between an object diagram and a sequence diagram. It uses free-form arrangement of objects which makes it easier to see all interactions involving a particular object. .[3]

3: 3:CheckDetails 2: 2:VerifyDetails : Cashier 1: 1:SubmitDetails 6: 6:SubmitType 14: 14:PayFee :Student DB

4: 4:DisplayValidDetails

7: 7:CheckType

5: 5:RequestType 13: 13:RequestFee 18: 18:IssueReport

9: 9:Display/ValidType 10: 10:CheckAmount 15: 15:Processfee 8: 8:VerifyType

17: 17:UpdateSucees/GenerateRecipt : Student 11: 11:Verifybalance 16: 16:checkfeeEntry 12: 12:DisplayBalance/Amount :FeeMaster DB

:Transacti onDB

Fig (4.4.3(a)): Pay Fee Main Flow

1 : 1 : S u b m it D e t a ils : F e e M a s te r DB : S tu d e n t 5 : 5 :R e S u b m it d e t a ils : C a s h ie r

4 : 4 : D is p la y In va lid D e t a ils 2 : 2 :V e rify D e ta ils : Tra n s a c t io n D b 3 : 3 : C h e c k D e t a ils

: S tu d e n t Db

Fig (4.4.3(b)): Pay Fee Exceptional Case-1

8: 8:VerifyType

1: 1;Subm itDetails 6: 6:Subm itType

7: 7:CheckType :Feem ast erDB

: S tudent

5: 5:RequestType 10: 10:InvalidType

: Cashier

9: 9:DisplayInvalidType

4: 4:DisplayValidDetails

2: 2:VerifyDetails

3: 3:CheckDetails

:Transacti onDB

:Student DB

Fig (4.4.3(c)): Pay Fee Exceptional Case-2

8: 8:V e rify Ty p e 1: 1:S u b m it D e tails 6: 6:S ub m itTy pe 14 : 1 4:P ay F e e

7 : 7 :C h e c k Ty p e : F eeM a s ter DB

: S tude nt

5: 5:R eq ues tTy p e 13 : 13 :R equ es tF e e 18: 18 :N o t S uc c es s

: C as h ier

9 : 9 :D is p lay /V alidTy p e

12: 12:D is play b alan c e /A m oun t 17: 17:U p date /N otS uc c es s

4: 4:D is p la y V alid D etails

2 : 2:V erify D e tails

1 1 : 1 1:V erify B ala nc e 16 : 1 6:C he c k F ee E ntry

10 : 1 0 :C he c k A m o unt 15 : 1 5:P ro c es s F e e

3: 3 :C hec k D et ails

: Tran s ac ti onD B

: S tude n t DB

Fig (4.4.3(d)): Pay Fee Exceptional Case-3

8 : 8 :V e rify Ty p e

1 : 1 :S u b m it D e ta ils 6 : 6 :S u b m it Ty p e

7 : 7 ;c h e c k Ty p e : F ee M a s te r DB

: S tu d e n t

5 : 5 :R e q u e s tTy p e 1 3 : 1 3 :Is s u e R e c ip t

: C a s h ie r

9 : 9 :D is p la y V a lid Ty p e

1 2 : 1 2 :D is pla y A m o u n /G e n era te R e c ipt 2 : 2 :V e rify D e ta ils 4 : 4 :D is p la y V a lid D e ta ils 1 0 : 1 0 :C h e c k A m o u n t 1 1 : 1 1 :V e rify A m o u n t 3 : 3 ;C h e c k D e t a ils

: Tra n s a c t i onDB

: S tu d e n t DB

Fig (4.4.3(e)): Enquiry Main Flow

1: 1:Subm itDetails :FeeMaster DB : Student 5: 5:InvalidDetails : Cashier

4: 4:InvalidDetails

2: 2:VerifyDetails

3: 3:CheckDetails

:Transact ionDb

:Student DB

Fig (4.4.3(f)): Enquiry Exceptional Case-1

8: 8:VerifyType

1: 1:SubmitDetails 6: 6:SubmitType

7: 7:CheckType ;FeeMaster DB

: Student

5: 5:RequestType 10: 10:TypeInvalid

: Cashier

9: 9:DisplayInvalidType

4: 4:DisplayValidDetails

2: 2:VerifyDetails

3: 3:Checkdetails

:Transacti onDB :Student DB

Fig (4.4.3(g)): Enquiry Exceptional Case-2

8: 8:V erifyTy pe

1: 1:S ubm itD etails 6: 6:S ubm itTy pe

7: 7:C hec k Ty pe :F eeM ast er DB

: S tudent

5: 5:Reques tTy pe 13: 13:InvalidInform ation : C as hier

9: 9:D is play Ty pe

12: 12:Dis aplay InvalidInform ation 10: 10:C hec k A m ount

2: 2:V erify D etails

11: 11:V erify A m ount

4: 4:D is play V alidD etails

3: 3:C hec k Details

:Trans ac ti onD B

:S tudent Db

Fig (4.4.3(h)): Enquiry Exceptional Case-3

8: 8:V erirfy Ty pe

1: 1:S ubm itD etails 6: 6:S ubm itTy pe

7: 7:Chec k Ty pe : F eeM as ter DB

: S tudent

5: 5:R eques tTy pe 13: 13:A m ountCredited 17: 17:Is s ueR ec ipt

: Cashier

9: 9:V alidTy pe

16: 16:Dis play Update 10: 10:C hec k A m ountCredit 12: 14: 14:UpdateA m ount 12:validA m ount/DD

15: 15:V erify U pdate 2: 2:V erify details 4: 4:Dis play V alidDetails :Trans act ionDb 11: 11:V erify C redit

3: 3:Chec k Details

:A c count DB

: S tudent DB

Fig (4.4.3(i)): Scholarship Main Flow

1: 1:S ubm itDetails :F eeM as ter DB : S tudent 5: 5:R eS ubm itDetails : C as hier

4: 4:InvalidDetails

2: 2:V erify Details

:Trans ac ti onDB

3: 3:C hec k D etails

:A c c ount DB

: S tudent DB

Fig (4.4.3(j)): Scholarship Exceptional Case-1

8: 8:VerifyTy pe

1: 1:S ubm itDetails 6: 6:Subm itType

7: 7:Chec k Ty pe :FeeM aster DB

: Student

5: 5:Reques tTy pe 10: 10:NotA V aliadTy pe

: Cashier

9: 9:InvalidTy pe

4: 4:Dis play V alidDetails

2: 2:V erifyDetails

3: 3:Chec kDetails :Trans ac ti onDB :A c count DB :S tudent DB

Fig (4.4.3(k)): Scholarship Exceptional Case-2

8: 8:V erifyTy pe

1: 1:S ubm itDetails 6: 6:S ubm itTy pe

7: 7:Chec k Ty pe :FeeM aster DB

: S tudent

5: 5:Reques tTy pe 13: 13:InvalidInform ation

: Cashier

9: 9: V alidTy pe

4: 4:Dis play V alidDetails

12: 12:InvalidInform ation 10: 10:Chec k A m ountTy pe

2: 2:V erifydetails :Trans ac ti onDB 3: 3:Chec k Details

11: 11:V erify Credit

:S tudent DB

:A c count DB

Fig (4.4.3(l)): Scholarship Exceptional Case-3

8: 8:VerifyDetails

1: 1:Subm itDetails 6: 6:Subm itType

7: 7:Check Type :FeeM aster DB

: Student

5: 5:ReuestType 13: 13:Am ountCredited 17: 17:UpdateNotS ucces

: Cashier

9: 9:ValidTy pe

10: 10:CheckAm ountCredit 16: 16:UpdateNotSucces

15: 15:V erifyUpdate

14: 14:UpdateA m ount

12: 12:DisplayV alidAm ount

11: 11:verifyCredit

2: 2:VerifyDetails 4: 4:DisplayValidDetails :Transacti onDB 3: 3:CheckDetails :Account DB

:Student DB

Fig (4.4.3(m)): Scholarship Exceptional Case-4

3.1.4 Activity Diagram:

Activity diagrams are used to document workflows in a system, from the business level down to the operational level. The general purpose of activity diagrams is to focus on flows driven by internal processing vs. external

Fig(4.4.5): Activity Diagram

3.2 DESIGN 3.2.1 ENTITY RELATIONSHIP DIAGRAM: [1]

Entity Relationship Diagram Notations: 2 Entity: An entity is an object or concept about which you want to store information

Weak Entity:

A weak entity is an entity that must defined by a foreign key relationship with another entity as it cannot be uniquely identified by its own attributes alone.

Key attribute:

A key attribute is the unique, distinguishing characteristic of the entity. For example, an employee's social security number might be the employee's key attribute.

Multivalued attribute:

A multivalued attribute can have more than one value. For example, an employee entity can have multiple skill values.

Derived attribute:

A derived attribute is based on another attribute. For example, an employee's monthly salary is based on the employee's annual salary.

Relationships:

Relationships illustrate how two entities share information in the database structure.

Cardinality:

Cardinality specifies how many instances of an entity relate to one instance of another entity.

Recursive relationship:

In some cases, entities can be self-linked. For example, employees can supervise other employees.

Fig (4.1): ER Diagram of Cash Management

Entity Relation Diagram

3.2.2. Class Diagram: Class diagram identify the class structure of a system, including the properties and methods of each class. Also depicted are the various relationships that can exist between classes, such as an inheritance relationship. The class diagram is one of the most widely used diagrams from the UML specification.[3]

C as hie r C na m e : c har C id : int C he c k R ec ords () 1 R et urm R ec ie pts () U pd ateR ec iepts () 1 C ollec tP ay m e nt s () 1 M an ages 1 Trans a c tinD B S R ollN o : in t Trans Id : int R e c ptN o : int N a m e : c har C h ec k D etails () C h ec k P ay m ents () C h ec k TotaF ee()

P ayF e e *

S tu de nt S rollno : int pa y F ee() C olle c tR e c ie pt s ()

R e trieve

1 F ee M as t er F ee Ty pe TotalF ee U pdateF e e()

S tuden tD B S R ollN o : int S N am e : c har B ranc h : c har Y ear : int C ours e : c h ar A ddres s : c har C hec k P ay m ent()

Tu tionF eeD e tails P aidD at e : in t P aidF ee : in t B alanc e : int R em ark s : c har C om put eB alanc e()

Trans p ort F e eD eta ils P aidD a te : in t P aidF ee : int B alanc e : int R em a rk s : c har C om p ut eB alanc e()

O t herF ee D eta ils P aidD a te : int P aidF ee : in t R em ark s : c ha r C om put eB a lan c e()

D D / S c ho lars hipD etails P aidD at e : int P aidF ee : int D D no : in t B alanc e : in t R em a rk s : c har C hec k P ay m ent()

Fig (4.3.1): Class Diagram of Cash Management System

3.3 USER INTERFACE DIAGRAM

Screenshot(1): User Login

Screenshot(2): Home Page

Screenshot(3): Student Registration

Screenshot(4): User Registration

Screenshot(5): Fee Transaction

Screenshot(6): Fee Type

Screenshot(7): Fee Master

Screenshot(8): Fee Collection

Screenshot(9): Voucher

Screenshot(10): Day Reports

Screenshot(11): Reports

3.4 DATA DICTIONARY

STUDENTREGISTRATION
S.NO 1 2 3 4 5 6 7 8 9 10 11 12 13 14 COLUMN_NAME Name FathersName HallTicketNo D.O.B Gender Caste Branch Currentyear AdmissionType StudentStatus YearofAdmission Address PhoneNo Emailid DATATYPE Varchar Varchar Varchar Varchar Varchar Varchar Varchar Varchar Varchar Varchar int Varchar int Varchar LENGTH 30 30 15 15 10 10 50 10 20 10 20 500 20 50 PRIMARYKEY NOT NULL Yes Yes REMARKS

TABLE 1. STUDENT REGISTRATION

LOGIN
S.NO 1 2 3 4 5 6 7 8 9 10 COLUMN_NAME USERID password Name status IDNO DOB Gender DEPARTMENT Address PhoneNo DATATYPE Varchar Varchar Varchar Varchar Varchar Varchar Varchar Varchar Varchar int LENGTH PRIMARYKEY NOT NULL 30 30 15 15 10 10 50 10 20 20 Yes Yes REMARKS

TABLE 2. LOGIN

USERREGESTRATION
S.NO COLUMN_NAME DATATYPE LENGTH PRIMARYKEY NOT NULL REMARKS

1 2 3 4 5 6 7 8 9 10

UserName Password Name IDNO DOB Gender Department Address PhoneNo Emailid

Varchar Varchar Varchar Varchar Varchar Varchar Varchar Varchar Varchar Varchar

30 30 15 15 10 10 50 20 500 20

Yes Yes

TABLE 3. USER REGISTRATION

FEETYPE
S.NO 1 2 COLUMN_NAME FeeTypeID FeeType DATATYPE Varchar Varchar LENGTH 30 30 PRIMARYKEY NOT NULL Yes REMARKS

TABLE 4. FEE TYPE

FEEMASTER
S.NO 1 COLUMN_NAME HallTicketNO DATATYPE Varchar LENGTH 30 PRIMARYKEY NOT NULL Yes Yes REMARKS

2 3 4

feeType Amount Remarks

Varchar int Varchar

30 30 500

TABLE 5. FEE MASTER

FEECOLLECTION
S.NO 1 2 3 4 5 6 7 COLUMN_NAME HallTicketNo FeeType Amountpaid Remarks RecNo date Status DATATYPE Varchar Varchar Varchar Varchar Varchar Varchar Varchar LENGTH 30 30 15 15 10 10 50 PRIMARYKEY NOT NULL Yes Yes REMARKS

TABLE 6. FEE COLLECTION

VOUCHERS
S.NO 1 2 3 4 COLUMN_NAME Name Gender vdate Cheque DATATYPE Varchar Varchar Varchar Varchar LENGTH 30 30 15 15 PRIMARYKEY NOT NULL REMARKS

5 6 7

amount Purpose PhNO

int Varchar int

10 10 50

TABLE 7. VOUCHERS

3.5 SQL QUERIES:

Creating a Database: To create a database determines the name of the data base , its owner (the user who creates the database), its size, and the files and file groups used to store it. Three types of files are used to store a database: Primary Files:

These files contain the startup information for the database. The primary files are also used to Store Data. Every database has one primary file. Secondary Files: These files hold all the data that does not fit in the primary data file. Databases do not need secondary data files if the primary file is large enough to hold all the data in the database. Transaction Log: These files hold the log information used to recover the database. There must be at least one transaction log file for each database, although there may be more than one. The minimum size for a log file is 512 kilobytes (KB). Create a database using the CREATE DATABASE WIZARD: To create a database using the Create Database Wizard Expand a server group, and then expand the server in which to create a database. On the Tools menu, click Wizards. Expand Database. Double-click Create Database Wizard. Complete the steps in the Wizard. Creating and Modifying a Table: After you have designed the database, the tables that will store the data in the database can be created. The data is usually stored in permanent tables. Tables are stored in the database files until they are deleted and are available to any user who has the appropriate permissions. Syntax for Data Definition Language (DDL) commands: 1. CREATE: used to create tables.

Syntax: SQL> create table <table name> 2. ALTER: It is used to change/modify the structure of the table. Syntax: SQL> alter table <table name> modify(field-name datatype(size)); (To Add) SQL> alter table <table name> add(field-name datatype(size)); 3. DROP: Drop command is used to delete the table from the database. Syntax: SQL> drop table <table name>;

Syntax for Data Manipulation Language (DML) commands: Data Manipulation Language has four commands: 1. INSERT: This command is used to insert the records into the table. Syntax: for Implicit Insertion: SQL> insert into< table name>values(field value1, field value 2.); Explicit Insertion: SQL> insert into < table name >values(column value1, column value2.); 2. DELETE: This command is used to delete the records from the table. Syntax: SQL> delete from < table name >where< condition >;

3. UPDATE: This command is used to add data into the existing table. Syntax: SQL> update < table name >set (column name)=(column value); < column name2 >= < column value2 >..n [ where < condition >]; 4. SELECT: This command is used to retrieve data records from an existing table. Syntax: SQL> select *from < table name >; Syntax of Select statement with all optional clauses i.e., from, group by, having, where, order by: SQL> select < condition1 > From < table name > Group by < condition2 > Having < condition3 > Where < condition4 > Order by < condition5 > ; Aggregate Operators in SQL: SQL supports five aggregate operators as mentioned below. a. Count [distinct]= a number of unique values in the column A. b. Average [distinct]= a number of unique values in the A column. c. Max [A]= a maximum value in the A column. d. Min (A)= a minimum value in the A column. Sum ([distinct])= the sum of all (unique) values in A column. Data Dictionary:

The logical characteristics of current systems data stores, including name, description, aliases, contents, and organization. Identifies processes where the data are used and where immediate access to information needed. Serves as the basis for identifying database requirements during system design. Uses of Data Dictionary: i. ii. iii. iv. To manage the detail in large systems To communicate a common meaning for all system elements To Document the features of the system To facilitate analysis of the details in order to evaluate characteristics and determine where system changes should be made. v. To locate errors and omissions in the systems

QUERIES:

1.

tb_login CREATE TABLE `tb_login` ( `USERID` varchar(20) NOT NULL, `USERID` varchar(20) NOT NULL, `password` varchar(20) DEFAULT NULL, `Name` varchar(30) DEFAULT NULL,`status` varchar(1) DEFAULT NULL, `IDNO` varchar(10) DEFAULT NULL, `DOB` varchar(10) DEFAULT NULL, `Gender` varchar(10) DEFAULT NULL,`DEPARTMENT` varchar(10) DEFAULT NULL, `Address` varchar(200) DEFAULT NULL,`PhoneNo` varchar(20) DEFAULT NULL, PRIMARY KEY (`USERID`) )

2. tb_student CREATE TABLE `tb_student` ( `Name` varchar(20) DEFAULT NULL,`FathersName` varchar(20) DEFAULT NULL,`HallTicketNO` varchar(20) NOT NULL,`DOB` varchar(20) DEFAULT NULL, `Gender` varchar(10) DEFAULT NULL,`Caste` varchar(20) DEFAULT NULL, `Branch` varchar(20) DEFAULT NULL, Currentyear` varchar(20) DEFAULT NULL, `AdmissionType` varchar(20) DEFAULT NULL,`StudentStatus` varchar(10) DEFAULT NULL, `YearofAdmission` int(20) DEFAULT NULL,

`Address` varchar(200) DEFAULT NULL,`PhoneNo` int(20) DEFAULT NULL,`Emailid` varchar(20) DEFAULT NULL,PRIMARY KEY (`HallTicketNO`))

3. tb_userreg CREATE TABLE `tb_userreg` ( `UserName` varchar(10) DEFAULT NULL,`Password` varchar(10) DEFAULT NULL, `Name` varchar(20) DEFAULT NULL,`IDNO` varchar(10) DEFAULT NULL, `DOB` varchar(10) DEFAULT NULL,`Gender` varchar(10) DEFAULT NULL, `Department` varchar(10) DEFAULT NULL,`Address` varchar(100) DEFAULT NULL,`PHNO` varchar(10) DEFAULT NULL, `Email` varchar(10) DEFAULT NULL )

4. tb_feetype CREATE TABLE `tb_feetype` (`FeeTypeID` int(10) NOT NULL AUTO_INCREMENT,`FeeType` varchar(30) DEFAULT NULL, PRIMARY KEY (`FeeTypeID`) )

5. tb_feemaster CREATE TABLE `tb_feemaster` ( `HallTicketNO` varchar(10) NOT NULL,`feeType` int(10) NOT NULL,`Amount` varchar(10) DEFAULT NULL, `Remarks` varchar(10) DEFAULT NULL,PRIMARY KEY (`HallTicketNO`))

6. tb_feecollection CREATE TABLE `tb_feecollection` ( `HallTicketNo` varchar(10) NOT NULL,`Feetype` int(10) DEFAULT NULL, `Amountpaid` varchar(10) DEFAULT NULL, Remarks` varchar(10) DEFAULT NULL,`RecNo` varchar(10) DEFAULT NULL,`date` varchar(12) DEFAULT NULL,`Status` varchar(1) DEFAULT NULL, PRIMARY KEY (`HallTicketNo`) )

7. b_voucher CREATE TABLE `tb_voucher` (`Name` varchar(20) DEFAULT NULL,`Gender` varchar(20) DEFAULT NULL,`vdate` varchar(20) DEFAULT NUL,`Cheque` varchar(20) DEFAULT NULL,`amount` varchar(20)

DEFAULT NULL,`Purpose` varchar(500) DEFAULT NULL,`PhNO` varchar(20) DEFAULT NULL )

CHAPTER 4 4 CONCLUSIONS

4.1 SCOPE FOR FUTURE ENHANCEMENTS:

It is possible to upgrade the system as per the technology and can be adaptable to any desired environment. As it is based on a simple design, any further changes can be easily adaptable. Security can also be achieved in case of future security issues as per the emerging technologies.

APPENDIX A List of Figures

S.No 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

Figure No Fig (2.2(a)): Fig (2.2(b)): Fig (4.1): Fig (4.3.1): Fig (4.3.2): Fig (4.3.3): Fig (4.4.1): Fig (4.4.2(a)): Fig (4.4.2(b)): Fig (4.4.2(c)): Fig (4.4.2(d)): Fig (4.4.2(e)): Fig (4.4.2(f)): Fig (4.4.2(g)): Fig (4.4.2(h)): Fig (4.4.2(i)): Fig (4.4.2(j)): Fig (4.4.2(k)): Fig (4.4.2(l)): Fig (4.4.2(m)): Fig (4.4.3(a)): Fig (4.4.3(b)): Fig (4.4.3(c)): Fig (4.4.3(d)): Fig (4.4.3(e)): Fig (4.4.3(f)): Fig (4.4.3(g)): Fig (4.4.3(h)): Fig (4.4.3(i)): Fig (4.4.3(j)): Fig (4.4.3(k)): Fig (4.4.3(l)): Fig (4.4.3(m)): Fig (4.4.4(a)): Fig (4.4.4(b)):

NAME OF THE FIGURE JBDC Two-tier Model JDBC Three- Tier model Entity Relationship Diagram of CMS Class Diagram of CMS Component Diagram Deployment Diagram Use Case Diagram of CMS Sequence Diagram of Pay Fee Main Flow Sequence Diagram of Pay Fee Exceptional Case-1 Sequence Diagram of Pay Fee Exceptional Case-2 Sequence Diagram of Pay Fee Exceptional Case-3 Sequence Diagram of Enquiry Main Flow Sequence Diagram of Enquiry Exceptional Case-1 Sequence Diagram of Enquiry Exceptional Case-2 Sequence Diagram of Enquiry Exceptional Case-3 Sequence Diagram of Scholarship Main Flow Sequence Diagram of Scholarship Fee Exceptional Case-1 Sequence Diagram of Scholarship Fee Exceptional Case-2 Sequence Diagram of Scholarship Fee Exceptional Case-3 Sequence Diagram of Scholarship Fee Exceptional Case-4 Collaboration Diagram of Pay Fee Main Flow Collaboration Diagram of Pay Fee Exceptional Case-1 Collaboration Diagram of Pay Fee Exceptional Case-2 Collaboration Diagram of Pay Fee Exceptional Case-3 Collaboration Diagram of Enquiry Main Flow Collaboration Diagram of Enquiry Exceptional Case-1 Collaboration Diagram of Enquiry Exceptional Case-2 Collaboration Diagram of Enquiry Exceptional Case-3 Collaboration Diagram of Scholarship Fee Main Flow Collaboration Diagram of Scholarship Fee Exceptional Case-1 Collaboration Diagram of Scholarship Fee Exceptional Case-2 Collaboration Diagram of Scholarship Fee Exceptional Case-3 Collaboration Diagram of Scholarship Fee Exceptional Case-4 State Chart Diagram State Chart Diagram

PAGE NO

APPENDIX B LIST OF TABLES

S. No 1 2 3 4 5 6 7

Table No Table 1 Table 2 Table 3 Table 4 Table 5 Table 6 Table 7

Table Description Student Registration Login User Registration Fee Type Fee Master Fee Collection Voucher

Page No

CONCLUSION

CASH MANAGEMENT SYSTEM ensures basic functionality of the student as well as the administrator.

We conclude that the functionalities developed are successfully implemented.

 Through the proposed CASH MANAGEMENT SYSTEM the expected efficiency and throughput is implemented.

REFERENCES

[1] Web programming, building internet application, Chris Bates 2nd edition, WILEY Dreamtech.

[2] Greedy Booch, James Rambough, Unified Modeling Language , Pearson Publications [3] Software Engineering, A Practitioners Approach-Roger Pressman, 6th edition. Mc GrawHill International Edition.