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
Department
(External of CS & IT,
Examiner) Department of CS & IT,
University of Azad Jammu & Kashmir University of Azad Jammu & Kashmir
Muzaffarabad Muzaffarabad
Sir Abd

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

DECLARATION

ii
 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:……...………

iii
 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

iv
 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 ........................................................................................... 28

v
 LIST OF FIGURES

Figure 3.1.1: Case diagram ...................................................................................... 9

Figure 3.2.1: User login form................................................................................. 10

Figure 3.2.2: Dashboard interface .......................................................................... 10

Figure 3.2.3: Datewise expense report ................................................................... 11

Figure 3.2.4: Monthwise expense report ................................................................ 11

Figure 3.2.5: Yearwise Expense Report ................................................................ 12

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

Figure 3.3.1: Application design ............................................................................ 13

Figure 3.5.1: Use case diagram .............................................................................. 15

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

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

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

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

vi
 LIST OF TABLES

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

vii
 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

viii
 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

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

x
 1 INTRODUCTION

Expense itracker iis ia irefined isystem iwhich iallows iuser ito iefficiently

manage ihis/her iexpenses iwith iease. iTracking iexpenses idaily ican ireally ihelp ito ius
i

save ilot iof imoney. iOnce iwe istart ioff iby itracking iour iexpenses ieach iday, iwe iwill
i

be iable ito iget ia ibetter iidea iwhere iyou iare ispending iyour imoney, iso iyou istay iin
i

control iand iachieve iyour igoal. iIt iwill ibe iable ito igenerate iyour iexpense iand isaving
i

report ias itime iduration iyou iselected. iThere iwill ibe ia ireminder ithat iwill ihelp ito
i

save imoney ifor iyour ipre-defined iexpenses.Daily iExpense iTracker iis ia icomplete
i

business isolution iwhose imain ifocus iis ion isaving iexpenses iand itime isupervision;
i

two ikey ifactors ithat iplay imajor irole iin isuccess iof iany iproject. iIt ibasically iconsists
i

of iexpense imanagement itool iwhich ibasically iconsist iof isaving iexpenses iin
i

different icategories. i
i

Daily iExpense iTracker iis ia icomplete ibusiness isolution iwhose imain

focus iis ion isaving iexpenses iand itime isupervision; itwo ikey ifactors ithat iplay imajor
i

role iin isuccess iof iany iproject. iIt ibasically iconsists iof iexpense imanagement itool
i

which ibasically iconsist iof isaving iexpenses iin idifferent icategories. iEach
i

functionality imaintains iconsistency iin ithe isystem isuch ias iif iuser isaves idetails ifrom
i

either iof iweb ior imobile ithen ireports iconsistency iwill ibe imaintained. iIt ialso icontains
i

the irelevant iinformation iof ithe iexpense iwhich iare isaved iin ithe idatabase. i
i

1
1.1 i OBJECTIVE

Expense iTracker i(DET) iaims ito ihelp ieveryone iwho iare iplanning ito

know itheir iexpenses iand isave ifrom iit. iDET iis ian iWebsite iwhich iusers ican iupdate
i

their idaily iexpenses iso ithat ithey iare iwell iknown ito itheir iexpenses. iThis iis ithe
i

project iwhich ikeeps irecords iof idaily iexpenses iof iUAJK iNC i(University iof iAzad
i

Jammu iand iKashmir iNeelum iCampus). iTo ikeep itrack iof idaily iexpenses iand
i

budgeting iand ito isave imoney ifor ipre-defined iexpenses iwhich iwill ihelp iplanning ion
i

i your ifuture iinvestments.

This iproject iis imainly iused ifor iUniversity iof iAzad iJammu i&

Kashmir iNC ito imaintain iexpenses. iTo iProvide iStatistical iresult iof isome imainly
i

parameter iof iUAJK. iThis iDaily iExpense iTracker iSystem iis iso idesigned ias ito iease
i

the iwork iload iof iDepartment. iTo iImproved iAutomated imethod ifor iexpenses iof
i

