Merge branch 'main' of ssh://github.com/RIT-SWEN-261-02/team-project-2231-swen-261-02-04-guessncheck
This commit is contained in:
commit
ef925152d9
6 changed files with 56 additions and 62 deletions
|
@ -180,37 +180,25 @@
|
|||
<p>Both the ViewModel and Model are built using Java and Spring Framework. Details of the components within these tiers are supplied below.</p>
|
||||
<h3 id="overview-of-user-interface">Overview of User Interface</h3>
|
||||
<p>This section describes the web interface flow; this is how the user views and interacts with the web application.</p>
|
||||
<p>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.</p>
|
||||
<p>The UI of the web application is structured such that it provides a unique experience for either helpers, managers, or unregistered users (guests). Guest users can only access the login page or register as a helper.</p>
|
||||
<p>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. Managers have an interface for pushing notifications to helpers subscribed to a need, which is done through their cupboard. Helpers have an interface for viewing their notifications inbox and managing their subscriptions, which is a separate tab only accessible to helpers.</p>
|
||||
<h3 id="view-tier">View Tier</h3>
|
||||
<blockquote>
|
||||
<p><em><strong>[Sprint 4]</strong> Provide a summary of the View Tier UI of your architecture.</em>
|
||||
<em>Describe the types of components in the tier and describe their</em>
|
||||
<em>responsibilities. This should be a narrative description, i.e. it has</em>
|
||||
<em>a flow or "story line" that the reader can follow.</em></p>
|
||||
</blockquote>
|
||||
<blockquote>
|
||||
<p><em><strong>[Sprint 4]</strong> You must provide at least <strong>2 sequence diagrams</strong> as is relevant to a particular aspects</em>
|
||||
<em>of the design that you are describing. (<strong>For example</strong>, in a shopping experience application you might create a</em>
|
||||
<em>sequence diagram of a customer searching for an item and adding to their cart.)</em>
|
||||
<em>As these can span multiple tiers, be sure to include an relevant HTTP requests from the client-side to the server-side</em>
|
||||
<em>to help illustrate the end-to-end flow.</em></p>
|
||||
</blockquote>
|
||||
<p><img src="file:////Users/mohdfareed/Developer/school/2231-swen-261-02-04/docs/sequenc-diagram.svg" alt="Adding a need to funding basket sequence diagram"></p>
|
||||
<blockquote>
|
||||
<p><em><strong>[Sprint 4]</strong> To adequately show your system, you will need to present the <strong>class diagrams</strong> where relevant in your design. Some additional tips:</em></p>
|
||||
<ul>
|
||||
<li><em>Class diagrams only apply to the <strong>ViewModel</strong> and <strong>Model</strong> Tier</em></li>
|
||||
<li><em>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.</em></li>
|
||||
<li><em>Correct labeling of relationships with proper notation for the relationship type, multiplicities, and navigation information will be important.</em></li>
|
||||
<li><em>Include other details such as attributes and method signatures that you think are needed to support the level of detail in your discussion.</em></li>
|
||||
</ul>
|
||||
</blockquote>
|
||||
<p>the view tier is responsible for displaying the site to the user. It takes information provided by the ViewModel tier and displays it to the user.
|
||||
The view tier is made up of component classes that provide the angular implementation as well as HTML/CSS to display the website such as the <code>add-edit.component.*</code> files</p>
|
||||
<p>This tier consists of multiple different directories with multiple files within. Each of these covers a different section of functionality for the admin or the helper.
|
||||
The <code>managment</code> directory contains the add-edit, list, and push components which control multiple important actions for the admin on the site.
|
||||
There are other components for every other function of the site as well.</p>
|
||||
<p>The following is a sequence diagram of the view tier for performing the action of adding a need to the funding basket. It shows the flow of information from the view to the view model tier. The diagram shows that the view tier is responsible for displaying the site to the user.</p>
|
||||
<p><img src="file:////Users/mohdfareed/Developer/school/2231-swen-261-02-04/docs/sequence-diagram-1.svg" alt="Adding a need to funding basket sequence diagram"></p>
|
||||
<p>The diagrams shows the flow of the logic within the view tier, and how it connects to the viewModel tier. The View tier uses the logic from the viewModel tier to perform different processes and actions.
|
||||
The angular logic of the view tier takes information provided by the viewModel tier to create a proper display of said information to the user.</p>
|
||||
<p>The following is a sequence diagram of the view tier for performing the action of removing a need from the cupboard. It shows the flow of information from the view to the view model tier.</p>
|
||||
<p><img src="file:////Users/mohdfareed/Developer/school/2231-swen-261-02-04/docs/sequence-diagram-2.svg" alt="Removing a need from the cupboard as admin"></p>
|
||||
<p>The diagrams shows the flow of the logic within the view tier, which involves propagating the intent to the ViewModel tier (controllers) through an HTTP request. The controller then uses the logic from the viewModel tier to perform different processes and actions, returning a response to the View tier to display to the user through HTTP responses.</p>
|
||||
<h3 id="viewmodel-tier">ViewModel Tier</h3>
|
||||
<blockquote>
|
||||
<p><em><strong>[Sprint 4]</strong> Provide a summary of this tier of your architecture. This</em>
|
||||
<em>section will follow the same instructions that are given for the View</em>
|
||||
<em>Tier above.</em></p>
|
||||
</blockquote>
|
||||
<p>The view model tier is responsible for providing the view with the data it needs. It is also responsible for providing the view with abstraction layer to the logic of manipulating data (business logic), such as the <code>CupboardController</code> class's <code>createNeed()</code> method. The view model tier is made up of controller classes that provide the view with endpoints that can be queries using HTTP requests to perform tasks or request information.</p>
|
||||
<p>This tier consists of 4 controller classes, each of which is responsible for a single functionality. The <code>CupboardController</code> class is responsible for managing needs in cupboards for managers. The <code>BasketController</code> class is responsible for managing funding baskets of helpers, including checking out with the basket. The <code>NotificationsController</code> class is responsible for managing notifications, including pushing new notifications and requesting inbox of messages. The <code>UserController</code> class is responsible for managing users, including authenticating users and registering new users.</p>
|
||||
<p>The class diagrams show that the controller classes access DAO classes to handle the logic of the application, which holds the business logic of the application. This allows the controller classes to focus on providing the view with endpoints that can be queries using HTTP requests, while allowing the DAO classes to focus on handling the business logic of the application and models for storing the data.</p>
|
||||
<pre style="all:unset;"><div class="mermaid">classDiagram
|
||||
|
||||
CupboardController ..> "1" CupboardDAO: Accesses data through
|
||||
|
@ -251,11 +239,6 @@
|
|||
+updateUser(id:int,user): User
|
||||
}</div></pre>
|
||||
<h3 id="model-tier">Model Tier</h3>
|
||||
<blockquote>
|
||||
<p><em><strong>[Sprint 2, 3 & 4]</strong> Provide a summary of this tier of your architecture. This</em>
|
||||
<em>section will follow the same instructions that are given for the View</em>
|
||||
<em>Tier above.</em></p>
|
||||
</blockquote>
|
||||
<p>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 <code>Need</code> class's <code>hasBeenMet()</code> method.</p>
|
||||
<p>The applications consists of 6 models, used by 4 different file DAOs. The <code>Need</code> model represents an advertised need by a manager that needs fulfillment. The <code>Basket</code> 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.</p>
|
||||
<p>The <code>User</code> model represents a user of the system. It holds the user's credentials and their role. The <code>User</code> model is used by the <code>UsersDAO</code> to manage users. The <code>UsersDAO</code> is responsible for managing users and their roles. It is also responsible for authenticating users and registering new users.</p>
|
||||
|
@ -452,7 +435,9 @@
|
|||
<h3 id="future-design-improvements">Future Design Improvements</h3>
|
||||
<p>The following are future design improvements that the team would explore if the team had additional time:</p>
|
||||
<ul>
|
||||
<li>The team would explore refactoring the code to improve the maintainability of the code. The team would also explore refactoring the code to improve the testability of the code, including automated frontend testing.</li>
|
||||
<li>The team would explore refactoring the code to improve the maintainability of the code. The team would also explore refactoring the code to improve the testability of the code, including automated frontend testing. This would also include reorganisation of the UI code to be more clearly stored in unique folders, for ease of readability.</li>
|
||||
<li>The team would look into resolving both API-level and UI-level issues as listed in Static Code Analysis.</li>
|
||||
<li>The team would look into resolving minor UX issues, such as buttons only working if the mouse does not leave the button during activation.</li>
|
||||
<li>The team would have liked to redesign the UI to improve the user experience. The team would have liked to improve the UI by adding more features, such as advanced filters for searching needs.</li>
|
||||
<li>The team would have liked to implement the second 10% feature, which would have allowed managers to create deals on needs, adding incentives for helpers to fund needs at specific times.</li>
|
||||
</ul>
|
||||
|
|
|
@ -149,33 +149,39 @@ Both the ViewModel and Model are built using Java and Spring Framework. Details
|
|||
|
||||
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.
|
||||
The UI of the web application is structured such that it provides a unique experience for either helpers, managers, or unregistered users (guests). Guest users can only access the login page or register as 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. Managers have an interface for pushing notifications to helpers subscribed to a need, which is done through their cupboard. Helpers have an interface for viewing their notifications inbox and managing their subscriptions, which is a separate tab only accessible to helpers.
|
||||
|
||||
### 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._
|
||||
the view tier is responsible for displaying the site to the user. It takes information provided by the ViewModel tier and displays it to the user.
|
||||
The view tier is made up of component classes that provide the angular implementation as well as HTML/CSS to display the website such as the `add-edit.component.*` files
|
||||
|
||||

