1. Money Tracking Project Seminar on Software Architecture Design 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

2. Contents Project introduction Architecture Design Architecture Styles Used Detailed Design Project Status

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

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

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

6. 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)‏

7. Design Decision & Architecture Design

8. Overall System Architecture- SOA Approach Operational Layer SQL Server Service Component Layer Service Layer Business Process layer Consumer Layer User managementTransaction management Transaction Report UserAccountTransactionTransaction itemCategory Functional component Service component Register user Create Account Create Purchase Get 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

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

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

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

12. 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 Controll er View (jsp) Web model (data) Thick client (Application) (Browsers) WS over http/https Tcp/ip WS over http/https Web services providers http/h ttps

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

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

15. Architecture styles

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

17. 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 - Handling request - Create web data Incoming request Response Delegate - Render html

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

19. SOA & Repositories SOA  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.

20. Detailed Design

21. Uses Cases

28. GUI Prototype

29. View-Controller mapping

30. Class diagram

31. Magnify a Typical Part

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

33. Sequence diagram Register User User Authentication Entry Transaction Create Account Create Category Generate Transaction Report By User Generate Report By Categories

34. Register User

35. User Authentication

36. Entry Transaction

37. Create Account

38. Create Category

39. Generate Transaction Report By User

40. Generate Report By Categories

41. Database schema

42. Project Status TasksStatusReasons Build up framework for the system 100% Prototype100% Implementation – functional requirement 30%Low java / web development skills in the team Implementation – nonfunctional requirements 10%Time constraint Service Provider0%Time constraint Documentation90% Notes: We need about 2 days more to complete all implementation