doc pages update

README.md

@@ -4,16 +4,20 @@
 [![Quality Gate Status](https://sonarcloud.io/api/project_badges/measure?project=Arquisoft_wiq_0&metric=alert_status)](https://sonarcloud.io/summary/new_code?id=Arquisoft_wiq_0)
 [![Coverage](https://sonarcloud.io/api/project_badges/measure?project=Arquisoft_wiq_0&metric=coverage)](https://sonarcloud.io/summary/new_code?id=Arquisoft_wiq_0)
 
-This is a base repo for the [Software Architecture course](http://arquisoft.github.io/) in [2023/2024 edition](https://arquisoft.github.io/course2324.html).
+This is a repo for the [Software Architecture course](http://arquisoft.github.io/) in [2023/2024 edition](https://arquisoft.github.io/course2324.html), modified by Ángel Luis Álvarez Iglesias (uo17919) from the base repo provided by the instructors.
 
 This repo is a basic application composed of several components.
 
 - **Gateway service**. Express service that is exposed to the public and serves as a proxy to the two previous ones.
-- **User service**. Express service that handles the insertion of new users in the system.
+- **User service**. Express service that handles the insertion of new users into the system.
 - **Auth service**. Express service that handles the authentication of users.
+- **Question Service**. Express service that handles the generation and formulation of game questions.
+- **Statistice Service**. Express service that handles the game statistics.
 - **Webapp**. React web application that uses the gateway service to allow basic login and new user features.
 
-Both the user and auth service share a Mongo database that is accessed with mongoose.
+The frontend design of this project was adapted from the frontend of an online MERN course that the student (uo17919) took (you can find the course repository [here](https://github.com/john-smilga/mern-jobify-v2)). The backend, however, follows the microservices architecture proposed for this project.
+
+The user, auth, question and stats service share a Mongo database that is accessed with mongoose.
 
 ## Quick start guide
 

docs/index.adoc

@@ -96,4 +96,10 @@ include::src/11_technical_risks.adoc[]
 // 12. Glossary
 include::src/12_glossary.adoc[]
 
+<<<<
+// 13. Test Report
+include::src/13_test_report.adoc[]
 
+<<<<
+// 14. Application Monitoring
+include::src/14_application_monitoring.adoc[]

docs/src/01_introduction_and_goals.adoc

@@ -2,7 +2,7 @@
 
 == Introduction and Goals
 
-Saber y Ganar is the Software Architecture project developed by Ángel Luis Álvarez Iglesias (uo17919), under the supervision of Jorge Álvarez Fidalgo.
+Wiq7 is a software project created by Ángel Luis Álvarez Iglesias (uo17919) as part of his Software Architecture course.
 
 This project consists of an application that features a question-and-answer game, designed to be both engaging and educational. Additionally, the application offers a statistics tracking system, allowing registered users to view their own performance metrics and compare them with those of other players.
 
@@ -28,7 +28,9 @@ The application is built using the MERN stack, which includes MongoDB for the da
 | RE7
 | The system will give access to information about the generated questions through an API.
 | RE8
-| Allow different game modes like the ones that appear in the quiz show page (Each wise man with his subject, Travel with us, The hot question, Discovering cities, ...).
+| The system will feature the "By Their Work, They Shall Be Known" game mode, as outlined on the quiz show page.
+| RE9
+| The system will feature the "Discovering Cities" game mode, as outlined on the quiz show page.
 |===
 
 === Quality Goals

docs/src/03_system_scope_and_context.adoc

@@ -74,7 +74,7 @@ statsserv -[hidden]l- questionserv
 | Gateway
 | The entry point of the application.
 | User service
-| Manages user registration.
+| Manages user data.
 | Authentication service
 | Manages user authentication.
 | Statistic service

docs/src/05_building_block_view.adoc

@@ -112,7 +112,7 @@ Contained Building Blocks::
 | Gateway
 | The entry point of the application.
 | User service
-| Manages user registration.
+| Manages user data.
 | Authentication service
 | Manages user authentication.
 | Statistic service

docs/src/06_runtime_view.adoc

@@ -2,9 +2,9 @@
 
 == Runtime View
 
-=== User Registration
+=== User Registration and Profile Update
 
-User registration in the application is managed through the user microservice (userservice). The user enters a username and password, and if the user is created successfully, a confirmation message is displayed. Otherwise, an error message is shown.
+User registration and profile update in the application is managed through the user microservice (userservice). The user completes the form, and upon successful submission, a confirmation message is displayed. Otherwise, an error message is shown.
 
 [plantuml, "user_registration", svg]
 ----
@@ -38,8 +38,8 @@ participant authserv as "auth serv"
 participant mongo as "MongoDB"
 
 user --> webapp: enter credentials
-webapp -> gw: get request
-gw -> authserv: get request
+webapp -> gw: post request
+gw -> authserv: post request
 authserv -> mongo: find user
 mongo -> authserv: 200
 authserv -> gw: 200
@@ -49,7 +49,7 @@ webapp --> user: confirmation message
 
 === Play
 
-The quiz game is managed through the authentication microservice (questionservice). The user starts a new game, and a new question with its corresponding answers is displayed.
+The quiz game is managed through the question microservice (questionservice). The user starts a new game, and a new question with its corresponding answers is displayed.
 
 [plantuml, "play", svg]
 ----
@@ -62,7 +62,7 @@ participant mongo as "MongoDB"
 user --> webapp: start game
 webapp -> gw: get request
 gw -> qserv: get request
-qserv -> mongo: find question
+qserv -> mongo: questions
 mongo -> qserv: 200
 qserv -> gw: 200
 gw -> webapp: 200
@@ -73,22 +73,51 @@ webapp --> user: give feedback
 
 === Statistics
 
-The application's statistics module is handled by the statistics microservice (statsservice). Upon user request, the game statistics are presented in a view.
+The application's statistics module is handled by the statistics microservice (statservice). Upon user request, the game statistics are presented in a view.
 
 [plantuml, "stats", svg]
 ----
 actor user
 participant webapp as "webApp"
 participant gw as "gateway"
-participant statsserv as "stats serv"
+participant statserv as "stat serv"
 participant mongo as "MongoDB"
 
 user --> webapp: enter stats page
 webapp -> gw: get request
-gw -> statsserv: get request
-statsserv -> mongo: get stats
-mongo -> statsserv: 200
-statsserv -> gw: 200
+gw -> statserv: get request
+statserv -> mongo: stats
+mongo -> statserv: 200
+statserv -> gw: 200
 gw -> webapp: 200
 webapp --> user: show stats view
 ----
+
+=== Ranking
+
+The application also includes a user ranking, obtained through the statistics (statservice) and user microservices (userservice).
+
+[plantuml, "ranking", svg]
+----
+actor user
+participant webapp as "webApp"
+participant gw as "gateway"
+participant statserv as "stats serv"
+participant userserv as "user serv"
+participant mongo as "MongoDB"
+
+user --> webapp: enter stats page
+webapp -> gw: get request
+gw -> statserv: get request
+statserv -> mongo: ranking
+mongo -> statserv: 200
+statserv -> gw: 200
+gw -> webapp: 200
+webapp -> gw: get request
+gw -> userserv: get request
+userserv -> mongo: find user
+mongo -> userserv: 200
+userserv -> gw: 200
+gw -> webapp: 200
+webapp --> user: show ranking
+----

docs/src/07_deployment_view.adoc

@@ -56,7 +56,7 @@ Gateway <--> "Question Service"
 | Gateway
 | The service that acts as an intermediary between the frontend and other backend services.
 | User Service
-| The service that handles user registration and management.
+| The service that handles user data.
 | Authentication Service
 | The service responsible for user authentication.
 | Statistic Service

docs/src/08_concepts.adoc

@@ -13,37 +13,36 @@ This section describes overall, principal regulations and solution ideas that ar
 rectangle User {
     +userId: String
     +name: String
+    +lastName: String
     +email: String
+    +username: String
     +passwordHash: String
 }
 
-rectangle Game {
-    +gameId: String
-    +userId: String
-    +startTime: Date
-    +endTime: Date
-    +score: Int
-}
-
 rectangle Question {
     +questionId: String
-    +text: String
-    +options: List
-    +correctAnswer: String
+    +name: String
+    +hint1: String
+    +hint2: String
+    +right: String
+    +wrong1: String
+    +wrong2: String
+    +wrong3: String
 }
 
 rectangle Statistic {
     +statId: String
     +userId: String
-    +totalGames: Int
-    +totalScore: Int
-    +averageScore: Float
+    +gameId: String
+    +questionId: String
+    +right: Boolean
+    +time: Int
+    +points: Int
 }
 
-User "1" -- "0..*" Game : participates in
+User "1" -- "0..*" Question : answers
 User "1" -- "0..*" Statistic : has
-Game "1" -- "0..*" Question : includes
-Game "1" -- "0..1" Statistic : generates
+Question "1" -- "0..1" Statistic : generates
 ----
 
 === User Experience Concepts (UX)
@@ -63,7 +62,7 @@ Later, during the login process, passwords are retrieved hashed from the databas
 
 **- Persistency**: The system will use a nosql database (Mongo DB) to store data.
 
-**- Transaction handling**: (todo)
+**- Transaction handling**: Transaction handling in the app begins with the frontend sending a request to the gateway, which routes it to the appropriate microservices. Each service processes its part of the transaction, interacting with the MongoDB database as needed to retrieve or update data. Once all services complete their operations, the results are sent back through the gateway to the frontend.
 
 **- Session handling**: The system will use JWT tokens for session handling.
 

docs/src/11_technical_risks.adoc

@@ -12,4 +12,5 @@ Below is a table presenting the risks and potential technical debts considered b
 | Code loss | The project may suffer from code loss due to a lack of proper version control. | To prevent this, Git will be used as the version control system for managing the code and storing it in a remote repository.
 | Loss of code quality | The project may suffer from a loss of code quality due to the lack of experience with the technologies used. | To prevent this, it is recommended to use code quality tools and to follow best practices.
 | Planning issues | The project may suffer from planning issues due to a lack of experience with project management. | To prevent this, It is recommended to divide the project into activities and tasks, estimate their duration, and allow for potential deviations.
+| Only one developer | The team is composed of a single person. | Unfortunately, there is no way to mitigate this risk, so it must be assumed.
 |===

docs/src/13_test_report.adoc

@@ -0,0 +1,65 @@
+[[test-report]]
+
+== Test Report
+
+Following tests were done to ensure the functionality, performance, and user experience of the application, including unit tests, end-to-end (E2E) tests, load tests, and usability tests.
+These tests aimed to validate individual components, overall system behavior, scalability, and ease of use
+
+=== Unit tests
+Comprehensive unit tests were conducted to ensure the reliability and functionality of the entire application, including both the frontend and the microservices (gateway, user, auth, question, and statistics). The testing approach focused on validating each component in isolation, ensuring proper interaction between the frontend and microservices.
+As a result, an overall test coverage of 80.2% on new code was achieved, reflecting strong code quality and stability. Detailed test results, including coverage breakdowns for each service and component, will be presented in the following section.
+
+=== Code coverage result
+The unit tests coverage, with a detailed breakdown, is shown in Image 13.1. It provides an overview of the coverage across the application's components and services.
+
+image::13_1_codecoverage.png["Sonarcloud code coverage"]
+
+=== E2E tests
+The following end-to-end (E2E) tests were performed to validate key features of the application:
+
+**- Registering a new user**: Tested that an unregistered user could successfully fill out the registration form and receive a confirmation message.
+**- User login**: Ensured that a registered user could log in and see a confirmation message upon successful submission of their credentials.
+**- User profile view**: Verified that a logged-in user could access and view their profile.
+**- User plays game**: Checked that a logged-in user could press play and see a question displayed on the screen.
+
+These tests were executed both locally, with manual browser observation, and headlessly in GitHub Actions. Locally, all tests were successful, but the "User plays game" test failed in GitHub Actions. This issue remains unresolved due to time constraints.
+
+=== Load tests
+
+Load tests were conducted on the application in the production environment using Gatling. The primary goal was to evaluate the login functionality under increasing user load. The following configuration was used for the test:
+
+```javascript
+setUp(scn.injectOpen(rampUsers(1000).during(300))).protocols(httpProtocol);
+```
+
+This setup simulated a gradual increase from 0 to 1000 users over a period of 5 minutes. The results obtained from the tests are summarized below:
+
+**Response Performance**
+
+image::13_4_gatling.png["Main results"]
+
+The results were highly satisfactory. All responses during the simulation were successful (HTTP 200), with response times consistently below 200 milliseconds. This demonstrates the system's ability to handle load efficiently without any significant delays.
+
+**Active Users**
+
+image::13_4_gatling_users.png["Active Users per Second"]
+
+On average, the number of active users per second during the 5-minute simulation was approximately 15. This indicates the system's ability to maintain a steady throughput while accommodating multiple concurrent users.
+
+**Requests per Second**
+
+image::13_4_gatling_responses.png["Responses per Second"]
+
+The average number of responses processed per second during the simulation was 24. This metric reflects the application’s capacity to handle a consistent flow of requests efficiently.
+
+**Response Time Distribution**
+
+image::13_4_gatling_resp_distr.png["Response Time Distribution"]
+
+The maximum response time observed throughout the test was under 200 milliseconds, further confirming the system's stability and quick response under load.
+
+=== Usability tests
+
+Informal usability tests were conducted with a few friends to gather feedback on the application's user experience. During the tests, they navigated through the main features, including registration, login, and playing the game. The feedback was generally positive, with users finding the interface intuitive and easy to use.
+
+The main suggestion for improvement was to reduce the loading time of images fetched from Wikidata. This could be addressed by storing the images locally to enhance performance. Overall, the application met their expectations for usability.

docs/src/14_application_monitoring.adoc

@@ -0,0 +1,4 @@
+[[application-monitoring]]
+
+== Application Monitoring
+

webapp/e2e/features/play-game.feature

@@ -1,4 +1,4 @@
-Feature: User plays game 1
+Feature: User plays game
 
 Scenario: The user is logged in
   Given a logged user