Documentation WIQ-ES05C

1. Introduction and Goals (wiq_es05c)

WIQ is a Web application requested by RTVE, in order to create an experimental online version of a question and answer contest similar to “Saber y Ganar”. The development of said application has been entrusted to our company, HappySw.

1.1. Requirements Overview

The main requirements to be met by our application will be found here.

1.2. Quality Goals

Goals	Description
Usability	The user must be able to use the system in a simple and intuitive way, so that a good experience is provided.
Accessibility	The system should be designed to be accessible to all users, including those with visual, auditory, motor, or cognitive disabilities. It should provide necessary accommodations to ensure seamless navigation and usage of the program.
Privacy	The system must ensure the privacy of users. In addition, they will not see the data of other users.
Performance	The application must have good performance, without excessive loading times.

Goals

Description

Usability

The user must be able to use the system in a simple and intuitive way, so that a good experience is provided.

Accessibility

The system should be designed to be accessible to all users, including those with visual, auditory, motor, or cognitive disabilities. It should provide necessary accommodations to ensure seamless navigation and usage of the program.

Privacy

The system must ensure the privacy of users. In addition, they will not see the data of other users.

Performance

The application must have good performance, without excessive loading times.

1.3. Stakeholders

Role/Name	Expectations
HappySw	Committed to delivering a high-quality application that meets user needs and client expectations, while also driving business success and growth.
Developer Team	Interested in improving their skills by completing this application.
RTVE	Interested in the social and financial success of the application. Seeks to increase audience through the popularity of the program.
Users	Interested in the application being entertaining and simple. Contributes to the popularity of the program through usage and word-of-mouth.

Role/Name

Expectations

HappySw

Committed to delivering a high-quality application that meets user needs and client expectations, while also driving business success and growth.

Developer Team

Interested in improving their skills by completing this application.

RTVE

Interested in the social and financial success of the application. Seeks to increase audience through the popularity of the program.

Users

Interested in the application being entertaining and simple. Contributes to the popularity of the program through usage and word-of-mouth.

2. Architecture Constraints

Each of the following constraints plays a crucial role in the formation of the software architecture and in determining the best practices for the development team. Next, we will explain the ones that the team must comply with.

1.Technical Constraints

Constraint	Description
Wikidata	Wikidata is a knowledge base that provides data sources, used to obtain information for the game. In this case, it is mandatory.
Docker	Software that allows automating the deployment of applications. The application will be running on a Docker host.
GitHub	A cloud storage service for collaborative application development, which facilitates effective communication, manages the tracking of different project versions, and distributes responsibilities equitably among team members.

Constraint

Description

Wikidata

Wikidata is a knowledge base that provides data sources, used to obtain information for the game. In this case, it is mandatory.

Docker

Software that allows automating the deployment of applications. The application will be running on a Docker host.

GitHub

A cloud storage service for collaborative application development, which facilitates effective communication, manages the tracking of different project versions, and distributes responsibilities equitably among team members.

2.Organizational Constraints

Constraint	Description
Team	A team formed by 5 individuals who will need to learn to work and coordinate together.
Time	The team will need to present the project with new advancements, adapting to the anticipated delivery dates, as well as what has been established in the minutes taken during the weekly team meetings.
Meetings	Every week there will be a meeting among the team members where problems will be discussed, the work that each member should do for the next meeting will be established, and the work done to date will be reviewed.

Constraint

Description

Team

A team formed by 5 individuals who will need to learn to work and coordinate together.

Time

The team will need to present the project with new advancements, adapting to the anticipated delivery dates, as well as what has been established in the minutes taken during the weekly team meetings.

Meetings

Every week there will be a meeting among the team members where problems will be discussed, the work that each member should do for the next meeting will be established, and the work done to date will be reviewed.

3.Convention Constraints

Constraint	Description
Documentation	Arc42 is a template for architecture documentation. It is the one we should use to generate the documentation.
Clean Code	he code should follow an order that does not pose any problem for another team member to understand. In addition, good practices such as naming conventions should be followed.
Structure	The project must follow a fixed structure, both the documentation and the code must be done under the same standards.

Constraint

Description

Documentation

Arc42 is a template for architecture documentation. It is the one we should use to generate the documentation.

Clean Code

he code should follow an order that does not pose any problem for another team member to understand. In addition, good practices such as naming conventions should be followed.

Structure

The project must follow a fixed structure, both the documentation and the code must be done under the same standards.

3. System Scope and Context

3.1. Business Context

Users authenticate themselves within the system using their personal information. The application offers a question-based game similar to "Saber y Ganar" . Additionally, users can check the ranking of all players. Furthermore, users have access to various metrics regarding their participation, including the number of games played, correct and incorrect answers, and time spent on each question .

