Merge branch 'ui_enchancements' of https://github.com/Arquisoft/wiq_en3a

 into ui_enchancements

docs/src/01_introduction_and_goals.adoc

@@ -64,6 +64,10 @@ See https://docs.arc42.org/section-1/[Introduction and Goals] in the arc42 docum
 | Reliability  | Ensure consistent and accurate question generation and user data management.
 | Performance  | Optimize system response times and capacity to handle multiple user interactions simultaneously.
 | Security     | Implement robust security measures to protect user data and prevent unauthorized access.
+| Usability    | Provide an intuitive and user-friendly interface to enhance user experience.
+| Portability  | Enable seamless deployment and operation across different environments and platforms.
+| Testability  | Facilitate comprehensive testing to ensure software correctness and identify potential issues early.
+| Availability | Ensure system uptime and accessibility to meet user demands and minimize downtime.
 |===
 
 
@@ -109,15 +113,15 @@ These stakeholders determine the extent and the level of detail of your work and
 Table with role names, person names, and their expectations with respect to the architecture and its documentation.
 ****
 
-[options="header",cols="1,2,2"]
+[options="header",cols="1,3,2"]
 
 
 |===
 | Role/Name     | Contact          | Expectations
 | Users         | N/A              | Intuitive and enjoyable quiz experience
-| Professors    | Pablo Gonzalez, Jose Labra  | The well-designed web application that fulfills the requirements
-| RTVE          | Project Manager  | Reliable and engaging platform for users
-| HappySw Team  | Development Team | Clear documentation and reliable system performance
+| Professors    | Pablo González ([email protected]), Jose Emilio Labra ([email protected]) | The well-designed web application that fulfills the requirements
+| RTVE          | www.rtve.es  | Reliable and engaging platform for users
+| Development   | Sergio Truébano Robles ([email protected]), Pedro Limeres Granado ([email protected]), Alberto Guerra Rodas ([email protected]), Ángel Macías Rodríguez ([email protected]), Rita Fernández-Catuxo Ortiz ([email protected]), Vira Terletska ([email protected]), Sergio Llenderrozos Piñera ([email protected]) | Clear documentation and reliable, performant and available system
 |===
 
 

docs/src/02_architecture_constraints.adoc

@@ -6,6 +6,8 @@ ifndef::imagesdir[:imagesdir: ../images]
 When designing the WIQ application, there are several constraints that must be taken into consideration, as they will have a significant impact on the overall design of the application and the architectural decisions. These constraints must be considered in order to ensure that the final product meets the needs and expectations of the users and stakeholders. The following table summarizes these constraints and provides a brief explanation for each one divided into technical, organizational and political constraints.
 
 === Technical constraints
+
+[options="header"]
 |===
 |Constraint|Explanation
 | WikiData | Our application must generate questions automatically getting data from WikiData 
@@ -15,6 +17,8 @@ When designing the WIQ application, there are several constraints that must be t
 |===
 
 === Organizational constraints
+
+[options="header"]
 |===
 |Constraint|Explanation
 | Team | The project will be done in a team composed of 7 students, so work must be assigned accordingly.
@@ -24,6 +28,8 @@ When designing the WIQ application, there are several constraints that must be t
 |===
 
 === Political constraints
+
+[options="header"]
 |===
 |Constraint|Explanation
 | Documentation | We are going to use AsciiDoc and follow the Arc42 template. 

docs/src/03_system_scope_and_context.adoc

@@ -50,7 +50,7 @@ The title of the table is the name of your system, the three columns contain the
 
 image::03_business_context.png["Business Context Diagram"]
 
-[cols="1,1,1" options="header"]
+[cols="1,1,1", options="header"]
 |===
 | **Partner** | **Input** | **Output**
 | User  | The user interacts with the WIQ web application using the front-end of the application. | The display of a page of the application with the questions and statistics.
@@ -77,7 +77,7 @@ together with a mapping table showing the relationships between channels and inp
 ****
 
 .Table of the Technical Context
-[cols="2,2"]
+[cols="2,2", options="header"]
 |===
 | **Component** | **Technologies Used**
 | Front-end      | HTML, CSS (Tailwind), JavaScript (React)
