DAILY EXPENSE TRACKER SYSTEM UAJ&K NC

By
Muhammad Ali Mughal

2015-NVC-006018

Amir Mushtaq

2015-NVC-006001

Session: 2015-2019

Supervisor
Dr Lal Hussain
Lecturer

DEPARTMENT OF COMPUTER SCIENCES & INFORMATION

TECHNOLOGY
FACULTY OF SCIENCES
NEELUM CAMPUS AUTHMUQAM
UNIVERSITYOF AZAD JAMMU & KASHMIR
MUZAFFARABAD
 APPROVAL CERTIFICATE

It is certified that the project work presented in this report entitled

“Daily Expense Tracker System” submitted by Muhammad Ali Mughal (Roll No.

01) and Amir Mushtaq (Roll No. 18) of Session (2015-19) supervised by Dr Lal

Hussain. No part of this report has been submitted anywhere else for any other degree.

This report is submitted to the BSCS in partially fulfillment of the requirement for the

degree of Bachelor in field of Computer Sciences of university of Azad Jammu &

Kashmir.

________________________ ________________________
Supervisor
________________________ External Examiner
Dr Lal Hussain Dr. Abdul-Majid
Lecturer Assistant Professor
DepartmentExaminer)
(External of CS & IT, Department of CS & IT,
University of Azad Jammu & Kashmir University of Azad Jammu &
Muzaffarabad Kashmir
Muzaffarabad
Sir Abd

________________________
Director Neelum Campus
Dr Ijaz-ul-Islam Dar
Authmuqam Dist. Neelum
University of Azad Jammu & Kashmir
Muzaffarabad
DECLARATION
 DECLARATION

We hereby declare that this project, neither as a whole nor as a part there of has

been copied out from any source. It is further declared that we have developed this

project and the accompanied report entirely based on our personal efforts made under

the sincere guidance of our supervisor Dr Lal Hussain. If any part of this report is

proved to be copied out or found to be reported, we shall standby the consequences.

No portion of the work presented in this report has been submitted in support of any

application for any other degree or qualification of this or any other university or

institute of learning.

We further declare that this project and all associated documents, reports and

records are submitted as partial requirements for the degree of Bachelor of Computer

Science and Information technology. We understand and transfer copyrights for these

materials to University of Azad Jammu and Kashmir. We shall not sale this project and

documents and shall not get any financial gains from these.

Muhammad Ali Mughal

Signature:……...………

Amir Mushtaq

Signature:……...………
 TABLE OF CONTENTS
APPROVAL CERTIFICATE.......................................................................ii
DECLARATION.........................................................................................iii
LIST OF FIGURES......................................................................................vi
LIST OF TABLES......................................................................................vii
LIST OF ACRONYMS AND ABBREVIATIONs...................................viii
ACKNOWLEDGEMENT............................................................................ix
ABSTRACT..................................................................................................x
1 INTRODUCTION.................................................................................1
1.1 OBJECTIVE..................................................................................2
1.2 EXISTING SYSTEM....................................................................2
1.3 PROPOSED SYSTEM..................................................................3
2 ARCHITECTURAL DECISIONS........................................................4
2.1 ASSUMPTIONS............................................................................4
2.2 GOAL SERVICE MODEL ANALYSIS.......................................5
2.3 FUNCTIONAL REQUIREMENTS..............................................6
2.3.1 Register a New User for a New Account...................................6
2.3.2 Login User.................................................................................6
2.3.3 Add Balance to the Account......................................................6
2.3.4 Create Item Category.................................................................6
2.3.5 Create Transactions....................................................................6
2.3.6 View Reports.............................................................................6
2.4 NON FUNCTIONAL REQUIREMENTS....................................7
2.4.1 User Location Varies.................................................................7
2.4.2 Security......................................................................................7
2.4.3 Performance...............................................................................8
3 DESIGN DECISIONS...........................................................................9
3.1 DATABASE DESIGN...................................................................9
3.2 USER INTERFACE DESIGN.....................................................10
3.3 OVERALL APPLICATION DESIGN........................................13
3.3.1 Views.......................................................................................13
 3.3.2 Controller.................................................................................13
3.3.3 Business Manager....................................................................14
3.3.4 Data Access Layer...................................................................14
3.3.5 DBWrapper..............................................................................14
3.4 PATTERNS.................................................................................14
3.4.1 Façade......................................................................................15
3.4.2 Observer...................................................................................15
3.5 USE CASE DIAGRAM...............................................................15
3.6 SEQUENCE DIAGRAM.............................................................16
4 REALIZATION DECISION...............................................................20
4.1 APPLICATION PLATFORM.....................................................20
4.2 DATABASE................................................................................20
4.3 APPLICATION SERVER...........................................................20
4.4 WEB SERVER............................................................................20
4.5 PROTOTYPE LIBRARY............................................................20
5 ARCHITECTURAL STYLES............................................................21
5.1 CLASSICAL STYLES................................................................21
5.1.1 Event-Based, Implicit Invocation............................................21
5.1.2 Layered....................................................................................21
5.2 MODERN STYLES.....................................................................23
5.2.1 Ajax..........................................................................................23
5.2.2 Web based- 3 tier.....................................................................23
5.2.3 CONFIGURABLE...................................................................24
6 CONCLUSIONS AND RESULTS.....................................................25
REFERENCES............................................................................................27
 LIST OF FIGURES

Figure 3.1.1: Case diagram.....................................................................................17

Figure 3.2.1: User login form.................................................................................18

Figure 3.2.2: Dashboard interface...........................................................................18

Figure 3.2.3: Datewise expense report....................................................................19

Figure 3.2.4: Monthwise expense report.................................................................19

Figure 3.2.5: Yearwise Expense Report.................................................................20

Figure 3.2.6: View report by date...........................................................................20

Figure 3.3.1: Application design.............................................................................21

Figure 3.5.1: Use case diagram...............................................................................23

Figure 3.6.1: Use case diagram for user login........................................................24

Figure 3.6.2: Use case diagram for add balance.....................................................25

Figure 3.6.3: Use case diagram to create transaction..............................................26

Figure 3.6.4 Use case diagram to view report by transaction date.........................27

vii
 LIST OF TABLES

Table 2.2: SOMA technique.....................................................................................5

viii
 LIST OF ACRONYMS AND

ABBREVIATIONs

SOMA: Self-organized Magnetic Array Media

HTTPS: Hypertext Transfer Protocol Secure

JSP: Java Server Page

ASP: Active Server Pages

MS SQL: Microsoft Structured Query Language

JDBC: Java Database Connectivity

JSF: JavaServer Faces

MVC: Model–view–controller

RDBMS: Relational Database Management System

MS: Microsoft

POJO: Plain Old Java Object

API: Application Programming Interface

AJAX: Asynchronous JavaScript and XML

SDLC: Software Development LifeCycle

SSL: Secure Sockets Layer

IT: Information Technology

UAJK: University of Azad Jammu and Kashmir

ix
 ACKNOWLEDGEMENT

All praises to gracious and the greatest almighty Allah who gave us

courage and sense to study the Computer sciences & Information Technology. A

lot of Darood–O–Salam to the Holy Prophet Hazrat Muhammad (SAW) who is

source of wisdom, guidance and knowledge for whole humanity.

A special thanks to our supervisor Dr Lal Hussain for his untiring support

and help. He has seriously followed the project to see fruitful results. He had a big

contribution for the effort’s successes of the project. The project owes much of its

progress to his, guidance and experience. The skills we have been able to learn

from him have already benefited us immensely and will continue to be a great

benefit to us throughout our future endeavors, both academically and

professionally.

We would like to express our sincere and cordial gratitude to the people

those who have supported us directly, purveyed mental encouragement, evaluated

and criticized our work in several phases during the development of this project

and for preparing this dissertation indirectly.

Thank you.

Muhammad Ali Mughal

Amir Mushtaq

x
 ABSTRACT

This project is an attempt to manage our daily expenses in a more

efficient and manageable way. Sometime we can’t remember where our money

goes. And we can’t handle our cash flow.

For this problem, we need a solution that everyone can manage their

expenses. So we decided to find an easier way to get rid of this problem. So, our

application attempts to free the user with as much as possible the burden of manual

calculation and to keep the track of the expenditure.

Instead of keeping a diary or a log of the expenses, this application

enables the user to not just keep the control on the expenses but also to generate

and save reports. With the help of this application, the user can manage their

expenses on a daily, weekly and monthly basis. Users can insert and delete

transactions as well as can generate and save their reports.

xi
 Chapter No 1

1 INTRODUCTION

Expense tracker is a refined system which allows user to efficiently

manage his/her expenses with ease. Tracking expenses daily can really help to us

save lot of money. Once we start off by tracking our expenses each day, we will be

able to get a better idea where you are spending your money, so you stay in control

and achieve your goal. It will be able to generate your expense and saving report as

time duration you selected. There will be a reminder that will help to save money

for your pre-defined expenses.Daily Expense Tracker is a complete business

solution whose main focus is on saving expenses and time supervision; two key

factors that play major role in success of any project. It basically consists of

expense management tool which basically consist of saving expenses in different

categories.

Daily Expense Tracker is a complete business solution whose main

focus is on saving expenses and time supervision; two key factors that play major

role in success of any project. It basically consists of expense management tool

which basically consist of saving expenses in different categories. Each

functionality maintains consistency in the system such as if user saves details from

either of web or mobile then reports consistency will be maintained. It also

contains the relevant information of the expense which are saved in the database.

1
1.1 OBJECTIVE

Expense Tracker (DET) aims to help everyone who are planning to

know their expenses and save from it. DET is an Website which users can update

their daily expenses so that they are well known to their expenses. This is the

project which keeps records of daily expenses of UAJK NC (University of Azad

Jammu and Kashmir Neelum Campus). To keep track of daily expenses and

budgeting and to save money for pre-defined expenses which will help planning on

your future investments.

This project is mainly used for University of Azad Jammu &

Kashmir NC to maintain expenses. To Provide Statistical result of some mainly

parameter of UAJK. This Daily Expense Tracker System is so designed as to ease

the work load of Department. To Improved Automated method for expenses of

university and to Improve the Daily expenses of Department. This system also

provide facilities to manage the teacher expenses of the UAJK.

1.2 EXISTING SYSTEM

 There is no Existing System of Daily Expense Tracker.

 The Record keeping system of Department is totally Manual .

 If we keep track of daily expenses manually it is time Consuming.

 It is quite difficult to get accurate statistical result.

 It is difficult to get timely information.

2
1.3 PROPOSED SYSTEM

In this System we are going to develop this by adding some extra

features. In expenses we have some expense feature like add expenses (we can add

new expense for a month), this system facilitates the Department to Save their daily

expenses of department with out consuming time and no chance of error. This

system provides facility of checking record by admin. Our system have user

friendly interface. User can easily check record of daily expenses.

This system can take a good market as it is usable by anyone who

are willing to manage their expenses and aiming to save for the future investments

and many more. There is not any range criteria or any kind of profession or gender

are focused, it will used hugely. Tools that are used for this system:

 Microsoft Windows 8.1

 Notepad++

 MS SQL

3
 Chapter No 2

2 ARCHITECTURAL DECISIONS

2.1 ASSUMPTIONS

Before developing the application, we have made following

assumptions:

 One user can have only one account.

 One category can have many items.

 Each user can define his own category list.

 Expense date should also be mentioned and should also be checked

everyday thouruoghly.

 When a user opens an Account the first time, the balance will be zero.

 In current implementation of this project one transaction contains only one

item but the structure that we provide is enabling us to do further extension

if we want to apply one transaction contains many items. For the sake of

simplicity and the time constraint we decided to implement the current

condition.

 User can generate the expense report based on the transaction date or

category type.

4
5
2.2 GOAL SERVICE MODEL ANALYSIS

Goal and Sub goals KPIs Services

To keep track of money of the Keeping the records on how
user and give the views on what much the balance insert in the
the user spend his/her money system and the purchases
made by the user on various
categories.
User must have an account that User has account. User can
is maintained by system. Any manage his categories. User
activities in the account must be can enter purchases. User can
kept and recorded. The view reports based on their
purchases made based on needs.
categories and must be reported
to users.
User can have an account System must provide account o Create account
management
User can have his own User can manage his own - Manage
categories categories that is unique for Categories
himself
o Add category

User can track his own User can insert transaction of - Insert purchase
purchases. purchases. transactions

o Insert transaction

o Insert item

User can have reports on his System provides user with two - Generate Reports
previous purchases. types of reports that are by
o By transaction
Transaction date and category.
date

o Report by

6
 category

Table 2.1: SOMA technique

7
2.3 FUNCTIONAL REQUIREMENTS

Functional requirements describe the behaviors (functions or

services) of the system that support the user’s goals, tasks or activities. By Goal

Services Model Analysis. The functional requirements of our application are:

2.3.1 Register a New User for a New Account

Users need to create a new account before they can add balance and

keep record of their purchase transactions.

2.3.2 Login User

System has to make sure that the user is the user that have

authorization to access the system so the user must be authenticated by login

process.

2.3.3 Add Balance to the Account

Users need to add balance before they can put input purchases that

they already made.

2.3.4 Create Item Category

Users can have their own item categories for items that they entered.

The category is personalized for users for their own using.

2.3.5 Create Transactions

User can add item name, price, description and the purchase date in

the transaction.

8
2.3.6 View Reports

 View all transaction by transaction date

9
2.4 NON FUNCTIONAL REQUIREMENTS

Non-functional requirements include the constraints and qualities of

the application.

2.4.1 User Location Varies

2.4.1.1 Web based system 

The user of the system expect to be able to keep track of his/her

money in the pocket anywhere he is as long as there is an internet connection for

accessing the system. For accomplishing these objectives, the system is created on

web based architecture systems.

2.4.2 Security

2.4.2.1 User authentication

To ensure the security of the user, the system needs to authenticate

on every user before the user can access the system. The way to do this is to make

sure that the user needs to login first. The user information will be saved in session.

2.4.2.2 Encrypting password in the database

For completely protecting the user’s information from outside or

from the system’s administrator itself, the system encrypt the password when

storing into the database. So even if the administrator of the system open and

retrieve the data on the database, password information of the user is in encrypted

format and cannot be stolen.

10
2.4.2.3 HTTPS (Hypertext Transfer Protocol Secure)

For securing the systems we need to implements the HTTPS

protocol to make sure that the information given by the user is secure and can not

be used by other person who is not authorized to access those information.

2.4.3 Performance

2.4.3.1 Separating the database layer with the business layer and application

layer

The architecture of the system needs to be design with clear

separation between Application Layer, Business Layer and Database Layer. To

implement this architecture we put the database in one machine separated in one

machine and the application and business layer will be put in 2 application servers.

We will propose separation between web server and application servers so the web

server can do the load balancing.

2.4.3.2 Load balancing using two web servers and application servers

The system will have the load balancing features that will divide the

load of each application servers in handling the request. Client request will be

handled by Web server and then the web server will give the load to either one of

the application server with less load.

11
 Chapter No 3

3 DESIGN DECISIONS

3.1 DATABASE DESIGN

After discussing with other groups, we came up with following

database schema. We agreed with the schema of separating items with transaction

because we want to keep track of the items. Our team tried to make specific

categorization for specific user so user can name his own categories, as he likes.

Figure 3.1.1: Case diagram

12
3.2 USER INTERFACE DESIGN

We have come up with the user interface design that will be used in

this project.

Figure 3.2.2: User login form

Figure 3.2.3: Dashboard interface

13
14
Figure 3.2.4: Datewise expense report

Figure 3.2.5: Monthwise expense report

15
Figure 3.2.6: Yearwise Expense Report

Figure 3.2.7: View report by date

16
3.3 OVERALL APPLICATION DESIGN

Figure 3.3.8: Application design

Our systems are divided into many layers inside the applications.

The layers that are defined in the system are :

3.3.1 Views

The views in the systems are the JSPs (Java Server Page) file that act

as the view only. The JSP is the user interface for this system that will have one

controller for each JSP file.

3.3.2 Controller

We try to design this system as the ASP.net (Active Server Pages)

Framework where each view has its own controller.

17
 This controller is the one who will receive inputs from the views and

give the output to be displayed in JSP. The controller also responsible for calling

the Business Manager for process the service needed.

3.3.3 Business Manager

Business Manager is the most important layer in the systems

because it contains all the main logic and business classes that makes the systems

working together. To encapsulate the system we try to implement façade class with

the name BusinessManager. This class is the only one that controller must know

for executing the system.

3.3.4 Data Access Layer

Data Access Layer is the components of the system that contains all

the query in the system. This layer will do the query using the DBWrapper and

then return the result to the business layer.

3.3.5 DBWrapper

DBWrapper (Database Wrapper) is the database connection class

that handle the connection to MS SQL (Microsoft Structured Query Language)

Server using JDBC (Java Database Connectivity) Driver 1.4 provided with

Microsoft. The systems database can be configured in the web.xml configuration

file so the admin does not have to know about this DBWrapper detail.

3.4 PATTERNS

We apply design patterns in this application to enhance the functionality of the

system.

18
3.4.1 Façade

Façade pattern is implemented in the system in the business logic

layer. Controller do not have to access to the detail of the business logic layer. It

just to need to communicate with the façade. The façade is implemented by

BusinessMgr.java.

3.4.2 Observer

The transaction manager notifies any registered observer when the

balance goes below zero or in negative amount during transactions. The observer

for this process is Balance Check class.

3.5 USE CASE DIAGRAM

Figure 3.5.9: Use case diagram

19
3.6 SEQUENCE DIAGRAM

Figure 3.6.10: Use case diagram for user login

20
Figure 3.6.11: Use case diagram for add balance

21
Figure 3.6.12: Use case diagram to create transaction

22
Figure 3.6.13 Use case diagram to view report by transaction date

23
 Chapter No 4

4 REALIZATION DECISION

4.1 APPLICATION PLATFORM

This project will use java technology, JSF (Java Server Faces)

Framework in particular because JSF support MVC (Model–view–controller)

Architecture so that it can be easily extended in future. The Ajax will also be used

4.2 DATABASE

This project will use SLQ Server 2005 Express Edition as this

RDBMS (Relational Database Management System) is free on license. SQL Server

is chosen.

4.3 APPLICATION SERVER

Apache Tomcat 6.1 will be used as a Container for this project

because it is license free and very compatible with java technology.

4.4 WEB SERVER

The Apache Web Server will be used in this project. The selection of

this web server is based on the requirements and that it would be very compatible

to work with Tomcat Application Server.

4.5 PROTOTYPE LIBRARY

Prototype is one of javascript library for doing ajax and javascript

programming. We can implements ajax easier with this library.

24
 Chapter No 5

5 ARCHITECTURAL STYLES

5.1 CLASSICAL STYLES

5.1.1 Event-Based, Implicit Invocation

The idea behind the implicit invocation in the event-based system is

that instead of invoking a procedure directly, a component can announce or

broadcast one or more events. When the event is announced the system itself

invokes all of the procedures that have been registered for the event. Thus an event

announcement “implicitly” causes the invocation of procedures in other modules.

In our project, the JSF framework handles all the events. When an

event arises, the observer of that event which is the Faces Servlet, will invoke the

method in the controllers that we have defined. We also implements the event

based styles in the transaction manager and balance checker.

5.1.2 Layered

A layered system is organized hierarchically, each layer providing

service to the layer above it and serving as a client to the layer below. Layered

systems have several desirable properties. First, they support design based on

increasing levels of abstraction. Second, they support enhancement. Like pipelines,

because each layer interacts with at most of the layers below and above, changes to

the function of one layer affects at most two other layers. Third, they support reuse.

25
In our project, we have used the following layers,

5.1.2.1 Web Server (Apache)

For serving the client request.

5.1.2.2 Application Server ( Tomcat)

JSP/ JSF, Servlet, POJO (Plain Old Java Object). In this project, we

apply the fractal value of software architecture especially using this layer style. We

apply layered principle in the design of our applications. The application could be

decomposed as View, controller for each view, Business Logic and Data Access

components.

5.1.2.3 Database Layer

SQL Server Express.

5.1.2.4 Façade

From the architectural point of view, the façade of a system is often

the most important from a design standpoint, as it sets the tone for the rest of the

system. Façade is an object that provides a simplified interface to a larger body of

code, such as a class library.

A façade can make a software library easier to use and understand,

since the façade has convenient methods for common tasks. It wraps a poorly-

designed collection of APIs with a single well-designed API (application

programming interface).

26
5.2 MODERN STYLES

5.2.1 Ajax

Ajax (Asynchronous JavaScript and XML) is a group of interrelated

web development technique used for creating interactive web applications or rich

internet applications. With Ajax, web application can retrieve data from the server

asynchronously in the background without interfering with the display and

behavior of the existing page. Data is retrieved using the XMLHttpRequest object.

We have used Ajax in a very small part of our project. While adding

balance, we don’t send all the information in the page to the server, we just send

the balance entered by the user and display that balance on the same page. In this

system we implement AJAX by using prototype.js.

5.2.2 Web based- 3 tier

The three tier used on our project are:

5.2.2.1 Web server (Apache)

The web server will only handle the client request.

5.2.2.2 Application server (Tomcat)

Application server will receive request from the web server and then

do the service requested.

5.2.2.3 Database server (SQL server Express)

27
5.2.3 CONFIGURABLE

Nowadays the needs of the dynamic application become an

important demand in performing some services in the application. The good

configuration of a system enable the user to modify the application externally so

users can easily change the behavior or the settings of the application. In our

project we have implemented the Configurable Style as the part of the JSF

Framework. We defined each controller for each view in xml configurable file and

the framework will automatically create those controllers for us and store it in

session when it is needed. We also use the xml file to configure our database

connection. So in the future if we want to change the database we can just change

the configuration file that determines the database connection.

28
 Chapter No 6

6 CONCLUSIONS AND RESULTS

Our group is very lucky to have this kind of project. This project is

very interesting because not only that we can develop our technical skills in

developing the Information Systems by using SDLC (Software Development Life

Cycle) but we also have to see from the view of the software architect. In this

project we also learn about project management skills that every member has his

own responsibilities and how by achieving those responsibilities means we can

maintain the stability of the whole team.

This Money Tracking System project which is given in the Software

Architecture course is really an interesting one. We can learn so many things

within just approximately 2 weeks. We learn about old and new architectural styles

and try to apply these styles in our application. Unfortunately few objectives for

this project is still uncompleted due to dateline time and the inexperienced of our

team member in certain area.

 Our group has not been able to separate the Tomcat with the Apache web

server for doing load balancing. Because all of us are developer in our

previous jobs so neither one of us knows about the way to implement this

things. We were also very concentrating in developing the application.

29
  Our group has not implemented the SSL (Secure Sockets Layer) for the

client request. The reason is the same for the previous reasons.

We realize that both of those two objectives are the main objectives

of the project and as important as the main application itself. In order to be a good

architect we should have knowledge not only a software development skill but also

another skills such as broader knowledge about infrastructure, new technologies,

new insight of research in IT (Information Technology) areas and last but not least

a good communication skills to be able to be the bridge of the business people with

IT people.

30
 REFERENCES

Access Consultants. (1998). The

final report on the analysis of the
household budget and
expenditure sur-
vey for St. Vincent and the
Grenadines. Atlanta GA.
Retrieved August 15, 2006, from
Access Consultants. (1998). The
final report on the analysis of the
household budget and
expenditure sur-
vey for St. Vincent and the
Grenadines. Atlanta GA.
Retrieved August 15, 2006, from
Access Consultants. (1998). The
final report on the analysis of the
household budget and
expenditure sur-
31
vey for St. Vincent and the
Grenadines. Atlanta GA.
Retrieved August 15, 2006, from
Access Consultants. (1998). The
final report on the analysis of the
household budget and
expenditure sur-
vey for St. Vincent and the
Grenadines. Atlanta GA.
Retrieved August 15, 2006, from
Access Consultants. (1998). The
final report on the analysis of the
household budget and
expenditure sur-
vey for St. Vincent and the
Grenadines. Atlanta GA.
Retrieved August 15, 2006, from
[1] Access Consultants. (1998). The final report on the analysis of the household
budget and expenditure sur-vey for St. Vincent and the Grenadines. Atlanta GA.
Retrieved August 15, 2006.

http://www.geocities.com/CollegePark/Library/3954/svghbes.pdf4

32
[2] Redpath, B. (1986). Family expenditure surveys: a second study of differential
responses comparing census characteristics of FES respondents and non-
respondents. Statistical News, 72, 151-171.

Intelligent Online Budget

[3]

Tracker
124
Conclusion
We have presented a working
prototype of an intelligent
online budget tracker. The
development
of this application has been
conducted in a stepwise
manner using the well defined
methodology,
RUP, customised according to
the requirements of the
33
system. Most of the goals set
at the begin-
ning of the development
phase have been met.
Security issues like web
security or network secu-
rity have also been treated in
the design and development
of the system, thus increasing
the reli-
ability of the system. Quality
management issues have also
been handled satisfactorily.
References
Access Consultants. (1998). The
final report on the analysis of the

34
household budget and
expenditure sur-
vey for St. Vincent and the
Grenadines. Atlanta GA.
Retrieved August 15, 2006, from
http://www.geocities.com/Colleg
ePark/Library/3954/svghbes.pdf
Central Statistics Office. (2001).
Household budget survey.
Government of Ireland.
Retrieved August 15,
2006, from
http://www.cso.ie/releasespublic
ations/documents/housing/hbs.pd
f
European Countries. (2004).
Household budget surveys in
candidate countries:
Methodological analysis
35
2003. European Countries.
Luxembourg. Retrieved
February 19, 2007, from
http://europa.eu.int/estatref/info/s
dds/en/hbs/hbs_meth2003_cand_
countries.pdf
FKJ Software. (2005). Graphics
Account 1.3. Retrieved
November 9, 2006, from
[3] FKJ Software. (2005). Graphics Account 1.3. Retrieved November 9, 2006.

Redpath, B. (1986). Family

expenditure surveys: a second
study of differential responses
comparing census
characteristics of FES
respondents and non-
respondents. Statistical News,
72, 151-171.

36
Redpath, B. (1986). Family
expenditure surveys: a second
study of differential responses
comparing census
characteristics of FES
respondents and non-
respondents. Statistical News,
72, 151-171.
Redpath, B. (1986). Family
expenditure surveys: a second
study of differential responses
comparing census
characteristics of FES
respondents and non-
respondents. Statistical News,
72, 151-171.
Redpath, B. (1986). Family
expenditure surveys: a second

37
study of differential responses
comparing census
characteristics of FES
respondents and non-
respondents. Statistical News,
72, 151-171.
Redpath, B. (1986). Family
expenditure surveys: a second
study of differential responses
comparing census
characteristics of FES
respondents and non-
respondents. Statistical News,
72, 151-171.
http://www.softplatz.com/Soft/Home-Hobby/Personal-Finance/Graphic-
Accounts.html

[4] In2M Corporation. (2007). Home budget software for household, family &
personal money management. Retrieved April 10, 2007.
http://www.mvelopes.com/

[5] http://www.dev.mysql.com/

38
 Intelligent Online Budget
][4]

