How To Build A Vodka System On A Microsoft Vodkasa.Org (A Microsoft Microsoft) System On Microsoft.Org On A Linux Computer (Ahemos) On A Macbook 2.5 (

Transcription

1 Software Design Description for VODKA Version 1.0 Approved April 18, 2007 Prepared by: Archit Baweja, Drew Hall, Sunny Huynh, Kevin Lynch, and Kanwarpreet Sethi Drexel University

2 Revision History Name Date Reason for Changes Version Archit Baweja, Drew Hall, Sunny Huynh, Kevin Lynch, and Kanwarpreet Sethi 17 Jan 2007 Initial Version 1.0 i

3 Contents 1 Introduction Purpose Scope Definitions, Acronyms, and Abbreviations Context Diagram Architecture Overview Three-Tier Architecture Oriented Architecture Survey of Technologies Used Data Layer Business Layer Presentation Layer Presentation Layer Components Financial Account Servlet Login Servlet Notification Servlet Report Servlet Search Servlet Summary Servlet Servlet History Servlet User Account Servlet View Account Servlet Business Layer Components Attach File Login Logout Report Revert Session Trend Data Layer Components Financial Account Notification User Account External Components Authentication Login Data Source SMS Design Features Login External Authentication User Account Creation User Account Modification User Account Deactivation Financial Account Creation Financial Account Modification ii

4 3.8 Financial Account Deactivation Temporary Deactivation of Financial Account Creation Modification Deactivation Revert Recover Deactivated Comment on Create Label View Account Summary View Financial s Sort Financial s Search s Generate Report Configure Account Balance Trigger Lost User Name Lost Password Lost Password Database Design Account Label Notification Permission History User Summary Advantages of Design Disadvantages of Design Design Rationale A Requirements Traceability Matrix 63 A.1 Traceability by Requirement Numbers A.2 Traceability by Design Component iii

5 1 Introduction 1.1 Purpose This document specifies the entire software architecture and design for the VODKA financial management system. These design decisions directly relate to the functionalities, performances, constraints, attributes, and interfaces of the system. VODKA is a tool to manage the financial accounts of student organizations within a schoool or university. There are two primary goals of the VODKAsystem. The first goal is to allow students to manage the financial accounts of their student organizations in a simple and reliable manner. And the second goal is to provide a centralized tool by which the parent school may audit the student organizations. In order to provide these two goals, the system focuses on simplicity, flexibility, security, accessibility, and scalability. For further detail, refer to the VODKA Software Requirements Specification [1]. 1.2 Scope This document describes the software architecture and design for the initial release of VODKA, version 1.0. The intended audience of this document exclusively includes the designers, the developers, and the testers of the VODKA software system. 1.3 Definitions, Acronyms, and Abbreviations AJAX A new emerging standard for web applications for dynamic content. AJAX communicates with a server to dynamically update only the necessary portions of a web page; this allows results to appear almost instantly and additionally cuts down on network traffic. Most frameworks for web application development use AJAX and are written in a higher level language such as Java or ASP.NET to avoid browser compatibility problems with handwriting Javascript. Audit An audit is an assessment of the accuracy by which a student organization s financial statements are presented. Check Request A check request is a request for the parent school or university to issue a check for a specified amount to a specified recipient. Communications Protocol A communications protocol defines the rules for sending data in a network. Each protocol may include information such as data representation, error detection, authentication and other information. Deactivation Deactivation of a user account in the VODKA system may mean one of two scenarios. Deactivation includes deletion and disabling of user accounts. Deleting of a user account is only possible if there is no prior history associated with the account. In the case of a user account having prior history, only disabling is possible. Finance Manager The Finance Manager is a user whose user account has priveleges to create, to edit, to delete, and to view all comments, financial accounts, transactions, and user accounts of every organization within the VODKAsystem. Financial Account Each financial account is an independent collection of transactions and their histories. A financial account is uniquely identified with an associated account number. HyperText Markup Language (HTML) The HyperText Markup Language is the predominant language used for the creation of web pages. HyperText Transfer Protocol (HTTP) The HyperText Transfer Protocol is the de facto standard protocol communications protocol for World Wide Web applications. Internet The Internet is a publicly accessible network of interconnected computer networks. 1

6 Internet Protocol (IP) The Internet Protocol is the standard communications protocol to distinguish computers connected over a network and to send data across the Internet. Network A computer network is the interconnection of multiple computers using a telecommunications system, which allows for the communication and sharing of resources. Non-Volatile Storage Non-volatile storage is the type of computer memory does not lose its stored information when powered off. Organization Advisor An Organization Advisor is a special user account provided for each organization with the privileges to create, to edit, to delete, and to view all comments, transactions, and user accounts of the particular organization to which the advisor belongs. Each organization must have at least, but not limited to, one advisor account. Privilege The VODKAsoftware system limits user accounts from performing certain actions; whether a user account can or cannot perform these actions is called the user s privileges. Priveleges are to create, edit, delete, and view; each action the user can take upon the system must be classified as one of these categories. User privileges are specific to different parts of the software system. -Oriented Architecture (SOA) A software architecture that uses software services as its main components. Simple Mail Transfer Protocol (SMTP) The Simple Mail Transfer Protocol is the de facto standard communications protocol for transmission over a network. Student Organization Officer Training (SOOT) At Drexel University, officers of student organizations must attend annual training sessions, called Student Organization Officer Training, that explain the policies and procedures involved in running student organizations. These policies and procedures include those regarding the management of financial accounts owned by the student organizations. System Administrator The system administrator is a special user whose user account has all the possible privileges available to any other user account as well as direct access to the underlying VODKAsoftware processes and server(s). This person(s) should be the one(s) permitted to access the physical machines running the VODKAsoftware system. The role of the system administrator is to perform system maintenance and configuration. A transaction is any entry into a financial account that documents financial accounting practives (e.g. recording a bank account deposit or pending check request). Transmission Control Protocol (TCP) The Transmission Control Protocol is a very commonly used communications protocol that guarantees transmission integrity over a network. Transport Layer Security (TLS) The Transport Layer Security is a set of communication encryption protocols that guarantee privacy and data integrity over a network. User A user is a person who interacts with the VODKAsoftware system. User Account A user account is an independent collection of user information that the VODKAsoftware system uses to recognize individual users. Each user account is uniquely identified by a user name and allows the software to track individual user privileges. Volatile Storage Volatile storage is a type of computer memory that requires power to retain the stored information. When volatile storage is powered off, all the stored information is lost. Web Browser A web browser is a software that allows users to view and interact with graphical and textual web sites on the World Wide Web. World Wide Web (WWW) The World Wide Web is network of interconnected documents on the Internet. 2

7 1.4 Context Diagram The context diagram shown in figure 1.4 shows how the main components of the VODKA system fits into context with its external components. Each external component is distinguished by a shaded box. Web Browser VODKA Web Server External Application External Authentication System SMS System VODKA Database Figure 1: Context Diagram VODKA s business layer interacts directly with the external authentication system, system, and SMS system. External application can be built that use the services provided by the VODKA business layer. 3

8 2 Architecture User Presentation Layer Login Servlet Trans History Servlet Summary Servlet Report Servlet User Acct Servlet Search Servlet Fin Acct Servlet Notification Servlet View Acct Servlet Servlet Business Layer Revert Attach File Trend Report Logout Login Session Authentication Login Data Source Data Layer Fin Acct User Acct Database Triggers Notification DB DB SMS Figure 2: Architecture Diagram 2.1 Overview The general architecture of VODKA is a combination of the three-tiered and service-oriented architectures. This hybrid style allows for clear separation of concerns and creates loosly-coupled, reusable components. The architectural model showing the tiered separation and components of the system is in figure 2. s are divided among the tiers to reduce dependencies and increase modularity in the design. 2.2 Three-Tier Architecture Many traditional web-based enterprise software systems have used the three-tier architecture since the 1990s. This client/server architecture model promotes the separation of responsibilities into three distinct layers. Each layer of the system depends only on the layer directly below it; layers may not depend on layers above them. The tiers, as shown in figure 2, are the presentation layer, business layer, and data layer. Components in the presentation layer handle interacting with the user, validating input data, and localization of data to display. Business layer components provide business logic and processing of data. Data layer components provide access to the database. 4

9 Benefits of using this architectural style include increased performance, flexibility, maintainability, reusability, and scalability [2]. Since the software is expected to be deployed for use by hundred of student organizations, scalability is an important consideration Oriented Architecture s in service-oriented architecture allow for loose-coupling in software design. This promotes reusability and flexibility to replace service components with new ones without impact on clients. Using service-oriented architecture also allows external applications to use services provided by the VODKA system. -oriented architecture aids VODKA s flexibility for integration with other external components, such as external authenitcation systems. 2.4 Survey of Technologies Used Data Layer The data layer of the VODKA financial system has to fullfill various non-functional besides the obvious functional ones. These non-functional requirements include Robustness ANSI-SQL compatibility Scalable Cost Taking these non-functional requirements in mind we surveyed the following databases Oracle 8i MySQL PostgreSQL 8.2 In each relational database system we looked for robustness of the architecture, and scalability. But what we valued most for this system was something that was cheap to setup and use, and standards compliant. Keeping these factors in mind the choice was made to go with PostgreSQL 8.2 which features unmatched standards compliance, cost effectiveness. MySQL had similar attributes, it lacked in standards compliance, and Oracle lost out in cost of setup and maintaining the system Business Layer The business layer runs Sun Microsystem s GlassFish v1 web server using Java EE 5.0 and Java SE 6.0 as the primary environment and programming language. The choice for programming language was decided based on Java s success in commercial enterprise systems. Alternative langauges considered were Ruby, PHP, C#, and ASP. Ruby on Rails was not chosen due to lack of knowledge among the team members, and the lack of large scale commercial products using it. PHP was not chosen over Java since the Java environment allows for better modularity and easier code maintainence. C# using ASP.NET was not chosen because of it requires using Microsoft IIS and Microsoft Windows. The Java environment has an advantage here because most Java-enabled web servers are freely available and can be run on freely available operating systems. ASP was not chosen because it is a legacy framework, which Microsoft is phasing out. Overall, the Java language and framework is one in which there exists a sufficient knowledge base without our team members, and it can be deployed onto many different environments (web servers and operating systems). For the development purposes, GlassFish is chosen to be the web server since it is the refernce implementation for Java EE 5.0. Other web servers considered were Apache Tomcat and JBoss. The current stable versions of both JBoss and Apache Tomcat do not fully support Java EE 5.0; Apache Tomcat has a 5

10 beta version that supports it but the beta version may contain undocumented bugs. Therefore, GlassFish was chosen but the system is designed such that different web servers may be substituted upon deployment. GlassFish supports both Java EE 5.0 and WS-* standards [4, 3] for ease of development. Java EE 5.0 was chosen because of its simplified implementation of web services over Java2 EE 1.4 and its support for the Java SE 6.0 programming language. The WS-* set of standards were chosen for its enhanced security and interoperability over prior web service standards Presentation Layer The presentation layer of VODKA must fulfill several system requirements. VODKA was envisioned as a thin client that is accessible by potentially any computer that can communicate with the server. Users must be able to quickly and securely access pertinent data with very short load times. Additionally, changes to the system can be easily made without forcing users to upgrade; simply refreshing the browser will update the client system for the clients. There are many ways the presentation layer can be implemented. Traditionally static webpages were generated by an application on the server. Communication between the client and the server was performed through HTML POST operations which relay response data to the serving application. Though this approach is certainly feasible and straightforward to implement it does not feel natural because it does not allow for dynamic content. That is, a new page must be reloaded after each operation; a dynamic client would seemingly respond instantaneously to the user as only the necessary portions of the client are updated. Static webpages, however, are very generic and thus almost every web browser should interpret the pages correct. 1.3 based webpages are much simpler and cleaner from coding and interactivity standpoints. Additionally, many frameworks exist to allow for AJAX pages to be easily generated. Of these frameworks, a few Java based frameworks seemed useful. The Google Web Toolkit (GWT) is one of the more successful and better known web toolkits. The toolkit provides not only a dynamic user interface but also ways to easily manage history, cookies, and remote procedure calls. The code is written in a subset of Java 1.4 and is translated to Javascript using the GWT Compiler. The GWT Compiler handles differences in Javascript implementations, allowing the code to run on different web browsers. GWT is designed in Java using a layout style similar to Java Swing. Additionally, it provides JUnit integration and Java debugging. However, one of the problems with GWT is that it does not rely on lazy loading because it sends the entire system to the user on the initial load. An alternative to GWT is Potix Corporation s ZK framework released under the GNU Public License. ZK is designed with a clear separation between the presentation layer and the business layer. ZK relies on an XML based renderer to generate dynamic webpages to the user from descriptions of the user interface. Though ZK does not have as much corporate support as GWT, it s clear separation of concerns between the model, view, and control components of the MVC paradigm is very clean. Because of its focus on separation of logics, VODKA uses Potix Corporation s the ZK Framework to assist in presenting information to the user. 2.5 Presentation Layer Components Financial Account Servlet Requirements Satisfied: 0580, 0590, 0600, 0605, 0610, 0615, 0620, 0630, 0640, 0650, 0655, 0660, 0660, 0665, 0670, 0680, 0690, 0700, 0710, 0715, 0720, 0730, 0740, 0750, 0760, 0770, 0780, 0790, 0800, 0810, 0820, 0830, 0840, 0850, 0860, 0870, 0880, 0890, 0895, 0900, 0905 The Financial Account Servlet manages the movement of data to and from the client software module. This includes checking for valid input and output Login Servlet Requirements Satisfied: 0470, 0480, 0490, 0500, 0510, 1390, 1400, 1410, 1420, 1430, 1440, 1450 The Login Servlet is responsible for providing and validating the authentication of user accounts in a robust manner. This includes checking for correct authentication formatting and passing the web browser to the welcome page. 6

11 2.5.3 Notification Servlet Requirements Satisfied: 1220, 1230, 1240, 1245, 1250, 1260, 1270 The Notification Servlet provides an interface for the user client to configure notifications for their Financial Accounts. This servlet is responsible to validate input and output to the client Report Servlet Requirements Satisfied: 1170, 1180, 1190, 1200, 1210 The Report servlet is responsible for marrying the user client with the Reports. It passes the messages and data between the two to provide VODKAgenerated reports for the user Search Servlet Requirements Satisfied: 1150 The search servlet is responsible for messages and data sent between the user client and the Financial Accounts. The servlet checks the format of the data Summary Servlet Requirements Satisfied: 1160 The Summary Servlet is responsible for gathering and formatting the data for the summary page for the user client Servlet Requirements Satisfied: 0910, 0920, 0930, 0935, 0940, 0950, 0960, 0965, 0970, 0975, 0980, 0985, 0990, 0995, 1000, 1005, 1010, 1020, 1025, 1030, 1040, 1050, 1060, 1070, 1080, 1090, 1100, 1110, 1120, 1130, 1140, 1150 The Servlet is responsible for providing the interface for the user client to view, sort, and modify transactions. It interfaces with the Financial Account and the User Account History Servlet Requirements Satisfied: 1090, 1100, 1110 The History Servlet is responsible for handling the messages and actions to view transaction history. It interfaces with the Financial Account User Account Servlet Requirements Satisfied: 0180, 0190, 0200, 0205, 0210, 0215, 0220, 0230, 0240, 0250, 0260, 0270, 0280, 0290, 0300, 0310, 0320, 0330, 0340, 0350, 0360, 0370, 0380, 0390, 0395, 0400, 0420, 0430, 0440, 0450, 0455, 0460, 0530, 0540, 0550, 0560, 0570 The User Account Servlet passes messages between the user client and other servlets to the User Account. It is responsible for checking for valid requests and responses View Account Servlet Requirements Satisfied: 0910, 0920, 0930, 0935, 0940, 0950, 0960, 0965, 0970, 0975, 0980, 0985, 0990, 0995, 1000, 1005, 1010, 1020, 1025, 1030, 1040, 1050, 1060, 1070, 1080, 1090, 1100, 1110, 1120, 1130, 1140, 1150 The View Account Servlet is responsible for sending and retrieving data between the user client and the Financial Account. It also validates the data and format of messages. 7

12 2.6 Business Layer Components Attach File Requirements Satisfied: 1060 The Attach File provides a method for attaching files to transactions. This service interactes with the to attach the files if the user s session is active and has the correct permissions to modify the transaction Login Requirements Satisfied: 0470, 0480, 0490, 0500, 0510, 1280, 1290, 1300, 1310, 1320, 1330, 1340, 1350, 1390, 1400, 1410, 1420, 1430, 1440, 1450 The Login provides all the methods and actions for the VODKAsystem to validate a user in the VODKAsystem. This service interacts with the User Account and External Authentication. It provides the following actions: security warnings to administrators via , authenticating user password, and validating user as a VODKAuser Logout Requirements Satisfied: 1450 The Logout provides VODKAwith the methods and actions to initiate the process of user account logout. It interfaces specifically with the Session Report Requirements Satisfied: 1170, 1180, 1190, 1200, 1210 The Report is used to generated financial reports and graphs for the specified Financial Account. The Report generates report information on transactions in an easy to read format. Additionally, it generates graphs that represent current transactions and formats data from the Trend into a graph Revert Requirements Satisfied: 1110 The Revert provides the software interface for the VODKAsystem to modify transactions to a state in the transaction history. It also deactivated transactions to be re-activated Session Requirements Satisfied: 1390, 1400, 1410, 1420, 1430, 1440, 1450 The Session handles the active sessions for the system. It tracks the users currently on the system and stores permissions and other persistent data for each user. It also handles the creation and deletion of sessions, which can only be performed by the Login and Logout s. It also automatically logs out inactive users Trend Requirements Satisfied: 1200, 1210 The Trend is used to predict trends for a specific Financial Account. The service analyzes previous transactions, and based on this, generates a prediction of trends for upcoming time periods. 2.7 Data Layer Components Financial Account Requirements Satisfied: 0580, 0590, 0600, 0605, 0610, 0615, 0620, 0630, 0640, 0650, 0655, 0660, 0660, 0665, 0670, 0680, 0690, 0700, 0710, 0715, 0720, 0730, 0740, 0750, 0760, 0770, 0780, 0790, 0800, 0810, 0820, 0830, 0840, 0850, 0860, 0870, 0880, 0890, 0895, 0900,

13 The Financial Account handles all actions related to financial accounts in the VODKAsystem. This includes creation, modification and deactivation of financial accounts. It also provides information related to a financial account such as account balance, and related transactions of a financial account Notification Requirements Satisfied: 1220, 1230, 1240, 1245, 1250, 1260, 1270 The Notification handles all the notifications that are sent to the users of the VODKAsystem. It is also used to save database triggers which can be set by users. The can also be configured to notify users of account activity like posting of new transactions, posting of new comments to transactions, etc Requirements Satisfied: 0910, 0920, 0930, 0935, 0940, 0950, 0960, 0965, 0970, 0975, 0980, 0985, 0990, 0995, 1000, 1005, 1010, 1020, 1025, 1030, 1040, 1050, 1060, 1070, 1080, 1090, 1100, 1110, 1120, 1130, 1140, 1150 The service is responsible for querying the database to retreive all transactions related to a specific financial account. It is also responsible for creation, modification and deletion of transactions. It also handles labelling transactions and posting comments to transactions. The is also called when information on a particular transaction is required User Account Requirements Satisfied: 0180, 0190, 0200, 0205, 0210, 0215, 0220, 0230, 0240, 0250, 0260, 0270, 0280, 0290, 0300, 0310, 0320, 0330, 0340, 0350, 0360, 0370, 0380, 0390, 0395, 0400, 0420, 0430, 0440, 0450, 0455, 0460, 0470, 0480, 0490, 0500, 0510, 0520, 0530, 0540, 0550, 0560, 0570 The User Account handles all the actions related to user accounts in the VODKAsystem. It is resposible for creation, modification, and deactivation of user accounts. It interacts directly with the database to provide data to all servlets that request it. 2.8 External Components Authentication Requirements Satisfied: 0140, 0150, 0160, 0170 The Authentication provides a method of authenticating users with an external system. This service interacts with the Login Data Source to accept or reject usernames and passwords Requirements Satisfied: 0100, 0110, 0120, 0130, 1230, 1380 The provides methods for sending messages to a user if certain events are triggered. Events can include, for example, funds in an account falling below a specific threshold Login Data Source Requirements Satisfied: 0140, 0150, 0160, 0170 The Login Data Source is an external system for user authentication. Some more common examples of authentication sources are databases or LDAP or PAM based systems SMS Requirements Satisfied: 1230 The SMS provides methods for sending text messages to a user if certain events are triggered. Events can include, for example, funds in an account falling below a specific threshold. 9

14 3 Design Features 3.1 Login The Login feature allows a user to login providing a valid username and password combination. It also prevents deactivated users from logging in to the system. User Presentation Layer Login Servlet Business Layer Login Session Authentication Login Data Source Data Layer User Acct DB DB Figure 3: Login - Vertical Slice The Login process first takes the username entered by the user and checks to make sure it is a valid username. If it is, the username and password combination is passed over to the Authenticate. On successful authentication, the Login gets the user privilege type from the User Account. It then proceeds to create a new unique session for the user using the Session. 10

15 alt alt User Web Browser <<servlet>> Login Login UserAcct Authenticate Login Data Source Session click login button login(user, password) login(user, password) check valid user name [invalid user name] deny login render page deny login [else] login(user, password) get login info authenticate [authentication failed] deny login deny login render page deny login [else] approve login get user privileges create-session(user, priveleges) approve login redirect to welcome page Figure 4: Login - Sequence Diagram 11

16 3.2 External Authentication The External Authentication Feature autheticates a VODKAuser with an external database. This is used when the default VODKAauthetication system is not used and all users are verified using an external authentication system. Authentication Login Data Source DB Figure 5: External Authentication - Vertical Slice The login service encrypts the user s username and password information and transfers it to the external authentication system. The external authentication system uses its own verification service to autheticate the user against its own database. The result is then passed back to the VODKALogin and the user is informed of success or failure. 12

17 Client Authenticate Login Data Source Database login(user, password) encrypt password get user record get user record compare user, password login result Figure 6: External Authentication - Sequence Diagram 13

18 3.3 User Account Creation The User Account Creation feature allows for the creation of a new User Account. A new User Account may only be created by users with specific privileges. Creating a new user account requires the following information: Username Password Name Address User Account Type Accessible Financial Accounts Financial Account Privileges User Presentation Layer User Acct Servlet Business Layer Session Data Layer User Acct DB Figure 7: User Account Creation - Vertical Slice The Create User Account GUI extracts all the information entered for creating a new user account and sends it to the User Account Servlet. The Servlet checks the data for consistency and checks the user account for the required privileges. The data is then passed over to the User Account which interacts with the database to create the new user account. 14

19 User eb Browser <<servlet>> UserAcct Session UserAcct load get session check permissions [invalid session or privileges] redirect to login page alt [else] render page enter account info click confirm button create account get session check permissions [invalid session or privileges] redirect to login page [else] create account ref alt external create user account redirect to welcome page Figure 8: User Account Creation - Sequence Diagram 15

20 3.4 User Account Modification The system allows the modification of any attribute of a user account. A user can change the user account attributes for his own user account. A Finance Manager and Organization Advisor can also change the user account of the users in the financial accounts User Presentation Layer User Acct Servlet Business Layer Session Data Layer User Acct DB Figure 9: Modify User Account - Vertical Slice A user of the system can modify only his own user account settings like name, etc. On the Preferences page when the user submits his new information for his user account, the web browser sends the request to modify the user account information to the UserAcct Servlet. The UserAcct Servlet checks to see the if the client making the request has a valid session id and privileges. If that is the case, the UserAcct Servlet requests the UserAcct to modify the given user account s information in the database. The UserAcct modifies the transaction in the database an returns a status on if the modification was successful. Based on this the UserAcct Servlet updates the user s webpage if the modification was successful. 16

21 User Web Browser <<servlet>> UserAcct UserAcct Database modify user account modify user account ref check user permissions & session id modify user account modify user account successstatus [successful?] show operation confirmation alt [else] show error message Figure 10: Modify User Account - Sequence Diagram 17

22 3.5 User Account Deactivation Users with Finance Manager & Organization Advisor privleges can deactivate a user account. Deactivation doesn t lead to complete deletion. This is so that the user accounts can be re-activated in the future. User Presentation Layer User Acct Servlet Business Layer Session Data Layer User Acct DB Figure 11: User Account Deactivation - Vertical Slice A Finance Manager or a Organization Advisor can select a user s account to deactivate. The web browser sends the request to deactivate to the UserAcct Servlet. The UserAcct Servlet first checks the session id and permissions of the client making the request for deactivation, to make sure if its valid. If so, the UserAcct checks the number of transactions created by the user account to be deactivated. If the number of transactions created by the user account to be deactivated is 0, the user accout is deleted. Otherwise, the UserAcct Servlet requests the UserAcct to deactivate the user account. The UserAcct notifies the UserAcct Servlet if the deactivation was successful or not. The UserAcct Servlet accordingly updates the user s web page to display if the deactivation was successful or not, and if the user account was deactivated or deleted. 18

23 User eb Browser <<servlet>> Login Database UserAcct Session Authenticate Data Source load get session check permissions [invalid session or privileges] redirect to login page alt [else] render page click delete delete account get session check permissions [invalid session or privileges] redirect to login page [else] delete account get transactions by user [no transactions] delete user alt delete user alt delete user disable user Figure 12: User Account Deactivation - Sequence Diagram 19

24 3.6 Financial Account Creation Financial Account Creation feature allows a user to create a new financial account. Only users with sufficient privileges in the VODKAsystem are allowed to use this feature. Each new financial account has a unique account number that defines it. Creating a new financial account asks a user to enter the following information: Account Number Account Name Comments/Description Associated Student Organization User Presentation Layer Fin Acct Servlet Business Layer Session Data Layer Fin Acct DB Figure 13: Financial Account Creation - Vertical Slice To create a new financial account, a user must have Finance Manager or System Administrator privileges. The Financial Account Creation GUI takes the required data to create a new financial account and transfers it to the Financial Account Servlet. The Servlet checks to confirm if the user has sufficient privileges. The Servlet checks the data for consistency and formatting and checks for Account Number and Account Name as they are mandatory fields. If everything is consistent and passes checks, the data is transfered to the Financial Account. The interacts with the Database and creates the new account. 20

25 Web FinAcct Session FinAcct Database load get session check permissions [invalid session or privileges] redirect to login page alt [else] render page enter account info click confirm button create account get session check permissions [invalid session or privileges] redirect to login page [else] create account alt create account redirect to welcome page Figure 14: Financial Account Creation - Sequence Diagram 21

26 3.7 Financial Account Modification The Financial Account Modification feature allows users to modify the properties related to an existing financial account. These include: Account Name Comments/Description Associated Student Organization The Account Number associated with an existing financial account is not modifiable. A user must have sufficient privileges to make any modifications to an existing financial account. User Presentation Layer Fin Acct Servlet Business Layer Session Data Layer Fin Acct DB Figure 15: Financial Account Modification - Vertical Slice To modify a financial account, a user must have Finance Manager or System Administrator privileges. While modifying a financial account the following properties cannot be left blank and are required to have a proper formatted value: Account Name The Modify Financial Account GUI extracts the modified data and transfers it to the Financial Account Servlet. The Servlet checks to make sure that the user has the required privileges. If the privileges meet the requirements, the data is checked for consistency and is passed on to the Financial Account. The interacts with the database and makes the modifications needed. 22

27 FinancialManager Web Browser <<servlet>> FinAcct FinAcct Database user request fin acct editing page user submits new data for fin acct submit new fin acct data ref check user permissions & session id change fin acct data change fin acct data success or failure [successfull?] show confirmation alt [else] show reason for no modification Figure 16: Financial Account Creation - Sequence Diagram 23

28 3.8 Financial Account Deactivation The Financial Account Deactivation feature allows a user with sufficient privileges to deactivate a financial account. Deactivation of a financial account includes the deletion and the disabling of a financial account. Deletion of a financial account is done when it has no history of usage associated with it. If an account has history associated with it, it is only disabled and never deleted. User Presentation Layer Fin Acct Servlet Business Layer Session Data Layer Fin Acct DB Figure 17: Financial Account Deactivation - Vertical Slice The Financial Account Deactivation GUI sends the user s request to deactivate an existing financial account to the Financial Account Servlet. The Financial Account Servlet makes sure the user permission requirements are met. It then requests a transaction history from the Financial Account for the requested financial account. If the returns a transaction history for the financial account then it is disabled by calling the Financial Account. On the other hand if there is no history returned, the financial account is deleted. 24

29 FinancialManager Web Browser <<servlet>> FinAcct FinAcct selects fin account name to be deactivated fin account to be deactivated check user permissions & session id alt ref get transaction for fin acct [no trasnactions] delete fin acct [else] disable show confimation message Figure 18: Financial Account Deactivation - Sequence Diagram 25

30 3.9 Temporary Deactivation of Financial Account The Temporary Deactivation of Financial Account feature is used to temporarily disable a financial account in the case of a violation of the university s policies. Only users with sufficient privileges are allowed to use this feature. User Presentation Layer View Acct Servlet Business Layer Session Data Layer Fin Acct DB Figure 19: Temporary Deactivation of Financial Account - Vertical Slice The Temporary Deactivation GUI sends the user s request to deactivate an existing financial account to the Financial Account Servlet. The Financial Account Servlet makes sure the user permission requirements are met. It then proceeds to call the Financial Account to disable the financial account. 26

31 FinancialManager Web Browser <<servlet>> FinAcct FinAcct selects fin account name to be deactivated fin account to be deactivated check user permissions & session id alt ref get transaction for fin acct [no trasnactions] delete fin acct [else] disable show confimation message Figure 20: Temporary Deactivation of Financial Account - Sequence Diagram 27

32 3.10 Creation The system allows the creation of new transaction. Any user with account modification privileges can create transactions. User Presentation Layer Servlet Business Layer Session Data Layer DB Figure 21: Create Financial s - Vertical Slice Any user with account modification privelges can create transactions. The user must enter all nonoptional attributes of a new transaction. After the user clicks the submission button on the page, the data entered is sent by the Web Browser to the Servlet. The Servlet checks the session id and if the user has account modification privileges. If it is so, the Servlet tells the to add the new transaction to the database. The adds the transaction to the database and returns a operation status. If the transaction creation is successful, the Servlet updates the web page tell the user the transaction was created and adds it to the list of transactions on the Account s Summary page. If the transaction creation is not successful, the user is given an error message explaining why the transaction creation was unsuccessful 28

33 Web Browser <<ser user enters transaction information on the page create new transaction ref check user permissions & session id create new transaction success or failure [successful?] show user confirmation alt [else] show user error message why Figure 22: Create Financial s - Sequence Diagram 29

34 3.11 Modification The system allows the modification of any attribute of a transaction. Only users with account modification privileges can modify transactions. User Presentation Layer Servlet Business Layer Session Data Layer DB Figure 23: Modify Financial s - Vertical Slice The user is presented with a list of all the transactions of a given account on the Account s Page. The user can click the modify button for a transaction to modify it. The browser then send the request to modify the transaction to the Servlet. The Servlet checks if the client making the request for details of the transaction has account modification privileges. The Servlet then forwards the request to the to modify the transaction. The modifyies the transaction in the database and returns a status on if the modification was successful. Based on this the Servlet updates the user s webpage if the modification was successful. 30

35 e <<servlet>> Database modify transaction modify transaction ref check user permissions & session id modify transaction modify transaction successstatus [successful?] show operation confirmation alt [else] show error message Figure 24: Modify Financial s - Sequence Diagram 31

36 3.12 Deactivation The system allows for the deactivation of a transaction. Any user with account modification privileges can deactivate a transaction. User Presentation Layer Servlet Business Layer Session Data Layer DB Figure 25: Deactivate Financial s - Vertical Slice The user is presented with a list of all the transactions of a given account on the Account s Page. The user can click the deactivate button for a transaction to deactivate it. The browser then send the request to deactivate the transaction to the Servlet. The Servlet checks if the client making the request for details of the transaction has account modification privileges. The Servlet then forwards the request to the to deactivate the transaction. The deactivates the transaction in the database and returns a status on if the deactivation was successful. Based on this the Servlet updates the user s webpage if the deactivation was successful. 32

37 User Web Browser <<servlet>> Database deactivate transaction deactivate transaction ref check user permissions & session id deactivate transaction deactivate transaction successstatus [successful?] show operation confirmation alt [else] show error message Figure 26: Deactivate Financial s - Sequence Diagram 33

38 3.13 Revert The system allows to revert a modified transaction to its previous form. Only users with account modification privileges can revert transactions. User Presentation Layer Servlet Business Layer Session Data Layer DB Figure 27: Revert Financial s - Vertical Slice The user is presented with a list of all the changes made to a transaction of a given account. The user can click the revert button on a specific history to become the current one. The browser then send the request to revert the transaction to the Servlet. The Servlet checks if the client making the request to revert the transaction has account modification privileges. The Servlet then forwards the request to the to revert the transaction. The reverts the transaction in the database and returns a status on the operation. Based on this the Servlet updates the user s webpage if the transaction was reverted. 34

39 User Web Browser <<servlet>> Database revert transaction revert transaction ref check user permissions & session id revert transaction revert transaction successstatus [successful?] show operation confirmation alt [else] show error message Figure 28: Revert Financial s - Sequence Diagram 35

40 3.14 Recover Deactivated The system allows to revert a deactivated transaction. Only users with account modification privileges can revert transactions. User Presentation Layer Servlet Business Layer Session Data Layer DB Figure 29: Revert Deactivated Financial s - Vertical Slice The user is presented with a list of all the deactivate transaction when the user requests it. The user can then ask for reverting a deactivated transaction The browser then sends the request to revert the deleted transaction to the Servlet. The Servlet checks if the client making the request to revert the deleted transaction has account modification privileges. The Servlet then forwards the request to the to revert the transaction. The reverts the transaction in the database and returns a status on the operation. Based on this the Servlet updates the user s webpage if the deleted transaction was reverted. 36

41 User Web Browser <<servlet>> Database revert deactivated transaction revert deactivated transaction ref check user permissions & session id revert deactivated transaction revert deactivated transaction successstatus [successful?] show operation confirmation alt [else] show error message Figure 30: Revert Deactivated Financial s - Sequence Diagram 37

42 3.15 Comment on The system allows the modification of any attribute of a transaction. Only users with account modification privileges can comment-on transactions. User Presentation Layer Servlet Business Layer Session Data Layer DB Figure 31: Comment On Financial s - Vertical Slice The user is presented with a list of all the transactions of a given account on the Account s Page. The user can edit a transaction to comment on it. The browser then sends the request to comment on the transaction to the Servlet. The Servlet checks if the client making the request for details of the transaction has account modification privileges. The Servlet then forwards the request to the to comment on the transaction. The comment on the transaction in the database and returns a status on if the modification was successful. Based on this the Servlet updates the user s webpage if the modification was successful. 38

43 User Web Browser <<servlet>> Database comment on transaction comment on transaction ref check user permissions & session id comment on transaction comment on transaction successstatus [successful?] show operation confirmation alt [else] show error message Figure 32: Comment On Financial s - Sequence Diagram 39

44 3.16 Create Label The Create Label feature allows a user to create labels for transactions which can be then used to categorize transactions. Each transaction can have multiple labels applied to it. User Presentation Layer Servlet Data Layer Business Layer DB Figure 33: Create a Label for s - Vertical Slice The user submits a label to be applied to a transaction which calls the Servlet. The transaction servlet checks for a valid session and then calls the transaction service to save the label to the related transaction. The user is notified of success or failure. 40

45 User Web Browser <<servlet>> user submits label for transactions save the label for transaction ref check user permissions & session id save the label for transaction success or failure [successful?] notify added alt [else] notify not added with reason Figure 34: Create a Label for s - Sequence Diagram 41

46 3.17 View Account Summary The View Account Summary feature is used to display a summary of all the financial accounts that a user account has access to. It allows the user to view all the balances associated with each financial account also. User Presentation Layer Summary Servlet Business Layer Session Data Layer Fin Acct DB Figure 35: View Account Summary - Vertical Slice On successful login, the Login calls the Summary Servlet as it needs to display all the financial accounts associated with the user account. The Summary Servlet passes the user account information to the User Account. The User Account interacts with the database and returns the list of financial accounts that the user has access to. This list of accounts is then passed to the Financial Account which retreives the Account Balance field related to each of them. This summary is then displayed as the main page on user login. 42

47 User Web Browser <<servlet>> Summary Session FinAcct load get session check permissions get accounts alltheaccounts show account summary page Figure 36: View Account Summary - Sequence Diagram 43

48 3.18 View Financial s The system allows the viewing of all the details of all transactions. Any user with sufficient viewing privileges can view all the details of a transaction. User Presentation Layer Servlet Business Layer Session Data Layer DB Figure 37: View Financial s - Vertical Slice The user is presented with a list of all the transactions of a given account on the Account s Page. The list of transaction shows only the most relevant details of each transaction. The user can click a transaction to obtain all the details of the transaction. When the user clicks a transaction the web browser sends a request to the Servlet to get all the details of the given transaction. The Servlet checks if the client making the request for details of the transaction has viewing privileges and then returns the transaction s details. The Servlet gets the transaction details, and returns it to the Web Browser to display all the transaction details. 44

49 User Web Browser <<servlet>> Session click a transaction request transaction details get session check permissions & session id request details for transaction transaction details transaction details update page Figure 38: View Financial s - Sequence Diagram 45

50 3.19 Sort Financial s The system allows for sorting of transactions. Any user of the system with viewing privileges can search for transactions. The sorting of all the tranactions can be based on any of the attributes saved for a transaction (as described in the SRS). User Presentation Layer Servlet Business Layer Session Data Layer DB Figure 39: Sort Financial s - Vertical Slice The user is presented with a list of all the transactions of a given account on the Account s Page. The list of transaction shows only the most relevant details of each transaction. The user can click a column of the list of transactions as per which the list of transactions should be sorted. All the sorting is done client side by the page s programming in the Web Browser. 46

51 User Web Browser user clicks the column header by which to sort sort transactions Figure 40: Sort Financial s - Sequence Diagram 47

52 3.20 Search s The system allows for searching of transactions. Any user of the system with viewing privileges can search for transactions. The search can be based on any of the attributes saved for a transaction (as described in the SRS). User Presentation Layer Search Servlet Business Layer Session Data Layer DB Figure 41: Search s - Vertical Slice On the Account s Summary page, the user is provided with a text field to input search criteria for transactions. As the user enters the search criteria in the field, the transaction list is updated with only the relevant transactions. The Search Servlet is given the search criterion entered by the user. The search servlet checks the privileges of the user to make sure the search request is from a valid user with viewing permissions. It then contacts the to give a list of transactions matching the given search criterion. The searches the database for all transactions matching the search criterion, and returns it to the the Search Servlet. The Search Servlet returns the transactions to the Web Browser which displays it to the user. 48

53 User Web Browser <<servlet>> Search Session submits search criteria search term get session check permissions get transactions matching search criteria transactions matching search criteria subset of transactions show short listed transactions Figure 42: Search s - Sequence Diagram 49

54 3.21 Generate Report The Generate Report feature allows a user to generate reports based on a time period that can be selected from the Report Generation GUI. The report generation also includes creation of graphs as well as reports. User Presentation Layer Report Servlet Business Layer Report Trend Data Layer DB Figure 43: Generate Report - Vertical Slice The Report Generation GUI allows a user to select the time period for which the user needs reports generated. The Report Servlet makes sure the session is valid and then requests the Reports for a report generation for the specified time period. The Reports in turn calls the to return all the transactions for the given time period. The Trend is then called to generate the data and calculations needed to perform for the report generation. The Reports then generates the entire report and graphs based on template report format. 50

55 User Web Browser <<servlet>> Report Session Reports Trends asks for a report get reports page get session check permissions show reports page request report for a period generate report for period get session check permissions request report generation for period get transactions for period transactions for given period generate report for transactions generated report generated report show generated reports Figure 44: Generate Report - Sequence Diagram 51

56 3.22 Configure Account Balance Trigger The Configure Account Balance Trigger feature allows a user to create an automatic trigger in case of Account Balance dropping below a certain limit. The database triggers a notification to be sent to the user to inform him in case the account balance drops. User Web Browser <<servlet>> Notification Trigger Notification user submits notification trigger information notification trigger information ref check user permissions & session id save trigger information success or failure [successful?] show confirmation msg alt [else] show error msg dispatch trigger Figure 45: Configure Account Balance Trigger - Sequence Diagram The Configure Account Balance Trigger GUI allows a certain balance amount to be set below which a trigger will be activated. This information is saved by calling the Notification which interacts with the database and sets the specific trigger. In case of the account balance dropping below the specified limit the database triggers the Notification which informs the user. 52

57 3.23 Lost User Name The system allows for the recovery of lost username based on registered address. Any user requesting his username is ed his username on his registered . User Presentation Layer Login Servlet Business Layer Data Layer Login User Acct Authentication Login Data Source DB DB Figure 46: Lost Username - Vertical Slice The user is presented with a link on the login page to request his username if he forgets it. The user clicks the appropriate link and the system notifies the user that the is sent. The browser meanwhile requests the Login Servlet to send the for the given . The Login Servlet then requests the Login to the lost username on the registered for the given address. The Login access the user account information in the database, and s the username to the user s registered address. 53

58 User Web Browser <<servlet>> Login Login UserAcct Database user requests lost username request lost username ref check user permissions & session id request sending lost username request sending lost username get username for notification sent Figure 47: Lost Username - Sequence Diagram 54

59 3.24 Lost Password The system allows for the recovery of lost password based on registered address. Any user requesting his password is ed his password on his registered . User Presentation Layer Login Servlet Business Layer Data Layer Login User Acct Authentication Login Data Source DB DB Figure 48: Lost Password - Vertical Slice The user is presented with a link on the login page to request his password if he forgets it. The user clicks the appropriate link and the system notifies the user that the is sent. The browser meanwhile requests the Login Servlet to send the for the given . The Login Servlet then requests the Login to the lost password on the registered for the given address. The Login access the user account information in the database, and s the password to the user s registered address Lost Password 55

60 User Web Browser <<servlet>> Login Login UserAcct ExternalDatabase user requests lost password request lost password ref check user permissions & session id request sending lost password request sending lost password send password reset for username notification sent message displayed Figure 49: Lost Password - Sequence Diagram 56

61 4 Database Design Comment associated with has History associated with FileAttachments has has Notification for Account has Label has applies to User has Permission related to Login Figure 50: Entity Relation Diagram The Entity Relation Diagram is a model of all the data that is kept in the database to satisfy all Priority 1 requirements of the system. This includes keeping records of all user acounts, financial accounts, the privileges for each user account to a corresponding financial account. The system keeps track of all transactions and all versions of each transaction. It also keeps data on registered notifications. 4.1 Account CREATE TABLE account ( id SERIAL PRIMARY KEY, ); name TEXT NOT NULL, account_number INTEGER NOT NULL, organization_name TEXT NOT NULL, description TEXT, -- optional is_active BOOLEAN NOT NULL 57