@@ -93,7 +93,7 @@ image::3_2-Technical-Context-Diagram-EN.png["Technical Context"]
 
 
 .Mapping Input/Output to Channels
-[cols="2,2"]
+[cols="2,2", options="header"]
 |===
 | **Component** | **Functionality**
 | Front-end | User interaction and results display.

docs/src/04_solution_strategy.adoc

@@ -42,6 +42,9 @@ See https://docs.arc42.org/section-4/[Solution Strategy] in the arc42 documentat
 * *npm*: default package manager for Node.js, providing a command-line interface to install, manage, and publish JavaScript packages. With over a million packages available in its registry, npm simplifies adding functionality to Node.js projects by handling dependencies and providing tools for versioning and publishing packages.
 * *Docker*: platform that will be used for deploying our services inside containers. Containers are lightweight, portable, and self-sufficient units that contain everything needed to run an application, including the code, runtime, system tools, libraries, and settings. Docker enables developers to package their applications along with all dependencies into containers, ensuring consistency across different environments, such as development, testing, and production.
 * *GitHub Actions*: built-in automation tool on GitHub that allows us to automate some workflows that are triggered after some specific github branches actions at development. It provides as continuous integration of the game functionality.
+* *Gatling*: Load test tool that allows us to record some user interaction from our application and simulate it as if various differnet users were accessing the application.
+* *Prometheus*: monitoring and alerting toolkit designed for reliability and scalability. It collects metrics from configured targets at specified intervals, stores them efficiently, and provides a powerful query language for analyzing and alerting on these metrics. It's particularly well-suited for dynamic environments like cloud-native applications and microservices architectures.
+* *Grafana*: open-source platform for monitoring and observability, providing customizable dashboards and visualization tools for analyzing metrics, logs, and other data sources. It allows users to create dynamic, interactive dashboards to monitor the health and performance of their systems and applications.
 
 === Technological decisions
 
@@ -54,7 +57,9 @@ As a conclusion, it was worth spending time making the migration for reducing th
 
 * *Microservices*: is an architectural style that structures an application as a collection of loosely coupled services. Each service is independently deployable, scalable, and can be developed using different programming languages, frameworks, or databases.
 In a microservices architecture, each service typically represents a specific business function or capability and communicates with other services through well-defined APIs. This enables teams to work independently on different parts of the application, allowing us to divide the work into different teams avoiding bottlenecks during production.
-* *APIs*: using microservices architecture enforces us to isolate each of the microservices and create well-defined interfaces for accesing those microservices from common gateway, reducing dependencies between services and allowing them to evolve independently. Well-defined interfaces imply not only services independance, but also team members independecance since nobody will need to wait for others for starting working themselves.  
+* *API Gateway*: centralized service that acts as an intermediary between clients and microservices. It serves as a single entry point for all client requests, providing various functionalities by means of routing and redirecting to the specific service in charge of that request They play a crucial role in building scalable and efficient distributed systems by abstracting away complexities and providing a unified interface for clients to interact with all available services.
+* *API*: using microservices architecture enforces us to isolate each of the microservices and create well-defined interfaces for accesing those microservices from common gateway, reducing dependencies between services and allowing them to evolve independently. Well-defined interfaces imply not only services' independance, but also team members independecance since nobody will need to wait for others for starting working themselves.  
+
 
 === Team Organization
 

docs/src/06_runtime_view.adoc

@@ -55,11 +55,12 @@ collections FrontEnd
 collections WikidataService
 database Wikidata
 
-User -> FrontEnd: Start Game
-FrontEnd -> WikidataService: "/GetQuestions"
+
 WikidataService-> Wikidata: Sparql query
 Wikidata-> WikidataService : entitites data
 WikidataService-> WikidataService: createQuestions()
+User -> FrontEnd: Start Game
+FrontEnd -> WikidataService: "/GetQuestions"
 WikidataService-> FrontEnd: Send 10 questions
 FrontEnd -> User: Question 1
 User-> FrontEnd: Answer 1