sampl Project Format

7/29/2019 sampl Project Format

1/81

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 calculationsconsuming 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


2/81

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


3/81

CONTENTS

CHAPTER 1

1. INTRODUCTION 1

1.1 Purpose 1

1.2 Scope 1

1.3 Existing System 1

1.4 Proposed 1

1.5 Modules 2

1.6 Application, Goal, Objective & Benefits 2

1.7 Requirements 2

1.8 Hardware Requirements 3

1.9 Software Requirements 3

CHAPTER 2

2. SOFTWARE REQUIREMENT SPECIFICATION 4

2.1 INTRODUCTION 4

2.1.1 Purpose 4

2.1.2 Document conventions 4

2.1.3 Intended Audience and Reading Suggest 4

2.1.4 Project Scope 4

2.1.5 Reference 5

2.2 OVERALL DESCRIPTION 5

2.2.1 Product perspective 5


4/81

2.2.2 Product Features 5

2.2.3 User Classes and Characteristics 6

2.2.4 Operating Environment 6

2.2.5 Design and Implementation Constraints 7

2.2.6 User Documentations 7

2.2.7 Assumptions and Dependencies 7

2.3 SYSTEM FEATURES 7

2.3.1 System Feature 1 7

2.3.2 System Feature 2 8

2.4 EXTERNAL INTERFACE REQUIREMENT 8

2.4.1 User Interface 8

2.4.2 Hardware Interface 8

2.4.3 Software Interface 8

2.4.4 Communication Interface 8

2.5 OTHER NON FUNCTIONAL REQUIREMENTS 9

2.5.1 Performance Requirements 9

2.5.2 Safety Requirements 9

2.5.3 Security Requirements 9

2.5.4 Software Quality Attributes 9

2.6 OTHER REQUIREMENTS

CHAPTER 3


5/81

3. ANALYSIS & DESIGN

3.1 BEHAVIORAL DIAGRAM

3.1.1Use 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.4Data 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


6/81

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


7/81

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:


8/81

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 : PC with 80 GB hard disk and 512 MB RAM

Operating System : Windows with MS Office

Software : Java, JDBC, JSP

DBMS : MySQL

1.8 Hardware Requirements:

Processor- Intel p4 based system

Processor Speed-250 MHz to 833 MHz

RAM- 64 MB to 256 MB


9/81

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


10/81

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 : Times New Roman 14(caps)

Subtitle : Times New Roman 14 (first letter caps) boldRemaining text : Times New Roman 12

Line spacing : 1.5 cms


11/81

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 andreceivable 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


12/81

3.2OVERALL 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:

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.

3.2.3 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


13/81

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.


14/81

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.

The system is user friendly.

Easy to access and easily understandable.

3.2.7 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.


15/81

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 # Description Priority

REQ-SR1 The user can retrieve the records [Priority = High]

REQ-SR2 Add/updating/del records [Priority =Medium]

REQ-SR3 Authenticating the record /data [Priority = medium]

3.3.2 Cash Receipts and Payments Feature


This features enhances all the activities by the payee and as well as the cashier.

Functional Requirements


REQ-CRP1 Cash Payment by the payee [Priority = High]


16/81

REQ-CRP2 Update the receivable payments Into the records [Priority = High]

REQ-CRP3 Add / deleting the records [Priority = medium]

REQ-CRP4 Provide receipt [Priority = High]

