1. Expense Tracking System Advisor : Dr. Ali Arsanjani Members: Ebe Pubudu Viduranga (12-05-2008)

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

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

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

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

6. Use Cases

7. Page Navigations

8. Architectural Styles Forced Dynamically Reconfigurable Architectural Style Multi-Tier Architectural Style Blackboard/Repository Pipes and Filters

9. Architectural Styles Implicitly Used Object oriented and data encapsulation Event based and implicit invocation, through their action listener and action events MVC Layered

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

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

12. Block-Diagram Single Server Scenario

13. Block Diagram Multi Server Scenario

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

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

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

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

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

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

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

21. Class Diagram

22. Login

23. Create Users

24. Add Transaction

25. Add Category

26. Reports