university iand ito iImprove ithe iDaily iexpenses iof iDepartment. iThis isystem ialso
i

provide ifacilities ito imanage ithe iteacher iexpenses iof ithe iUAJK.
i

1.2 i EXISTING iSYSTEM

• There iis ino iExisting iSystem iof iDaily iExpense iTracker.

• The iRecord ikeeping isystem iof iDepartment iis itotally iManual i. i

• If iwe ikeep itrack iof idaily iexpenses imanually iit iis itime iConsuming.

• It iis iquite idifficult ito iget iaccurate istatistical iresult.

• It iis idifficult ito iget itimely iinformation.

2
1.3 i PROPOSED iSYSTEM

In ithis iSystem iwe iare igoing ito idevelop ithis iby iadding isome iextra

features. iIn iexpenses iwe ihave isome iexpense ifeature ilike iadd iexpenses i(we ican iadd
i

new iexpense ifor ia imonth), ithis isystem ifacilitates ithe iDepartment ito iSave itheir idaily
i

expenses iof idepartment iwith iout iconsuming itime iand ino ichance iof ierror. iThis
i

system iprovides ifacility iof ichecking irecord iby iadmin. iOur isystem ihave iuser
i

friendly iinterface. iUser ican ieasily icheck irecord iof idaily iexpenses. i
i

This isystem ican itake ia igood imarket ias iit iis iusable iby ianyone iwho iare

willing ito imanage itheir iexpenses iand iaiming ito isave ifor ithe ifuture iinvestments iand
i

many imore. iThere iis inot iany irange icriteria ior iany ikind iof iprofession ior igender iare
i

focused, iit iwill iused ihugely. iTools ithat iare iused ifor ithis isystem:
i

• Microsoft iWindows i8.1

• Notepad++

• MS iSQL

3
 Chapter iNo i2

2 ARCHITECTURAL DECISIONS i

2.1 i ASSUMPTIONS

Before ideveloping ithe iapplication, iwe ihave imade ifollowing

assumptions:
i

• One iuser ican ihave ionly ione iaccount.

• One icategory ican ihave imany iitems.

• Each iuser ican idefine ihis iown icategory ilist.

• Expense idate ishould ialso ibe imentioned iand ishould ialso ibe ichecked

everyday ithouruoghly.
i

• When ia iuser iopens ian iAccount ithe ifirst itime, ithe ibalance iwill ibe izero.

• In icurrent iimplementation iof ithis iproject ione itransaction icontains ionly ione

item ibut ithe istructure ithat iwe iprovide iis ienabling ius ito ido ifurther iextension
i

if iwe iwant ito iapply ione itransaction icontains imany iitems. iFor ithe isake iof
i

simplicity iand ithe itime iconstraint iwe idecided ito iimplement ithe icurrent
i

condition.
i

• User ican igenerate ithe iexpense ireport ibased ion ithe itransaction idate ior

category itype.
i

4
2.2 i GOAL iSERVICE iMODEL iANALYSIS

Goal iand iSub igoals KPIs Services

To ikeep itrack iof imoney iof ithe Keeping ithe irecords ion ihow
user iand igive ithe iviews ion iwhat
i much ithe ibalance iinsert iin ithe
i

the iuser ispend ihis/her imoney

i system iand ithe ipurchases
i

made iby ithe iuser ion ivarious

i

categories.
i

User imust ihave ian iaccount ithat User ihas iaccount. iUser ican
is imaintained iby isystem. iAny
i manage ihis icategories. iUser
i

activities iin ithe iaccount imust ibe

i can ienter ipurchases. iUser ican
i

kept
i and
i irecorded. The
i view ireports ibased ion itheir
i

purchases
i made
i based
i on
i needs.
i

categories iand imust ibe ireported

i

to iusers.
i

User ican ihave ian iaccount System imust iprovide iaccount o Create iaccount
management
i

User i can i have his

i own User ican imanage ihis iown
i - Manage
categories
i categories ithat iis iunique ifor
i iCategories
himself
i o Add icategory