REQ-BR5 Maintaining the bills [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.


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 : Cashier enters the personal ID and Password.

Response : ID and Password are validated.Stimulus : Cashier selects the type of transaction to be done.

Response : The page of selected type of transaction is opened. It even

supports redirection of the pages.

Stimulus : Cashier performs the transaction.


17/81

Response : The transaction is stored in the database and the cashier is

intimated of completion of the transaction.

Stimulus : The cashier logs out of the system.

Response : Login page is displayed.


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-SDR1 Login/Logout [Priority = High]

REQ-SDR2 Add/View [Priority =High]

REQ-SDR3 Delete [Priority = medium]

REQ-SDR4 Generate Receipt [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 theadministration/management.


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


18/81

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 ResponseStimulus : Accountant/Cashier enters the password ID and Password and

select on login.

Response : ID and Password are validation.

Stimulus : If wrong ID/Password is entered.

Response : The system asks for a valid ID and Password.

Stimulus : If valid ID and Password are entered.

Response : The cashier is directed towards the Home page by the system.


The cashier must be an authentic person. The cashier ID and Password should

be genuine in order to log into the system.


REQ-L1 Login [Priority = High]

REQ-L2 Authenticated [Priority =High]

3.3.5 Fee Payment


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 : Accountant/Cashier selects the type of fee to be paid

(For e.g. Tuition fee)

Response : The Tuition fee payment receipt form is displayed.


19/81

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

receipt.

Response : The fee is paid and the payment is saved in the database. The

receipt of the fee is generated as a printed form.


The basics functional requirement of this features is the student paying the fee

and the cashier receiving the fee.


REQ-FP1 Paying the fee [Priority = High]

REQ-FP2 Update [Priority =High]

REQ-FP3 Generate receipt [Priority =High]

3.3.6 Reports


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 : The cashier enters each and every transaction into the fee collection

statement with in a particular period of time and select on the save

button.


20/81

Response : The statement is recorded in the Database and the management can

access whenever required.

Stimulus : The cashier select on the print button.

Response : The transaction statement entered is printed for forwarding it further to

the management

Functional Requirement

The functional requirements for this feature are the printer.


REQ-RP1 View [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 toanother. All the screens are user friendly

3.4.2 Hardware Interfaces

Internet connection

System with P4 processors

512 MB RAM

Network Interface Card


21/81

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

Thisproject 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.


22/81

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.


23/81

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


24/81

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


25/81

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:


26/81

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 : 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:UpdateSucees/GenerateRecipt

18: 18:IssueReport

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


27/81

: S tu d e n t : C a s h i e r : F e e M a s t e rD B : T r a n s a c t io n D b : S t u d e n t D b

1 : 1 : S u b m it D e t a i l s

2 : 2 : V e r i f y D e t a il s

3 : 3 : C h e c k D e t a i l

4 : 4 : D i s p l a y In v a l id D e t a i ls

5 : 5 :R e S u b m i t d e t a il s

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


28/81

: S t u d e n t : C a s h i e r : F e e m a s t e rD B : T ra n s a c t io n D B : S tu d e n t D B

1 : 1 ; S u b m i tD e t a il s

2 : 2 : V e r ify D e t a i l s

3 : 3 : C h e c k D e t a il s

4 : 4 : D i s p l a y V a l i d D e t a i l s

5 : 5 : R e q u e s t T y p e

6 : 6 :S u b m i tT y p e

7 : 7 : C h e c k T y p e

8 : 8 : V e r i fy T y p e

9 : 9 : D i s p l a y In v a li d T y p e

1 0 : 1 0 : I n v a l i d T y p e

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


29/81

: Student : Cashier :FeeMasterDB :TransactionDB :StudentDB

1: 1:SubmitDetails

2: 2:VerifyDetails

3: 3:CheckDetails


5: 5:RequestType

6: 6:SubmitType

7: 7:CheckType

8: 8:VerifyType


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


30/81

: S tudent : Cashier :FeeM as terDB :Transact ionDB :S tudentDB

1: 1:SubmitDetails

2: 2:V erifyDetails

3: 3;CheckDetails


5: 5:RequestType

6: 6:Subm itType

7: 7;checkType

8: 8:V erifyType

9: 9:DisplayValidType

10: 10:CheckAm ount

11: 11:VerifyAmount

12: 12:DisplayAmoun/GenerateRecipt

13: 13:IssueRecipt

Fig (4.4.2(e)): Enquiry Main Flow


31/81

: S t u d e n t : C a s h i e r : F e e M a s t e rD B : T r a n s a c t io n D b : S t u d e n t D B

1 : 1 : S u b m it D e t a i l s

2 : 2 : V e r if y D e t a i l s

3 : 3 : C h e c k D e t a i l

4 : 4 : I n va l i d D e t a i ls

5 : 5 : I n va l i d D e t a i ls

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


32/81

: S tudent : Cashier ;FeeM as terDB :Trans ac t ionDB :S tudentDB

1: 1:SubmitDetai ls

2: 2:Veri fyDetai ls

3: 3:Checkdetai ls

4: 4:DisplayV al idDetails

5: 5:RequestType

6: 6:SubmitType

7: 7:CheckType

8: 8 :Veri fyType

9: 9:DisplayInvalidType

10: 10:TypeInvalid

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


33/81

: S tudent : Cashier :FeeM as terDB :TransactionDB :S tudentDb

1: 1:SubmitDetails

2: 2:VerifyDetails

3: 3:CheckDetails

4: 4:DisplayV alidDetails

5: 5:RequestType

6: 6:SubmitType

7: 7:CheckType

8: 8:V erifyType

9: 9:DisplayType

10: 10:CheckAmount

11: 11:VerifyA mount

12: 12:DisaplayInvalidInformation

13: 13:InvalidInformat ion

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


34/81

: Student : Cashier :FeeMasterDB :TransactionDb :StudentDB :AccountDB

1: 1:SubmitDetails

2: 2:Verifydetails

3: 3:CheckDetails


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


35/81

: S tu de n t : C a s hie r : F e e M a s t e rD B : Tra n s ac t io n D B : S tu d e n t D B : A c c o u n t D B

1 : 1 : S u b m i tD e t a il s

2 : 2 : V e r ify D e t a i ls

3 : 3 : C h e c k D e t a il s

4 : 4 : I n va l i d D e t a i l s

5 : 5 : R e S u b m i tD e t a il s

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


36/81

: S tudent : Cashier :FeeM asterDB :Transact ionDB :S tudentDB :AccountDB

1: 1:SubmitDetails

2: 2:VerifyDetails

3: 3:CheckD etails


5: 5:RequestType

6: 6:SubmitType

7: 7:CheckType

8: 8:VerifyType

9: 9:InvalidType

10: 10:NotAV aliadType

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


37/81

: S tudent : Cashier :FeeM asterDB :Trans ac t ionDB :S tudentDB :A c countDB

1: 1:SubmitDetai ls

2: 2:Ver i fydetai ls

3: 3:CheckDetai ls

4: 4:DisplayVal idDetai ls

5: 5:RequestType

6: 6:Subm i tType

7: 7:CheckType

8: 8:Ve r i fyType

9: 9: Val idType

10: 10:CheckA mountType

11: 11:Ver i fyCredi t

12: 1 2:InvalidInform ation

13: 13:InvalidInform ation

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


38/81

: Student : Cashier :FeeMasterDB :TransactionDB :StudentDB :AccountDB

1: 1:SubmitDetails

2: 2:VerifyDetails

3: 3:CheckDetails


5: 5:ReuestType

6: 6:SubmitType

7: 7:CheckType

8: 8:VerifyDetails

9: 9:ValidType


11: 11:verifyCredit

12: 12:DisplayValidAmount

13: 13:AmountCredited

14: 14:UpdateAmount

15: 15:VerifyUpdate

16: 16:UpdateNotSucces


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


39/81

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]

: Student

: Cashier

:FeeMaster

DB

:Transacti

onDB

:Student

DB

3: 3:CheckDetails

8: 8:VerifyType

11: 11:Verifybalance16: 16:checkfeeEntry

1: 1:SubmitDetails6: 6:SubmitType

14: 14:PayFee

5: 5:RequestType13: 13:RequestFee18: 18:IssueReport

2: 2:VerifyDetails


7: 7:CheckType


10: 10:CheckAmount15: 15:Processfee

17: 17:UpdateSucees/GenerateRecipt

12: 12:DisplayBalance/Amount

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


40/81

: S t u d e n t : C a s h ie r

: F e e M a s t e r

D B

: T r a n s a c t

i o n D b

: S t u d e n t

D b

3 : 3 : C h e c k D e t a ils

1 : 1 : S u b m it D e t a i ls

5 : 5 : R e S u b m i t d e t a il s

2 : 2 : V e r ify D e t a i l s4 : 4 : D i s p l a y I n v a l i d D e t a i l s

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


41/81

: Student : Cashier

:FeemasterDB

:Transacti

onDB :Student

DB

3: 3:CheckDetails

8: 8:VerifyType

1: 1;SubmitDetails

6: 6:SubmitType

5: 5:RequestType

10: 10:InvalidType

2: 2:VerifyDetails4: 4:DisplayValidDetails

7: 7:CheckType


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


42/81

: S tu d e n t : C a s h ie r

: F e e M a s t e r D B

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

: S t u d e n tD B

3 : 3 : C h e c k D e t a i ls

8 : 8 : V e r i f y T y p e

1 1 : 1 1 : V e r i fy B a l a n c e1 6 : 1 6 : C h e c k F e e E n t r y

1 : 1 : S u b m i t D e t a i l s6 : 6 :S u b m i tT y p e1 4 : 1 4 : P a y F e e

5 : 5 : R e q u e s t T y p e1 3 : 1 3 : R e q u e s t F e e1 8 : 1 8 : N o t S u c c e s s

2 : 2 : V e r if y D e t a i l s4 : 4 : D i s p l a y V a l i d D e t a i l s

7 : 7 : C h e c k T y p e

9 : 9 : D i s p l a y / V a l id T y p e

1 0 : 1 0 :C h e c k A m o u n t1 5 : 1 5 : P r o c es s F e e

1 2 : 1 2 : D i s p l a y b a l a n c e / A m o u n t1 7 : 1 7 : U p d a t e / N o t S u c c e s s

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


43/81

: S t u d e n t : C a s h ie r

: F e e M a s t e r

D B

: T r a n s a c t i

o n D B

: S t u d e n t

D B

3 : 3 ; C h e c k D e t a i l s

8 : 8 : V e r i f y T y p e

1 1 : 1 1 : V e r ify A m o u n t

1 : 1 : S u b m it D e t a i ls6 : 6 : S u b m it T y p e

5 : 5 : R e q u e s t T y p e1 3 : 1 3 : I s s u e R e c i p t

7 : 7 ;c h e c k T y p e

9 : 9 : D i s p la y V a l id T y p e

2 : 2 : V e r i f y D e t a i l s4 : 4 : D i s p l a y V a l i d D e ta i l s

1 0 : 1 0 :C h e c k A m o u n t

1 2 : 1 2 : D i s p l a y A m o u n / G e n e r a te R e c i p t

Fig (4.4.3(e)): Enquiry Main Flow


44/81

: Student : Cashier

:FeeMaster

DB

:Transact

ionDb :Student

DB

3: 3:CheckDetails

1: 1:SubmitDetails

5: 5:InvalidDetails

2: 2:VerifyDetails4: 4:InvalidDetails

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


45/81

: Student : Cashier

;FeeMaster

DB

:Transacti

onDB:Student

DB

3: 3:Checkdetails

8: 8:VerifyType

1: 1:SubmitDetails6: 6:SubmitType

5: 5:RequestType10: 10:TypeInvalid

2: 2:VerifyDetails4: 4:DisplayValidDetails

7: 7:CheckType


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


46/81

: Student : Cashier

:FeeMaster

DB

:Transact i

onDB

:Student

Db

3: 3:CheckDetai ls

8: 8:V er ifyType

11: 11:Ver i fyAmount

1: 1:SubmitDetai ls

6: 6:Subm i tType

5: 5:RequestType13: 13:InvalidInformation

2: 2:VerifyDetails

4: 4:DisplayVal idDetails

7: 7:CheckType

9: 9:DisplayType

10: 10:CheckAmount12: 12:DisaplayInvalidInformation

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


47/81

:Account

DB

: Student : Cashier

:FeeMaster

DB

:Transact

ionDb

:Student

DB

3: 3:CheckDetai ls

8: 8:Verir fyType

11: 11:Veri fyC redit15: 15:Veri fyU pdate

1: 1:SubmitDetai ls6: 6:Subm i tType

5: 5:RequestType13: 13:AmountCredited

17: 17:IssueRecipt

2: 2:Veri fydetai ls

4: 4:DisplayVal idDetails

7: 7:CheckType

9: 9:Val idType

10: 10:CheckA mountCredit12: 12:val idAmount/DD14: 14:UpdateAm ount

16: 16:DisplayUpdate

Fig (4.4.3(i)): Scholarship Main Flow


48/81

: S tudent : Cas hier

:FeeMaster

DB

:Transacti

onDB

:Student

DB

:Account

DB

3: 3:Check Detai ls

1: 1:SubmitDetai ls

5: 5:ReSubmitDetai ls

2: 2:VerifyDetails4: 4:InvalidDeta ils

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


49/81

: S tudent : Cashier

:FeeMaster

DB

:Transacti

onDB

:Student

DB

:Account

DB

3: 3:CheckDetails

8: 8:VerifyType

1: 1:Subm itDetails6: 6:SubmitType

5: 5:RequestType10: 10:NotAV aliadType

2: 2:VerifyDetails4: 4:DisplayV alidDetails

7: 7:CheckType

9: 9:InvalidType

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


50/81

: S tudent : Cashier

:FeeMasterDB

:Transacti

onDB

:Student

DB

:Account

DB

3: 3:Check Detai ls

8: 8:VerifyType

11: 11:VerifyCredit

1: 1:Subm itDetai ls6: 6:Subm itType

5: 5:RequestType13: 13:InvalidInformation

2: 2:Verifydetails


7: 7:CheckType

9: 9: ValidType

10: 10:CheckAmountType

12: 12:InvalidInform ation

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


51/81

: Student : Cashier

:FeeMaster

DB

:Transacti

onDB

:StudentDB

:Account

DB

3: 3:CheckDetails

8: 8:VerifyDetails

11: 11:verifyCredit15: 15:V erifyUpdate

1: 1:SubmitDetails6: 6:Subm itType

5: 5:ReuestType13: 13:AmountCredited


2: 2:VerifyDetails


7: 7:CheckType

9: 9:ValidType


12: 12:DisplayValidAmount14: 14:UpdateAmount


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

3.1.4 Activity Diagram:


52/81

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


53/81

Fig(4.4.5): Activity Diagram


54/81

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

3 Weak Entity:

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


55/81

4 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.

5 Multivalued attribute:

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

can have multiple skill values.

6 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.

7 Relationships:

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

8 Cardinality:

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

entity.


56/81

9 Recursive relationship:

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

employees.


57/81

Fig (4.1): ER Diagram of Cash Management

Entity RelationEntity Relation

DiagramDiagram


58/81

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 themost widely used diagrams from the UML specification.[3]

FeeMas te r

FeeType

TotalFee

UpdateFee()

Tut ionFeeDetai ls

Pa idDate : in t

PaidFee : intBalance : int

Remarks : char

ComputeBa lance( )

TransportFeeDetai ls

PaidDate : int

PaidFee : intBalance : int

Remarks : char

ComputeBa lance( )

OtherFeeDetai ls

PaidDate : int

PaidFee : intRemarks : char

ComputeBa lance( )

DD/ScholarshipDetai ls

Pa idDate : in t

PaidFee : int

DDno : int

Balance : intRemarks : char

CheckPayment( )

Student

S rollno : int

payFee()

Col lectReciepts()

StudentDB

SRol lNo : int

SN ame : c ha r

Branch : char

Year : in t

Course : char

A ddres s : c ha r

CheckPayment( )

Transact inDB

SRol lNo : int

TransId : int

RecptNo : int

Name : char

CheckDetai ls( )

C hec k Pay men ts ( )

CheckTotaFee()

Cashier

Cname : char

Cid : int

CheckRecords()

ReturmReciepts()

UpdateReciepts()

Co l lec tPayments ( )

*1 *1

PayFee

1

1

1

1

Retr ieve

1

1

1

1

Manages

Fig (4.3.1): Class Diagram of Cash Management System


59/81

3.3 USER INTERFACE DIAGRAM

Screenshot(1): User Login


60/81

Screenshot(2): Home Page

Screenshot(3): Student Registration


61/81

Screenshot(4): User Registration

Screenshot(5): Fee Transaction


62/81

Screenshot(6): Fee Type

Screenshot(7): Fee Master


63/81

Screenshot(8): Fee Collection

Screenshot(9): Voucher


64/81

Screenshot(10): Day Reports

Screenshot(11): Reports


65/81

3.4 DATA DICTIONARY

STUDENTREGISTRATION

S.NO COLUMN_NAME DATATYPE LENGTH PRIMARYKEY NOT

NULL

REMARKS

1 Name Varchar 30 - -

2 FathersName Varchar 30 - -

3 HallTicketNo Varchar 15 Yes Yes

4 D.O.B Varchar 15 - -

5 Gender Varchar 10 - -

6 Caste Varchar 10 - -

7 Branch Varchar 50 - -

8 Currentyear Varchar 10 - -

9 AdmissionType Varchar 20 - -

10 StudentStatus Varchar 10 - -

11 YearofAdmission int 20 - -

12 Address Varchar 500 - -

13 PhoneNo int 20 - -

14 Emailid Varchar 50 - -

TABLE 1. STUDENT REGISTRATION


66/81

LOGIN


NULL

REMARKS

1 USERID Varchar 30 Yes Yes

2 password Varchar 30 - -

3 Name Varchar 15 -

-

4 status Varchar 15 - -

5 IDNO Varchar 10 - -

6 DOB Varchar 10 - -


8 DEPARTMENT Varchar 10 - -

9

Address Varchar 20 - -

10 PhoneNo int 20 - -

TABLE 2. LOGIN

USERREGESTRATIONS.NO COLUMN_NAME DATATYPE LENGTH PRIMARYKEY NOT

NULL

REMARKS


67/81

1 UserName Varchar 30 - -

2 Password Varchar 30 - -

3 Name Varchar 15 Yes Yes

4 IDNO Varchar 15 - -

5 DOB Varchar 10 - -


7 Department Varchar 50 - -

8 Address Varchar 20 - -

9 PhoneNo Varchar 500 - -

10 Emailid Varchar 20 - -

TABLE 3. USER REGISTRATION

FEETYPE


NULL

REMARKS

1 FeeTypeID Varchar 30 Yes -

2 FeeType Varchar 30 - -

TABLE 4. FEE TYPE

FEEMASTER


NULL

REMARKS

1 HallTicketNO Varchar 30 Yes Yes


68/81

2 feeType Varchar 30 - -

3 Amount int 30 - -

4 Remarks Varchar 500 - - -

TABLE 5. FEE MASTER

FEECOLLECTIONS.NO COLUMN_NAME DATATYPE LENGTH PRIMARYKEY NOT

NULL

REMARKS

1 HallTicketNo Varchar 30 Yes Yes

2 FeeType Varchar 30 - -

3 Amountpaid Varchar 15 - -

4 Remarks Varchar 15 - -

5 RecNo Varchar 10 - -

6 date Varchar 10 - -

7 Status Varchar 50 - -

TABLE 6. FEE COLLECTION

VOUCHERSS.NO COLUMN_NAME DATATYPE LENGTH PRIMARYKEY NOT

NULL

REMARKS

1 Name Varchar 30 - -


3 vdate Varchar 15 - -

4 Cheque Varchar 15 - -


69/81

5 amount int 10 - -

6 Purpose Varchar 10 - -

7 PhNO int 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:


70/81

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.


71/81

Syntax:

SQL> create table

2. ALTER: It is used to change/modify the structure of the table.

Syntax:

SQL> alter table modify(field-name datatype(size));

(To Add)

SQL> alter table add(field-name datatype(size));

3. DROP: Drop command is used to delete the table from the database.

Syntax:

SQL> drop table ;

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 >;


72/81

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:


73/81

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. To manage the detail in large systems

ii. To communicate a common meaning for all system elements

iii. To Document the features of the system

iv. 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` ( ÙSERID` varchar(20) NOT NULL,ÙSERID` varchar(20) NOT NULL, `password` varchar(20) DEFAULT NULL,

`Name` varchar(30) DEFAULT NULL,`status` varchar(1) DEFAULT NULL,

ÌDNO` varchar(10) DEFAULT NULL, `DOB` varchar(10) DEFAULT NULL,

`Gender` varchar(10) DEFAULT NULL,`DEPARTMENT` varchar(10)

DEFAULT NULL, Àddress` varchar(200) DEFAULT NULL,`PhoneNo`

varchar(20) DEFAULT NULL, PRIMARY KEY (ÙSERID`) )

