42
Seminar on Software Architecture Design Money Tracking Project Money Tracking Project Date: Dec 05, 2008 Group 2 Adviser: Dr. Ali Arsanjani Student group: Khoa Ho Aamir Khan Jayaram Timsina Sabin Shrestha Thao Ngoc Duy Tran

Money Tracking Project Seminar on Software Architecture Design Money Tracking Project Date: Dec 05, 2008 Group 2 Adviser: Dr. Ali Arsanjani Student group:

Embed Size (px)

Citation preview

Seminar on Software Architecture Design

Money Tracking ProjectMoney Tracking Project

Date: Dec 05, 2008Group 2

Adviser: Dr. Ali Arsanjani Student group:

Khoa HoAamir KhanJayaram Timsina Sabin ShresthaThao Ngoc Duy Tran

Contents

Project introduction Architecture Design Architecture Styles Used Detailed Design Project Status

Project Description

Money Tracking System manages the purchase transactions.

It allows to Follow up all purchase items of each transaction and

categorizes these items. Manages accounts belonging to the system user. Each

purchase transaction will be assigned for one among these accounts.

Generating reports, detailed report on all purchase transactions; and sum of purchase amount according to a specific category.

General assumption

In the restriction of time and the compromise on the common database schema with other groups, the system is constructed in the following assumptions:

One system user can have many accounts. There is not sharing user account.

All the transactions in the system are purchase transactions.

Any transaction makes decreasing the expense will be entered as negative amount.

Project requirements

Functional requirements Register a system user Create new bank account linking to the system user Create transactions (purchases). Allowing to entry detailed items belonging to the

transaction. Allowing categorizing on items. Report: Listing transactions, According to account,

According to time period Report: Sum amount according to specific a category/time

period

Non-functional requirements

Web-base application Three tiers design Load balancing At least using one webservice Security - System requires user login Using https for some required pages (such as login page)

Design Decision & Architecture Design

Overall System Architecture- SOA Approach

Operational LayerSQL Server

Service Component Layer

Service Layer

Business Process layer

Consumer Layer

User management Transaction management

Transaction Report

User Account Transaction Transaction item CategoryFunctional component

Service component

Register user

Create Account

Create PurchaseGet List

Transaction Get Total purchase

Account management

Candidate services

Desktop Application Web

(MVC model)

Integrate service Layer

Tomcat/ jaxws-2_0

QoS Layer

Apache logging

Tomcat https configu-ration

Ws-policy

User authenticate

SOA Approach

Why? Easily to align and decouple the business

processes with the detailed implementation. Change the back-end packages without effect on

the client side It is a best practice for a distributed system

SOA Layers

Operational layer: the project uses Express SQL server edition that is free version.  

Service Component layer: location of all the functional packages

The functional components will handle basic functions effect on the data entities.

The service components will compose all basic functions provided by functional components, adding some control processes and aligning them to the business process 

Service layer: identifies which services in Service component layer will be exposed to outside.

SOA Layers (cont) Business process layer: at present, there is not any package

in this layer. But if we have more time, we plan to use the BPEL that supports to combine a bundle of services provide by service layer into flows, in order to meet any new specific use case or business process.

Consumer layer: this layer contains front-end applications for clients.

With SOA approach, the system allows client to access in both way, application with rich user interface and web application.  

Integrate service Layer: there areTomcat application server as a mediate for integrating all layers, jaxws 2.0 is used as engine for all web services running on. 

Quality of service layer (QoS): provides some mechanisms to keep trace for all activities occurring in system using file logging, to secure data transferring using https, and to authenticate web service consumers using WS-policy.

System Architecture in Tier View

Business Logic Tier

/ Data Access Tier

Database Tier

Windows

Web Tier

JSP / JSF / Servlet

Thin client

(Browser)

(Browsers)

Tomcat Application Server

Data Entity

MSSql

Spring/Apache

Business Tier

Data Access Layer

Controller

View

(jsp)

Web model (data)

Thick client

(Application)

(Browsers)

WS over http/https

Tcp/ip

WS over http/https

Web services providers

http/https

System Architecture in Tier View Thin client : using web browsers. Using http / https protocol for security.

Thick client: with SOA approach, the project support to build the rich UI applications at client side.

Web tier: is built based on MVC model using spring framework. The web hosting uses Apache Tomcat. The server can run on both Linux and Windows.

Business logic tier: the layer solves business processes. It’s also the Service Component Layer that is described in SOA approach section.

Data access tier: responsible in data persistence, handling the connection pool for whole system. Data entity belongs to this tier.