User can
i track
i i his own User ican iinsert itransaction iof
i - Insert ipurchase
purchases.
i purchases.
i itransactions
o Insert itransaction
o Insert iitem

User ican ihave ireports ion ihis System iprovides iuser iwith - Generate iReports
previous ipurchases.
i two itypes iof ireports ithat iare
i o By itransaction
by iTransaction idate iand
i date
i

category.
i o Report iby
category
i

Table i2.1: i iSOMA itechnique

5
2.3 i FUNCTIONAL iREQUIREMENTS

Functional irequirements idescribe ithe ibehaviors i(functions ior

services) iof ithe isystem ithat isupport ithe iuser’s igoals, itasks ior iactivities. iBy iGoal
i

Services iModel iAnalysis. iThe ifunctional irequirements iof iour iapplication iare:
i

2.3.1 Register ia iNew iUser ifor ia iNew iAccount

Users ineed ito icreate ia inew iaccount ibefore ithey ican iadd ibalance iand

keep irecord iof itheir ipurchase itransactions.

i

2.3.2 Login iUser

System ihas ito imake isure ithat ithe iuser iis ithe iuser ithat ihave

authorization ito iaccess ithe isystem iso ithe iuser imust ibe iauthenticated iby ilogin
i

process. i
i

2.3.3 Add iBalance ito ithe iAccount

Users ineed ito iadd ibalance ibefore ithey ican iput iinput ipurchases ithat

they ialready imade. i

i

2.3.4 Create iItem iCategory

Users ican ihave itheir iown iitem icategories ifor iitems ithat ithey ientered.

The icategory iis ipersonalized ifor iusers ifor itheir iown iusing.
i

2.3.5 Create iTransactions

User ican iadd iitem iname, iprice, idescription iand ithe ipurchase idate iin

the itransaction. i
i

2.3.6 View iReports

• View iall itransaction iby itransaction idate

6
2.4 i NON iFUNCTIONAL iREQUIREMENTS

Non-functional irequirements iinclude ithe iconstraints iand iqualities iof

the iapplication.
i

2.4.1 User iLocation iVaries

2.4.1.1 i Web ibased isystem i i

The iuser iof ithe isystem iexpect ito ibe iable ito ikeep itrack iof ihis/her

money iin ithe ipocket ianywhere ihe iis ias ilong ias ithere iis ian iinternet iconnection ifor
i

accessing ithe isystem. iFor iaccomplishing ithese iobjectives, ithe isystem iis icreated ion
i

web ibased iarchitecture isystems.

i

2.4.2 Security

2.4.2.1 i User iauthentication

To iensure ithe isecurity iof ithe iuser, ithe isystem ineeds ito iauthenticate

on ievery iuser ibefore ithe iuser ican iaccess ithe isystem. iThe iway ito ido ithis iis ito imake
i

sure ithat ithe iuser ineeds ito ilogin ifirst. iThe iuser iinformation iwill ibe isaved iin isession.
i

2.4.2.2 i Encrypting ipassword iin ithe idatabase

For icompletely iprotecting ithe iuser’s iinformation ifrom ioutside ior

from ithe isystem’s iadministrator iitself, ithe isystem iencrypt ithe ipassword iwhen
i

storing iinto ithe idatabase. iSo ieven iif ithe iadministrator iof ithe isystem iopen iand
i

retrieve ithe idata ion ithe idatabase, ipassword iinformation iof ithe iuser iis iin iencrypted
i

format iand icannot ibe istolen.

i

7
2.4.2.3 i HTTPS i(Hypertext iTransfer iProtocol iSecure)

For isecuring ithe isystems iwe ineed ito iimplements ithe iHTTPS iprotocol

to imake isure ithat ithe iinformation igiven iby ithe iuser iis isecure iand ican inot ibe iused iby
i

other iperson iwho iis inot iauthorized ito iaccess ithose iinformation. i
i

2.4.3 Performance

2.4.3.1 i Separating ithe idatabase ilayer iwith ithe ibusiness ilayer iand iapplication

