generated from rit-ecet-notes/new-course
Finish course
This commit is contained in:
parent
0f548841b3
commit
e8012afa5f
GPG key ID:
61C1E13067E0018E
3 changed files with 500 additions and 1 deletions
37
0001-uncommitted.patch
Normal file
37
0001-uncommitted.patch
Normal file
File diff suppressed because one or more lines are too long
462
DesignDoc.md
Normal file
462
DesignDoc.md
Normal file
|
|
@ -0,0 +1,462 @@
|
|||
---
|
||||
geometry: margin=1in
|
||||
---
|
||||
# GuessN'Check Design Documentation
|
||||
|
||||
## Team Information
|
||||
* Team name: GuessN'Check
|
||||
* Team members
|
||||
* Mohammed Fareed
|
||||
* Ryan Leifer
|
||||
* Kenny Casey
|
||||
* Blizzard Finnegan
|
||||
* Neav Ziv
|
||||
|
||||
## Executive Summary
|
||||
|
||||
This is a summary of the project.
|
||||
|
||||
### Purpose
|
||||
> _**[Sprint 2 & 4]** Provide a very brief statement about the project and the most
|
||||
> important user group and user goals._
|
||||
|
||||
The project consists of a web application that allows managers (school administrators) to advertise needs (school supplies) and allows helpers (donors) to fund those needs. The application will allow users (managers) to create a need, and then allow other users (helpers) to fund that need. It will also allow helpers to create a funding basket, which will allow them to fund multiple needs at once. Managers have access to cupboards that holds all their advertised needs. The application also allows helpers to checkout with their baskets, which will allow them to fund all needs in their funding basket.
|
||||
|
||||
### Glossary and Acronyms
|
||||
> _**[Sprint 2 & 4]** Provide a table of terms and acronyms._
|
||||
|
||||
| Term | Definition |
|
||||
|------|------------|
|
||||
| SPA | Single Page |
|
||||
| MVP | Minimum Viable Product |
|
||||
| DAO | Data Access Object |
|
||||
| API | Application Programming Interface |
|
||||
| UI | User Interface |
|
||||
|
||||
|
||||
## Requirements
|
||||
|
||||
This section describes the features of the application.
|
||||
|
||||
### Definition of MVP
|
||||
> _**[Sprint 2 & 4]** Provide a simple description of the Minimum Viable Product._
|
||||
|
||||
The minimum viable product will allow users to create and fund needs, with minimal authentication. The application should allow user and managers to login, managers to create needs, and helpers to fund needs. The application provides cupboards for managers to advertise their needs, and funding baskets for helpers to checkout and fund multiple needs at once.
|
||||
|
||||
### MVP Features
|
||||
> _**[Sprint 4]** Provide a list of top-level Epics and/or Stories of the MVP._
|
||||
|
||||
### Enhancements
|
||||
> _**[Sprint 4]** Describe what enhancements you have implemented for the project._
|
||||
|
||||
|
||||
## Application Domain
|
||||
|
||||
This section describes the application domain.
|
||||
|
||||
```mermaid
|
||||
classDiagram
|
||||
class User { Credentials }
|
||||
class Manager["U-Fund Manager"]
|
||||
class Cupboard
|
||||
class Helper
|
||||
class Basket["Funding Basket"]
|
||||
class Need
|
||||
class Checkout
|
||||
class Notify["Notifications Center"]
|
||||
class Deal["Funding Deal"]
|
||||
|
||||
User "1" --> "1" Manager : Logs in as
|
||||
User "1" --> "1" Helper : Logs in as
|
||||
|
||||
Deal "1" --> "1" Need : Applies to
|
||||
Deal "*" <-- "1" Manager : Customizes
|
||||
Deal "*" --> "1" Checkout : Applies upon
|
||||
|
||||
Manager "1" --> "1" Cupboard : Manages data of needs in
|
||||
Cupboard "1" <-- "1..*" Need : Organized for management in
|
||||
|
||||
Helper "1" --> "1" Basket : Organizes supported needs in
|
||||
Helper "1" --> "*" Cupboard : Searches through needs in all
|
||||
Basket "*" <-- "*" Need : Organized for fulfillment in
|
||||
|
||||
Notify "1" <-- "1" Manager : Submits notifications about needs
|
||||
Notify "1" --> "*" Helper : Notifies on new messages regarding a need
|
||||
Notify "1" <-- "1" Helper : Subscribes to messages about a need
|
||||
|
||||
Checkout "1" <-- "1" Helper : Fulfills needs through
|
||||
Checkout "1" <-- "1" Basket : Its needs are fulfilled upon
|
||||
```
|
||||
|
||||
> _**[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._
|
||||
|
||||
The domain of the application is split into two main sub-domains, the `U-Fund Manager` side and the `Helper` side, which are connected mainly through `Need`s. The `U-Fund Manager` side is responsible for creating and managing needs in `Cupboard`s and specifying `Funding Deal`s on those needs. Managers are also responsible for managing other `User`s as well as their roles.
|
||||
|
||||
The `Helper` side is responsible for searching through needs in `Cupboard`s and funding them by grouping them in `Funding Basket`s. Helpers fund the needs in their baskets by going through the `Checkout` process, which applies `Funding Deal`s.
|
||||
|
||||
A `Notification Center` is responsible for notifying managers about the fulfillment of their needs and notifying helpers about changes to the needs they are funding (in their baskets). `Helpers` subscribe to notifications about a `Need`, which `Managers` push to this service. The service then notifies all `Helpers` that are subscribed to the `Need` about the new `Message`.
|
||||
|
||||
|
||||
## 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. (_When requested, replace this diagram with your **own** rendition and representations of sample classes of your system_.)
|
||||
|
||||
|
||||
|
||||
The web application, is built using the Model–View–ViewModel (MVVM) architecture pattern.
|
||||
|
||||
The Model stores the application data objects including any functionality to provide persistance.
|
||||
|
||||
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.
|
||||
|
||||
The UI of the web application is structured as follows: The user is presented with a login page. The user can login as a manager or a helper. The top shows the accessible tabs to the user. Managers and access their cupboard and manage users through tabs. Helpers can search needs and manage their funding baskets through tabs. Managers have access to a need editing page when updating or adding needs. Helpers have access to a checkout interface through their funding baskets. Guest users can only access the login page or register as a helper. Managers can change the role of a user to either a manager or a helper.
|
||||
|
||||
|
||||
### 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 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._
|
||||
|
||||
```mermaid
|
||||
classDiagram
|
||||
|
||||
CupboardController ..> "1" CupboardDAO: Accesses data through
|
||||
BasketController ..> "1" FundingBasketDAO: Accesses data through
|
||||
NotificationsController ..> "1" NotificationsDAO: Accesses data through
|
||||
UserController ..> "1" UsersDAO: Accesses data through
|
||||
|
||||
class CupboardController {
|
||||
+createNeed(): Need
|
||||
+getNeed(): Need
|
||||
+updateNeed(): Need
|
||||
+searchNeeds(): Need[]
|
||||
}
|
||||
|
||||
class BasketController {
|
||||
-refreshBasket(): void
|
||||
|
||||
+addNeed(id: int): Need
|
||||
+getBasket(): Need[]
|
||||
+removeNeed(id: int)
|
||||
+checkout(ids: int[])
|
||||
}
|
||||
|
||||
class NotificationsController {
|
||||
+pushNotification(needID, message): Notification
|
||||
+subscribe(needID, userID): boolean
|
||||
+unsubscribe(needID, userID): boolean
|
||||
+getNotifications(userID): Notification[]
|
||||
+removeNotification(userID, notificationID): boolean
|
||||
}
|
||||
|
||||
class UserController{
|
||||
+register(User): User
|
||||
+authenticate(user: AuthUser): User
|
||||
+getUsers(): User[]
|
||||
+getUser(id:int): User
|
||||
+deleteUser(id:int): User
|
||||
+updateUser(id:int,user): User
|
||||
}
|
||||
```
|
||||
|
||||
### Model Tier
|
||||
> _**[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._
|
||||
|
||||
The model tier is responsible for storing and managing the data of the application. It is also responsible for providing the data to the view model tier. The model tier is made up data access objects (DAOs) that provide the view model tier with the data it needs. The model tier is also responsible for providing the view model tier with the logic it needs to manipulate the data, such as the `Need` class's `hasBeenMet()` method.
|
||||
|
||||
The applications contains two models, one for needs and one for funding baskets. The `Need` model represents an advertised need by a manager that needs fulfillment. The `Basket` model represents a collection of needs that a helper wants to fund. A basket does not hold the needs' information directly, but it holds references to needs stored in cupboards using their IDs. This allows the basket to be updated when the needs are updated. This is accomplished by having a single source of truth for the needs, which is the cupboard to which the need belongs.
|
||||
|
||||
```mermaid
|
||||
classDiagram
|
||||
Need "*" <--"1" CupboardDAO : Manages data of
|
||||
CupboardDAO <|.. CupboardFileDAO
|
||||
FundingBasketDAO <|.. FundingBasketFileDAO
|
||||
|
||||
Notification "*" <--"1" NotificationsDAO : Manages data of
|
||||
NotificationsCenter "1" <--"1" NotificationsDAO : Manages subscriptions through
|
||||
NotificationsDAO <|.. NotificationsFileDAO
|
||||
|
||||
User "*" <-- "1" UsersDAO : Manages data of
|
||||
UsersDAO <|.. UsersFileDAO
|
||||
|
||||
|
||||
class Need {
|
||||
+id: int
|
||||
+name: String
|
||||
+amount_in_stock: double
|
||||
+amount_needed: double
|
||||
+amount_unit: String
|
||||
+tags: String[]
|
||||
|
||||
+hasBeenMet(): boolean
|
||||
+addTag(String tag): void
|
||||
+removeTag(String tag): void
|
||||
+clearTags(): void
|
||||
}
|
||||
|
||||
class CupboardDAO {
|
||||
+createNeed(Need need): Need
|
||||
+getNeed(int id): Need
|
||||
+updateNeed(Need need): Need
|
||||
+deleteNeed(int id): boolean
|
||||
+getNeeds(): Need[]
|
||||
+findNeedsByName(String query): Need[]
|
||||
+findNeedsByTag(String query): Need[]
|
||||
+findNeedsByRequired(double query): Need[]
|
||||
}
|
||||
|
||||
class CupboardFileDAO {
|
||||
+ needs: Need[]
|
||||
- nextID: int
|
||||
- filename: String
|
||||
|
||||
+createNeed(Need need): Need
|
||||
+getNeed(int id): Need
|
||||
+updateNeed(Need need): Need
|
||||
+deleteNeed(int id): boolean
|
||||
+findNeedsByName(String query): Need[]
|
||||
+findNeedsByTag(String query): Need[]
|
||||
+findNeedsByRequired(double query): Need[]
|
||||
- save(): void
|
||||
- load(): void
|
||||
- nextID(): int
|
||||
- createFile(filename: String): void
|
||||
}
|
||||
|
||||
class Basket {
|
||||
+user: string
|
||||
-needIDs: int[]
|
||||
|
||||
+addNeed(int id): boolean
|
||||
+removeNeed(int id): boolean
|
||||
+getNeeds(): int[]
|
||||
}
|
||||
|
||||
class FundingBasketDAO {
|
||||
+getNeeds(): int[]
|
||||
+addNeed(int id): boolean
|
||||
+removeNeed(int id): boolean
|
||||
}
|
||||
|
||||
class FundingBasketFileDAO {
|
||||
- baskets: int[]
|
||||
- filename: String
|
||||
|
||||
+getNeeds(): int[]
|
||||
+addNeed(int id): boolean
|
||||
+removeNeed(int id): boolean
|
||||
- save(): void
|
||||
- load(): void
|
||||
- createFile(filename: String): void
|
||||
}
|
||||
|
||||
class Notification {
|
||||
+id: int
|
||||
+needID: int
|
||||
+message: String
|
||||
}
|
||||
|
||||
class NotificationsCenter {
|
||||
+subscriptions: Dictionary<int, int[]>
|
||||
+notifications: Dictionary<int, int[]>
|
||||
+notificationsRepo: Notification[]
|
||||
}
|
||||
|
||||
class NotificationsDAO {
|
||||
+pushNotification(needID, message): Notification
|
||||
+subscribe(needID, userID): boolean
|
||||
+unsubscribe(needID, userID): boolean
|
||||
+getNotifications(userID): Notification[]
|
||||
+removeNotification(userID, notificationID): boolean
|
||||
}
|
||||
|
||||
class NotificationsFileDAO {
|
||||
- notifications: Notification[]
|
||||
- NotificationsCenter
|
||||
- filename: String
|
||||
|
||||
+pushNotification(needID, message): Notification
|
||||
+subscribe(needID, userID): boolean
|
||||
+unsubscribe(needID, userID): boolean
|
||||
+getNotifications(userID): Notification[]
|
||||
+removeNotification(userID, notificationID): boolean
|
||||
- save(): void
|
||||
- load(): void
|
||||
- createFile(filename: String): **void**
|
||||
}
|
||||
|
||||
class User{
|
||||
-salt: byte[]
|
||||
-id: int
|
||||
+firstName: String
|
||||
+lastName: String
|
||||
+username: String
|
||||
-passHash: byte[]
|
||||
+isAdmin: boolean
|
||||
|
||||
+isPassword(pass_test:String): boolean
|
||||
+getID(): int
|
||||
}
|
||||
|
||||
class UsersDAO{
|
||||
+register(user:User):User
|
||||
+authenticate(username:string,password:password):boolean
|
||||
+updateUser(id:int,password:string):User
|
||||
+deleteUser(id:int):User
|
||||
+getUsers():User[]
|
||||
+getUser(id:int):User
|
||||
+getUserByUsername(username:string):User
|
||||
}
|
||||
|
||||
class UsersFileDAO{
|
||||
-users:Map<int,User>
|
||||
-nextID: int
|
||||
-filename:String
|
||||
|
||||
+register(user:User):User
|
||||
+authenticate(username:string,password:password):boolean
|
||||
+updateUser(id:int,password:string):User
|
||||
+deleteUser(id:int):User
|
||||
+getUsers():User[]
|
||||
+getUser(id:int):User
|
||||
+getUserByUsername(username:string):User
|
||||
-nextID():int
|
||||
-save():boolean
|
||||
-load():boolean
|
||||
-createFile():File
|
||||
}
|
||||
```
|
||||
|
||||
## OO Design Principles
|
||||
> _**[Sprint 2, 3 & 4]** Will eventually address up to **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._
|
||||
|
||||
### Single Responsibility Principle
|
||||
|
||||
The single responsibility principle is applied to the `Need` class. The `Need` class is responsible for storing the data of a need. It is not responsible for any other functionality. The model tier diagram shows that responsibilities beyond data storage, such as manipulating multiple needs in a cupboard, are handled by the `CupboardDAO` class. This allows the `Need` class to focus on its single responsibility of storing the data of a need, while allowing the `CupboardDAO` class to handle the single responsibility of managing multiple needs.
|
||||
|
||||
### Controller Design Pattern
|
||||
|
||||
The controller design pattern is applied to the `CupboardController` and `BasketController` classes. The controller design pattern is used to separate the logic of the application from the view. The controller classes are responsible for handling the requests from the view and providing the view with the data it needs. The controller classes are also responsible for handling the logic of the application, such as creating needs and funding baskets. This allows the view to focus on displaying the data and allows the controller to focus on handling the business logic of the application.
|
||||
|
||||
> _**[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._
|
||||
|
||||
> _**[Sprint 4]** Discuss **future** refactoring and other design improvements your team would explore if the team had additional time._
|
||||
|
||||
## Testing
|
||||
|
||||
### Acceptance Testing
|
||||
> _**[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._
|
||||
|
||||
All the user stories have passed their acceptance criteria tests. In total, 9 user stories have been implemented and 26 acceptance criteria tested. No tests have failed and no issues have been found during acceptance testing. Some bugs have been found and reported during testing, but none that affect the acceptance criteria of the user stories.
|
||||
|
||||
### 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._
|
||||
|
||||
#### Controller Tier
|
||||
|
||||
|
||||
This is the analysis at the Controller Tier code for the project.
|
||||
|
||||
|
||||
|
||||
##### Analysis
|
||||
|
||||
|
||||
The report shows shows an average coverage of 86.5% for the controller tier, mainly due to the addition of the new `FundingBasketController`, which does not have as much testing as the cupboard controller. The `CupboardController` has an average coverage of 89%, which is very close to the recommended coverage of 90%. The funding basket controller has an average coverage of 84.5%, which is further from the recommended coverage.
|
||||
|
||||
#### Model Tier
|
||||
|
||||
|
||||
This is the analysis at the Model Tier code for the project.
|
||||
|
||||
|
||||
|
||||
##### Analysis
|
||||
|
||||
|
||||
The report shows an average coverage of 77%, which is much less than the recommended 95% for the model tier. The `Need` class shows a 100% branch coverage but only 75% instructions coverage, due to the additions done to the class without their accompanying tests. The new `Basket` class is poorly tested on both instructions and branches, with 0% coverage on both. Increasing the testing coverage of the model tier is a high priority for the team.
|
||||
|
||||
#### Persistence Tier
|
||||
|
||||
|
||||
This is our analysis at the Persistence Tier code for the project.
|
||||
|
||||
|
||||
|
||||
##### Analysis
|
||||
|
||||
|
||||
The persistence tier shows a sever lacking of testing, with an average code coverage of 15.5%. It is by far the least tested portion of the code base and is at the highest priority for testing efforts. Tests will be written to bring up both instructions coverage and branches coverages to 90%, the recommended code coverage set for the project.
|
||||
|
||||
#### Well-tested Component
|
||||
|
||||
|
||||
This is our analysis of a well-tested component.
|
||||
|
||||
|
||||
|
||||
##### Analysis
|
||||
|
||||
|
||||
The class report shows that the `CupboardController` has the best code coverage with the highest average out of all other classes at 89%. Since the recommended average is 90%, the team will focus on increasing the code coverage of the `FundingBasketController` to bring up the average coverage of the controller tier to the recommended 90%. Priority will still be given to bringing the model tier up to the recommended 95% coverage.
|
||||
|
||||
#### Poorly-tested Component
|
||||
|
||||
|
||||
This is our analysis of a poorly-tested component.
|
||||
|
||||
|
||||
|
||||
##### Analysis
|
||||
|
||||
|
||||
The class report shows that the cupboard persistence tier class is untested. Its coverage is 0% for most of its functions. The `CupboardFileDAO` makes up the entire persistence code base. The testing efforts of the team will priorities this tier equally to bring up the code coverage of the whole persistence tier to the project's recommended coverage of 90%. Priority will still be given to bringing the model tier up to the recommended 95% coverage.
|
||||
|
|
@ -1 +1 @@
|
|||
Subproject commit d8f50ff4aae0a1192e6c1d9545848ad1f960d6f5
|
||||
Subproject commit ef925152d98dfd985160f85c88fba3bee6b9ade4
|
||||
Loading…
Add table
Reference in a new issue