Fixed some typos in the documentation

docs/src/01_introduction_and_goals.adoc

@@ -17,11 +17,11 @@ These include
 
 RTVE wants to offer a web application based on the famous Spanish TV show 
 https://es.wikipedia.org/wiki/Saber_y_ganar["Saber y Ganar"] 
-to its users in commemoration of the 28th anniversary of the show. This show consisted on 
+to its users in commemoration of the 28th anniversary of the show. This show consists on
 answering a number of questions with different types and subjects obtaining a prize for 
 each question well answered.
 
-The expected goal is to offer a well-desgined game that maintains all the quality standards
+The expected goal is to offer a well-designed game that maintains all the quality standards
 that the company offers like maintainability, security, etc...; while trying to fulfill the
 user's needs to provide a positive UX.   
 
@@ -100,9 +100,9 @@ A table with quality goals and concrete scenarios, ordered by priorities
 | Implementing redundancy and failover mechanisms can help ensure continuous availability.
 
 | 3
-| Accesibility 
+| Accessibility
 | Any user must be able to enjoy playing with our application despite any disability they could have. 
-| HTML standards must be followed to try to minimize the lack of Accesibility of our Application. Another important feature is the contrast of our web. All of these can be tested with Accessibilty tools available on Internet.  
+| HTML standards must be followed to try to minimize the lack of Accessibility of our Application. Another important feature is the contrast of our web. All of these can be tested with Accessibility tools available on Internet.
 
 | 4
 | Security
@@ -142,13 +142,13 @@ Table with role names, person names, and their expectations with respect to the
 |===
 |Role/Name|Contact|Expectations
 | RTVE | rtve.dircom@rtve.es | A web application that emulates the functionality of the famous Spanish TV show "Saber y Ganar". 
-| HappySw | contact_projects@happysw.es | An application that meets all the  requirements asked by RTVE mantaining the quality that offers the company. 
+| HappySw | contact_projects@happysw.es | An application that meets all the  requirements asked by RTVE maintaining the quality that offers the company.
 | Professors 
 | 
 * Pablo González: gonzalezgpablo@uniovi.es 
 * Jose Labra: labra@uniovi.es
 | A well-designed web application that fulfills the functional requirements for the game to work, as well as, the quality requirements.
-| Users |  | A quiz game to test their knowdlege on different fields. The game must be easy to use and must record all of their past games. 
+| Users |  | A quiz game to test their knowledge on different fields. The game must be easy to use and must record all of their past games.
 | Development team
 |
 * Carlos Menéndez González (UO288056@uniovi.es)

docs/src/02_architecture_constraints.adoc

@@ -44,10 +44,10 @@ The development of the application has several architectural constraints that mu
 [options="header",cols="1,3"]
 |===
 |Constraint|Explanation
-| Team members | The team is composed of 7 members from the same lab team.
+| Team members | The team is composed of 7 members from the same lab group.
 | Time | The application is developed in a limited time (the semester).
 | Meetings | At least one meeting per week will have place in order to discuss what needs to be done next.
-| Git | The developement team must use git for version control management.
+| Git | The development team must use git for version control management.
 |===
 
 === Conventions
@@ -57,6 +57,6 @@ The development of the application has several architectural constraints that mu
 | Language | All the project must be developed in English.
 | ARC42 | The documentation of the project must use the ARC42 template.
 | GitHub conventions | Changes in the project must be carried out by using different branches. Issues are used as official communication means.
-| OpenAPI | The APIs documentation will follow https://www.openapis.org/[OpenAPI specification] to have an standarized way of documenting and make it easier for the users consulting it.
+| OpenAPI | The APIs documentation will follow https://www.openapis.org/[OpenAPI specification] to have an standardized way of documenting and make it easier for the users consulting it.
 | JSend | All services must follow the https://github.com/omniti-labs/jsend[JSend] specification for each JSON response. 
 |===

docs/src/03_system_scope_and_context.adoc

