VODKA Software Design Descriptionyfcai/CS451/samples/DesignDocVodka.pdfSoftware Design Description...

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

Revision History

Name Date Reason for Changes Version

Archit Baweja, Drew Hall, SunnyHuynh, Kevin Lynch, and Kan-warpreet Sethi

17 Jan 2007 Initial Version 1.0

i

Contents

1 Introduction 11.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Definitions, Acronyms, and Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.4 Context Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Architecture 42.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Three-Tier Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3 Service-Oriented Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.4 Survey of Technologies Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.4.1 Data Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.4.2 Business Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.4.3 Presentation Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.5 Presentation Layer Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.5.1 Financial Account Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.5.2 Login Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.5.3 Notification Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5.4 Report Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5.5 Search Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5.6 Summary Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5.7 Transaction Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5.8 Transaction History Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5.9 User Account Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.5.10 View Account Servlet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.6 Business Layer Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.6.1 Attach File Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.6.2 Login Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.6.3 Logout Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.6.4 Report Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.6.5 Revert Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.6.6 Session Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.6.7 Trend Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.7 Data Layer Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.7.1 Financial Account Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.7.2 Notification Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.7.3 Transaction Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.7.4 User Account Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.8 External Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.8.1 Authentication Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.8.2 Email Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.8.3 Login Data Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.8.4 SMS Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Design Features 103.1 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2 External Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3 User Account Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.4 User Account Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.5 User Account Deactivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.6 Financial Account Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.7 Financial Account Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

ii

3.8 Financial Account Deactivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.9 Temporary Deactivation of Financial Account . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.10 Transaction Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.11 Transaction Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.12 Transaction Deactivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.13 Revert Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.14 Recover Deactivated Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.15 Comment on Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.16 Create Label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.17 View Account Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.18 View Financial Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.19 Sort Financial Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.20 Search Transactions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.21 Generate Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.22 Configure Account Balance Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 523.23 Lost User Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.24 Lost Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 553.25 Lost Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4 Database Design 574.1 Account . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.2 Label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.3 Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.4 Permission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.5 Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.6 Transaction History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.7 User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5 Summary 625.1 Advantages of Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.2 Disadvantages of Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625.3 Design Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

A Requirements Traceability Matrix 63A.1 Traceability by Requirement Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63A.2 Traceability by Design Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

iii

1 Introduction

1.1 Purpose

This document specifies the entire software architecture and design for the VODKA financial managementsystem. 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 financialaccounts of their student organizations in a simple and reliable manner. And the second goal is to provide acentralized tool by which the parent school may audit the student organizations. In order to provide thesetwo goals, the system focuses on simplicity, flexibility, security, accessibility, and scalability. For furtherdetail, 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, version1.0. The intended audience of this document exclusively includes the designers, the developers, and thetesters of the VODKA software system.

1.3 Definitions, Acronyms, and Abbreviations

AJAX A new emerging “standard” for web applications for dynamic content. AJAX communicates witha server to dynamically update only the necessary portions of a web page; this allows results to appearalmost instantly and additionally cuts down on network traffic. Most frameworks for web applicationdevelopment use AJAX and are written in a higher level language such as Java or ASP.NET to avoidbrowser compatibility problems with handwriting Javascript.

Audit An audit is an assessment of the accuracy by which a student organization’s financial statementsare presented.

Check Request A check request is a request for the parent school or university to issue a check for aspecified 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, authenticationand 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 onlypossible if there is no prior history associated with the account. In the case of a user account havingprior 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 everyorganization 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 lan-guage used for the creation of web pages.

HyperText Transfer Protocol (HTTP) The HyperText Transfer Protocol is the de facto standardprotocol communications protocol for World Wide Web applications.

Internet The Internet is a publicly accessible network of interconnected computer networks.

1

Internet Protocol (IP) The Internet Protocol is the standard communications protocol to distinguishcomputers connected over a network and to send data across the Internet.

Network A computer network is the interconnection of multiple computers using a telecommunicationssystem, 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 storedinformation when powered off.

Organization Advisor An Organization Advisor is a special user account provided for each organizationwith the privileges to create, to edit, to delete, and to view all comments, transactions, and useraccounts of the particular organization to which the advisor belongs. Each organization must have atleast, but not limited to, one advisor account.

Privilege The VODKAsoftware system limits user accounts from performing certain actions; whether auser 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 thesecategories. User privileges are specific to different parts of the software system.

Service-Oriented Architecture (SOA) A software architecture that uses software services as its maincomponents.

Simple Mail Transfer Protocol (SMTP) The Simple Mail Transfer Protocol is the de facto standardcommunications protocol for email transmission over a network.

Student Organization Officer Training (SOOT) At Drexel University, officers of student organiza-tions must attend annual training sessions, called Student Organization Officer Training, that explainthe policies and procedures involved in running student organizations. These policies and proceduresinclude 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 possibleprivileges available to any other user account as well as direct access to the underlying VODKAsoftwareprocesses and server(s). This person(s) should be the one(s) permitted to access the physical machinesrunning the VODKAsoftware system. The role of the system administrator is to perform systemmaintenance and configuration.

Transaction A transaction is any entry into a financial account that documents financial accountingpractives (e.g. recording a bank account deposit or pending check request).

Transmission Control Protocol (TCP) The Transmission Control Protocol is a very commonly usedcommunications protocol that guarantees transmission integrity over a network.

Transport Layer Security (TLS) The Transport Layer Security is a set of communication encryptionprotocols 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 VODKAsoftwaresystem uses to recognize individual users. Each user account is uniquely identified by a user name andallows the software to track individual user privileges.

Volatile Storage Volatile storage is a type of computer memory that requires power to retain the storedinformation. 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 andtextual web sites on the World Wide Web.

World Wide Web (WWW) The World Wide Web is network of interconnected documents on the In-ternet.

2

1.4 Context Diagram

The context diagram shown in figure 1.4 shows how the main components of the VODKA system fitsinto context with its external components. Each external component is distinguished by a shaded box.

VODKA Database

VODKAWeb Server

Web Browser

External Authentication

EmailSystem

SMS System

External Application

Figure 1: Context Diagram

VODKA’s business layer interacts directly with the external authentication system, email system, andSMS system. External application can be built that use the services provided by the VODKA business layer.

3

2 Architecture

TransactionService

Fin AcctService

User AcctService

DatabaseTriggers

NotificationService

DB

SessionService

LoginService

DB

LoginData Source

AuthenticationService

• • •EmailService

SMSService

User

LogoutService

LoginServlet

SummaryServlet

ReportService

TrendService

User AcctServlet

Fin AcctServlet

Trans HistoryServlet

ReportServlet

RevertService

TransactionServlet

Presentation Layer

Business Layer

Data Layer

View AcctServlet

Attach FileService

SearchServlet

NotificationServlet

Figure 2: Architecture Diagram

2.1 Overview