Element	Description
User	The user will be able to utilize the functionalities of login, register, and the game to answer the questions.
Application	The application will communicate with the WikiData to retrieve game questions and answers, and it will store them in a database. Additionally, when prompted by the system, it will retrieve a question along with the four answer options from the database.

Element

Description

User

The user will be able to utilize the functionalities of login, register, and the game to answer the questions.

Application

The application will communicate with the WikiData to retrieve game questions and answers, and it will store them in a database. Additionally, when prompted by the system, it will retrieve a question along with the four answer options from the database.

3.2. Technical Context

Element	Description
User service	Express service that handles the insertion of new users in the system.
QuestionsService	Express Service for managing questions and answers. This service handles searching for questions and answers, as well as their insertion into and retrieval from the database.
HistoryService	Express service that handles the game results of the logged-in player
RoomService	Express service that is responsible for managing the multiplayer functionality of the game.
Webapp	Frontend of the application that uses the gateway service to allow basic login and new user features.
WikiData	API used by the system to obtain questions and answers.
MongoDB	A MongoDB database to store questions and answers, as well as user information such as usernames and passwords.

Element

Description

User service

Express service that handles the insertion of new users in the system.

QuestionsService

Express Service for managing questions and answers. This service handles searching for questions and answers, as well as their insertion into and retrieval from the database.

HistoryService

Express service that handles the game results of the logged-in player

RoomService

Express service that is responsible for managing the multiplayer functionality of the game.

Webapp

Frontend of the application that uses the gateway service to allow basic login and new user features.

WikiData

API used by the system to obtain questions and answers.

MongoDB

A MongoDB database to store questions and answers, as well as user information such as usernames and passwords.

Technologies	Description
JavaScript	A fundamental programming language for web development. It’s used to create logic and interactivity in web and mobile applications.
React	A JavaScript framework used to build interactive and dynamic user interfaces. It’s especially popular for developing single-page applications (SPAs).
MongoDB	A NoSQL database that uses JSON documents to store data. It’s widely used in web and mobile applications, especially those requiring flexible and fast scalability.
Docker	Contenerization platform that simplifies the deployment and management of applications. It allows packaging an application and all its dependencies into lightweight, portable containers, making it easy to deploy across different development and production environments.
GitHub Actions	GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. You can create workflows that build and test every pull request to your repository, or deploy merged pull requests to production.
Express	Express.js is a fast and minimalist web framework for Node.js. It is used to create scalable and efficient web applications. With Express.js, developers can quickly and easily build robust and customizable web servers.

Technologies

Description

JavaScript

A fundamental programming language for web development. It’s used to create logic and interactivity in web and mobile applications.

React

A JavaScript framework used to build interactive and dynamic user interfaces. It’s especially popular for developing single-page applications (SPAs).

MongoDB

A NoSQL database that uses JSON documents to store data. It’s widely used in web and mobile applications, especially those requiring flexible and fast scalability.

Docker

Contenerization platform that simplifies the deployment and management of applications. It allows packaging an application and all its dependencies into lightweight, portable containers, making it easy to deploy across different development and production environments.

GitHub Actions

GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. You can create workflows that build and test every pull request to your repository, or deploy merged pull requests to production.

Express

Express.js is a fast and minimalist web framework for Node.js. It is used to create scalable and efficient web applications. With Express.js, developers can quickly and easily build robust and customizable web servers.

4. Solution Strategy

4.1. Technology Decisions

The following technologies are used in the development of our application:

React: We chose React as our JavaScript library for building user interfaces due to its efficiency, flexibility, and the ability to create reusable UI components. React is also a popular framework that we had not previously worked with and were interested in learning. This choice aligns with our goal of maintaining a consistent and efficient codebase while expanding our technical skills. Link to the architectural decision * Architecture Decision 1-Language Selection for documentation
JavaScript: JavaScript was chosen as the language for application development due to its versatility, wide support across various platforms, and its status as the standard language for web development. Additionally, using JavaScript both on the client and server sides allows for a more streamlined and efficient development process. Link to the architectural decision * Architecture Decision 1-Language Selection for documentation
MongoDB: MongoDB was selected as our database due to its scalability and flexibility in handling data. This non-relational database aligns with our needs for a fluid and intuitive data handling process. While MySQL, a relational database, offers structured query language and consistency, we opted for MongoDB because it provides more flexibility in terms of data storage and retrieval, which is more suitable for our application’s needs. Link to the architectural decision * Architecture Decision 3-Database Platform === Top-level Decomposition ==== IDE We have chosen Visual Studio Code as our platform since we have experience with it and it is the platform we will work best with.