2. tb_student CREATE TABLE `tb_student` ( `Name` varchar(20) DEFAULTNULL,`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, ÀdmissionType` varchar(20) DEFAULT NULL,`StudentStatus`

varchar(10) DEFAULT NULL, `YearofAdmission` int(20) DEFAULT NULL,


74/81

Àddress` varchar(200) DEFAULT NULL,`PhoneNo` int(20) DEFAULT

NULL,Èmailid` 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,ÌDNO` varchar(10) DEFAULT NULL,

`DOB` varchar(10) DEFAULT NULL,`Gender` varchar(10) DEFAULT NULL,

`Department` varchar(10) DEFAULT NULL,Àddress` varchar(100)

DEFAULT NULL,`PHNO` varchar(10) DEFAULT NULL, Èmail` 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,Àmount` 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,

Àmountpaid` 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,àmount` varchar(20)


75/81

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

varchar(20) DEFAULT NULL )

CHAPTER 4

4 CONCLUSIONS


76/81

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


77/81

S.No Figure No NAME OF THE FIGURE PAGE

NO

1 Fig (2.2(a)): JBDC Two-tier Model

2 Fig (2.2(b)): JDBC Three- Tier model

3 Fig (4.1): Entity Relationship Diagram of CMS

4 Fig (4.3.1): Class Diagram of CMS