The general architecture of VODKA is a combination of the three-tiered and service-oriented architec-tures. This hybrid style allows for clear separation of concerns and creates loosly-coupled, reusable compo-nents. The architectural model showing the tiered separation and components of the system is in figure 2.Services 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 the1990s. This client/server architecture model promotes the separation of responsibilities into three distinctlayers. Each layer of the system depends only on the layer directly below it; layers may not depend on layersabove them.

The tiers, as shown in figure 2, are the presentation layer, business layer, and data layer. Componentsin the presentation layer handle interacting with the user, validating input data, and localization of data todisplay. Business layer components provide business logic and processing of data. Data layer componentsprovide access to the database.

4

Benefits of using this architectural style include increased performance, flexibility, maintainability, reusabil-ity, and scalability [2]. Since the software is expected to be deployed for use by hundred of student organi-zations, scalability is an important consideration.

2.3 Service-Oriented Architecture

Services in service-oriented architecture allow for loose-coupling in software design. This promotesreusability and flexibility to replace service components with new ones without impact on clients. Usingservice-oriented architecture also allows external applications to use services provided by the VODKA sys-tem. Service-oriented architecture aids VODKA’s flexibility for integration with other external components,such as external authenitcation systems.

2.4 Survey of Technologies Used

2.4.1 Data Layer

The data layer of the VODKA financial system has to fullfill various non-functional besides the obviousfunctional 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 whatwe 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 unmatchedstandards compliance, cost effectiveness. MySQL had similar attributes, it lacked in standards compliance,and Oracle lost out in cost of setup and maintaining the system.

2.4.2 Business Layer

The business layer runs Sun Microsystem’s GlassFish v1 web server using Java EE 5.0 and Java SE 6.0as the primary environment and programming language. The choice for programming language was decidedbased on Java’s success in commercial enterprise systems.

Alternative langauges considered were Ruby, PHP, C#, and ASP. Ruby on Rails was not chosen dueto 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 codemaintainence. C# using ASP.NET was not chosen because of it requires using Microsoft IIS and MicrosoftWindows. The Java environment has an advantage here because most Java-enabled web servers are freelyavailable and can be run on freely available operating systems. ASP was not chosen because it is a legacyframework, which Microsoft is phasing out.

Overall, the Java language and framework is one in which there exists a sufficient knowledge base withoutour team members, and it can be deployed onto many different environments (web servers and operatingsystems). For the development purposes, GlassFish is chosen to be the web server since it is the refernceimplementation for Java EE 5.0. Other web servers considered were Apache Tomcat and JBoss. The currentstable versions of both JBoss and Apache Tomcat do not fully support Java EE 5.0; Apache Tomcat has a

5

beta version that supports it but the beta version may contain undocumented bugs. Therefore, GlassFishwas 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.0was chosen because of its simplified implementation of web services over Java2 EE 1.4 and its support forthe Java SE 6.0 programming language. The WS-* set of standards were chosen for its enhanced securityand interoperability over prior web service standards.

2.4.3 Presentation Layer

The presentation layer of VODKA must fulfill several system requirements. VODKA was envisioned as athin client that is accessible by potentially any computer that can communicate with the server. Users mustbe able to quickly and securely access pertinent data with very short load times. Additionally, changes tothe system can be easily made without forcing users to upgrade; simply refreshing the browser will updatethe client system for the clients.

There are many ways the presentation layer can be implemented. Traditionally static webpages weregenerated by an application on the server. Communication between the client and the server was performedthrough HTML ”POST” operations which relay response data to the serving application. Though thisapproach is certainly feasible—and straightforward to implement—it does not feel natural because it doesnot allow for dynamic content. That is, a new page must be reloaded after each operation; a dynamic clientwould 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 thepages 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. Thetoolkit provides not only a dynamic user interface but also ways to easily manage history, cookies, andremote procedure calls. The code is written in a subset of Java 1.4 and is translated to Javascript usingthe GWT Compiler. The GWT Compiler handles differences in Javascript implementations, allowing thecode 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 isthat 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 onan 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 themodel, view, and control components of the MVC paradigm is very clean. Because of its focus on separationof logics, VODKA uses Potix Corporation’s the ZK Framework to assist in presenting information to theuser.

2.5 Presentation Layer Components

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

2.5.2 Login Servlet

Requirements Satisfied: 0470, 0480, 0490, 0500, 0510, 1390, 1400, 1410, 1420, 1430, 1440, 1450The 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 browserto the welcome page.

6

2.5.3 Notification Servlet

Requirements Satisfied: 1220, 1230, 1240, 1245, 1250, 1260, 1270The Notification Servlet provides an interface for the user client to configure notifications for their Fi-

nancial Accounts. This servlet is responsible to validate input and output to the client.

2.5.4 Report Servlet

Requirements Satisfied: 1170, 1180, 1190, 1200, 1210The Report servlet is responsible for marrying the user client with the Reports Service. It passes the

messages and data between the two to provide VODKAgenerated reports for the user.

2.5.5 Search Servlet

Requirements Satisfied: 1150The search servlet is responsible for messages and data sent between the user client and the Financial

Accounts Service. The servlet checks the format of the data.

2.5.6 Summary Servlet

Requirements Satisfied: 1160The Summary Servlet is responsible for gathering and formatting the data for the summary page for the

user client.

2.5.7 Transaction 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 Transaction Servlet is responsible for providing the interface for the user client to view, sort, andmodify transactions. It interfaces with the Financial Account Service and the User Account Service.

2.5.8 Transaction History Servlet

Requirements Satisfied: 1090, 1100, 1110The Transaction History Servlet is responsible for handling the messages and actions to view transaction

history. It interfaces with the Financial Account Service.

2.5.9 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 AccountService. It is responsible for checking for valid requests and responses.

2.5.10 View Account Servlet


The View Account Servlet is responsible for sending and retrieving data between the user client and theFinancial Account Service. It also validates the data and format of messages.

7

2.6 Business Layer Components

2.6.1 Attach File Service

Requirements Satisfied: 1060The Attach File Service provides a method for attaching files to transactions. This service interactes

with the Transaction Service to attach the files if the user’s session is active and has the correct permissionsto modify the transaction.

2.6.2 Login Service

Requirements Satisfied: 0470, 0480, 0490, 0500, 0510, 1280, 1290, 1300, 1310, 1320, 1330, 1340, 1350,1390, 1400, 1410, 1420, 1430, 1440, 1450

The Login Service provides all the methods and actions for the VODKAsystem to validate a user inthe VODKAsystem. This service interacts with the User Account Service and External AuthenticationService. It provides the following actions: security warnings to administrators via e-mail, authenticatinguser password, and validating user as a VODKAuser.

2.6.3 Logout Service

Requirements Satisfied: 1450The Logout Service provides VODKAwith the methods and actions to initiate the process of user account

logout. It interfaces specifically with the Session Service.

2.6.4 Report Service

Requirements Satisfied: 1170, 1180, 1190, 1200, 1210The Report Service is used to generated financial reports and graphs for the specified Financial Account.

