+
+
Game Logic: This component acts as the core of the QuestionGame, orchestrating the flow of games, managing question selection, enforcing game rules, and tracking scores. It ensures that gameplay proceeds smoothly and according to the predefined logic, offering a seamless experience for the user.
+GameService: This component acts as the core of the QuestionGame, orchestrating the flow of games, managing question selection, enforcing game rules, and tracking scores. It ensures that gameplay proceeds smoothly and according to the predefined logic, offering a seamless experience for the user.
User Account Management: Responsible for handling user accounts, this component manages registration, authentication, and profile management. It safeguards user data while providing a personalized experience through game history tracking and preference settings.
+PlayerService: Responsible for handling user accounts, this component manages registration, authentication, and profile management. It safeguards user data while providing a personalized experience through game history tracking and preference settings.
Question Management: This component interacts directly with the Wikidata service to fetch data for question generation. It processes and curates content to produce relevant, challenging questions for the game, thereby ensuring a varied and educational experience.
+QuestionService: This component interacts directly with the Wikidata service to fetch data for question generation. It processes and curates content to produce relevant, challenging questions for the game, thereby ensuring a varied and educational experience.
API Management: Serving as the gateway for external developers, this component exposes a set of RESTful APIs that allow access to player information and question data. It handles request processing, authentication, and data delivery, facilitating third-party integrations and extensions of the WIQ platform.
+RestApiService: Serving as the gateway for external developers, this component exposes a set of RESTful APIs that allow access to player information and question data. It handles request processing, authentication, and data delivery, facilitating third-party integrations and extensions of the WIQ platform.
+
The generation of questions in our application is handled through a combination of classes and interfaces, primarily QuestionGeneratorV2 and QuestionGeneratorService.
+The two classes mentioned before use a JSON file that stores the question templates. These templates are used to generalize the question generation process. The JSON file is structured as follows:
+The JSON has the following structure:
+language_placeholder, question_placeholder, and answer_placeholder are strings used as placeholders for the language, question, and answer, respectively.
categories is an array containing objects representing different categories of questions.
Each category object has two properties:
+name: The name of the category.
questions: An array of objects representing questions within that category.
Each question object has the following properties:
+type: The type of question.
statements: An array of objects representing statements in different languages for the question. Each object has two properties: language and statement.
question: The property queried to generate the question.
answer: The property queried to obtain the answer.
sparqlQuery: The SPARQL query used to retrieve data for generating the question and answer.
{
+ "language_placeholder": "[LANGUAGE]",
+ "question_placeholder": "[QUESTION]",
+ "answer_placeholder": "[ANSWER]",
+ "categories": [
+ {
+ "name": "Geography",
+ "questions": [
+ {
+ "type": "capital",
+ "statements": [
+ {
+ "language": "es",
+ "statement": "¿Cuál es la capital de [QUESTION]?"
+ },
+ {
+ "language": "en",
+ "statement": "What is the capital of [QUESTION]?"
+ },
+ {
+ "language": "fr",
+ "statement": "Quelle est la capitale de [QUESTION]?"
+ }
+ ],
+ "question": "countryLabel",
+ "answer": "capitalLabel",
+ "sparqlQuery": "..."
+ },
+ {
+ "type": "currency",
+ "statements": [
+ {
+ "language": "es",
+ "statement": "¿Cuál es la moneda de [QUESTION]?"
+ },
+ {
+ "language": "en",
+ "statement": "What is the currency of [QUESTION]?"
+ },
+ {
+ "language": "fr",
+ "statement": "Quelle est la monnaie de [QUESTION]?"
+ }
+ ],
+ "question": "countryLabel",
+ "answer": "currencyLabel",
+ "sparqlQuery": "..."
+ }
+ ]
+ },
+ {
+ "name": "Science",
+ "questions": [
+ {
+ "type": "element",
+ "statements": [
+ {
+ "language": "es",
+ "statement": "¿Cuál es el símbolo químico del [QUESTION]?"
+ },
+ {
+ "language": "en",
+ "statement": "What is the chemical symbol of [QUESTION]?"
+ },
+ {
+ "language": "fr",
+ "statement": "Quel est le symbole chimique du [QUESTION]?"
+ }
+ ],
+ "question": "elementLabel",
+ "answer": "symbol",
+ "sparqlQuery": "..."
+ }
+ ]
+ }
+ ]
+}Here’s an example of how you could use this JSON structure to query information:
+To execute a query you just need to build a SPARQL query that retrieves the data you need. For example, to get the capital of a country, you could use the following query:
+select distinct ?country ?countryLabel ?capital ?capitalLabel where {
+ ?country wdt:P31 wd:Q6256 .
+ ?capital wdt:P31 wd:Q5119 .
+ ?country wdt:P36 ?capital .
+ ?country rdfs:label ?countryLabel .
+ ?capital rdfs:label ?capitalLabel .
+ FILTER NOT EXISTS {?country wdt:P31 wd:Q3024240} .
+ FILTER(LANG(?countryLabel)="es" && LANG(?capitalLabel)="es")
+ }Once you have a query the next step is to add it to thr JSON file. Following the previous example, you should start declaring a new object inside the questions array of the Geography category. You should fill the type, statements, question, answer, and sparqlQuery properties with the appropriate values. For the type field you could add the value "capital", for the statements array you could add the statements in different languages also adding to them the placeholder that you used in the question_placeholder field. For the question field you should add the value "countryLabel", for the answer you should add the value "capitalLabel". For the sparqlQuery field you should replace in your original query every instance of "countryLabel" with the value of question_placeholder and "capitalLabel" with the value of answer_placeholder. The final object should look like the one showed in the JSON hierarchy example.
By following this approach, you can dynamically generate a wide variety of questions based on the structured data stored in your JSON file. This allows for flexibility and scalability in your question generation process.
+Once we have the JSON file with the question templates, we can start generating questions. Each time the application starts the QuestionGeneratorService class reads the JSON file and stores the question templates in memory. This way, the application can generate questions without needing to read the file each time. These templates are stored in a synchronized stack, which allows for thread-safe access to the templates. When the application starts after reading the JSON file and storing the templates the QuestionGeneratorService class deletes all the questions that are stored in the database. After deleting the questions, the QuestionGeneratorService starts a cycle that generates all the questions in all the 3 main languages of the app for a specific type of question each two and a half minutes. This cycle is repeated until all the question types are generated. After this every 24 hours the cycle will start again with the parsing of the JSON, filling the Stack, emptying the database and generating the questions. All this process can be forced by an Admin user through the Admin panel in the app where an Admin can change the JSON (which will lead to the restart of the question generation process) or delete all questions.
+To be able to achieve continuous delivery, we need to have a good test coverage. We need to have a good test coverage to be able to refactor the code without breaking it, to be able to deliver the software with confidence and to be able to deliver the software with quality.
+In our project, we have implemented unit tests for various components of the application. The tests are written in Java and use the JUnit 5 framework for testing. We also use the Spring Boot Test framework for testing Spring Boot applications, which provides utilities and annotations to test the application in a way that is very close to its actual runtime behavior. The tests are located in the src/test/java/com/uniovi directory. The main test class is Wiq_UnitTests.java, which contains tests for various services and repositories in our application.
+We have implemented load tests to evaluate the performance of our website under extreme situations. For this we use the "Gatling" application, which allows us to evaluate a set of web requests by simulating the number of users who make them simultaneously. +All tests have been carried out with a load of 1, 250, 1000, 2000 and 5000 users, for the following use cases: login, show profile, show apikey, play a game, show personal ranking, show the global ranking, change the language, return to the index and log out.
+1 User:
+
+250 Users:
+
+1000 Users:
+
+2000 Users:
+
+5000 Users:
+
+General information: All responses to the server have generally worked correctly, except for the third response, which logs in using existing credentials. We don’t know exactly why this last request doesn’t work. If we analyze how the number of users affects the login, at first it does not generate any errors, but response times increase considerably, until reaching 5000 active users at the same time, then there is some error related to a timeout.
+
+
1 User:
+
+250 Users:
+
+1000 Users:
+
+2000 Users:
+
+5000 Users:
+
+General information: For this use case, from the beginning all requests worked correctly. As the active users increased, the response time increased, but it was not until reaching 5,000 active users that the request failed, logically related to a timeout. In any case, the graph of the number of responses per second shows quite balanced, with only a large gap of erroneous requests.
+
+
1 User:
+
+250 Users:
+
+1000 Users:
+
+2000 Users:
+
+5000 Users:
+
+General information: The results of the load tests carried out to show the player’s profile almost completely coincide with the results of showing the ApiKey, since in both tests two requests are made, which are supported very well by active users, up to 5000 users, where there are already some failed requests but in rare moments.
+
+
1 User:
+
+250 Users:
+
+1000 Users:
+
+2000 Users:
+
+5000 Users:
+
+General information: The tests of playing the game were the most expensive loading test by far, since each of the users makes a total of 94 requests to the website, in which the vast majority of them are to update visual features of the game such as points, counter or time bar. These tests were so heavy that we had to modify the usability of the application on the host computer, because it ran out of resources when testing 1000 users. Surprisingly, the website supports up to 1000 active users simultaneously without causing any problems other than slightly high waiting times. But after 2,000 active users, failures increase exponentially. The graph of the 5000 users is shown below, where there is a peak in which there are 4193 active users and more than 5000 requests are being made, of which 3000 of them fail. In total, 280,000 requests are made, really heavy.
+
+
1 User:
+
+250 Users:
+
+1000 Users:
+
+2000 Users:
+
+5000 Users:
+
+General information: For these tests we return a little to normal, compared to the previous tests that were excessively heavy. For these tests, access to the personal ranking and its successive pages was attempted. The results were very positive, with very low response times for up to 5000 users, in the latter case generating some failures that are not proportionally relevant.
+
+
1 User:
+
+250 Users:
+
+1000 Users:
+
+2000 Users:
+
+5000 Users:
+
+General information: These tests are very similar to the previous ones, but instead of being the personal ranking it is the global one. However, the response times are very different, being much longer in the case of the global ranking. This is because not only do you have to calculate all the players who have a score, but also add their internal scores to know their position in the ranking, which entails a much greater burden, leading to errors related to timeout when there are 5000 users. Furthermore, the graph shows a rather curious peak of errors, in which 2000 simultaneous requests are made and 1900 are failed.
+
+
1 User:
+
+250 Users:
+
+1000 Users:
+
+2000 Users:
+
+5000 Users:
+
+General information: The execution of these tests consisted of changing the language from the current one to English, then to French and finally to Spanish. Since it is an update of all the dialogues on the page, we assumed that it was going to cause more problems than the current ones. The tests showed considerably good response times even for the maximum number of users tested, in the latter case potentially generating some errors.
+
+
1 User:
+
+250 Users:
+
+1000 Users:
+
+2000 Users:
+
+5000 Users:
+
+General information: These results surprised us quite a bit, since we thought it was going to be the lightest action since it was only about loading the root directory of the website. However, the response times generated are much higher than expected, with half of the requests being longer than 1200ms for 1000 users, and for the maximum number of users, 9% of the requests failing.
+
+
1 User:
+
+250 Users:
+
+1000 Users:
+
+2000 Users:
+
+5000 Users:
+
+General information: Finally, tests were carried out to log out your user. These tests gave very positive results since, despite the fact that for many users there are high waiting times, no errors were caused due to a timeout. The only errors that you will see, now with the 5000 active users, have to do with the 'ClosedChannelException' exception, which is a verified exception in Java that occurs when trying to perform input/output operations on a channel that has been closed.
+
+
In conclusion, the tests generally show very positive results. In no test, except for the game, are there errors with up to 2000 users simultaneously, and errors begin to appear after 5000 users. Looking at the results, the lightest cases are showing the profile, showing the personal ranking and logging out. On the other hand, the hardest cases are playing the game (by far) and showing the global ranking. The tests of the 'multiplayer' game mode could not be carried out, because it was not yet fully implemented at the time of carrying out the load tests.
+