4.1.1. Diagram design tools

We will use PlantUML as the tool for creating diagrams since it is the recommended one for the course. We use PowerPoint for the business context diagrams. We use Draw.io for the building block view diagrams.

4.2. Key Quality Goals

Usability: The application should be easy to use, intuitive, and self-explanatory, providing a good user experience.
Performance: As a quiz game, the application should respond quickly to user interactions to avoid wait times during gameplay. This ensures a smooth and engaging user experience.
Security: The application should protect user data and prevent unauthorized access.
Maintainability: The code should be easy to understand, modify, and extend, allowing for easy updates and improvements.
Scalability: The application should be able to handle an increasing number of users and data without performance issues.
Availability: The application should be available for use at all times and across different devices, ensuring that users can play the game whenever and wherever they want.
Adaptability: The application should be adaptable to different devices, including desktops, tablets, and mobile phones. This ensures that the game can reach a wider audience and provide a good user experience regardless of the device used.

4.3. Organizational decisions

Here are the organization decisions made:

Language: We will use English as the primary language for both documentation and code.
GitHub issues: We will use GitHub issues as the main source for problem resolution, so that whenever something poses an obstacle, it will be documented in GitHub issues.

5. Building Block View

5.1. Whitebox WIQ

Motivation: The motivation for performing this decomposition is to obtain a clear view of the system developed for the WIQ application. By breaking the system down into its basic components, we aim to establish a comprehensive understanding of its structure and functionality.
Contained Building Blocks

Name	Responsibility
Webapp	Provides the interface to do everything necessary in the application, sign in, sign up, sign out, play the different game modes, view the history and the ranking of the daily questions
Gateway service	The API Gateway is a server that handles many functionalities in a single place for the clients to interact. In also works as a reverse proxy between your client applications and the back-end microservices architecture.
Authservice	Microservice that is responsible of checking the credentials of the user who wants to log in and storing the last game of the daily question for the correct operation of that game mode
Userservice	Microservice that is responsible to check the correct validity of the data entered by the user and add the user if everything is correct
Roomservice	Microservice that is responsible to manage the questions in the room, the users and the rooms.
Historyservice	Microservice that is responsible for saving and returning the history of user games, update the user daily question history and return a ranking of the daily history.
Questionservice	Microservice that is responsible to generate the different Wikidata questions through an automatic generation using Wikidata, returns the generated questions from the database and generates the daily question.
Databases	Stores information about users, games, questions and history

Name

Responsibility

Webapp

Provides the interface to do everything necessary in the application, sign in, sign up, sign out, play the different game modes, view the history and the ranking of the daily questions

Gateway service

The API Gateway is a server that handles many functionalities in a single place for the clients to interact. In also works as a reverse proxy between your client applications and the back-end microservices architecture.

Authservice

Microservice that is responsible of checking the credentials of the user who wants to log in and storing the last game of the daily question for the correct operation of that game mode

Userservice

Microservice that is responsible to check the correct validity of the data entered by the user and add the user if everything is correct

Roomservice

Microservice that is responsible to manage the questions in the room, the users and the rooms.

Historyservice

Microservice that is responsible for saving and returning the history of user games, update the user daily question history and return a ranking of the daily history.

Questionservice

Microservice that is responsible to generate the different Wikidata questions through an automatic generation using Wikidata, returns the generated questions from the database and generates the daily question.

Databases

Stores information about users, games, questions and history

5.2. Level 2

5.2.1. White Box Users Services

Name	Responsibility
authservice	Exposes API endpoints that enable the authentication of a user by verifying their existence in the database and ensuring the correctness of the provided password and update the date of the last daily game.
userservice	Exposes API endpoint that enable the registration of a user. It validates user registration details by checking the uniqueness of the email and username in the database, as well as verifying the format and correctness of the provided password, ensuring it matches the repeated entry.
userdb	The user database stores user information, including their email, username, hashed password and the last day the user played the daily. Each user have their credentials securely stored for authentication purposes.

Name

Responsibility

authservice

Exposes API endpoints that enable the authentication of a user by verifying their existence in the database and ensuring the correctness of the provided password and update the date of the last daily game.

userservice

Exposes API endpoint that enable the registration of a user. It validates user registration details by checking the uniqueness of the email and username in the database, as well as verifying the format and correctness of the provided password, ensuring it matches the repeated entry.

userdb

The user database stores user information, including their email, username, hashed password and the last day the user played the daily. Each user have their credentials securely stored for authentication purposes.

5.2.2. White Box Questionservice