|
||||
This tier consists of multiple different directories with multiple files within. Each of these covers a different section of functionality for the admin or the helper.
|
||||
The `managment` directory contains the add-edit, list, and push components which control multiple important actions for the admin on the site.
|
||||
There are other components for every other function of the site as well.
|
||||
|
||||
> _**[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._
|
||||
The following is a sequence diagram of the view tier for performing the action of adding a need to the funding basket. It shows the flow of information from the view to the view model tier. The diagram shows that the view tier is responsible for displaying the site to the user.
|
||||
|
||||

|
||||
|
||||
The diagrams shows the flow of the logic within the view tier, and how it connects to the viewModel tier. The View tier uses the logic from the viewModel tier to perform different processes and actions.
|
||||
The angular logic of the view tier takes information provided by the viewModel tier to create a proper display of said information to the user.
|
||||
|
||||
The following is a sequence diagram of the view tier for performing the action of removing a need from the cupboard. It shows the flow of information from the view to the view model tier.
|
||||
|
||||

|
||||
|
||||
The diagrams shows the flow of the logic within the view tier, which involves propagating the intent to the ViewModel tier (controllers) through an HTTP request. The controller then uses the logic from the viewModel tier to perform different processes and actions, returning a response to the View tier to display to the user through HTTP responses.
|
||||
|
||||
### 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._
|
||||
|
||||
The view model tier is responsible for providing the view with the data it needs. It is also responsible for providing the view with abstraction layer to the logic of manipulating data (business logic), such as the `CupboardController` class's `createNeed()` method. The view model tier is made up of controller classes that provide the view with endpoints that can be queries using HTTP requests to perform tasks or request information.
|
||||
|
||||
This tier consists of 4 controller classes, each of which is responsible for a single functionality. The `CupboardController` class is responsible for managing needs in cupboards for managers. The `BasketController` class is responsible for managing funding baskets of helpers, including checking out with the basket. The `NotificationsController` class is responsible for managing notifications, including pushing new notifications and requesting inbox of messages. The `UserController` class is responsible for managing users, including authenticating users and registering new users.
|
||||
|
||||
The class diagrams show that the controller classes access DAO classes to handle the logic of the application, which holds the business logic of the application. This allows the controller classes to focus on providing the view with endpoints that can be queries using HTTP requests, while allowing the DAO classes to focus on handling the business logic of the application and models for storing the data.
|
||||
|
||||
```mermaid
|
||||
classDiagram
|
||||
|
@ -220,9 +226,6 @@ classDiagram
|
|||
```
|
||||
|
||||
### 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.
|
||||
|
||||
|
@ -460,7 +463,9 @@ The results show that the UI has 3 critical issues, all of which are due to inte
|
|||
|
||||
The following are future design improvements that the team would explore if the team had additional time:
|
||||
|
||||
* The team would explore refactoring the code to improve the maintainability of the code. The team would also explore refactoring the code to improve the testability of the code, including automated frontend testing.
|
||||
* The team would explore refactoring the code to improve the maintainability of the code. The team would also explore refactoring the code to improve the testability of the code, including automated frontend testing. This would also include reorganisation of the UI code to be more clearly stored in unique folders, for ease of readability.
|
||||
* The team would look into resolving both API-level and UI-level issues as listed in Static Code Analysis.
|
||||
* The team would look into resolving minor UX issues, such as buttons only working if the mouse does not leave the button during activation.
|
||||
* The team would have liked to redesign the UI to improve the user experience. The team would have liked to improve the UI by adding more features, such as advanced filters for searching needs.
|
||||
* The team would have liked to implement the second 10% feature, which would have allowed managers to create deals on needs, adding incentives for helpers to fund needs at specific times.
|
||||
|
||||
|
|
Binary file not shown.
File diff suppressed because one or more lines are too long
Before Width: | Height: | Size: 20 KiB |
4
docs/sequence-diagram-1.svg
Normal file
4
docs/sequence-diagram-1.svg
Normal file
File diff suppressed because one or more lines are too long
After Width: | Height: | Size: 20 KiB |
4
docs/sequence-diagram-2.svg
Normal file
4
docs/sequence-diagram-2.svg
Normal file
File diff suppressed because one or more lines are too long
After Width: | Height: | Size: 14 KiB |
Loading…
Add table
Reference in a new issue