@@ -82,7 +82,7 @@ image::03_technical_context.png["Technical Context"]
 |===
 | Component | Description
 | WebApp | Accessible via the internet, allowing users to interact with the KaW application. 
-| Services | Provide access to user information and generated questions, enabling integration with external systems. Also, provides an API intreface for consulting certain information.
+| Services | Provide access to user information and generated questions, enabling integration with external systems. Also, provides an API interface for consulting certain information.
 | Database | Stores and retrieves user data, including registration information and participation history. Also, questions can be stored for caching purposes. 
 | Wikidata | Accepts SPARQL queries and returns the requested data about questions. 
 |===

docs/src/04_solution_strategy.adoc

@@ -36,13 +36,13 @@ See https://docs.arc42.org/section-4/[Solution Strategy] in the arc42 documentat
 - *React* : React will simplify the task build reusable and modular UI elements for our application thanks to its component-based structure. It also allows us to use JSX, which is a syntax extension for JavaScript that allows us to write HTML elements inside our JavaScript code. This will make our code more readable and easier to debug.
 - *Express* : Web application framework for Node.js which will simplify development on the server side. There is also available a wide range of third-party middlewares that we could include on our application.
 - *TypeScript* : Since we will be using JavaScript and are more familiar with statically typed languages we will use TypeScript for the services of our application. This will also reduce the likelihood of some unexpected errors at runtime.
-- *MongoDB* : We chose MongoDB since we consider we could take advantage of it's flexible schema. Its native support for JSON and its simple query language also influenced our decision. We also consider this a valauable oportunity to learn and work with a document database.
+- *MongoDB* : We chose MongoDB since we consider we could take advantage of it's flexible schema. Its native support for JSON and its simple query language also influenced our decision. We also consider this a valuable opportunity to learn and work with a document database.
 - *Docker*: To deploy our project, Docker was chosen due to its handy portability and its perfect integration with microservices applications. 
 
 
 === Decomposition of the System 
 
-==== Arquitectural patterns
+==== Architectural patterns
 - *Microservices*: 
 As the main architecture for the whole project. The system is divided into several modules representing
 a functional requirement like question generation. Each of these modules will be independent from
@@ -75,7 +75,7 @@ corresponding service that answers that petition and returns its value.
 
 | Usability 
 | The application aims for user-friendly accessibility with an intuitive design. 
-| Different web tools can be used to test accesibility and responsive design such as 
+| Different web tools can be used to test accessibility and responsive design such as
 https://chromewebstore.google.com/detail/lighthouse/blipmdconlkpinefehnmjammfjpmpbjk?hl=es&pli=1[Google LightHouse], https://webaim.org/resources/contrastchecker/[Contrast Checker] or https://wave.webaim.org/[Wave].
 |===
 

docs/src/06_runtime_view.adoc

@@ -50,7 +50,7 @@ an error message showing "Invalid credentials" will appear to the user, and if t
 correct, a valid JSON response is created together with the creation of a session token that
 allows the user to stay authenticated for a period of time. Finally the user will be able to access the application.
 
-This case scenario is also represented on the following diagram (splitted in two for better readability):
+This case scenario is also represented on the following diagram (split in two for better readability):
 
 [mermaid]
 ....
@@ -97,7 +97,7 @@ from WQS, to also generate answers and distractors. If WQS gets timed out (e.g.
 than 5 sec to retrieve the data to fill template), it is chosen an already generated question from
 cache to always try to return the exact number of questions requested.
 
-Second, the other half are simply retrieved from previosuly wikidata generated questions which are
+Second, the other half are simply retrieved from previously wikidata generated questions which are
 stored in DB. Then, both array of questions are combined to return the n questions requested.
 
 Optionally, if questions are required in a certain language. The QS queries a translation Service
@@ -109,7 +109,7 @@ reformatting the translated string into questions array.
 Finally, QS sends them back to the Gateway, so again the response can then be redirected 
 towards the WebApp. Finally, the WebApp displays the questions of the game.
 
-This case scenario is also represented with the following diagrams (splitted for better understanding).
+This case scenario is also represented with the following diagrams (split for better understanding).
 
 Overview of Question Generation workflow:
 [mermaid]