Name	Responsibility
questionservice	Exposes API endpoints that enable generate questions by making a call to the Wikidata, retrieving relevant information, and subsequently saving the generated question in the database. Additionally, it is responsible for providing questions tailored for each type of game available in the application.
questionsdb	The questions database stores the question along with their correct answer, the category to which the question belongs, the type of the question and the answers to those questions.

Name

Responsibility

questionservice

Exposes API endpoints that enable generate questions by making a call to the Wikidata, retrieving relevant information, and subsequently saving the generated question in the database. Additionally, it is responsible for providing questions tailored for each type of game available in the application.

questionsdb

The questions database stores the question along with their correct answer, the category to which the question belongs, the type of the question and the answers to those questions.

5.2.3. White Box Historyservice

Name	Responsibility
historyservice	Exposes API endpoints that enable the storage of data for each normal game played and providing access to this data in two formats. It offers two types of data retrieval: one that returns all normal games played with their respective data, and another that returns the complete history, encompassing all data related to every game played.
historydb	The historydb stores user data and maintains a record of each normal game played. For every game, it saves essential details including the game number, the number of correct questions, the number of failed questions, the time taken to complete the game, and the date on which it was played.

Name

Responsibility

historyservice

Exposes API endpoints that enable the storage of data for each normal game played and providing access to this data in two formats. It offers two types of data retrieval: one that returns all normal games played with their respective data, and another that returns the complete history, encompassing all data related to every game played.

historydb

The historydb stores user data and maintains a record of each normal game played. For every game, it saves essential details including the game number, the number of correct questions, the number of failed questions, the time taken to complete the game, and the date on which it was played.

6. Runtime View

The GatewayService is the micro-service that redirect all the ruequests to all the other micro-services such as AuthService or QuestionService but that is not directly pointed out in the diagrams.

6.1. Register user

The user wants to register in the sistem
The app redirects the register request to the RegisterService
The register service sends to the database the data to get information about it
A response is sent by the database with information about that user in process of registration
The RegisterService validates if the user is correct with that info recieved
If the check was afirmative then the RegisterService registre the user
The RegisterService inform with the result the app
Finally the app carries that result to the user

6.2. Login

The user wants to login his account
The app redirects the login request to the LoginService
The LoginService request information about that login data recieved
A answer is sent by the database with the requested data
After checking if it’s a valid login the LoginService sends a response to the app
Finally the app inform the user about his login process

6.3. Generate a question

The QuestionService wants to generate a question
It requests all the necesary info to build a question to WikiData
WikiData responds with the requested data
The QuestionService builds the question with the data recieved
Finally the QuestionService writes the new question in the QuestionsDB

6.4. Request a question

The App needs a new question to show to the user so uses Rest to comunicate with the QuestionService
The QuestionService requests that random question to our MongoDB of questions
The DB sends that question to the QuestionService
The QuestionService send again that question to the app so the user can continue with his experience

6.5. Request user’s history

The user wants to see his history
The app requests that user’s data and games to the HistoryService
The HistoryService gathers all the data needed from the History data base
The history service sends back that data to the Application where is processed
All the games and statistics are shown to the user

6.6. Request ranking

The user wants to see the ranking of all players
The app requests to the HistoryService that ranking
The HistoryService gets the ranking from the History data base
Finally the ranking is shown to the user

6.7. Multiplayer game

Two users want to join a room and play a multiplayer game
The application sends a request to the RoomsService
This RoomsService where a room was created moments ago create a socket for each player
The RoomsService gets from the app the game details, questions and logic.
All the game is managed by the RoomsService
When the game is finished the RoomsService sends a response to the application
Then the application sends all the results to the players

7. Deployment View

The application is hosted in a virtual machine type Linux ubuntu 20.04 gen2 and has open the port 3000 and 8000 so that it’s possible to connect via HTTP using a basic browser.

All the application is deploid over docker. Each of the represented elements are a docker container (also the databases) and they are based on microservices architecture so they can communicate between them with HTTP and BD connections.

8. Cross-cutting Concepts

8.1. Domain concepts

Visit https://github.com/Arquisoft/wiq_es05c/wiki/Domain-Model to consult our Domain model.

8.2. User Experience

The user interface is the part of our application with which users interact directly. It’s designed to be intuitive and easy to use, providing a smooth and pleasant experience for users as they navigate through the various functions and features of the application.

The user will either register in the application or log in if they have already registered before. If they have played before, they will be able to view different metrics regarding those games. Additionally, they can start a new game at any time and, upon completion, view the statistics of their results.

Here you can see the home page of our webapp.

8.3. Security & Safety

Privacy: The data introduced will be private and not visible to other users.
The password will be stored encrypted.