The Report Service generates report information on transactions in an easy to read format. Additionally, itgenerates graphs that represent current transactions and formats data from the Trend Service into a graph.

2.6.5 Revert Service

Requirements Satisfied: 1110The Revert Service 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.

2.6.6 Session Service

Requirements Satisfied: 1390, 1400, 1410, 1420, 1430, 1440, 1450The Session Service 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 deletionof sessions, which can only be performed by the Login and Logout Services. It also automatically logs outinactive users.

2.6.7 Trend Service

Requirements Satisfied: 1200, 1210The Trend Service 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

2.7.1 Financial Account Service

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

8

The Financial Account Service handles all actions related to financial accounts in the VODKAsystem.This includes creation, modification and deactivation of financial accounts. It also provides informationrelated to a financial account such as account balance, and related transactions of a financial account.

2.7.2 Notification Service

Requirements Satisfied: 1220, 1230, 1240, 1245, 1250, 1260, 1270The Notification Service 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 Service can also be configured to notifyusers of account activity like posting of new transactions, posting of new comments to transactions, etc.

2.7.3 Transaction Service


The Transaction service is responsible for querying the database to retreive all transactions related to aspecific financial account. It is also responsible for creation, modification and deletion of transactions. Italso handles labelling transactions and posting comments to transactions. The Transaction Service is alsocalled when information on a particular transaction is required.

2.7.4 User Account Service

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 Service handles all the actions related to user accounts in the VODKAsystem. Itis resposible for creation, modification, and deactivation of user accounts. It interacts directly with thedatabase to provide data to all servlets that request it.

2.8 External Components

2.8.1 Authentication Service

Requirements Satisfied: 0140, 0150, 0160, 0170The Authentication Service 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.

2.8.2 Email Service

Requirements Satisfied: 0100, 0110, 0120, 0130, 1230, 1380The Email Service provides methods for sending email messages to a user if certain events are triggered.

Events can include, for example, funds in an account falling below a specific threshold.

2.8.3 Login Data Source

Requirements Satisfied: 0140, 0150, 0160, 0170The 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.

2.8.4 SMS Service

Requirements Satisfied: 1230The SMS Service 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

3 Design Features

3.1 Login

The Login feature allows a user to login providing a valid username and password combination. It alsoprevents deactivated users from logging in to the system.

User AcctService

DB

SessionService

LoginService

DB

LoginData Source


User

LoginServlet

Presentation Layer

Business Layer

Data Layer

Figure 3: Login - Vertical Slice

The Login process first takes the username entered by the user and checks to make sure it is a validusername. If it is, the username and password combination is passed over to the Authenticate Service. Onsuccessful authentication, the Login Service gets the user privilege type from the User Account Service. Itthen proceeds to create a new unique session for the user using the Session Service.

10

alt

alt

Web Browser <<servlet>>

Login

<<service>>

Login

<<service>>

UserAcct

<<service>>

Authenticate

Login Data

Source

<<service>>

Session

login(user, password)


check valid user name

deny login

render page

deny login


get login info

authenticate

deny login

deny login

render page

deny login

approve login

get user privileges

create-session(user, priveleges)

approve login

redirect to welcome page

User

click login button

[invalid user name]

[else]

[authentication failed]

[else]

Figure 4: Login - Sequence Diagram

11

3.2 External Authentication

The External Authentication Feature autheticates a VODKAuser with an external database. This isused when the default VODKAauthetication system is not used and all users are verified using an externalauthentication system.

DB

LoginData Source


Figure 5: External Authentication - Vertical Slice

The login service encrypts the user’s username and password information and transfers it to the externalauthentication system. The external authentication system uses its own verification service to autheticatethe user against its own database. The result is then passed back to the VODKALogin Service and the useris informed of success or failure.

12

<<service>>

Authenticate

Login

Data Source

Database


get user record

encrypt password

get user record

compare user, password

login result

Service Client

Figure 6: External Authentication - Sequence Diagram

13

3.3 User Account Creation

The User Account Creation feature allows for the creation of a new User Account. A new User Accountmay only be created by users with specific privileges. Creating a new user account requires the followinginformation:

• Username

• Password

• Name

• Email Address

• User Account Type

• Accessible Financial Accounts

• Financial Account Privileges

User AcctService

DB

SessionService

User

User AcctServlet

Presentation Layer

Business Layer

Data Layer

Figure 7: User Account Creation - Vertical Slice

The Create User Account GUI extracts all the information entered for creating a new user account andsends it to the User Account Servlet. The Servlet checks the data for consistency and checks the user accountfor the required privileges. The data is then passed over to the User Account Service which interacts withthe database to create the new user account.

14

alt

alt

User�eb Browser <<servlet>>

UserAcct

<<service>>

Session

<<service>>

UserAcct

redirect to login page

load

get session

[invalid session or privileges]

check permissions

render page

[else]

enter account info

click confirm button

create account

get session

check permissions


[else]


create account


external create user

accountref

Figure 8: User Account Creation - Sequence Diagram

15

3.4 User Account Modification

The system allows the modification of any attribute of a user account. A user can change the user accountattributes for his own user account. A Finance Manager and Organization Advisor can also change the useraccount of the users in the financial accounts

User AcctService

DB

SessionService

User

User AcctServlet

Presentation Layer

Business Layer

Data Layer

Figure 9: Modify User Account - Vertical Slice

A user of the system can modify only his own user account settings like name, email etc. On thePreferences page when the user submits his new information for his user account, the web browser sends therequest to modify the user account information to the UserAcct Servlet. The UserAcct Servlet checks to seethe if the client making the request has a valid session id and privileges. If that is the case, the UserAcctServlet requests the UserAcct Service to modify the given user account’s information in the database. TheUserAcct Service modifies the transaction in the database an returns a status on if the modification wassuccessful. Based on this the UserAcct Servlet updates the user’s webpage if the modification was successful.

16

alt

User Web Browser <<servlet>>

UserAcct

<<service>>

UserAcct

modify user account

check user permissions

& session idref

Database

modify user account

[successful?]

[else]

show operation confirmation

modify user account

modify user account

show error message

successStatus

Figure 10: Modify User Account - Sequence Diagram

17

3.5 User Account Deactivation

Users with Finance Manager & Organization Advisor privleges can deactivate a user account. Deac-tivation doesn’t lead to complete deletion. This is so that the user accounts can be re-activated in thefuture.

DB

User

Presentation Layer

Business Layer

Data Layer

User Acct

Servlet

Session

Service

User Acct

Service

Transaction

Service

Figure 11: User Account Deactivation - Vertical Slice

A Finance Manager or a Organization Advisor can select a user’s account to deactivate. The web browsersends the request to deactivate to the UserAcct Servlet. The UserAcct Servlet first checks the session idand permissions of the client making the request for deactivation, to make sure if its valid. If so, theUserAcct checks the number of transactions created by the user account to be deactivated. If the numberof transactions created by the user account to be deactivated is 0, the user accout is deleted. Otherwise,the UserAcct Servlet requests the UserAcct Service to deactivate the user account. The UserAcct Servicenotifies the UserAcct Servlet if the deactivation was successful or not. The UserAcct Servlet accordinglyupdates the user’s web page to display if the deactivation was successful or not, and if the user account wasdeactivated or deleted.

