Upload
owen-jenkins
View
213
Download
0
Tags:
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)
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
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.
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
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
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
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