8.4. Architecture and design patterns

The State pattern is a behavioral design pattern used to model situations where an object must change its behavior based on its internal state. Instead of having a single method that handles all possible actions, the State pattern divides actions into separate classes, each representing a different state. Each state class implements a common interface, allowing the main object to transition from one state to another without affecting its overall functionality.

Each state has its own logic and specific rules. The State pattern enables the game to dynamically adapt to the player’s current state.

Microservices are an architectural and organizational approach to software development. In our model, software is composed of small, independent services that communicate through well-defined APIs.

Each service is created for specific business capabilities and performs a single function. This allows for independent updates, deployments, and scalability to meet the needs of specific features.

In summary, microservices offer a flexible and scalable way to build applications, enabling greater agility and accelerating time-to-market for new features .

8.5. Development concepts

In order to test the proper functioning of our application, we have implemented various types of tests, including unit tests, load tests, and end-to-end (E2E) tests. Additionally, we have conducted different accessibility and maintenance tests to study its performance.

Testing has been carried out on the gateway-service, user-service, history-service, auth-service and room-service microservices and the game webapp component.

9. Architecture Decisions

10. Quality Requirements

Content

This section contains all quality requirements as quality tree with scenarios. The most important ones have already been described in section 1.2. (quality goals)

Here you can also capture quality requirements with lesser priority, which will not create high risks when they are not fully achieved.

Motivation

Since quality requirements will have a lot of influence on architectural decisions you should know for every stakeholder what is really important to them, concrete and measurable.

Further Information

See Quality Requirements in the arc42 documentation.

10.1. Quality Tree

10.2. Quality Scenarios

Quality Goal	Scenario	Description
Usability	A new user registers on the WIQ platform	The registration process should be intuitive and straightforward. The user should be able to easily navigate through the registration form and submit the required information without encountering any confusion or errors.
Accesibility	A user with vision problems accesses the application	The platform must have the necessary font size and sufficient contrast with the background so that all the text is completely legible.
Privacy	A user views their participation history on the WIQ platform.	The platform should only display the participation history of the authenticated user and should not allow access to the history of other users. User data should be securely stored and protected from unauthorized access.
Performance	Multiple users simultaneously play a game on the WIQ platform.	The platform should maintain fast response times even under heavy load, ensuring that users can answer questions within the specified time limit without experiencing delays or interruptions.

Quality Goal

Scenario

Description

Usability

A new user registers on the WIQ platform

The registration process should be intuitive and straightforward. The user should be able to easily navigate through the registration form and submit the required information without encountering any confusion or errors.

Accesibility

A user with vision problems accesses the application

The platform must have the necessary font size and sufficient contrast with the background so that all the text is completely legible.

Privacy

A user views their participation history on the WIQ platform.

The platform should only display the participation history of the authenticated user and should not allow access to the history of other users. User data should be securely stored and protected from unauthorized access.

Performance

Multiple users simultaneously play a game on the WIQ platform.

The platform should maintain fast response times even under heavy load, ensuring that users can answer questions within the specified time limit without experiencing delays or interruptions.

11. Risks and Technical Debts

11.1. Risks

11.1.1. Internal Risks

Risks that we can have under control and it´s our responsability to fight against them:

Internal	More detail	How to fight it
A member fire out the project	It’s possible that due to reasons like having a lot of pressure or being overwhelmed by the project members of the group quit the project or the subject	Try to communicate with each other and having a sensible rhythm advancing with the project. Also helping each other when we can
First time delivering a full stack app	We could have a lack of experience with a project as big as this that have a bit of every field.	Searching and learning the new things we could need during the project and talking with the other members if we know more of a determined field trying to help them
Lack of time	We can have some though weeks because we have other subjects to study and other projects and exams that can consumpt our time	Attemp to be responsible with our time and tasks and try to organize ourselves as good as we can
New technologies	Some technologies that we will use in the projects are new for us such as React or managing a database due to our lack of experience	Learning the new things that we don’t know and not being unwilling to confront new things such as technologies or languages that we have lack of experience on them
Not accomplish deadlines	It can happen that we don’t archieve what it’s requested into the project in time and end up sending an uncompleted final product or during the middle deadlines	To avoid this we have to keep a good rhythm advancing and planing good and adequated tasks in the weekly meetings done in the labs so we don’t run out of time not done

Internal

More detail

How to fight it

A member fire out the project

It’s possible that due to reasons like having a lot of pressure or being overwhelmed by the project members of the group quit the project or the subject

Try to communicate with each other and having a sensible rhythm advancing with the project. Also helping each other when we can

First time delivering a full stack app

We could have a lack of experience with a project as big as this that have a bit of every field.