18

alt

�eb Browser <<servlet>>

UserAcct

<<service>>

Session

<<service>>

Authenticate

Login

Data Source

Database

alt


load

get session


check permissions

render page

[else]

User

click delete

delete account

get session

check permissions

alt


[else]


delete account

<<service>>

Transaction

get transactions by user

[no transactions]

delete user

delete user

delete user

disable user

Figure 12: User Account Deactivation - Sequence Diagram

19

3.6 Financial Account Creation

Financial Account Creation feature allows a user to create a new financial account. Only users withsufficient privileges in the VODKAsystem are allowed to use this feature. Each new financial account has aunique account number that defines it. Creating a new financial account asks a user to enter the followinginformation:

• Account Number

• Account Name

• Comments/Description

• Associated Student Organization

DB

User

Presentation Layer

Business Layer

Data Layer

Fin Acct

Servlet

Session

Service

Fin Acct

Service

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 transfersit to the Financial Account Servlet. The Servlet checks to confirm if the user has sufficient privileges. TheServlet checks the data for consistency and formatting and checks for Account Number and Account Nameas they are mandatory fields. If everything is consistent and passes checks, the data is transfered to theFinancial Account Service. The Service interacts with the Database and creates the new account.

20

alt

alt

�� Web ��FinAcct

<<service>>

Session

<<service>>

FinAcct


load

get session


check permissions

render page

[else]

enter account info

click confirm button

create account

get session

check permissions


[else]


create account


Database

create account

Figure 14: Financial Account Creation - Sequence Diagram

21

3.7 Financial Account Modification

The Financial Account Modification feature allows users to modify the properties related to an existingfinancial 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 havesufficient privileges to make any modifications to an existing financial account.

DB

UserPresentation Layer

Business Layer

Data Layer

Fin Acct

Servlet

Session

Service

Fin Acct

Service

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 havea proper formatted value:

• Account Name

The Modify Financial Account GUI extracts the modified data and transfers it to the Financial AccountServlet. The Servlet checks to make sure that the user has the required privileges. If the privileges meet therequirements, the data is checked for consistency and is passed on to the Financial Account Service. TheService interacts with the database and makes the modifications needed.

22

alt

FinancialManager Web Browser <<servlet>>

FinAcct

<<service>>

FinAcct


& session idref

submit new fin acct data

success or failure

user request fin acct

editing page

user submits new data

for fin acct

change fin acct data

[successfull?]

[else]

show confirmation

show reason for

no modification

Database

change fin acct data

Figure 16: Financial Account Creation - Sequence Diagram

23

3.8 Financial Account Deactivation

The Financial Account Deactivation feature allows a user with sufficient privileges to deactivate a financialaccount. 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 hashistory associated with it, it is only disabled and never deleted.

DB

User

Presentation Layer

Business Layer

Data Layer

Fin Acct

Servlet

Session

Service

Fin Acct

Service

Figure 17: Financial Account Deactivation - Vertical Slice

The Financial Account Deactivation GUI sends the user’s request to deactivate an existing financialaccount to the Financial Account Servlet. The Financial Account Servlet makes sure the user permissionrequirements are met. It then requests a transaction history from the Financial Account Service for therequested financial account. If the Service returns a transaction history for the financial account then it isdisabled by calling the Financial Account Service. On the other hand if there is no history returned, thefinancial account is deleted.

24

alt


FinAcct

<<service>>

FinAcct

selects fin account name

to be deactivated


& session idref

fin account to

be deactivated

[no trasnactions]

[else]

get transaction for fin acct

delete fin acct

disable

show confimation message

Figure 18: Financial Account Deactivation - Sequence Diagram

25

3.9 Temporary Deactivation of Financial Account

The Temporary Deactivation of Financial Account feature is used to temporarily disable a financialaccount in the case of a violation of the university’s policies. Only users with sufficient privileges are allowedto use this feature.

DB

User

Presentation Layer

Business Layer

Data Layer

View AcctServlet

Session

Service

Transaction

Service

Fin Acct

Service

Figure 19: Temporary Deactivation of Financial Account - Vertical Slice

The Temporary Deactivation GUI sends the user’s request to deactivate an existing financial account tothe Financial Account Servlet. The Financial Account Servlet makes sure the user permission requirementsare met. It then proceeds to call the Financial Account Service to disable the financial account.

26

alt


FinAcct

<<service>>

FinAcct

selects fin account name

to be deactivated


& session idref

fin account to

be deactivated

[no trasnactions]

[else]

get transaction for fin acct

delete fin acct

disable

show confimation message

Figure 20: Temporary Deactivation of Financial Account - Sequence Diagram

27

3.10 Transaction Creation

The system allows the creation of new transaction. Any user with account modification privileges cancreate transactions.

DB

User

Presentation Layer

Business Layer

Data Layer

Transaction

Servlet

Transaction

Service

Session

Service

Figure 21: Create Financial Transactions - Vertical Slice

Any user with account modification privelges can create transactions. The user must enter all non-optional attributes of a new transaction. After the user clicks the submission button on the page, the dataentered is sent by the Web Browser to the Transaction Servlet. The Transaction Servlet checks the session idand if the user has account modification privileges. If it is so, the Transaction Servlet tells the TransactionService to add the new transaction to the database. The Transaction Service adds the transaction to thedatabase and returns a operation status. If the transaction creation is successful, the Transaction Servletupdates the web page tell the user the transaction was created and adds it to the list of transactions on theAccount Transactions Summary page. If the transaction creation is not successful, the user is given an errormessage explaining why the transaction creation was unsuccessful

28

�� Web Browser <<ser

Transaction

<<service>>

Transaction

user enters transaction

information on the page


& session idref

create new transaction

[successful?]

[else]

show user confirmation

create new transaction

success or failure

show user error

message why

alt

Figure 22: Create Financial Transactions - Sequence Diagram

29

3.11 Transaction Modification

The system allows the modification of any attribute of a transaction. Only users with account modificationprivileges can modify transactions.

DB

User

Presentation Layer

Business Layer

Data Layer

Transaction

Servlet

Transaction

Service

Session

Service

Figure 23: Modify Financial Transactions - Vertical Slice

The user is presented with a list of all the transactions of a given account on the Account TransactionsPage. The user can click the modify button for a transaction to modify it. The browser then send therequest to modify the transaction to the Transaction Servlet. The Transaction Servlet checks if the clientmaking the request for details of the transaction has account modification privileges. The Transaction Servletthen forwards the request to the Transaction Service to modify the transaction. The Transaction Servicemodifyies the transaction in the database and returns a status on if the modification was successful. Basedon this the Transaction Servlet updates the user’s webpage if the modification was successful.