Web service provider tier: is web-based enterprise services built on JAX-WS, it exposes business logic services of the system for external clients.

Business logic, Data access and web service provider tiers are located in the same application server.

Database tier: the project uses SQL Server Express edition. It can be located in separated server using windows platform.

Technologies Used

Technology : Webservice, SOA approach Language : Java, JSP, Javascript DBMS : Express MSSQL Server Web server : Tomcat Server 6.0.18 OS : Windows MVC Model framework : Spring Framework 2.5.6

Architecture styles

Layer Architecture This style is applied in many parts of this project.

In the pure version of this pattern, each level communicates only with its immediate neighbors.

However, in this architecture, there are also some layers that can across other layers, such as QoS layer. 

Some advantages of this style:

The architecture provides high degree of cohesion within the layer. We can easy replace a layer by another one that has the same interfaces with the replaced one.

Each layer may hide private information from other layers.   Some disadvantages that should be considered:

Strict Layered Style may cause performance problem depending on the number of layers

Debugging in Strict Layered Style may be complex

May be difficult to decide on the number of layers

MVC The MVC model is applied in the web layer.

Views, controller, and Web data (model) are separate components that allow modification, change or replace in each “layer” without significantly disturbing the other.

Spring framework

Front controller

View template (jsp)

Controller

Web data

Web data

- Handling request

- Create web dataIncoming request

Response

Delegate

- Render html

Ajax

The system uses Ajax technique to fetch data to client without effecting on other client parts. It support effective data validation as well.

SOA & RepositoriesSOA

With SOA approach using Web service technique, the system is designed more flexible in functional expanding aspects. It’s also suitable architecture for distributed systems. (The details mentioned above.)

Repositories

•The system uses MS SQL server that enables centralized data storage.

•The Centric Data Repository pattern supports for maintainable, backup/recovering; the data store is independent of the clients. It reduces the cost for transition data explicitly from one subsystem to another.

•Because of the restriction on number of connection to MS SQL Server Express edition, the project provides a Data Access layer that handles the connection pool for the whole system.

Detailed Design

Uses Cases

Register User

User

User Authentication

Create Account

Entry transaction

Create category

Generate report

GUI Prototype

Logon Transaction

UserAdd

Account(popup)

TransactionAdd

Add

user

Login

Add

account

Add

tran

sact

ion

CategoryAdd (popup)

Add

category

ReportByItem

ReportByCategory

Gen

erat

eR

epor

ts

ItemAdd(popup)

Add

item

Return

Ret

urn

Ret

urn

Ret

urn Return

Sign

out

Ret

urn

Ret

urn

View-Controller mapping

Class diagram

mts.biz::Transaction Managermts.biz::Account Manager

mts.biz::User Managermts.biz::Report Manager

mts.biz::MoneyTracker

mts.biz::Category Managermts.biz::Item Managermts.auth::AuthManager

mts.db.dbactions::UserDBAction

mts.db.dao::IUserDao<<interface>>

mts.db.dao::UserDao

mts.db.dbobject::UserEntity

ConnectionFactory

mts.db.dbactions::CategoryDBAction

mts.db.dao::ICategoryDao<<interface>>

mts.db.dao::CategoryDao

mts.db.dbobject::CategoryEntity

mts.db.dbactions::AccountDBAction

mts.db.dao::IAccountDao<<interface>>

mts.db.dao::AccountDao

mts.db.dbobject::AccountEntity

mts.db.dbactions::TransactionDBAction

mts.db.dao::ITransactionDao<<interface>>

mts.db.dao::TransactionDao

mts.db.dbobject::TransactionEntity

mts.auth::AuthIinfo

mts.report::ReportDataAction

Magnify a Typical Part

Design Patterns Used Factory Method:

MoneyTracker is in responsible to create instance of other manager objects

Singleton

All manager objects are implemented as singleton classes

Connection pool also uses this pattern to handle the DB connection

Façade

MoneyTracker is single gateway that can access all other business functions.

Template

Template pattern is used in web tier. One common controller object provide a skeleton request process. It simplifies the implementation of request handlers.

Sequence diagram

Register User User Authentication Entry Transaction Create Account Create Category Generate Transaction Report By User Generate Report By Categories

Register User

User Authentication

Entry Transaction

Create Account

Create Category

Generate Transaction Report By User

Generate Report By Categories

Database schema

Project StatusTasks Status Reasons

Build up framework for the system

100%

Prototype 100%

Implementation – functional requirement

30% Low java / web development skills in the team

Implementation – nonfunctional requirements

10% Time constraint

Service Provider 0% Time constraint

Documentation 90%

Notes: We need about 2 days more to complete all implementation