Searching and learning the new things we could need during the project and talking with the other members if we know more of a determined field trying to help them

Lack of time

We can have some though weeks because we have other subjects to study and other projects and exams that can consumpt our time

Attemp to be responsible with our time and tasks and try to organize ourselves as good as we can

New technologies

Some technologies that we will use in the projects are new for us such as React or managing a database due to our lack of experience

Learning the new things that we don’t know and not being unwilling to confront new things such as technologies or languages that we have lack of experience on them

Not accomplish deadlines

It can happen that we don’t archieve what it’s requested into the project in time and end up sending an uncompleted final product or during the middle deadlines

To avoid this we have to keep a good rhythm advancing and planing good and adequated tasks in the weekly meetings done in the labs so we don’t run out of time not done

11.1.2. External Risks

Risks that we can try to prevent but at the end doesn’t depend on us:

External risk	More detail	How to fight it
Depending on extern technologies	It’s possible that due to depend on external libraries such as react or external services like Azure we can find ourselves with the poject not working derivated from failures on that external technologies	Try to investigate and use reliable services and libraries that are not likely to end up deprecated or with bugs and failures on their releases
Accidents in the presentation day	Accidents can happen and if something like a train or bus not working or some unexpected problem that we can experience the presentation day (2nd May) it´s possible that someone can be absent in that final presentation	To avoid this we should try to be cautious and arrive with a big margin time and having alternatives
Malicious people	Maybe people who spends all day looking for machines or url’s that are vulnerable finds our machine and tries to break into it or obtain information (maybe already happened)	We should implement what we are learning and already have learned about security and mantaining our systems save and sound.

External risk

More detail

How to fight it

Depending on extern technologies

It’s possible that due to depend on external libraries such as react or external services like Azure we can find ourselves with the poject not working derivated from failures on that external technologies

Try to investigate and use reliable services and libraries that are not likely to end up deprecated or with bugs and failures on their releases

Accidents in the presentation day

Accidents can happen and if something like a train or bus not working or some unexpected problem that we can experience the presentation day (2nd May) it´s possible that someone can be absent in that final presentation

To avoid this we should try to be cautious and arrive with a big margin time and having alternatives

Malicious people

Maybe people who spends all day looking for machines or url’s that are vulnerable finds our machine and tries to break into it or obtain information (maybe already happened)

We should implement what we are learning and already have learned about security and mantaining our systems save and sound.

11.2. Technical Debt

Technical Debt	Description
Improve multiplayer gamemode	There are some multiplayer aspects that can be improved such as functionallity and performance
White label in login and register	In the register and login area the label of the inputs can´t be put in white to contrast in the dark mode
Some bugs in diverse gamemodes	Some of the game modes have minor bugs that need to be deeply tested
Improve ranking	Make a ranking for each game mode or some idea similar
Fullfill coverage	We have the coverage around 80% so try to ascend that to 100%
Fix the security hotspots	Sonar Cloud mark diverse security hotspots so we could try to fix them
Color change and language buttons frozen	When in game we were forced to block those buttons because if you change them it restarted the timer and questions in game
More languages	At the moment we only have spanish and english translations so adding more languages is a good idea

Technical Debt

Description

Improve multiplayer gamemode

There are some multiplayer aspects that can be improved such as functionallity and performance

White label in login and register

In the register and login area the label of the inputs can´t be put in white to contrast in the dark mode

Some bugs in diverse gamemodes

Some of the game modes have minor bugs that need to be deeply tested

Improve ranking

Make a ranking for each game mode or some idea similar

Fullfill coverage

We have the coverage around 80% so try to ascend that to 100%

Fix the security hotspots

Sonar Cloud mark diverse security hotspots so we could try to fix them

Color change and language buttons frozen

When in game we were forced to block those buttons because if you change them it restarted the timer and questions in game

More languages

At the moment we only have spanish and english translations so adding more languages is a good idea

12. Glossary

