diff --git a/docs/src/09_architecture_decisions.adoc b/docs/src/09_architecture_decisions.adoc index 421aff80..3daf3d02 100644 --- a/docs/src/09_architecture_decisions.adoc +++ b/docs/src/09_architecture_decisions.adoc @@ -26,7 +26,13 @@ During the application development process, decisions had to be made as issues e |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. + +|Template method pattern +|We chose to apply our software design knowledge and generate the questions following a template method in Java. This allows us to create new questions easily and without duplicating too much code. + +|Use of JPA in the Question Generator +|We used JPA in favor of JDBC as when tables are related in a DB, JPA makes it easier to write into the DB. |=== -If needed, a more descriptive record can be seen link:https://github.com/Arquisoft/wiq_en2b/wiki[here]. +If needed, more details are given in the link:https://github.com/Arquisoft/wiq_en2b/wiki[wiki]. diff --git a/docs/src/11_technical_risks.adoc b/docs/src/11_technical_risks.adoc index 4b7987dd..c48e770a 100644 --- a/docs/src/11_technical_risks.adoc +++ b/docs/src/11_technical_risks.adoc @@ -16,6 +16,52 @@ ifndef::imagesdir[:imagesdir: ../images] |Coordination and responsability problems |It is probably the first time involvement in developing a project from scratch, including decisions on architecture, design, and implementation, introduces various challenges. Misunderstandings regarding tasks and version control management errors can result in individuals inadvertently disrupting the work of others. Additionally, the necessity to make numerous decisions and reach agreements increases the likelihood of errors, potentially consuming significant time and effort. |To ensure effective collaboration and organization, adhere to the teachers' instructions concerning GitHub, including utilizing features such as issues and pull requests, and maintain a disciplined approach to your work. Furthermore, leverage the collective knowledge and suggestions of every team member, integrating them with your existing expertise. + +|Hardcoded url in prometheus.yml +|We do not have the expertise in prometheus to know how to properly set up the URL, so we decided to harcode it. +|Investigate the way to use a variable in the file and use it. + +|Hardcoded ip in graphana dashboard.yml +|As in the previous case, we do not have the expertise in graphana to know how to properly set up the IP, so we decided to harcode it. +|Investigate the way to use a variable in the file and use it. + +|Non optimal code (loadAnswers) +|When designing the application we did not take into account that two users may have the same question given to them at the same time. To solve a problem that would arise with that, we decided to just load the distractors of a question once and use the same distractors for all following games, this means that a question always has the same distractors which can get boring. +|Rewrite the code (which means altering the workflow) so the distractors are load per game and user, so everytime a questions is asked, the distractors are different. + +|Use of "supress warnings" +|We use Lombok to annotate our classes and make the code lighter, this means that getters and setters are generated by the annotations and not explicitly written in our code, due to this, SonarCloud thinks that our private attributes are not used (the getters and setters are public and used by outside classes, but SonarCloud does not detect that). +|Sadly, at this moment we do not think this can be avoided, so the mitigation is just to wait for a SonarCloud update that does detect this. + +|Questions tied to ID +|Questions are tied to the game entities by means of relational tables via id, which makes it difficult to update if they change. +|Creating a unique identifier for each question that can stay throughout versions, so we do not need the BD autogenerated ID to access them. + +|JWT handling could be improved +|Handling the session has been difficult and we came up with a solution that works, but can be improved. +|We should investigate how to improve session handling, as an example using React context + +|Usage of React +|React has proven to be a pain to work with, so we could change it for better options in case we shall continue the developing of the application. +|Changing to Vue.js should be considered. + +|Queries are hardcoded +|To write the questions faster and prevent losing time with possible bugs we hardcoded the queries to Wikidata, which makes the code less readable and maintainable. +|The queries can be written in an external file and then read in the code, possibly using a properties file. + +|QG code can be refactored for lighter classes +|As with all the projects in Software developing, as you code you find yourself repeating lines, this has happened in the Question templates, which makes it a bit tedious to change those files. +|More abstract classes should be included between the QuestionTemplate.java class and each implementation of it. + +|Use of relational DB for questions +|We started using a relational DB as we were more comfortable with it, but it caused its own troubles, as repeating many lines in the DB. +|Using a NoSQL DB as Neo4j for storing the questions could be better as it would be lighter and we would keep the relations that exist in Wikidata between questions. + +|e2e ran in local +|We had many troubles trying to set up the e2e in the actions, as they include setting up the db and filling it before this tests are started. +|We should investigate about this and learn how to set up the tests. + + |=== -In terms of technical debt, it's likely to be significant due to our lack of familiarity with the majority of the technologies involved for most of the team. Both Wikidata and React present considerable challenges, and we anticipate accumulating substantial technical debt in both areas. At present, our only strategy for mitigation is to search for potential solutions online. \ No newline at end of file +In terms of technical debt, it's likely to be significant due to our lack of familiarity with the majority of the technologies involved for most of the team. Both Wikidata and React present considerable challenges, and we anticipate accumulating substantial technical debt in both areas. At present, our only strategy for mitigation is to search for potential solutions online. diff --git a/docs/src/12_glossary.adoc b/docs/src/12_glossary.adoc index f9503e9f..f7e783a9 100644 --- a/docs/src/12_glossary.adoc +++ b/docs/src/12_glossary.adoc @@ -9,5 +9,5 @@ ifndef::imagesdir[:imagesdir: ../images] |Term |Definition |Distractor | Incorrect answer shown to the user alongside the correct one in each question |KiWiq | The name of our project -|Question Generator |A module of the application responsible for querying Wikidata, creating the questions and storing them in our DB +|Question Generator (QG) |A module of the application responsible for querying Wikidata, creating the questions and storing them in our DB |===