30

alt

�� e <<servlet>>

Transaction

<<service>>

Transaction

modify transaction


& session idref

Database

modify transaction

[successful?]

[else]


modify transaction

modify transaction

show error message

successStatus

Figure 24: Modify Financial Transactions - Sequence Diagram

31

3.12 Transaction Deactivation

The system allows for the deactivation of a transaction. Any user with account modification privilegescan deactivate a transaction.

DB

User

Presentation Layer

Business Layer

Data Layer

Transaction

Servlet

Transaction

Service

Session

Service

Figure 25: Deactivate Financial Transactions - Vertical Slice

The user is presented with a list of all the transactions of a given account on the Account TransactionsPage. The user can click the deactivate button for a transaction to deactivate it. The browser then sendthe request to deactivate the transaction to the Transaction Servlet. The Transaction Servlet checks if theclient making the request for details of the transaction has account modification privileges. The TransactionServlet then forwards the request to the Transaction Service to deactivate the transaction. The TransactionService deactivates the transaction in the database and returns a status on if the deactivation was successful.Based on this the Transaction Servlet updates the user’s webpage if the deactivation was successful.

32

alt


Transaction

<<service>>

Transaction

deactivate transaction


& session idref

Database


[successful?]

[else]




show error message

successStatus

Figure 26: Deactivate Financial Transactions - Sequence Diagram

33

3.13 Revert Transaction

The system allows to revert a modified transaction to its previous form. Only users with account modi-fication privileges can revert transactions.

DB

User

Presentation Layer

Business Layer

Data Layer

Transaction

Servlet

Transaction

Service

Session

Service

Figure 27: Revert Financial Transactions - Vertical Slice

The user is presented with a list of all the changes made to a transaction of a given account. The usercan click the revert button on a specific history to become the current one. The browser then send therequest to revert the transaction to the Transaction Servlet. The Transaction Servlet checks if the clientmaking the request to revert the transaction has account modification privileges. The Transaction Servletthen forwards the request to the Transaction Service to revert the transaction. The Transaction Servicereverts the transaction in the database and returns a status on the operation. Based on this the TransactionServlet updates the user’s webpage if the transaction was reverted.

34

alt


Transaction

<<service>>

Transaction

revert transaction


& session idref

Database

revert transaction

[successful?]

[else]


revert transaction

revert transaction

show error message

successStatus

Figure 28: Revert Financial Transactions - Sequence Diagram

35

3.14 Recover Deactivated Transaction

The system allows to revert a deactivated transaction. Only users with account modification privilegescan revert transactions.

DB

User

Presentation Layer

Business Layer

Data Layer

Transaction

Servlet

Transaction

Service

Session

Service

Figure 29: Revert Deactivated Financial Transactions - Vertical Slice

The user is presented with a list of all the deactivate transaction when the user requests it. The user canthen ask for reverting a deactivated transaction The browser then sends the request to revert the deletedtransaction to the Transaction Servlet. The Transaction Servlet checks if the client making the request torevert the deleted transaction has account modification privileges. The Transaction Servlet then forwards therequest to the Transaction Service to revert the transaction. The Transaction Service reverts the transactionin the database and returns a status on the operation. Based on this the Transaction Servlet updates theuser’s webpage if the deleted transaction was reverted.

36

alt


Transaction

<<service>>

Transaction

revert deactivated transaction


& session idref

Database


[successful?]

[else]




show error message

successStatus

Figure 30: Revert Deactivated Financial Transactions - Sequence Diagram

37

3.15 Comment on Transaction

The system allows the modification of any attribute of a transaction. Only users with account modificationprivileges can comment-on transactions.

DB

User

Presentation Layer

Business Layer

Data Layer

Transaction

Servlet

Transaction

Service

Session

Service

Figure 31: Comment On Financial Transactions - Vertical Slice

The user is presented with a list of all the transactions of a given account on the Account TransactionsPage. The user can edit a transaction to comment on it. The browser then sends the request to comment onthe transaction to the Transaction Servlet. The Transaction Servlet checks if the client making the requestfor details of the transaction has account modification privileges. The Transaction Servlet then forwards therequest to the Transaction Service to comment on the transaction. The Transaction Service comment onthe transaction in the database and returns a status on if the modification was successful. Based on this theTransaction Servlet updates the user’s webpage if the modification was successful.

38

alt


Transaction

<<service>>

Transaction

comment on transaction


& session idref

Database


[successful?]

[else]




show error message

successStatus

Figure 32: Comment On Financial Transactions - Sequence Diagram

39

3.16 Create Label

The Create Label feature allows a user to create labels for transactions which can be then used tocategorize transactions. Each transaction can have multiple labels applied to it.

DB

User

Presentation Layer

Business Layer

Data Layer

Transaction

Servlet

Transaction

Service

Figure 33: Create a Label for Transactions - Vertical Slice

The user submits a label to be applied to a transaction which calls the Transaction Servlet. The trans-action servlet checks for a valid session and then calls the transaction service to save the label to the relatedtransaction. The user is notified of success or failure.

40


Transaction

<<service>>

Transaction


& session idref

save the label for transaction

[successful?]

[else]

user submits label for transactions

save the label for transaction

success or failure

notify added

notify not added with reason

alt

Figure 34: Create a Label for Transactions - Sequence Diagram

41

3.17 View Account Summary

The View Account Summary feature is used to display a summary of all the financial accounts that auser account has access to. It allows the user to view all the balances associated with each financial accountalso.

DB

User

Presentation Layer

Business Layer

Data Layer

SummaryServlet

SessionService

Fin AcctService

Figure 35: View Account Summary - Vertical Slice

On successful login, the Login Service calls the Summary Servlet as it needs to display all the financialaccounts associated with the user account. The Summary Servlet passes the user account information to theUser Account Service. The User Account Service interacts with the database and returns the list of financialaccounts that the user has access to. This list of accounts is then passed to the Financial Account Servicewhich retreives the Account Balance field related to each of them. This summary is then displayed as themain page on user login.

42


Summary

<<service>>

Session

<<service>>

FinAcct

load

get session

check permissions

get accounts

allTheAccounts

show account summary page

Figure 36: View Account Summary - Sequence Diagram

43

3.18 View Financial Transactions

The system allows the viewing of all the details of all transactions. Any user with sufficient viewingprivileges can view all the details of a transaction.

DB

User

Presentation Layer

Business Layer

Data Layer

Transaction

Servlet

Transaction

Service

Session

Service

Figure 37: View Financial Transactions - Vertical Slice

The user is presented with a list of all the transactions of a given account on the Account TransactionsPage. The list of transaction shows only the most relevant details of each transaction. The user can click atransaction to obtain all the details of the transaction. When the user clicks a transaction the web browsersends a request to the Transaction Servlet to get all the details of the given transaction. The TransactionServlet checks if the client making the request for details of the transaction has viewing privileges and thenreturns the transaction’s details. The Transaction Servlet gets the transaction details, and returns it to theWeb Browser to display all the transaction details.

