Expense Tracking System Project

Submitted to:

Dr. Ali Arsanjani, Ph.D.

Adjunct Associate Professor of Computer Science, MUM

Submitted by:

GROUP-I

Ardhita maharindra
Muskan Regmi
Nir Gurung
Sudeep Karkee
Tika Gurung

Date: December 4th, 2008

 Table of contents

1. Introduction......................................................................................................................3
2. Architectural Decisions....................................................................................................4
2.1 Assumptions...............................................................................................................4
2.2. Goal Service Model Analysis...................................................................................5
2.3. Functional Requirements..........................................................................................6
2.4. Non Functional requirements...................................................................................7
3. Design Decisions.............................................................................................................8
3.1. Database Design.......................................................................................................8
3.2. User Interface Design..............................................................................................9
3.3. Overall Application Design....................................................................................12
3.4. Patterns...................................................................................................................13
3.4.1. Façade..............................................................................................................13
3.4.2. Observer...........................................................................................................14
3.5. Use case Diagram...................................................................................................14
3.7. Sequence Diagram..................................................................................................16
3.7.1. Register New User...................................................................................................16
3.7.3. Add Balance.............................................................................................................18
3.7.5. Create Transaction...........................................................................................20
3.7.7. View Report by Category........................................................................................22
5. Architectural Styles used in our project.........................................................................23
5.1. Classical styles........................................................................................................23
5.1.1. Event-based, Implicit Invocation.....................................................................23
5.1.2. Layered............................................................................................................24
5.1.3. Façade..............................................................................................................24
5.2. Modern styles..........................................................................................................25
5.2.1. Ajax..................................................................................................................25
5.2.2. Web based- 3 tier.............................................................................................25
5.2.3. Configurable....................................................................................................25
6. Deployment Guide.........................................................................................................26
6.1. System requirements...............................................................................................26
6.2. Provided materials..................................................................................................26
6.3. Steps to setup..........................................................................................................26
7. Team Management and Uncompleted Objectives.........................................................27
7.1. Team Management..................................................................................................27
7.2. Uncompleted Objectives.........................................................................................28
1. Introduction
Expense Tracking System is a 3-tier web based application developed by Ardhita,
Sudeep, Tika, Nir and Muskan. This application has been developed to fulfill the
requirement of the Dynamic Software Architecture course. This application has many
limitations which can be overcome in future.

The main purpose of this application is to track all the expenses made by a user. The user
can generate report of his expenses based on the transaction date of the expenses or
category of items.

This application will be deployed on separate web server and application server. And for
load balancing, it will be deployed on two web servers and application servers.
2. Architectural Decisions

Figure 2: Architectural design

2.1 Assumptions

Before developing the application, we have made following assumptions,

1. One user can have only one account.

2. One category can have many items.

3. Each user can define his own category list.

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

5. 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.
6. User can generate the expense report based on the transaction date or category
type.
2.2. Goal Service Model Analysis

Our group try to implements one of the SOMA technique which is the Goal Service
Model Analysis to define the services of the application.

Goal and Sub goals KPIs Services

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

1.1. User must have an account User has account. User can
that is maintained by system. Any manage his categories. User can
activities in the account must be enter purchases. User can view
kept and recorded. The purchases reports based on their needs.
made based on categories and
must be reported to users.
- Register user
1.1.1. User can have an account System must provide account
management o Create user

o Create account
- Manage Categories
1.1.2. User can have his own User can manage his own
categories categories that is unique for o Add category
himself
- Insert purchase
1.1.3. User can track his own User can insert transaction of
transactions
purchases. purchases.
o Insert transaction

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

o Report by category

2.3. Functional Requirements

Functional requirements describe the behaviors (functions or services) of the system that
support the user’s goals, tasks or activities. We defined the functional requirements from
the services that is provided by Goal Services Model Analysis. The functional
requirements of our application are,

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

3. Add balance to the account

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

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.

5. Create Transactions

User can Add item name, price, description and the purchase date in the
transaction.

6. View Reports
 a. View all transaction by transaction date

b. View Transaction by category

2.4. Non Functional requirements

Non-functional requirements include the constraints and qualities of the application.

1. User Location varies

a. 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. Security

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

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

c. HTTPS

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.

3. Performance

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

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

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: Database schema

3.2. User Interface Design.

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

Figure 3.2.1: User Registration form

Figure 3.2.2: User login form

 Figure 3.2.3: Balance entry form

Figure 3.2.4: Manage category form

 Figure 3.2.5: Create transaction form

Figure 3.2.6: View report by transaction date

 Figure 3.2.7: View report by category type

3.3. Overall Application Design

Figure 3.3: Application design

Our systems are divided into many layers inside the applications. The layers that are
defined in the system are :

1. Views

The views in the systems are the JSPs 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.

2. Controller

We try to design this system as the ASP.net Framework where each view has its
own controller. 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. 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.

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.