5 Fig (4.3.2): Component Diagram

6 Fig (4.3.3): Deployment Diagram

7 Fig (4.4.1): Use Case Diagram of CMS

8 Fig (4.4.2(a)): Sequence Diagram of Pay Fee Main Flow

9 Fig (4.4.2(b)): Sequence Diagram of Pay Fee Exceptional Case-1

10 Fig (4.4.2(c)): Sequence Diagram of Pay Fee Exceptional Case-2

11 Fig (4.4.2(d)): Sequence Diagram of Pay Fee Exceptional Case-3

12 Fig (4.4.2(e)): Sequence Diagram of Enquiry Main Flow

13 Fig (4.4.2(f)): Sequence Diagram of Enquiry Exceptional Case-1

14 Fig (4.4.2(g)): Sequence Diagram of Enquiry Exceptional Case-2

15 Fig (4.4.2(h)): Sequence Diagram of Enquiry Exceptional Case-3

16 Fig (4.4.2(i)): Sequence Diagram of Scholarship Main Flow

17 Fig (4.4.2(j)): Sequence Diagram of Scholarship Fee Exceptional

Case-1

18 Fig (4.4.2(k)): Sequence Diagram of Scholarship Fee Exceptional

Case-2

19 Fig (4.4.2(l)): Sequence Diagram of Scholarship Fee Exceptional