44


Transaction

<<service>>

Session

<<service>>

Transaction

request transaction details

get session

click a transaction

request details for transaction

transaction details

transaction details

check permissions

& session id

update page

Figure 38: View Financial Transactions - Sequence Diagram

45

3.19 Sort Financial Transactions

The system allows for sorting of transactions. Any user of the system with viewing privileges can searchfor transactions. The sorting of all the tranactions can be based on any of the attributes saved for atransaction (as described in the SRS).

DB

User

Presentation Layer

Business Layer

Data Layer

Transaction

Servlet

Transaction

Service

Session

Service

Figure 39: Sort Financial Transactions - Vertical Slice

The user is presented with a list of all the transactions of a given account on the Account TransactionsPage. The list of transaction shows only the most relevant details of each transaction. The user can click acolumn of the list of transactions as per which the list of transactions should be sorted. All the sorting isdone client side by the page’s programming in the Web Browser.

46

User Web Browser

user clicks the column

header by which to sort

sort transactions

Figure 40: Sort Financial Transactions - Sequence Diagram

47

3.20 Search Transactions

The system allows for searching of transactions. Any user of the system with viewing privileges can searchfor transactions. The search can be based on any of the attributes saved for a transaction (as described inthe SRS).

DB

User

Presentation Layer

Business Layer

Data Layer

Search

Servlet

Transaction

Service

Session

Service

Figure 41: Search Transactions - Vertical Slice

On the Account Transactions Summary page, the user is provided with a text field to input search criteriafor transactions. As the user enters the search criteria in the field, the transaction list is updated with onlythe relevant transactions. The Search Servlet is given the search criterion entered by the user. The searchservlet checks the privileges of the user to make sure the search request is from a valid user with viewingpermissions. It then contacts the Transaction Service to give a list of transactions matching the given searchcriterion. The Transaction Service 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 Browserwhich displays it to the user.

48


Search

<<service>>

Session

<<service>>

Transaction

get session

check permissions

submits search criteria

search term

get transactions matching search criteria

transactions matching search criteria

subset of transactions

show short listed transactions

Figure 42: Search Transactions - Sequence Diagram49

3.21 Generate Report

The Generate Report feature allows a user to generate reports based on a time period that can be selectedfrom the Report Generation GUI. The report generation also includes creation of graphs as well as reports.

DB

User

Presentation Layer

Business Layer

Data Layer

ReportServlet

ReportService

TrendService

TransactionService

Figure 43: Generate Report - Vertical Slice

The Report Generation GUI allows a user to select the time period for which the user needs reportsgenerated. The Report Servlet makes sure the session is valid and then requests the Reports Service for areport generation for the specified time period. The Reports Service in turn calls the Transaction Service toreturn all the transactions for the given time period. The Trend Service is then called to generate the dataand calculations needed to perform for the report generation. The Reports Service then generates the entirereport and graphs based on template report format.

50


Report

<<service>>

Session

<<service>>

Reports

get reports page

get session

check permissions

request report for a period

asks for a report

show reports page

generate report for period

get session

check permissions

<<service>>

Trends

<<service>>

Transaction

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

3.22 Configure Account Balance Trigger

The Configure Account Balance Trigger feature allows a user to create an automatic trigger in case ofAccount Balance dropping below a certain limit. The database triggers a notification to be sent to the userto inform him in case the account balance drops.

<<service>>

Trigger

alt


Notification


& session idref

<<service>>

Notification

[successful?]

[else]

success or failure

user submits

notification trigger informationnotification trigger information

save trigger information

show confirmation msg

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 atrigger will be activated. This information is saved by calling the Notification Service which interacts withthe database and sets the specific trigger. In case of the account balance dropping below the specified limitthe database triggers the Notification Service which informs the user.

52

3.23 Lost User Name

The system allows for the recovery of lost username based on registered email address. Any user requestinghis username is emailed his username on his registered email.

DB

User

Presentation Layer

Business Layer

Data Layer

LoginServlet

LoginService

DB

LoginData Source


User AcctService

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 userclicks the appropriate link and the system notifies the user that the email is sent. The browser meanwhilerequests the Login Servlet to send the email for the given email. The Login Servlet then requests the LoginService to email the lost username on the registered email for the given email address. The Login Serviceaccess the user account information in the database, and emails the username to the user’s registered emailaddress.

53


Login

<<service>>

Login

user requests lost username


& session idref

<<service>>

UserAcct

request lost username

Database

request sending

lost username email

email notification sent

request sending

lost username email get username

for email

Figure 47: Lost Username - Sequence Diagram

54

3.24 Lost Password

The system allows for the recovery of lost password based on registered email address. Any user requestinghis password is emailed his password on his registered email.

DB

User

Presentation Layer

Business Layer

Data Layer

LoginServlet

LoginService

DB

LoginData Source


User AcctService

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 userclicks the appropriate link and the system notifies the user that the email is sent. The browser meanwhilerequests the Login Servlet to send the email for the given email. The Login Servlet then requests the LoginService to email the lost password on the registered email for the given email address. The Login Serviceaccess the user account information in the database, and emails the password to the user’s registered emailaddress.

3.25 Lost Password

55


Login

<<service>>

Login

user requests lost password


& session idref

<<service>>

UserAcct

request lost password

ExternalDatabase

request sending

lost password email

email notification sent

message displayed

request sending

lost password email send password reset

email for username

Figure 49: Lost Password - Sequence Diagram

56

4 Database Design

User

Account

Transaction

Permission

TransactionHistory

Label

Comment

has

applies to

has

associated

with

has

Login

related to

has

hasNotification

has

for

FileAttachmentsassociated

with

Figure 50: Entity Relation Diagram

The Entity Relation Diagram is a model of all the data that is kept in the database to satisfy allPriority 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 alltransactions 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

The account table keeps records of all financial accounts in the system. For each financial account wekeep the following information

• id - a unique id for each organization

• acccount number - the account number for the student organization which has this financial account

• organization name - the name of the student organization which has this financial account

• description - a column which holds an optional description for this financial account.

• is active - defines whether this is an active financial account or not.

4.2 Label

-- Labels, used to categorize transactions.

CREATE TABLE labels (


label_value TEXT NOT NULL,

account_id INTEGER REFERENCES accounts

);

The labels table keeps a track of all valid labels for assigning to transactions for a given financial account.For this purpose it stores the following data for each table.

• id - a unique identifier for each label.

• label value - the value of the label.

• account id - a reference to a financial account id in the accounts table which has this label.

4.3 Notification

-- registered notifications for a user.

CREATE TABLE notifications (


notification_type INTEGER REFERENCES notification_types,

user_id INTEGER REFERENCES users,


);

-- Enumeration: EMAIL, SMS

CREATE TABLE notification_types (


notification_type TEXT NOT NULL

);