Term	Definition
Accessibility	Accessibility is the practice of designing products, devices, services, or environments to be usable by people with disabilities. It aims to ensure that everyone, regardless of their physical or cognitive abilities, can perceive, understand, navigate, and interact with digital or physical environments effectively and without barriers.
API	An API (Application Programming Interface) is a set of rules, protocols, and tools that enables different software applications to communicate and interact with each other. It defines the methods and data formats that applications can use to request and exchange information, allowing for seamless integration and interoperability between systems, services, and platforms.
Back end	The back end is the part of a web application that operates behind the scenes and is responsible for managing and processing data, as well as handling requests from the front end. It includes the server, application logic, and database.
Database	Database is a structured collection of data that is organized in a way that allows for efficient storage, retrieval, manipulation, and management. They facilitate data organization, retrieval, and analysis, enabling businesses to make informed decisions, support transactional operations, and deliver valuable services to users.
Docker	Docker is a platform that simplifies the process of developing, deploying, and running applications by utilizing containerization technology.
Front end	Front end is the part of a web application that users interact with directly. It encompasses everything that users see, touch, and interact with in their web browsers. This includes the user interface (UI), design elements, layouts, content, and interactive features.
GitHub	GitHub is a web-based platform and version control system that facilitates collaboration and software development workflows.
JavaScript	JavaScript is a programming language primarily employed for web development. It enables developers to add interactivity, dynamic behavior, and client-side scripting to web pages.
JSON	Stands for JavaScript Object Notation. It’s a lightweight data interchange format that is easy for humans to read and write and easy for machines to parse and generate.
MongoDB	MongoDB is a NoSQL database that stores data in a flexible, document-oriented format called BSON (Binary JSON). It is designed for scalability, high performance, and ease of development.
Node.js	Node.js is a server-side runtime environment that allows developers to run JavaScript code outside of a web browser.
Performance	Performance refers to the responsiveness, speed, and efficiency of a system or application in executing tasks and handling user interactions. It encompasses factors such as response time, throughput, resource consumption, and scalability, all of which contribute to a satisfactory user experience.
React	React is a JavaScript library for building interactive and dynamic user interfaces.
Usability	Usability refers to the extent to which a product or system can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction. It focuses on enhancing the user experience by ensuring that interfaces are intuitive, tasks are easy to accomplish, and interactions are pleasant.
Wikidata	Wikidata is an open knowledge base. It serves as a centralized repository for structured data.

Term

Definition

Accessibility

Accessibility is the practice of designing products, devices, services, or environments to be usable by people with disabilities. It aims to ensure that everyone, regardless of their physical or cognitive abilities, can perceive, understand, navigate, and interact with digital or physical environments effectively and without barriers.

API

An API (Application Programming Interface) is a set of rules, protocols, and tools that enables different software applications to communicate and interact with each other. It defines the methods and data formats that applications can use to request and exchange information, allowing for seamless integration and interoperability between systems, services, and platforms.

Back end

The back end is the part of a web application that operates behind the scenes and is responsible for managing and processing data, as well as handling requests from the front end. It includes the server, application logic, and database.

Database

Database is a structured collection of data that is organized in a way that allows for efficient storage, retrieval, manipulation, and management. They facilitate data organization, retrieval, and analysis, enabling businesses to make informed decisions, support transactional operations, and deliver valuable services to users.

Docker

Docker is a platform that simplifies the process of developing, deploying, and running applications by utilizing containerization technology.

Front end

Front end is the part of a web application that users interact with directly. It encompasses everything that users see, touch, and interact with in their web browsers. This includes the user interface (UI), design elements, layouts, content, and interactive features.

GitHub

GitHub is a web-based platform and version control system that facilitates collaboration and software development workflows.

JavaScript

JavaScript is a programming language primarily employed for web development. It enables developers to add interactivity, dynamic behavior, and client-side scripting to web pages.

JSON

Stands for JavaScript Object Notation. It’s a lightweight data interchange format that is easy for humans to read and write and easy for machines to parse and generate.

MongoDB

MongoDB is a NoSQL database that stores data in a flexible, document-oriented format called BSON (Binary JSON). It is designed for scalability, high performance, and ease of development.

Node.js

Node.js is a server-side runtime environment that allows developers to run JavaScript code outside of a web browser.

Performance

Performance refers to the responsiveness, speed, and efficiency of a system or application in executing tasks and handling user interactions. It encompasses factors such as response time, throughput, resource consumption, and scalability, all of which contribute to a satisfactory user experience.

React

React is a JavaScript library for building interactive and dynamic user interfaces.

Usability

Usability refers to the extent to which a product or system can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction. It focuses on enhancing the user experience by ensuring that interfaces are intuitive, tasks are easy to accomplish, and interactions are pleasant.

Wikidata

Wikidata is an open knowledge base. It serves as a centralized repository for structured data.

13. Tests Results

13.1. Coverage

13.2. Unit Tests Results

13.2.1. Auth Service Tests

File	% Stmts	% Branch	% Funcs	% Lines
All files	100	87.5	100	100
auth-model.js	100	100	100	100
auth-service.js	100	87.5	100	100

Test Suites: 1 passed, 1 total
Tests: 3 passed, 3 total
Snapshots: 0 total
Time: 1.391 s

13.2.2. User Service Tests

