path: root/docs/DesignDoc.md

---
geometry: margin=1in
---

# PROJECT Design Documentation

## Team Information

- Team name: Jelly Solutions
- Team members
  - Ben Almstead
  - Tyler Ferrari
  - Hayden Hartman
  - Akash Keshav
  - Angelina Zhen

## Executive Summary

Our project is intended to create a space to fund aquatic conservation, from physical ecosystems such as coral reefs to aquatic creatures such as jellyfish. Users will be able to donate funds, both physical and monetary, to individal 'needs', and see how close to reaching a funding goal each need is. Admin accounts can manage needs for the helpers to contribute to. We have a focus on a quality, with a uniform user experience across all features of the site, regardless if a user is a helper or an admin.

### Purpose

The purpose of this project is to provide an avenue for companies to crowd-fund and for users to contribute to funds of their choosing.

> _**[Sprint 2 & 4]** Provide a very brief statement about the project and the most
> important user group and user goals._

### Glossary and Acronyms

> _**[Sprint 2 & 4]** Provide a table of terms and acronyms._

| Term           | Definition                                     |
| -------------- | ---------------------------------------------- |
| SPA            | Single Page                                    |
| Need           | Element to donate to                           |
| Contribute     | Donate                                         |
| Checkout       | Pay / Support                                  |
| DAO            | Document Object Model                          |
| Component      | UI Element                                     |
| Models         | Structure / Laypout                            |
| Helper         | Contributor / User                             |
| Manager        | Administrator                                  |
| Modal          | Pop-up page                                    |
| Toast          | On-screen notification                         |
| API key        | Token unique to a sesssion for API interaction |
| JS             | Jelly Sollutions                               |
| Funding basket | User's needs                                   |

## Requirements

This section describes the features of the application.

The requirements for this u-fund project to be functional include a system for organizations (administrators) to create funding goals (needs) that can be satisfied by clients (users).

> _In this section you do not need to be exhaustive and list every
> story. Focus on top-level features from the Vision document and
> maybe Epics and critical Stories._

#### Uniform Application Design
All pages and components should be consitent in style and layout. The user experience should be consistent across pages. Everything should be clear and consistent for usability, especially if a user is unfamilliar with our site. Usabilty options should consistently apply, such as different layouts, light/dark mode, or different devices across all pages and components. 

#### Layout Information Priority
The most relevant information should always be presented first or be the most visually attracting. Sorting should be able to be controlled by the user in order to access the most relevant information in the cleanest way possible. The layouts should be consistenet across all pages.

#### Security
Users should only be able to acess API functions that match their user type. When a helper acesses an admin only feature, page or command, they should be re-directed or denied access. API commands are verified through the authentication service, with the API key per session granting access to the commands. This prevents anyone from accessing or modifying data they should not have access to. 

#### Services and Abstractions
Common code and features should be consolidated into services and classes in order to limit repeated functionality. Classes are abstracted where possible, increasing reusability and code quality across the frontend and backend. All components should use the services as much as possible to keep the code clean and understandable for matinence and bugfixing.

### Definition of MVP

> _**[Sprint 2 & 4]** Provide a simple description of the Minimum Viable Product._

Users are able to login to the Ufund, either as a manager or helper. They can create secure passwords for account security. Helpers are able to go to the cupboard and can view needs, search for needs, add/remove needs to their funding basket, and check out and fund needs. Managers can add, remove, and edit needs in the cupboard. When editing needs, managers can edit one or more properties and update needs for users. Needs have many properties including images, descriptions, goal types and amounts. Needs are saved so users and managers will see when they are updated. Managers can view stats on a managment page.

### MVP Features

> _**[Sprint 4]** Provide a list of top-level Epics and/or Stories of the MVP._

  - AS a Developer I WANT to create a funding basket component SO THAT needs can be viewed within the cupboard on the dashboard.
  - As a user I want to see a homepage so that I can navigate the site.
    - AS a User I WANT to see a home page when visiting the site SO THAT I can easily navigate through pages.
    - AS a Developer I WANT implement basic, functional CSS for components and pages SO THAT there is basic formatting that can be navigated.
  - AS a Developer I WANT to have a cupboard component SO THAT I can display the needs from the cupboard in the UI
  - AS a developer I WANT to create data storage for users SO THAT users are able to login to the website through the login page.
  - AS a Developer I WANT to create a need page component SO THAT users can view a singular need in an entire page.
  - AS a Developer I WANT to submit a request to input a username SO THAT each unique user can access their saved needs.
  - AS a user I WANT to see images to needs SO THAT I can get a better idea of what I’m donating to.
  - AS a manager I WANT to see a list of statistics about the UFund SO THAT I can manage the ufund better.
  - AS a user I WANT to see a clear and navigable login page SO THAT I can easily login or create a new account.
  - As a user I WANT to enable light/dark mode to increase usability based on user preferences.
  - AS a Manager I WANT to submit a request to edit an existing need through the existing need-list-component,  SO THAT it is added to the cupboard in a consistent way.
  - AS a Developer I want api keys to be removed when expired SO THAT hundreds of expired keys do not pile up.
  - As a user I want to put in my password so that my account is secure.
  - AS a user I WANT to see a simple signup page SO THAT I can easily create an account without confusion.
  - 