The notifications and notification types table keep track of all registered database notifications for allusers in the system. Whenever a user registers a email notification for balance change for an associatedfinancial account, a record is created in the notifications table. The table keeps track of the following datafor each notification

• id - a unique id to identify this record

• notification type - a reference to the enumeration table notification types which defines what kind ofnotification this record defines

• user id - the user id of the user who registered this notification

• account id - the account id of the financial account which this notification referes to.

58

4.4 Permission

-- what kind of access does a user have for a particular account

CREATE TABLE permissions (


account_id INTEGER REFERENCES accounts,

can_view BOOLEAN NOT NULL,

can_modify BOOLEAN NOT NULL,

is_advisor BOOLEAN NOT NULL,

is_financial_advisor BOOLEAN NOT NULL

PRIMARY KEY (user_id, account_id)

);

The permissions table defines the previliges a user is granted for accessing and modifying records of afinancial account. The combination of the user id and account id uniquely determine a record in this table.The table keeps the following data to define user access/modification privileges for a user and a correspondingfinancial account.

• user id - a reference to the user id in the users table for which this record defines access rights.

• account id - a reference to the account id in the accounts table for which this record defines a user’sprivileges

• can view - a boolean attribute which defines if the user with the user id has privileges to view thetransactions in the account with the account id

• can modify - a boolean attribute which defines if the user with the user id has privileges to modify thetransactions in the account with the account id

• is advisor - a boolean attribute which defines if the user with the user id is the organization advisorfor the account with the account id

• is financial advisor - a boolean attribute which defines if the user with the user id is the financialadvisor for the account with the account id

4.5 Transaction

CREATE TABLE transactions (

id SERIAL PRIMARY KEY


);

The transactions table stores the transaction id’s of the transactions. It also stores the financial account idfor which the transaction is for. This column references the account id in the accounts table listed above.The transaction id refers to the latest revision of a transaction in the transaction histories table listed in thenext sub-section.

4.6 Transaction History

CREATE TABLE transaction_histories (

id INTEGER REFERENCES transactions,

version INTEGER NOT NULL,

check_number INTEGER, -- (if applicable)

date_and_time DATE NOT NULL,

payee TEXT NOT NULL,

59

description TEXT NOT NULL,

amount INTEGER NOT NULL,

comment TEXT, -- optional

source_account_id INTEGER REFERENCES accounts,

destination_account_id INTEGER, -- (if applicable)

reconciliation_status BOOLEAN NOT NULL,

timestamp TIMESTAMP NOT NULL,


change_type INTEGER REFERENCES transaction_change_types

PRIMARY KEY (id, version)

);

The transaction histories table stores all the transactions along with all revisions of every transaction inthe system. As shown primary key of this table is the combination of the id and version columns.

It has the following columns

• id - an unique id for different transactions. This references the

• version - a unique id

• check number - an optional data column which keeps the check number associated with this transaction.

• date and time - this column records the date and time of creation of this transaction record

• payee - this column records the name of the person or establishment who payed for this transaction

• description - a short description of the nature of the transaction

• amount - the amount of money involved with this transaction.

• comment - an optional comment which users can add.

• source account id - the account number of the source account for this transaction

• destination account id - the account number of the destination account for this transaction

• reconciliation status - this columns records if this transaction has been reconciled

• timestamp - the timestamp of creation of this transaction revision

• user id - this column references the user id in the users table of the user who created this revision.

• change type - this column references the table transaction change types which defines the various kindsof changes that are applicable in a version of the transaction.

CREATE TABLE transaction_change_types (


change_type TEXT NOT NULL

);

The transaction change types tables is an enumeration for the different kinds of changes that are appli-cable for a transaction version.

60

4.7 User

-- all the users in the system

CREATE TABLE users (


name VARCHAR(20) NOT NULL, -- as per requirement 0300

email VARCHAR(60) NOT NULL, -- as per requirement 0320

login_id INTEGER REFERENCES logins,

is_active BOOLEAN NOT NULL

);

The users table keeps records of all registered users in the system. On notable exception is the absenceof the password data which is kept in another more secure database, usually external to the system andmaintained by the target university. The users table keeps the following data for each user account

• id - a unique id identifying each user account record.

• name - the name of the user this user account belongs to

• login id - the username of the user with which the user identifies himself/herself to the system.

• is active - this column defines if this user account record is currently active, or deactivated.

61

5 Summary

5.1 Advantages of Design

The chosen archtecture and design are advantageous to VODKA as they allow for maximum configura-bility and maintenance of the system. Though these are major goals for nearly every system, VODKA guar-antees flexibility in configuration with the use of distributed web services. This modularity allows VODKAto be flexible enough to support very demanding systems that span multiple servers or small enough to runon a single machine for less demanding server loads.

Additionally, the design accounts for the possible existence of other external financial systems thatVODKA must interact with. VODKA provides hooks to communicate with these systems using custom webservices which are aware of the VODKA interface as well as how to interact with the other systems. Thoughnone of these are provided with VODKA, it will be very easy to incorporate these services.

This design also allows for easy swapping and creation of alternative services. It is very possible that afinancial system requires a different method of user authentication. VODKA provides a simple way to swapout these services with custom services.

The configurability of the system allows for system administrators to easily make simple, specific changesto the system without fully understanding the design of the system.

5.2 Disadvantages of Design

VODKA heavily relies on web services and distributed communication. This distribution adds oftenunneccessary complexity in design, maintenance, and configuration. Many configurations of VODKA willnever require complex setups spanning multiple machines. If all of the services are provided by the samemachine, a significant performance overhead will be assumed because the web services will be generated andprocessing messages which might be better suited as method calls on a local machine.

5.3 Design Rationale

The existing VODKA design was chosen because it allows for maximal flexibility in the configurationof the system. Though web services may be complex in creation and more demanding, they do allow for amuch simpler way to expand the system and deal with different authentication requirements.

62

A Requirements Traceability Matrix

A.1 Traceability by Requirement Numbers

Non-functional requirements are labeled “NFR” to denote that there are no explicit software componentsdesigned to specifically satisfy them. These requirements have cross-cutting concerns in which many differentcomponents and environmental factors address.

Req # Design Component