File	% Stmts	% Branch	% Funcs	% Lines
All files	100	95.83	100	100
user-model.js	100	100	100	100
user-service.js	100	95.83	100	100

Test Suites: 1 passed, 1 total
Tests: 8 passed, 8 total
Snapshots: 0 total
Time: 1.292 s

13.2.3. Gateway Service Tests

File	% Stmts	% Branch	% Funcs	% Lines
All files	93.54	93.75	84.21	97.82
gateway-service.js	93.54	93.75	84.21	97.82

Test Suites: 1 passed, 1 total
Tests: 34 passed, 34 total
Snapshots: 0 total
Time: 0.922 s

13.2.4. Room Service Tests

File	% Stmts	% Branch	% Funcs	% Lines
All files	89.7	66.66	100	89.55
RoomQuestions.js	86.59	64.7	100	86.45
room-service.js	97.43	100	100	97.36

Test Suites: 2 passed, 2 total
Tests: 11 passed, 11 total
Snapshots: 0 total
Time: 2.126 s

13.2.5. WebApp Tests

File	% Stmts	% Branch	% Funcs	% Lines
All files	82.43	63.77	74.86	82.36
App.js	85.71	50	100	85.71
index.js	0	100	100	0
reportWebVitals.js	0	0	0	0
GuestLayout.js	11.11	0	0	11.11
authcontext.js	100	100	100	100
authenticationLayout.js	100	100	100	100
AddUser.js	89.28	70	66.66	89.28
Footer.js	100	75	100	100
AnswerButton.jsx	100	50	100	100
AnswersBlock.jsx	100	83.33	100	100
BasicGame.js	78.37	69.23	81.25	78.37
EnunciadoBlock.jsx	100	100	100	100
Game.js	69.09	35.29	66.66	69.09
QuestionArea.jsx	85.71	0	75	85.71
CustomGameMode.js	76.92	100	40	76.92
CustomWindow.js	93.33	50	66.66	93.33
DailyGameMode.js	92.3	50	87.5	92.3
GameMode.js	100	100	100	100
InfinityGameMode.js	70.83	62.5	50	70.83
RoomGame.js	96.42	100	100	96.42
SameCategoryMode.js	100	100	100	100
GameTimer.jsx	100	75	100	100
Timer.jsx	69.44	76.19	71.42	68.57
AllGamesBlock.jsx	93.75	64.28	100	93.75
GameBlock.jsx	95.65	57.14	100	95.65
History.js	0	0	0	0
StatsBlock.jsx	100	76.19	100	100
Home.js	94.11	50	100	94.11
Login.js	84.37	58.33	33.33	84.37
Logout.js	100	100	100	100
NavBar.js	90.38	61.9	87.5	92.15
PrincipalView.js	100	100	100	100
Ranking.js	68.75	100	33.33	68.75
CreateRoom.js	93.33	100	80	92.85
JoinRoom.js	96.29	100	100	96.29
RankingRoom.js	100	100	100	100
Room.js	80.95	72.72	72.72	80.95
socket.js	100	100	100	100
internacionalizacion	100	100	100	100

Test Suites: 34 passed, 34 total
Tests: 119 passed, 119 total
Snapshots: 0 total
Time: 31.338 s

13.3. E2E Tests Results

We have conducted various E2E (End-to-End) tests. E2E tests are a methodology used to ensure that applications behave as expected and that data flow is maintained for all types of user tasks and processes.

In summary, E2E tests validate the complete functionality of an application from start to finish, ensuring that all components interact correctly and that the software meets expectations before its release.

13.4. Load Tests Results

We have also conducted load tests. Load testing is a type of performance test that evaluates a software system or application’s ability to handle normal and high workloads. These tests verify that the software meets the expected performance criteria and end-user expectations.

In summary, load testing allows us to ensure performance and identify bottlenecks.

14. Accesibility Tests Results

14.1. AChecker

To ensure the accessibility of our website, we utilized the AChecker tool.
As can be seen in the attached image, we evaluated all windows of the web application according to AAA accessibility criteria, and the results have been positive. This means that our application complies with the strictest standards in terms of accessibility for people with disabilities.
We are committed to providing an inclusive experience for all our users.

14.2. LightHouse

We conducted thorough testing using Google Lighthouse for our web application, and the results have been quite positive. According to Google Lighthouse, the average accessibility score (calculated as the mean across all views within the web application) is 94%, indicating strong adherence to accessibility standards. Additionally, the performance score averages at 86%, demonstrating efficient loading times and overall responsiveness.

We are committed to maintaining high standards of both accessibility and performance to ensure an optimal user experience. These results validate our efforts in creating a robust and user-friendly web application.