i layer

The iarchitecture iof ithe isystem ineeds ito ibe idesign iwith iclear

separation ibetween iApplication iLayer, iBusiness iLayer iand iDatabase iLayer. iTo
i

implement ithis iarchitecture iwe iput ithe idatabase iin ione imachine iseparated iin ione
i

machine iand ithe iapplication iand ibusiness ilayer iwill ibe iput iin i2 iapplication iservers.
i

We iwill ipropose iseparation ibetween iweb iserver iand iapplication iservers iso ithe iweb
i

server ican ido ithe iload ibalancing.

i

2.4.3.2 i Load ibalancing iusing itwo iweb iservers iand iapplication iservers

The isystem iwill ihave ithe iload ibalancing ifeatures ithat iwill idivide ithe

load iof ieach iapplication iservers iin ihandling ithe irequest. iClient irequest iwill ibe
i

handled iby iWeb iserver iand ithen ithe iweb iserver iwill igive ithe iload ito ieither ione iof
i

the iapplication iserver iwith iless iload. i i

i

8
 Chapter iNo i3

3 DESIGN DECISIONS i

3.1 DATABASE iDESIGN

After idiscussing iwith iother igroups, iwe icame iup iwith ifollowing

database ischema. iWe iagreed iwith ithe ischema iof iseparating iitems iwith itransaction
i

because iwe iwant ito ikeep itrack iof ithe iitems. i iOur iteam itried ito imake ispecific
i

categorization ifor ispecific iuser iso iuser ican iname ihis iown icategories, ias ihe ilikes.
i

Figure i3.1.1: i iCase idiagram

9
3.2 USER iINTERFACE iDESIGN

We ihave icome iup iwith ithe iuser iinterface idesign ithat iwill ibe iused iin

this iproject.
i

Figure i3.2.1: i iUser ilogin iform

Figure i3.2.2: i iDashboard iinterface

10
iiiiiiiii

Figure i3.2.3: i iDatewise iexpense ireport

Figure i3.2.4: i iMonthwise iexpense ireport

11
Figure i3.2.5: i iYearwise iExpense iReport

Figure i3.2.6: i iView ireport iby idate

12
3.3 OVERALL iAPPLICATION iDESIGN

Figure i3.3.1: i iApplication idesign

Our isystems iare idivided iinto imany ilayers iinside ithe iapplications.

The ilayers ithat iare idefined iin ithe isystem iare i:

i

3.3.1 Views

The iviews iin ithe isystems iare ithe iJSPs i(Java iServer iPage) ifile ithat iact

as ithe iview ionly. iThe iJSP iis ithe iuser iinterface ifor ithis isystem ithat iwill ihave ione
i

controller ifor ieach iJSP ifile.

i

3.3.2 Controller

We itry ito idesign ithis isystem ias ithe iASP.net i(Active iServer iPages)

Framework iwhere ieach iview ihas iits iown icontroller. i

i

13
 This icontroller iis ithe ione iwho iwill ireceive iinputs ifrom ithe iviews iand

i give ithe ioutput ito ibe idisplayed iin iJSP. iThe icontroller ialso iresponsible ifor icalling

i the iBusiness iManager ifor iprocess ithe iservice ineeded.

3.3.3 Business iManager

Business iManager iis ithe imost iimportant ilayer iin ithe isystems ibecause

i it icontains iall ithe imain ilogic iand ibusiness iclasses ithat imakes ithe isystems iworking

i together. iTo iencapsulate ithe isystem iwe itry ito iimplement ifaçade iclass iwith ithe iname

i BusinessManager. iThis iclass iis ithe ionly ione ithat icontroller imust know ifor
i i

i executing ithe isystem.

3.3.4 Data iAccess iLayer

Data iAccess iLayer iis ithe icomponents iof ithe isystem ithat icontains iall

i the iquery iin ithe isystem. iThis ilayer iwill ido ithe iquery iusing ithe iDBWrapper iand ithen