5. DBWrapper

DBWrapper is the database connection class that handle the connection to MS

SQL Server using JDBC 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.

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
BalanceCheck class.

3.5. Use case Diagram

Figure 3.4: Usecase diagram

3.6. Class Diagram

The class diagram for this system is too big to be put in the document so thefollowing
link is provided to this class diagram.
http://softwarearch.pbwiki.com/f/Group1-+Class+Diagram.rar

Figure 3.5: Class diagram

3.7. Sequence Diagram
3.7.1. Register New User

Figure 3.6.1: Use case diagram for register user

3.7.2. Login user

Figure 3.6.2: Use case diagram for user login

3.7.3. Add Balance

Figure 3.6.3: Use case diagram for add balance

3.7.4. Manage Category

Figure 3.6.4: Use case diagram to manage category

3.7.5. Create Transaction

Figure 3.6.5: Use case diagram to create transaction

3.7.6. View Report By Transaction Date

Figure 3.6.6: Use case diagram to view report by transaction date

3.7.7. View Report by Category

Figure 3.6.7: Use case diagram to view report by category

4. Realization decision

1. Application Platform

This project will use java technology, JSF Framework in particular because JSF
support MVC Architecture so that it can be easily extended in future. The Ajax
will also be used because it enhances the performance of the application by
sending the specific portion of the data in the page to the server and keeping the
other data in the page untouched.

2. Database

This project will use SLQ Server 2005 Express Edition as this RDBMS is free on
license. SQL Server is chosen because it supports multiple connections for user
and it has better transaction support than MS Access. The other reason is many of
the group members know this Database technology very well.

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

5. Prototype Library

Prototype is one of javascript library for doing ajax and javascript programming.
We can implements ajax easier with this library.

5. Architectural Styles used in our project

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. Balance checker will observe the transaction
manage if the balance reached below zero.

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.

In our project, we have used the following layers,

a. Web Server (Apache)

- For serving the client request.

b. Application Server ( Tomcat)

- JSP/ JSF, Servlet, POJO. 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. In the business logic itself we define
multiple layer that is encapsulated in one façade. The Façade styles that we used will be
explained in the next description.

c. Database Layer
- SQL Server Express

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

In our project, we have created a BusinessManager.java class as a Façade in a business

package which interacts with all the other classes. So the application layer just deals with
the façade, i.e. BusinessManager class.
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,

a. Web server (Apache)

The web server will only handle the client request.

b. Application server (Tomcat)

Application server will receive request from the web server and then do
the service requested.

c. Database server (SQL server Express)

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

6.1. System requirements

1. MS SQLServer Express edition should be installed

2. Java (jdk1.6.0_04) or higher should be installed
3. Apache tomcat server should be installed

6.2. Provided materials

1. Database Schema ExpenseTrackingSystem files

2. ExpenseTrackingSystem war file

6.3. Steps to setup

1. Copy paste the Database schema files to SQL server data folder
2. Copy paste the war file and extract war file
3. In the extracted folder go to WEB-INF and open the web.xml file in edit mode
a. In the context-parameter parameter change the param-value to //localhost
where param-name is databaseServer
b. In the context-parameter parameter change the param-value to already
created SQL database administrator user where param-name is
databaseUser
c. In the context-parameter parameter change the param-value to created
SQL database administrator password where param-name is
databasePassword
4. Now we have to zip the extracted folder and change its extension to war
5. Deploy the war file.
7. Team Management and Uncompleted Objectives

7.1. Team Management

Our group is very lucky to have maximum number of group member which is five
persons. This project is very interesting because not only that we can develop our
technical skills in developing the Information Systems by using SDLC 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/her own responsibilities and how by
achieving those responsibilities means we can maintain the stability of the whole team.
Here are the responsibilities and duties given for each member :

1. Integration
a. Person in charge : Ardhita Maharindra
b. Members who do the integration part
i. Ardhita Maharindra
ii. Sudeep Karkee
iii. Tika Gurung

2. Business Laayer : Sudeep Karkee

a. Person in Charge : Sudeep Karkee
b. Members who do the Business Layer part
i. Sudeep Karkee

3. User Interface :
a. Person in charge : Muskan Regmi
b. Members who do the User Interface parts :
i. Muskan Regmi
ii. Nir Gurung

4. Database Query and connectivity :

a. Person in charge : Tika Gurung
b. Members who do the Database and Connectivity
i. Tika Gurung
ii. Ardhita Maharindra

5. Documentation :
a. Person in Charge : Nir Gurung
b. Members who do the Documentation :
i. Nir Gurung
ii. Muskan Regmi
iii. Ardhita Maharindra
7.2. Uncompleted Objectives

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. Following are
the objectives that are not yet implemented in this project but can be done in the future to
enhance the performance of the system.

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

2. Our group has not implemented the SSL 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 areas and
last but not least a good communication skills to be able to be the bridge of the business
people with IT people.