0100 2.8.20110 2.8.20120 2.8.20130 2.8.20140 2.8.1, 2.8.30150 2.8.1, 2.8.30160 2.8.1, 2.8.30170 2.8.1, 2.8.30180 2.5.9, 2.7.40190 2.5.9, 2.7.40200 2.5.9, 2.7.40205 2.5.9, 2.7.40210 2.5.9, 2.7.40215 2.5.9, 2.7.40220 2.5.9, 2.7.40230 2.5.9, 2.7.40240 2.5.9, 2.7.40250 2.5.9, 2.7.40260 2.5.9, 2.7.40270 2.5.9, 2.7.40280 2.5.9, 2.7.40290 2.5.9, 2.7.40300 2.5.9, 2.7.40310 2.5.9, 2.7.40320 2.5.9, 2.7.40330 2.5.9, 2.7.40340 2.5.9, 2.7.40350 2.5.9, 2.7.40360 2.5.9, 2.7.40370 2.5.9, 2.7.40380 2.5.9, 2.7.40390 2.5.9, 2.7.40395 2.5.9, 2.7.40400 2.5.9, 2.7.40410 2.5.9, 2.7.40420 2.5.9, 2.7.40430 2.5.9, 2.7.40440 2.5.9, 2.7.40450 2.5.9, 2.7.40455 2.5.9, 2.7.40460 2.5.9, 2.7.40470 2.5.2, 2.6.2, 2.7.40480 2.5.2, 2.6.2, 2.7.4

63


0490 2.5.2, 2.6.2, 2.7.40500 2.5.2, 2.6.2, 2.7.40510 2.5.2, 2.6.2, 2.7.40520 2.5.9, 2.7.40530 2.5.9, 2.7.40540 2.5.9, 2.7.40550 2.5.9, 2.7.40560 2.5.9, 2.7.40570 2.5.9, 2.7.40580 2.5.1, 2.7.10590 2.5.1, 2.7.10600 2.5.1, 2.7.10605 2.5.1, 2.7.10610 2.5.1, 2.7.10615 2.5.1, 2.7.10620 2.5.1, 2.7.10630 2.5.1, 2.7.10640 2.5.1, 2.7.10650 2.5.1, 2.7.10655 2.5.1, 2.7.10660 2.5.1, 2.7.10665 2.5.1, 2.7.10670 2.5.1, 2.7.10680 2.5.1, 2.7.10690 2.5.1, 2.7.10700 2.5.1, 2.7.10710 2.5.1, 2.7.10715 2.5.1, 2.7.10720 2.5.1, 2.7.10730 2.5.1, 2.7.10740 2.5.1, 2.7.10750 2.5.1, 2.7.10760 2.5.1, 2.7.10770 2.5.1, 2.7.10780 2.5.1, 2.7.10790 2.5.1, 2.7.10800 2.5.1, 2.7.10810 2.5.1, 2.7.10820 2.5.1, 2.7.10830 2.5.1, 2.7.10840 2.5.1, 2.7.10850 2.5.1, 2.7.10860 2.5.1, 2.7.10870 2.5.1, 2.7.10880 2.5.1, 2.7.10890 2.5.1, 2.7.10895 2.5.1, 2.7.10900 2.5.1, 2.7.10905 2.5.1, 2.7.10910 2.5.10, 2.7.30920 2.5.10, 2.7.3

64


0930 2.5.10, 2.7.30935 2.5.10, 2.7.30940 2.5.10, 2.7.30950 2.5.10, 2.7.30960 2.5.10, 2.7.30965 2.5.10, 2.7.30970 2.5.10, 2.7.30975 2.5.10, 2.7.30980 2.5.10, 2.7.30985 2.5.10, 2.7.30990 2.5.10, 2.7.30995 2.5.10, 2.7.31000 2.5.10, 2.7.31005 2.5.10, 2.7.31010 2.5.10, 2.7.31020 2.5.10, 2.7.31025 2.5.10, 2.7.31030 2.5.10, 2.7.31040 2.5.10, 2.7.31050 2.5.10, 2.7.31060 2.6.1, 2.7.31070 2.7.31080 2.7.31090 2.5.7, 2.7.31100 2.5.7, 2.7.31110 2.5.7, 2.6.5, 2.7.31120 2.7.31130 2.7.31140 2.7.31150 2.5.5, 2.7.31160 2.5.61170 2.5.4, 2.6.41180 2.5.4, 2.6.41190 2.5.4, 2.6.41200 2.5.4, 2.6.4, 2.6.71210 2.5.4, 2.6.4, 2.6.71220 2.5.3, 2.7.21230 2.5.3, 2.8.2, 2.7.21240 2.5.3, 2.7.21245 2.5.3, 2.7.21250 2.5.3, 2.7.21260 2.5.3, 2.7.21270 2.5.3, 2.7.21280 2.6.21290 2.6.21300 2.6.21310 2.6.21320 2.6.21330 2.6.21340 2.6.21350 2.6.2

65


1360 NFR1370 NFR1380 2.8.21390 2.5.2, 2.6.2, 2.6.61400 2.5.2, 2.6.2, 2.6.61410 2.5.2, 2.6.2, 2.6.61420 2.5.2, 2.6.2, 2.6.61430 2.5.2, 2.6.2, 2.6.61440 2.5.2, 2.6.2, 2.6.61450 2.5.2, 2.6.2, 2.6.3, 2.6.61460 NFR1470 NFR1500 NFR1510 NFR1520 NFR1530 NFR1540 NFR1550 NFR1560 NFR1570 NFR1580 NFR

A.2 Traceability by Design Component

Design Component Req #

2.5.1 0580, 0590, 0600, 0605, 0610, 0615, 0620, 0630, 0640, 0650, 0655,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

2.5.2 0470, 0480, 0490, 0500, 0510, 1390, 1400, 1410, 1420, 1430, 1440,1450

2.5.3 1220, 1230, 1240, 1245, 1250, 1260, 12702.5.4 1170, 1180, 1190, 1200, 12102.5.5 11502.5.6 11602.5.7 1090, 1100, 11102.5.9 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, 0520,0530, 0540, 0550, 0560, 0570

2.5.10 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

2.6.1 10602.6.2 0470, 0480, 0490, 0500, 0510, 1280, 1290, 1300, 1310, 1320, 1330,

1340, 1350, 1390, 1400, 1410, 1420, 1430, 1440, 14502.6.3 14502.6.4 1170, 1180, 1190, 1200, 1210

66

Design Component Req #

2.6.5 11102.6.6 1390, 1400, 1410, 1420, 1430, 1440, 14502.6.7 1200, 12102.7.1 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

2.7.2 1220, 1230, 1240, 1245, 1250, 1260, 12702.7.3 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

2.7.4 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

2.8.1 0140, 0150, 0160, 01702.8.2 0100, 0110, 0120, 0130, 1230, 13802.8.3 0140, 0150, 0160, 01702.8.4 1230

67

References

[1] Archit Baweja, Drew Hall, Sunny Huynh, Kevin Lynch, and Kanwarpreet Sethi. Software requirementsspecification for VODKA, 2007.

[2] Software Engineering Institute. Three tier software architectures, 2000.

[3] Web Service Security TC. Soap message security 1.1 (ws-security). Standard specification, OASIS,February 2006.

[4] Web Services Reliable Messaging TC. Ws-reliability 1.1. Standard, OASIS, November 2004.

68

Date post:	27-Dec-2019
Category:	Documents
Upload:	others
View:	3 times
Download:	0 times

VODKA Software Design Descriptionyfcai/CS451/samples/DesignDocVodka.pdfSoftware Design Description...

Documents