Expense Tracking System

Advisor : Dr. Ali Arsanjani

Members: Ebe

Pubudu

Viduranga

(12-05-2008)

Purpose

To track independent user’s expenditure and generate monthly, filtered and categorical report.

Non-Functional-Requirements

• The service must have high availability and less probability of failure•  The service must be deployed through secure channel.•  User name and password information should be encrypted.•  System should be able to be accessed from internet.•  Minimum level of DB locking, due to other systems• The system should be capable for load balancing and fail over.

Functional-Requirements

• Items must include name, description, price and categories.• Users must not share categories.• Users must have one account, and account must include balance.• Users should be able to see monthly, periodical and categorical reports• There should be a way of knowing balance before adding item.•  Categories should be structured in hierarchy. 

Assumptions

•  Ability to use two clustered servers may imply ability to use multiple clustered servers.

•  Ability to use one encryption method may imply ability to use multiple encryption methods 

•  Three levels of categories may imply multiple levels of categories.•  One user has one account

Use Cases

Page Navigations

Architectural Styles Forced

• Dynamically Reconfigurable Architectural Style        

• Multi-Tier Architectural Style       

•  Blackboard/Repository   

    • Pipes and Filters 

Architectural Styles Implicitly Used

•  Object oriented and data encapsulation

• Event based and implicit invocation, through their action listener and action events 

• MVC

• Layered

Architectural Styles Optional

1.  REST

·         Advantage- Simplifies communication of the tiers in heterogeneous environment and decouples tiers.

·         Disadvantage-Tomcat, which is specifically specified in non functional requirement, has very limited support for it. Also team does not have required expertise on the subject.

2.    Service Oriented Architecture (SOA)

·         Advantage-Allows communication of the tiers in heterogeneous environment and decouples tiers.

·         Disadvantage- Tomcat, which is specifically specified in non functional requirement, has support through additional package, which may be incompatible in common deployment environment.

Architectural Styles Optional (cont..)

 3.  Rich Internet Application

         Advantage- Gives smooth, natural, fast (responsive) rich interface         

          Disadvantage- Requires more client side JavaScript expertise, where needs more research and training. Also, it needs more time to implement.

4, Grammar Oriented Object Design

        Advantage-   Highly configurable and expandable.

        Disadvantage- Team doesn’t have expertise in the field and also it needs grammar translation engine to be developed. 

Block-Diagram

Single Server Scenario

Block Diagram

Multi Server Scenario

Pattern Used

• Problem: As specified reporter should collect all the items satisfying certain conditions from database and give monthly, filtered and categorical reports.

• Solution Options: Here we could have used State Pattern, Strategy Pattern and Visitor Pattern.

– State Pattern– Strategy– Visitor Pattern

• Problem: They are static utility functions, needs to be bundled such as common java.util.Math class.

• Solution: Therefore we have used Singleton pattern. 

Pattern Used (cont..)

• Problem :

In our application we have to model to decrease complexity between data access layer and business layer and decouple these two layers as possible.

• Solution :

Faced pattern

• Problem: Data in database needs to be structured into object in order to be used in objec oriented manner and needs to be accessed in object oriented ways.

• Solution Options:

Auto generated Data Access Objects

POJO + Serializes

Hibernate

Pattern Used (cont..)Problem :

In this application we have to design interactive web application.

Solution :

ICE Faces implicitly contain this MVC model and integrated Ajax application framework that enables Java EE application to easily create and deploy thin-client rich Internet applications (RIA) in pure Java. 

Problem: We needed to control application flow centrally.

Solution: Current frameworks all use Front Controller design pattern.

Problem: We needed to change format of the object . For example we get Category object from data access layer, but presentation layer is expecting SelectItem element.

Solution Options: We need to put Filters at the middle, or adapter.

Implementation Decision (DAL)

• Using plain java connection and write java commands. • Creating stored procedures at the database side and call

them through prepared statement • Through data access objects• Using EJB• EJB 3 or JPA• Hibernate

Implementation Decision (LBC)

1. mod_proxy- it is slow, and supports only one backend tomcat, which doesn't give us load balancing functionality.

2. mod_proxy-aip- it is the newest, fastest one, but haven't yet tested thoroughly. Since it is first time for most of our team, therefore probability of bug might slow us down. 

3. mod_jk- this is thoroughly tested, able to support multiple Tomcat at the back, therefore it was our choice.

Rich Client Layer

• XmlHttpRequest-which asks us huge development

• DWR- simplify server call easily, but still have to write javascript code

• Scriptaculous, Google WTK...--the provide functionality to javascript, not java.

• IceFaces- no need to write client javascript, and integrated with jsf 

Implementation Decision (DB)

1. MySQL- Development environment is not so familiar, and not as good as MS SSMS. 

2. Sybase- No one in the team has experience with. Therefore ruled out.

3. MS SQL Server- We have to use express edition, since the other editions are not free. Development environment is really developer friendly.

Class Diagram

Login

Create Users

Add Transaction

Add Category

Reports