@@ -197,7 +197,7 @@ that data is sent to the Gateway and then forwarded to the User Service, which i
 updating the Database with the updated user history. This process is repeated for each answer to 
 a question.
 
-Once the user answer the final question of the game, appart from doing the beforementioned process,
+Once the user answer the final question of the game, apart from doing the before-mentioned process,
 the user history is also updated with the game "highlights" such as time spent playing.
 
 This case scenario is also represented on the following diagram:

docs/src/07_deployment_view.adoc

@@ -47,7 +47,7 @@ unit and end-to-end tests, as well as an attempt to deploy the application to a
 This setup enables our team to achieve continuous deployment and delivery (CD) together with
 continuous integration (CI).
 
-Just for record, a guide followed by the team to deploy our appplication can be found
+Just for record, a guide followed by the team to deploy our application can be found
 https://github.com/Arquisoft/wiq_en3b/blob/master/docs/deploymentGuide.md[here]. 
 
 
@@ -196,7 +196,7 @@ Mapping of Building Blocks to Infrastructure::
 | Service that generates questions with WikiData. The same function can be found for our API consumers.
 
 | Question Database
-| Database to save the templates and querys for WikiData.
+| Database to save the templates and queries for WikiData.
 
 | WikiData
 | The API used to get information from WikiData.

docs/src/08_concepts.adoc

@@ -59,8 +59,8 @@ See https://docs.arc42.org/section-8/[Concepts] in the arc42 documentation.
 
 ==== Internationalization
 