i return ithe iresult ito ithe ibusiness ilayer.

3.3.5 DBWrapper

DBWrapper i(Database iWrapper) iis ithe idatabase iconnection iclass

i that ihandle ithe iconnection ito iMS iSQL i(Microsoft iStructured iQuery iLanguage)

i Server iusing iJDBC i(Java iDatabase iConnectivity) iDriver i1.4 iprovided iwith

i Microsoft. iThe isystems idatabase ican ibe iconfigured iin ithe iweb.xml iconfiguration

i file iso ithe iadmin idoes inot ihave ito iknow iabout ithis iDBWrapper idetail.

3.4 PATTERNS

We iapply idesign ipatterns iin ithis iapplication ito ienhance ithe ifunctionality iof ithe

i system.

14
3.4.1 Façade

Façade ipattern iis iimplemented iin ithe isystem iin ithe ibusiness ilogic

layer. iController ido inot ihave ito iaccess ito ithe idetail iof ithe ibusiness ilogic ilayer. iIt
i

just ito ineed ito icommunicate iwith ithe ifaçade. iThe ifaçade iis iimplemented iby
i

BusinessMgr.java.
i

3.4.2 Observer i

The itransaction imanager inotifies iany iregistered iobserver iwhen ithe

balance igoes ibelow izero ior iin inegative iamount iduring itransactions. iThe iobserver
i

for ithis iprocess iis iBalance iCheck iclass.

i

3.5 USE iCASE iDIAGRAM

Figure i3.5.1: i iUse icase idiagram

15
3.6 SEQUENCE iDIAGRAM

Figure i3.6.1: i iUse icase idiagram ifor iuser ilogin

16
Figure i3.6.2: i iUse icase idiagram ifor iadd ibalance

17
Figure i3.6.3: i iUse icase idiagram ito icreate itransaction

18
Figure i3.6.4 i iUse icase idiagram ito iview ireport iby itransaction idate

19
 Chapter iNo i4

4 REALIZATION DECISION i

4.1 APPLICATION iPLATFORM

This iproject iwill iuse ijava itechnology, iJSF i(Java iServer iFaces)

Framework iin iparticular ibecause iJSF isupport iMVC i(Model–view–controller)

i

Architecture iso ithat iit ican ibe ieasily iextended iin ifuture. iThe iAjax iwill ialso ibe iused i
i

4.2 DATABASE

This iproject iwill iuse iSLQ iServer i2005 iExpress iEdition ias ithis

RDBMS i(Relational iDatabase iManagement iSystem) iis ifree ion ilicense. iSQL iServer
i

is ichosen.
i

4.3 APPLICATION iSERVER

Apache iTomcat i6.1 iwill ibe iused ias ia iContainer ifor ithis iproject

because iit iis ilicense ifree iand ivery icompatible iwith ijava itechnology.
i

4.4 WEB iSERVER

The iApache iWeb iServer iwill ibe iused iin ithis iproject. iThe iselection iof

this iweb iserver iis ibased ion ithe irequirements iand ithat iit iwould ibe ivery icompatible
i

to iwork iwith iTomcat iApplication iServer.

i

4.5 PROTOTYPE iLIBRARY

Prototype iis ione iof ijavascript ilibrary ifor idoing iajax i iand ijavascript

programming. iWe ican iimplements iajax ieasier iwith ithis ilibrary.

i

20
 Chapter iNo i5

5 ARCHITECTURAL STYLES i

5.1 CLASSICAL iSTYLES

5.1.1 Event-Based, iImplicit iInvocation

The iidea ibehind ithe iimplicit iinvocation iin ithe ievent-based isystem iis

that iinstead iof iinvoking ia iprocedure idirectly, ia icomponent ican iannounce ior
i

broadcast ione ior imore ievents. iWhen ithe ievent iis iannounced ithe isystem iitself
i

invokes iall iof ithe iprocedures ithat ihave ibeen iregistered ifor ithe ievent. iThus ian ievent
i

announcement i“implicitly” icauses ithe iinvocation iof iprocedures iin iother imodules.
i