### Enhancements

> _**[Sprint 4]** Describe what enhancements you have implemented for the project._

Security
  - We have implemented a set of security features to enhance the security of the application
  - We have added an authentication system, which verifies a user can access the correct pages, and keeps them logged in after they have logged in once
    - Users cannot access funding basket or dashboard unless logged in
    - Helpers cannot access the manager dashboard
    - Managers cannot access funding basket
  - We have also added a number of password requirements to our signup page, guaranteeing users have strong passwords to keep their accounts secure
    - Passwords must be 6 characters or longer
    - Passwords must have one symbol
    - Passwords must have a number
    - Passwords must have an uppercase letter
    - Passwords must have a lowercase letter

Sort filters

- We have implemented a number of sorting filters in the cupboard, allowing users and managers to easily sort through needs with different priorities
- You can sort by funding goal
- You can sort by Location
- You can sort by name
- You can sort by an urgency tag on needs
- You can sort by type of need
- You can sort by most completed

## Application Domain

This section describes the application domain.

![Domain Model](domain-model.png)

> _**[Sprint 2 & 4]** Provide a high-level overview of the domain for this application. You
> can discuss the more important domain entities and their relationship
> to each other._

Each user views 1 cupboard which can contain 0 or more needs. They can take 1 or more needs and put them in their funding basket which they can then check out. Each user has 1 funding basket. 1 manager will manage the 1 cupboard, add, removing, and editing needs within it. Needs have two or more properties. Managers cannot interact with the 1 funding basket each user has. 

## Architecture and Design

This section describes the application architecture.

### Summary

The following Tiers/Layers model shows a high-level view of the webapp's architecture.
**NOTE**: detailed diagrams are required in later sections of this document.

> _**[Sprint 1]** (Augment this diagram with your **own** rendition and representations of sample system classes, placing them into the appropriate M/V/VM (orange rectangle) tier section. Focus on what is currently required to support **Sprint 1 - Demo requirements**. Make sure to describe your design choices in the corresponding _**Tier Section**_ and also in the _**OO Design Principles**_ section below.)_

![The Tiers & Layers of the Architecture](architecture-tiers-and-layers.png)

The web application is built using the Model–View–ViewModel (MVVM) architecture pattern.

The Model section contains our back-end structure, split into three sections: Model, Persistence, and Controller. Each of the files contained for each section are below each item.

The View is the client-side SPA built with Angular utilizing HTML, CSS and TypeScript. The ViewModel provides RESTful APIs to the client (View) as well as any logic required to manipulate the data objects from the Model.

Both the ViewModel and Model are built using Java and Spring Framework. Details of the components within these tiers are supplied below.

### Overview of User Interface

This section describes the web interface flow; this is how the user views and interacts with the web application.

> _Provide a summary of the application's user interface. Describe, from the user's perspective, the flow of the pages/navigation in the web application.
> (Add low-fidelity mockups prior to initiating your **[Sprint 2]** work so you have a good idea of the user interactions.) Eventually replace with representative screen shots of your high-fidelity results as these become available and finally include future recommendations improvement recommendations for your **[Sprint 4]** )_

Home Page:
![The Tiers & Layers of the Architecture](homepage.png)

![The Tiers & Layers of the Architecture](homepageLight.png)

Login Page:
![The Tiers & Layers of the Architecture](login.png)

![The Tiers & Layers of the Architecture](loginLight.png)

Signup Page:
![The Tiers & Layers of the Architecture](signup.png)

![The Tiers & Layers of the Architecture](signupLight.png)

Dashboard:
![The Tiers & Layers of the Architecture](dashboard.png)

Cupboard:
![The Tiers & Layers of the Architecture](cupboard.png)

![The Tiers & Layers of the Architecture](cupboardLight.png)

Need page:
![The Tiers & Layers of the Architecture](needpage.png)

Funding basket:
![The Tiers & Layers of the Architecture](basket.png)

### View Tier

> _**[Sprint 4]** Provide a summary of the View Tier UI of your architecture.
> Describe the types of components in the tier and describe their
> responsibilities. This should be a narrative description, i.e. it has
> a flow or "story line" that the reader can follow._