Tracker
124
Conclusion
We have presented a working
prototype of an intelligent
online budget tracker. The
development
of this application has been
conducted in a stepwise
manner using the well defined
methodology,
RUP, customised according to
the requirements of the
system. Most of the goals set
at the begin-

39
ning of the development
phase have been met.
Security issues like web
security or network secu-
rity have also been treated in
the design and development
of the system, thus increasing
the reli-
ability of the system. Quality
management issues have also
been handled satisfactorily.
References
Access Consultants. (1998). The
final report on the analysis of the
household budget and
expenditure sur-

40
vey for St. Vincent and the
Grenadines. Atlanta GA.
Retrieved August 15, 2006, from
http://www.geocities.com/Colleg
ePark/Library/3954/svghbes.pdf
Central Statistics Office. (2001).
Household budget survey.
Government of Ireland.
Retrieved August 15,
2006, from
http://www.cso.ie/releasespublic
ations/documents/housing/hbs.pd
f
European Countries. (2004).
Household budget surveys in
candidate countries:
Methodological analysis

41
2003. European Countries.
Luxembourg. Retrieved
February 19, 2007, from
http://europa.eu.int/estatref/info/s
dds/en/hbs/hbs_meth2003_cand_
countries.pdf
FKJ Software. (2005). Graphics
Account 1.3. Retrieved
November 9, 2006, from
http://www.softplatz.com/Soft/H
ome-Hobby/Personal-
Finance/Graphic-Accounts.html
In2M Corporation. (2007).
Home budget software for
household, family & personal
money management.
Retrieved April 10, 2007, from

42
43