In iour iproject, ithe iJSF iframework ihandles iall ithe ievents. iWhen ian

event iarises, ithe iobserver iof ithat ievent iwhich iis ithe iFaces iServlet, iwill iinvoke ithe
i

method iin ithe icontrollers ithat iwe ihave idefined. iWe ialso iimplements ithe ievent
i

based istyles iin ithe itransaction imanager iand ibalance ichecker. i

i

5.1.2 Layered

A ilayered isystem iis iorganized ihierarchically, ieach ilayer iproviding

service ito ithe ilayer iabove iit iand iserving ias ia iclient ito ithe ilayer ibelow. iLayered
i

systems ihave iseveral idesirable iproperties. iFirst, ithey isupport idesign ibased ion
i

increasing ilevels iof iabstraction. iSecond, ithey isupport ienhancement. iLike ipipelines,
i

because ieach ilayer iinteracts iwith iat imost iof ithe ilayers ibelow iand iabove, ichanges ito
i

the ifunction iof ione ilayer iaffects iat imost itwo iother ilayers. iThird, ithey isupport ireuse.
i

21
In iour iproject, iwe ihave iused ithe ifollowing ilayers,

5.1.2.1 Web iServer i(Apache)

For iserving ithe iclient irequest.

5.1.2.2 Application iServer i( iTomcat)

JSP/ iJSF, iServlet, iPOJO i(Plain iOld iJava iObject). iIn ithis iproject, iwe

apply ithe ifractal ivalue iof isoftware iarchitecture iespecially iusing ithis ilayer istyle. iWe
i

apply ilayered iprinciple iin ithe idesign iof iour iapplications. iThe iapplication icould ibe
i

decomposed ias iView, icontroller ifor ieach iview, iBusiness iLogic iand iData iAccess
i

components. i
i

5.1.2.3 Database iLayer

SQL iServer iExpress.

5.1.2.4 Façade

From ithe iarchitectural ipoint iof iview, ithe ifaçade iof ia isystem iis ioften

the imost iimportant ifrom ia idesign istandpoint, ias iit isets ithe itone ifor ithe irest iof ithe
i

system. iFaçade iis ian iobject ithat iprovides ia isimplified iinterface ito ia ilarger ibody iof
i

code, isuch ias ia iclass ilibrary. i

i

A ifaçade ican imake ia isoftware ilibrary ieasier ito iuse iand iunderstand,

since ithe ifaçade ihas iconvenient imethods ifor icommon itasks. iIt iwraps ia ipoorly-
i

designed icollection iof iAPIs iwith ia isingle iwell-designed iAPI i(application

programming iinterface).
i

22
5.2 MODERN iSTYLES

5.2.1 Ajax

Ajax i(Asynchronous iJavaScript iand iXML) iis ia igroup iof iinterrelated

web idevelopment itechnique iused ifor icreating iinteractive iweb iapplications ior irich
i

internet iapplications. iWith iAjax, iweb iapplication ican iretrieve idata ifrom ithe iserver
i

asynchronously iin ithe ibackground iwithout iinterfering iwith ithe idisplay iand
i

behavior iof ithe iexisting ipage. iData iis iretrieved iusing ithe iXMLHttpRequest iobject.
i

We ihave iused iAjax iin ia ivery ismall ipart iof iour iproject. iWhile iadding

balance, iwe idon’t isend iall ithe iinformation iin ithe ipage ito ithe iserver, iwe ijust isend ithe
i

balance ientered iby ithe iuser iand idisplay ithat ibalance ion ithe isame ipage. iIn ithis
i

system iwe iimplement iAJAX iby iusing iprototype.js.

i

5.2.2 Web ibased- i3 itier

The ithree itier iused ion iour iproject iare:

5.2.2.1 Web iserver i(Apache)

The iweb iserver iwill ionly ihandle ithe iclient irequest.

5.2.2.2 Application iserver i(Tomcat)

Application iserver iwill ireceive irequest ifrom ithe iweb iserver iand ithen