> _**[Sprint 4]** You must provide at least **2 sequence diagrams** as is relevant to a particular aspects
> of the design that you are describing. (**For example**, in a shopping experience application you might create a
> sequence diagram of a customer searching for an item and adding to their cart.)
> As these can span multiple tiers, be sure to include an relevant HTTP requests from the client-side to the server-side
> to help illustrate the end-to-end flow._

> _**[Sprint 4]** To adequately show your system, you will need to present the **class diagrams** where relevant in your design. Some additional tips:_
>
> - _Class diagrams only apply to the **ViewModel** and **Model** Tier_
> - _A single class diagram of the entire system will not be effective. You may start with one, but will be need to break it down into smaller sections to account for requirements of each of the Tier static models below._
> - _Correct labeling of relationships with proper notation for the relationship type, multiplicities, and navigation information will be important._
> - _Include other details such as attributes and method signatures that you think are needed to support the level of detail in your discussion._

### ViewModel Tier

> _**[Sprint 1]** List the classes supporting this tier and provide a description of their purpose._

Controllers
 - AuthController: Handles http requests to login and logout users, calling to the authService
 - CupboardController: Handles http requests to interact with needs, calling to the cupboardService
 - UserController: Handles http requests to interact with users, calling to the userService

Services
 - authService: Handles logging in and out, as well as authenticating users when they try and visit pages. 
 - cupboardService: Handles all logic dealing with needs, verifying inputs and throwing errors.
 - userService:  Handles all logic dealing with users, verifying inputs and throwing errors.

> _**[Sprint 4]** Provide a summary of this tier of your architecture. This
> section will follow the same instructions that are given for the View
> Tier above._

Requests are sent from the view tier and handled by controllers. For example, when creating a new need a POST request is sent from the frontend and caught by the cupboardController. The cupboardController first authenticates the user, calling the authService and making sure the user has proper access. Next, the cupboardService is called to create a need. The cupboardService checks for a valid goal and name, and then creates a need from the model tier, returning back up. The cupboardController and userController all call authService to authenticate users.

> _At appropriate places as part of this narrative provide **one** or more updated and **properly labeled**
> static models (UML class diagrams) with some details such as associations (connections) between classes, and critical attributes and methods. (**Be sure** to revisit the Static **UML Review Sheet** to ensure your class diagrams are using correct format and syntax.)_
>
![UML](u-fund.drawio.png)

### Model Tier

> _**[Sprint 1]** List the classes supporting this tier and provide a description of there purpose._

The Model Tier contains the classes responsible for handling and serving Need data. In the model subsection is our Need.java, which handles the Need class itself and provides helper functions to get and set Need data. The persistence subjection handles stored data, using Data Access Objects (DAOs). The Controller section connects the two previous ones, handling the transfer of Needs to persistent storage.

> _**[Sprint 2, 3 & 4]** Provide a summary of this tier of your architecture. This
> section will follow the same instructions that are given for the View
> Tier above._

In our model tier we have a Need class, a User class, and a UserAuth class. The Need class represents needs and has fields for all of their values. Users have a passwordHash field, storing a hashed version of their password, an List of integers, representing the ID's of needs in the basket, and the userType which determines their privileges. The UserAuth class stores a key, a username, and expiration. A key is generated for a user and is used to authenticate the user. The username is the name associated with the key and the expiration is how long until the user must login again.

> _At appropriate places as part of this narrative provide **one** or more updated and **properly labeled**
> static models (UML class diagrams) with some details such as associations (connections) between classes, and critical attributes and methods. (**Be sure** to revisit the Static **UML Review Sheet** to ensure your class diagrams are using correct format and syntax.)_

![UML](u-fund.drawio.png)

## OO Design Principles

> _**[Sprint 1]** Name and describe the initial OO Principles that your team has considered in support of your design (and implementation) for this first Sprint._

- Law of Demeter: Classes only talk to nearby classes.
  - This principle is used to ensure that unintended behavior is minimal, by making each class only talk to others that make sense in the scope of the application. For example, the `dashboard` component interacts with the `need-list` and `funding-basket` components because they are needed to display needs on the dashboard, but it does not interact with the `login` or `signup` components, as they are not needed in order to ensure the functionality of the dashboard. These are located in the ViewModel and Model Tiers.
- Low Coupling: Limit the number of classes connected to each individual class.
  - We use Low Coupling principles to ensure that only classes related in function are actually interacting with each other. In our Angular setup, classes interact with their respective services instead of sharing the data with other classes. `NeedService` connects to `need-page`, `need-list`, `funding-basket`, and `cupboard`, but the components themselves do not interact with each other. This is more efficient and prevents one component from stalling if another errors. Because the service exclusively handles CRUD operations, it will not cause the connected components to stall if it encounters an error. These examples are located in the ViewModel Tier.
