diff options
| -rw-r--r-- | bash.exe.stackdump | 28 | ||||
| -rw-r--r-- | docs/CodeCoverage.png | bin | 33191 -> 33047 bytes | |||
| -rw-r--r-- | docs/DesignDoc.md | 120 | ||||
| -rw-r--r-- | ufund-ui/.scannerwork/.sonar_lock | 0 | ||||
| -rw-r--r-- | ufund-ui/.scannerwork/report-task.txt | 6 |
5 files changed, 106 insertions, 48 deletions
diff --git a/bash.exe.stackdump b/bash.exe.stackdump new file mode 100644 index 0000000..4c939da --- /dev/null +++ b/bash.exe.stackdump @@ -0,0 +1,28 @@ +Stack trace: +Frame Function Args +0007FFFFA350 00021005FEBA (000210285F48, 00021026AB6E, 000000000000, 0007FFFF9250) msys-2.0.dll+0x1FEBA +0007FFFFA350 0002100467F9 (000000000000, 000000000000, 000000000000, 0007FFFFA628) msys-2.0.dll+0x67F9 +0007FFFFA350 000210046832 (000210285FF9, 0007FFFFA208, 000000000000, 000000000000) msys-2.0.dll+0x6832 +0007FFFFA350 000210068F86 (000000000000, 000000000000, 000000000000, 000000000000) msys-2.0.dll+0x28F86 +0007FFFFA350 0002100690B4 (0007FFFFA360, 000000000000, 000000000000, 000000000000) msys-2.0.dll+0x290B4 +0007FFFFA630 00021006A49D (0007FFFFA360, 000000000000, 000000000000, 000000000000) msys-2.0.dll+0x2A49D +End of stack trace +Loaded modules: +000100400000 bash.exe +7FFB97CA0000 ntdll.dll +7FFB96B20000 KERNEL32.DLL +7FFB94F90000 KERNELBASE.dll +7FFB970B0000 USER32.dll +7FFB94F60000 win32u.dll +7FFB96AE0000 GDI32.dll +7FFB958E0000 gdi32full.dll +000210040000 msys-2.0.dll +7FFB95630000 msvcp_win.dll +7FFB954E0000 ucrtbase.dll +7FFB97860000 advapi32.dll +7FFB97000000 msvcrt.dll +7FFB972C0000 sechost.dll +7FFB95AC0000 RPCRT4.dll +7FFB944A0000 CRYPTBASE.DLL +7FFB95A20000 bcryptPrimitives.dll +7FFB96940000 IMM32.DLL diff --git a/docs/CodeCoverage.png b/docs/CodeCoverage.png Binary files differindex ef835fd..723aa02 100644 --- a/docs/CodeCoverage.png +++ b/docs/CodeCoverage.png diff --git a/docs/DesignDoc.md b/docs/DesignDoc.md index 01287c8..651465d 100644 --- a/docs/DesignDoc.md +++ b/docs/DesignDoc.md @@ -1,36 +1,48 @@ --- geometry: margin=1in --- + # PROJECT Design Documentation ## Team Information -* Team name: Jelly Solutions -* Team members - * Ben Almstead - * Tyler Ferrari - * Hayden Hartman - * Akash Keshav - * Angelina Zhen + +- 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. +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._ - +> _**[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 | +> _**[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 | ## Requirements @@ -39,18 +51,21 @@ 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 +> story. Focus on top-level features from the Vision document and > maybe Epics and critical Stories._ ### 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. 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. Needs are saved so users and managers will see when they are updated. ### MVP Features -> _**[Sprint 4]** Provide a list of top-level Epics and/or Stories of the MVP._ + +> _**[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._ Security @@ -67,14 +82,14 @@ Security - 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 +- 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 @@ -94,13 +109,14 @@ This section describes the application architecture. ### Summary -The following Tiers/Layers model shows a high-level view of the webapp's architecture. +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 web application is built using the Model–View–ViewModel (MVVM) architecture pattern. +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. @@ -108,14 +124,12 @@ The View is the client-side SPA built with Angular utilizing HTML, CSS and TypeS 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]** )_ - +> _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:  @@ -146,26 +160,28 @@ Need page: Funding basket:  - ### 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 +> 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 +> _**[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 +> 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._ +> +> - _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 @@ -186,10 +202,11 @@ Requests are sent from the view tier and handled by controllers. For example, wh > _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.)_ -> - +> +>  ### 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. @@ -202,8 +219,8 @@ In our model tier we have a Need class, a User class, and a UserAuth class. The > _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.)_ -> - +> +>  ## OO Design Principles @@ -223,14 +240,16 @@ In our model tier we have a Need class, a User class, and a UserAuth class. The > _**[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 + +> _**[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 + > _This section will provide information about the testing performed > and the results of the testing._ @@ -239,6 +258,7 @@ Currently around 115 tests, with roughly 90% coverage overall. Model tier is abo ### Acceptance Testing We have 24 passing Acceptance Tests and 5 failing Acceptance Tests. 4 of these failures are unable to be tested because of a missing feature, as it is not a requirement for our sprint backlog. All issues that have been found are easily fixable during the next sprint. + > _**[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 @@ -246,6 +266,7 @@ We have 24 passing Acceptance Tests and 5 failing Acceptance Tests. 4 of these f > 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 @@ -253,13 +274,16 @@ We have 24 passing Acceptance Tests and 5 failing Acceptance Tests. 4 of these f 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 +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._  ## 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._ + +> _**[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.** @@ -267,4 +291,4 @@ Our unit testing strategy was to use a consistent styles of test across our pers **(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.**
\ No newline at end of file +**(2025/04/03): Sprint #3: Unanimously decided on enhancements, while narrowing focus on what needs to be finished for the sprint.** diff --git a/ufund-ui/.scannerwork/.sonar_lock b/ufund-ui/.scannerwork/.sonar_lock new file mode 100644 index 0000000..e69de29 --- /dev/null +++ b/ufund-ui/.scannerwork/.sonar_lock diff --git a/ufund-ui/.scannerwork/report-task.txt b/ufund-ui/.scannerwork/report-task.txt new file mode 100644 index 0000000..bd04884 --- /dev/null +++ b/ufund-ui/.scannerwork/report-task.txt @@ -0,0 +1,6 @@ +projectKey=typescript-ufund +serverUrl=http://localhost:9000 +serverVersion=25.3.0.104237 +dashboardUrl=http://localhost:9000/dashboard?id=typescript-ufund +ceTaskId=c64c4ea3-3003-491d-a51d-2169aff045fd +ceTaskUrl=http://localhost:9000/api/ce/task?id=c64c4ea3-3003-491d-a51d-2169aff045fd |
