Docs/docu overview

docs/src/01_introduction_and_goals.adoc

@@ -2,7 +2,7 @@ ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-introduction-and-goals]]
 == Introduction and Goals
-RTVE has hired the company HappySw, composed of students from the Oviedo School of Software Engineering, to develop a new experimental version of the quiz show Saber y Ganar. This application will be called WIQ, where users will be able to register and log in to play. The application will consist of answering questions of different types generated with Wikidata. For each question answered correctly, points will be obtained.
+RTVE has hired the company HappySw, composed of students from the Oviedo School of Software Engineering, to develop a new experimental version of the quiz show Saber y Ganar. This application will be called KiWiq, where users will be able to register and log in to play. The application will consist of answering questions of different types generated with Wikidata. For each question answered correctly, points will be obtained.
 
 === Requirements Overview
 * The system shall provide non-registered users with the option to sign up.
@@ -40,7 +40,7 @@ See the complete functional requirements in the xref:#section-annex[Annex] of th
 |===
 |Role/Name|Expectations
 | RTVE  | To have a new experimental version of the Saber y Ganar quiz show.
-| HappySw | Develop a good application that fullfills the requirements expected by the client.
+| HappySw | Develop a good application that fulfills the requirements expected by the client.
 | Registered user | To play with an entertaining and easy-to-use application. An application with which the user learn about different topics.
 | Wikidata | Being able to offer service allowing people to use the data through the API.
 |===

docs/src/04_solution_strategy.adoc

@@ -17,6 +17,8 @@ Regarding the technologies, we decided to use the following ones:
 
  * **Java SpringBoot 3** for the backend/API, it being a language we are all comfortable with. The server will easily support multithreading if needed due to SpringBoot being an abstraction over servlets, something we would be able only to simulate if we used Node.js as it uses a single-threaded event loop.
 
+ * **Java ** for the Question Generator process, due to the ease for connecting with the DB via JPA and our familiarity.
+
 === Organizational breakdown 
 
 Currently, we have been meeting twice a week, but that may change in the future. Most, if not all of us, were present for these meetings, and relevant decisions were also discussed on the side and between members, as well discussions related to opinions on some matter. Some of these meetings took place in person while others took place on a Discord Server.
@@ -46,4 +48,4 @@ Regarding the code style, we must make two important distinctions: the frontend
  * In the backend, the structure will be that of a typical Maven project.
  * In the frontend, the structure will be quite different:
  ** The `src/components` will contain single components which we may reuse.
- ** The `src/pages` will contain the endpoints and will follow a simple structure. For instance, given a `/statistics/personal` and a `/statistics/general` endpoints, both will be independent React components that will return the page and be placed under the `src/pages/statistics` folder.
+ ** The `src/pages` will contain the endpoints and will follow a simple structure. For instance, given a `/statistics/personal` and a `/statistics/general` endpoints, both will be independent React components that will return the page and be placed under the `src/pages/statistics` folder.

docs/src/05_building_block_view.adoc

@@ -39,7 +39,7 @@ Contained Building Blocks::
 ****
 * **WIQ Client:** This is the connection between the user and the application. It will allow the users to play the WIQ game. This part will be developed in React with Typescript for its clear component structure, simplified code quality and separation of concerns.
 * **WIQ REST API:** This is the part responsible for managing the users that log into the application, managing also the logic of the game and sending the request to the Wikidata API for the question generation. This part is going to be developed in SpringBoot due to its foundations on the Java programming language, which is the language that the developers find the easiest to develop in.
-* **Question Generator Module:** This component is in charge of everything related with the questions. It retrieves the information from WikiData QS and stores it in the WIQ Database. It is also asked for questions and answers by the WIQ REST API.
+* **Question Generator Module:** This component is in charge of everything related with the questions. It retrieves the information from WikiData QS and stores it in the WIQ Database, which later is queried for questions and answers from the REST API.
 * **WIQ Database:** This is where the most important data is going to be stored. Such as, users questions and other game info that will be specified in the future. The database we chose to use is PostgreSQL, since it is compatible with Docker and it's an object-relational kind of database, which is easier for the developers to use. Another alternative would've been to use MySQL.
 ****
 

docs/src/07_deployment_view.adoc

@@ -43,4 +43,4 @@ Our main idea is that the server will be a self-contained .jar file with all the
 The database will contain the data used by the system. Therefore, it will contain user data, as well as the data related to the questions and their answers. The databases to store the questions (and therefore the answers) and the user data might be different, though.
 
 ===== Question Generator
-The question generator will be run only at the beginning of the application. It will connect with Wikidata using SPARQL to generate questions and answers and store them in the database. This question generation will generate all the questions used by the application at once.
+The question generator will be run only at the beginning of the application. It will connect with Wikidata using SPARQL to generate questions and answers and store them in the database. This question generation will generate all the questions used by the application at once. It could be run again to generate new questions if they are added.

docs/src/08_concepts.adoc

@@ -87,10 +87,11 @@ Question "n" -- "n" Answer
 | User | The people using the application, they have statistics and take part in a ranking to compete
 | Answer | Models each possible answer, created to reuse answers that are common to different questions, as well as distractors
 | Game | It is created when the user starts a game and includes the rounds that the user has to answer
+| Statistics | Stores information about the amount of correct and wrong answers that each user has answered
 |===
 
 .Question Generator
-The Question Generator is an important part of our application, it is already briefly described in Section 6, but mopre insight is given here.
+The Question Generator is an important part of our application, it is already briefly described in Section 6, but more insight is given here.
 
 The Question Generator module is written in Java and connects via HTTP with Wikidata query service. 
 It follows a template design pattern where each Java class is responsible for generating the questions and answers.
@@ -113,4 +114,4 @@ In order to archieve this, we will implement two modules regarding questions, on
 Our code will be deployed within an Azure's Virtual Machine using continuous integration. 
 
 .Under-the-hood:
-Regarding Data persistence, our project has two DB, one for storing questions as stated before while the other one will be in charge of storing any other meaningful data for the game such us users or game's histories.
+Regarding Data persistence, our project has a PostgreSQL DB, which stores information about users, statistics, games, answers and questions.

docs/src/09_architecture_decisions.adoc

@@ -23,6 +23,9 @@ During the application development process, decisions had to be made as issues e
 
 |HTTPS
 |To improve security we have decided to make HTTPS as one main requirements in out project as can be seen in issue #51.
+
+|Architecture of the Question Generator
+|It has been decided to implement the QG in an independent module so it is only run once and it is not generating questions at real time, this way, we are not dependent on wikidata for having our application available.
 |===
 
 If needed, a more descriptive record can be seen link:https://github.com/Arquisoft/wiq_en2b/wiki[here].