- Pure Fabrication: Using helper functions to split up larger classes into more managable chunks.
  - For example, this principle is showcased in our `AuthService`. Instead of having the `UserService` handle user management and user authorization at the same time, we have split the authorization part into a new AuthService class to handle login, while the UserService handles just the CRUD operations pertaining to the user. These classes are located in the ViewModel Tier.
- Single Responsibility: Each function should only have one function to prevent unintended errors.
  - This principle is used in our `CupboardController`, as it's only functionality is to connect the front-end and back-end through our REST API. This means that cupboard-related operations are not backlogged by any other classes, which is efficient and prevents unintended behavior in the application. This can be seen in the Model Tier.

> _**[Sprint 2, 3 & 4]** Will eventually address upto **4 key OO Principles** in your final design. Follow guidance in augmenting those completed in previous Sprints as indicated to you by instructor. Be sure to include any diagrams (or clearly refer to ones elsewhere in your Tier sections above) to support your claims._

> _**[Sprint 3 & 4]** OO Design Principles should span across **all tiers.**_

## Static Code Analysis/Future Design Improvements

> _**[Sprint 4]** With the results from the Static Code Analysis exercise,
> **Identify 3-4** areas within your code that have been flagged by the Static Code
> Analysis Tool (SonarQube) and provide your analysis and recommendations.  
> Include any relevant screenshot(s) with each area._

![sonarQube](sonarQube.png)

 - Overall, our results from SonarQube were very good. We had overall good coverage and did not have any major issues. Though we definitely have a number of issues flagged, the majority of them are info, with less than 10 high or medium severity issues. Even then, the major severity issues are fairly minor, such as reusing a string in the field of a thrown error and not putting comments in a nested class.

 ![Sonar severity](severity.png)
 ![Sonar error](sonarError.png)

> _**[Sprint 4]** Discuss **future** refactoring and other design improvements your team would explore if the team had additional time._

Some refactoring and improvements we would have made if we had additional time are as follows:
  - Improve tests consistentcy and raise code coverage
  - Add more information and create an overall more polished manager dashboard
    - Statistics over time
    - Radial and progress bars to represent data
    - Additional insights on needs
  - Add a more robust and accessible image system for needs, allowing managers to upload images instead of using links
  - Additional checkout persistence
    - Values remaining in checkout fields
    - Receipts for checking out
  - Deleted needs list and a way to bring back deleted needs
  - Filter tags for needs, allowing searching through tags set by managers

## Testing

> _This section will provide information about the testing performed
> and the results of the testing._

Currently around 115 tests, with roughly 90% coverage overall. Model tier is above 95% individually.

### Acceptance Testing

We have around 40 passing Acceptance Tests. A few tests, such as being logged out after long enough aren't easy to test, as our authentication removes authentications that are over 30 days old. There are probably a few pages and edge cases which are not accounted for in user testing, but have been thouroughly tested through the backend, frontend, or have been individually delt with. 

> _**[Sprint 2 & 4]** Report on the number of user stories that have passed all their
> acceptance criteria tests, the number that have some acceptance
> criteria tests failing, and the number of user stories that
> have not had any testing yet. Highlight the issues found during
> acceptance testing and if there are any concerns._

### Unit Testing and Code Coverage

> _**[Sprint 4]** Discuss your unit testing strategy. Report on the code coverage
> achieved from unit testing of the code base. Discuss the team's
> coverage targets, why you selected those values, and how well your
> code coverage met your targets._

Our unit testing strategy was to use a consistent styles of test across our persistence tier, model tier, and service/controller tier. On top of this, later on we had a single team member work on the majority of tests, resulting in a consistent style across all of the testing. On top of this, we consistently generated coverage reports and then wrote new tests to cover missing lines/branches. Overall, we had ~95% code coverage with the lowest coverage of a class being 82%. Our model tier was above 90% coverage.

> _**[Sprint 2, 3 & 4]** **Include images of your code coverage report.** If there are any anomalies, discuss
> those._

![alt text](CodeCoverage.png)

## Ongoing Rationale

> _**[Sprint 1, 2, 3 & 4]** Throughout the project, provide a time stamp **(yyyy/mm/dd): Sprint # and description** of any _**major**_ team decisions or design milestones/changes and corresponding justification._

**(2025/02/12): Sprint #1: Decided on the U-fund theme as Aquatic / Coral Reef.**

**(2025/02/15): Sprint #1: Outlined structure of Back-End Application.**

**(2025/03/17): Sprint #2: Decided on Important Stories for Sprint 2 Backlog, and reworked Design Architecture.**

**(2025/04/03): Sprint #3: Unanimously decided on enhancements, while narrowing focus on what needs to be finished for the sprint.**