do ithe iservice irequested.

i

5.2.2.3 Database iserver i(SQL iserver iExpress)

23
5.2.3 CONFIGURABLE

Nowadays ithe ineeds iof ithe idynamic iapplication ibecome ian

important idemand iin iperforming isome iservices iin ithe iapplication. iThe igood
i

configuration iof ia isystem ienable ithe iuser ito imodify ithe iapplication iexternally iso
i

users ican ieasily ichange ithe ibehavior ior ithe isettings iof ithe iapplication. iIn iour iproject
i

we ihave iimplemented ithe iConfigurable iStyle ias ithe ipart iof ithe iJSF iFramework. iWe
i

defined ieach icontroller ifor ieach iview iin ixml iconfigurable ifile iand ithe iframework
i

will iautomatically icreate ithose icontrollers ifor ius iand istore iit iin isession iwhen iit iis
i

needed. iWe ialso iuse ithe ixml ifile ito iconfigure iour idatabase iconnection. iSo iin ithe
i

future iif iwe iwant ito ichange ithe idatabase iwe ican ijust ichange ithe iconfiguration ifile
i

that idetermines ithe idatabase iconnection.

i

24
 Chapter iNo i6

6 CONCLUSIONS AND RESULTS i i

Our igroup iis ivery ilucky ito ihave ithis ikind iof iproject. iThis iproject iis

very iinteresting ibecause inot ionly ithat iwe ican idevelop iour itechnical iskills iin
i

developing ithe iInformation iSystems iby iusing iSDLC i(Software iDevelopment iLife
i

Cycle) ibut iwe ialso ihave ito isee ifrom ithe iview iof ithe isoftware iarchitect. iIn ithis
i

project iwe ialso ilearn iabout iproject imanagement iskills ithat ievery imember ihas ihis
i

own iresponsibilities iand ihow iby iachieving ithose iresponsibilities imeans iwe ican
i

maintain ithe istability iof ithe iwhole iteam.

i

This iMoney iTracking iSystem iproject iwhich iis igiven iin ithe iSoftware

Architecture icourse iis ireally ian iinteresting ione. iWe ican ilearn iso imany ithings iwithin
i

just iapproximately i2 iweeks. iWe ilearn iabout iold iand inew iarchitectural istyles iand itry
i

to iapply ithese istyles iin iour iapplication. iUnfortunately ifew iobjectives ifor ithis
i

project iis istill iuncompleted idue ito idateline itime iand ithe iinexperienced iof iour iteam
i

member iin icertain iarea. i

i

• Our igroup ihas inot ibeen iable ito iseparate ithe iTomcat iwith ithe iApache iweb

server ifor idoing iload ibalancing. iBecause iall iof ius iare ideveloper iin iour
i

previous ijobs iso ineither ione iof ius iknows iabout ithe iway ito iimplement ithis
i

things. iWe iwere ialso ivery iconcentrating iin ideveloping ithe iapplication.
i

25
 • Our igroup ihas inot iimplemented ithe iSSL i(Secure iSockets iLayer) ifor ithe

iclient irequest. iThe ireason iis ithe isame ifor ithe iprevious ireasons. i

We irealize ithat iboth iof ithose itwo iobjectives iare ithe imain iobjectives

of ithe iproject iand ias iimportant ias ithe imain iapplication iitself. iIn iorder ito ibe ia igood
i

architect iwe ishould ihave iknowledge inot ionly ia isoftware idevelopment iskill ibut ialso
i

another iskills isuch ias ibroader iknowledge iabout iinfrastructure, inew itechnologies,
i

new iinsight iof iresearch iin iIT i(Information iTechnology) iareas iand ilast ibut inot ileast
i

a igood icommunication iskills ito ibe iable ito ibe ithe ibridge iof ithe ibusiness ipeople iwith
i

i IT ipeople.

26
27
 REFERENCES

[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

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

[3] FKJ Software. (2005). Graphics Account 1.3. Retrieved November 9, 2006.

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/

28