-One of the things to increase accesibility is giving our application the
-capability of beign in various languages so people around the world can play
+One of the things to increase accessibility is giving our application the
+capability of being in various languages so people around the world can play
 our game. Obviously, internationalization is more than just changing the 
 language of the Application but due to time constraints we will just offer 
 Spanish, English, Ukrainian and French languages ( although, our API can generate questions
@@ -93,7 +93,7 @@ and avoid getting suspended.
 
 Keeping a secure website for our users is one of our main quality
 goals. For that, all the passwords stored in MongoDB are simply
-hashes so attackers cannot decypher them easily. The library used
+hashes so attackers cannot decipher them easily. The library used
 in the AuthService and UserService to store or compare passwords
 is called *bcrypt*. This library provides with an easy way
 to hash passwords and keep user's data secured.
@@ -152,9 +152,9 @@ the quality standards we are required.
 
 - End-to-End Testing:
 
-Appart from testing functionality, all our code must also meet the required
+Apart from testing functionality, all our code must also meet the required
 domain functionality such as registration, login, etc. For that, Jest is used
-in combination with https://pptr.dev/[pupeeter] which provides a High-level API
+in combination with https://pptr.dev/[puppeteer] which provides a High-level API
 to control browsers and simulate our different User Stories (domain functionality)
 that the project requires.
 
@@ -179,15 +179,15 @@ With these test, the team tries to deliver high quality functionality to the
 users by simply testing with them and examine its behaviour.
 
 The team will select different people to try our application to get Information
-on how to improve it, at the end, this application is for them! Also, accesibility
+on how to improve it, at the end, this application is for them! Also, accessibility
 and contrast color checks will be carried out since they are part of any
-usability tesing process.
+usability testing process.
 
 ==== Code generation
 
 ===== JSend
 
-To have an standarized way of responses for the different Microservices that our
+To have an standardized way of responses for the different Microservices that our
 application have, the JSend specification has been chosen. This specification allows
 the team to have uniform JSON responses so other parts of the system such as
 Frontend, always know what to expect from these services. 
@@ -232,7 +232,7 @@ flowchart LR
 
 === "Under-the-hood" concepts
 
-==== Persistency
+==== Persistence
 
 As stated in point 4.1, the chosen database for the project is MongoDB 
 which offers us a document-oriented schema. This type of database fits
@@ -312,7 +312,7 @@ erDiagram
 |===
 | Document | Description 
 | USER 
-| Holds all the data relationed to a user registered into our game. It
+| Holds all the data related to a user registered into our game. It
 has a relation with *ONE USER_HISTORY* and *ONE USER_PROFILE* document
 | USER_HISTORY
 | Holds all the records/statistics of a single user through all played games.
@@ -358,22 +358,22 @@ flowchart LR
 
 To handle the different sessions of our different users, JWT are also used
 for this purpose. For each logged in user, a token will be generated for
-authenticating them as stated previosly, and also, for mantaining a session
+authenticating them as stated previously, and also, for maintaining a session
 and hold the necessary information without having to reenter the users' credentials.
 In this way, the user will have to keep on its browser this token to maintain
 alive the session.
 
 === Operation concepts
 
-==== Monitoring with Grafana & Promotheus
+==== Monitoring with Grafana & Prometheus
 
-To provide with quality to the Application, a monitorance system has been applied using
+To provide with quality to the Application, a monitoring system has been applied using
 Grafana and Prometheus,to always keep track of how the application is performing. The 
 work is simple, it has been added Prometheus to "scrap" information from the Gateway Service
 like all the petitions it is asked to it.
 
 This information is available at kawgame.xyz:8000/metrics and the Prometheus application,
-that manages it, at kawgame.xyz:9091. Although, this is retrival is good, for the "humans"
+that manages it, at kawgame.xyz:9091. Although, this is retrieval is good, for the "humans"
 is not so comfortable to the "eye". For that, Grafana has been set up.
 
 This application help us to see in a graphical way all the load that our Application is
@@ -393,12 +393,12 @@ sequenceDiagram
     Grafana-->>-u: Display graphs
 ....
 
-==== Persisting the Persistance 
+==== Persisting the Persistence
 
 As requested by our shareholders, the application needed to keep all data from previous
 deployments. For that, the team has decided to have a simple yet powerful solution with
 the usage of Volumes of Docker. 
 
 With this approach, each container from the Infrastructure shown before has its own data
 stored in those Volumes and it is also independent from it, so any new release will use
-the previous data and "persist the persistance".
+the previous data and "persist the persistence".

docs/src/10_quality_requirements.adoc

@@ -51,7 +51,7 @@ In any case the tree should include links to the scenarios of the following sect
 graph TD
     A[Quality] --> B[Usability]
     A --> C[Availability]
-    A --> D[Accesibility]
+    A --> D[Accessibility]
     A --> E[Security]
     A --> F[Performance]
     A --> H[Privacy]

docs/src/11_technical_risks.adoc

@@ -44,7 +44,7 @@ for our stakeholders and users.
 to avoid the rate limit (1000 requests/hr) 
 
 | Inexperience
-| The little knowdlege about new tecnologies used in the project like React, Express or Docker; can cause a failure in the implementation of it.
+| The little knowledge about new technologies used in the project like React, Express or Docker; can cause a failure in the implementation of it.
 | Research and constant learning through development can lead to better understanding of the technologies.
 
 |===
@@ -55,9 +55,9 @@ to avoid the rate limit (1000 requests/hr)
 |===
 | Risk | Description | Mitigation
 
-| Reponse times
+| Response times
 | Having to wait for API responses can cause serious Bottlenecks on the WebApp. Users would have to wait a long time for each game they want to play.
-| The usage of asynchronus calls can be very beneficial for this risk to be mitigated.  
+| The usage of asynchronous calls can be very beneficial for this risk to be mitigated.
 
 | Deadlines
 | Time constraints tied to the constant delivery of features can lead to not ending with the required project features.
@@ -73,7 +73,7 @@ to avoid the rate limit (1000 requests/hr)
 | Debt | Description
 
 | Azure
-| The decision of using this platform is fully based on the team's knowdlege. Although, it could not be the best option/approach since other platforms such as AWS or hosting ones can have other benefits. 
+| The decision of using this platform is fully based on the team's knowledge. Although, it could not be the best option/approach since other platforms such as AWS or hosting ones can have other benefits.
 
 |===