Case-3

20 Fig (4.4.2(m)): Sequence Diagram of Scholarship Fee Exceptional

Case-421 Fig (4.4.3(a)): Collaboration Diagram of Pay Fee Main Flow

22 Fig (4.4.3(b)): Collaboration Diagram of Pay Fee Exceptional Case-1

23 Fig (4.4.3(c)): Collaboration Diagram of Pay Fee Exceptional Case-2

24 Fig (4.4.3(d)): Collaboration Diagram of Pay Fee Exceptional Case-3

25 Fig (4.4.3(e)): Collaboration Diagram of Enquiry Main Flow

26 Fig (4.4.3(f)): Collaboration Diagram of Enquiry Exceptional Case-1

27 Fig (4.4.3(g)): Collaboration Diagram of Enquiry Exceptional Case-2

28 Fig (4.4.3(h)): Collaboration Diagram of Enquiry Exceptional Case-3

29 Fig (4.4.3(i)): Collaboration Diagram of Scholarship Fee Main Flow30 Fig (4.4.3(j)): Collaboration Diagram of Scholarship Fee

Exceptional Case-1

31 Fig (4.4.3(k)): Collaboration Diagram of Scholarship Fee

Exceptional Case-2

32 Fig (4.4.3(l)): Collaboration Diagram of Scholarship Fee

Exceptional Case-3

33 Fig (4.4.3(m)): Collaboration Diagram of Scholarship Fee

Exceptional Case-4

34 Fig (4.4.4(a)): State Chart Diagram

35 Fig (4.4.4(b)): State Chart Diagram


78/81

APPENDIX B

LIST OF TABLES


79/81

S. No Table No Table Description Page No

1 Table 1 Student Registration

2 Table 2 Login

3 Table 3 User Registration

4 Table 4 Fee Type

5 Table 5 Fee Master

6 Table 6 Fee Collection

7 Table 7 Voucher

CONCLUSION

CASH MANAGEMENT SYSTEM ensures basic functionality of the student as

well as the administrator.

We conclude that the functionalities developed are successfully implemented.


80/81

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.


81/81

[2] Greedy Booch, James Rambough, Unified Modeling Language , Pearson

Publications

[3] Software Engineering, A Practitioners Approach-Roger Pressman, 6th edition. Mc

GrawHill International Edition.

Documents

sampl Project Format