Skip to content

Commit

Permalink
replacing some scenario diragrams, changed some arch. constraints to …
Browse files Browse the repository at this point in the history
…decisions and complete quality scenarios
  • Loading branch information
alexfdzs committed Apr 29, 2024
1 parent 548c63c commit 1b5757e
Show file tree
Hide file tree
Showing 6 changed files with 13 additions and 10 deletions.
Binary file modified docs/images/getQuestionScenario.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file modified docs/images/getRecordScenario.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file modified docs/images/quality_tree.png
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
8 changes: 1 addition & 7 deletions docs/src/02_architecture_constraints.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -10,13 +10,7 @@ ifndef::imagesdir[:imagesdir: ../images]
| _Web app_ | The application we are developing is a web game called WIQ consisting of automatically generated questions and answers. Users, once logged in, must answer within a certain time to win prizes.
Additionally, users will also have access to the history of their games.
| _Documentation_ | Diagrams and ASCIIDoc will be used along with the Arc42 template to keep the documentation updated throughout the development of the web app.
| _SPARQL_ | To generate the questions and answers for the game, we will use SPARQL in Wikidata as it is a great source of information to provide
different types of questions to the users, making the game versatile and non-repetitive.
| _Question generator_ | Using the Sparql querys, questions will be automatically generated along with the correct and three incorrect answers. This questions will be
answered by the user and saved in their history. By using this generator, we ensure that the likelihood of getting the same question in another game is almost none.
| _Users login_ | The login of the users must be the first thing that shows up when you open the web of the game. Users will be able to register and to log in. After registering,
it will be necessary to log in to access the website and start the game.
Users who already have an account will have the option to start the game or view their data from previus games (number of games, correct and incorrect answers, time played, etc).
| _Question generator with Wikidata_ | Questions will be automatically generated along with the correct and three incorrect answers. This questions will be generated with Wikidata.
| _Deployment_ | The web app must have a frontend to interact with the game through a web interface, which will be deployed in a virtual machine. To deploy locally
for testing before releasing, we will use Docker and npm.
|===
Expand Down
9 changes: 7 additions & 2 deletions docs/src/09_architecture_decisions.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -9,13 +9,17 @@ ifndef::imagesdir[:imagesdir: ../images]
[options="header",cols="1,2"]
|===
| Decision | Reason
| _React.js_ | We decided to use React.js because it is one of the most popular Javascript libraries used nowadays.
Although none of us were familiar with it, we thought it would make programming the front-end part of the app better and easier for us.
| _Javascript_ | We chose to stick with Javascript for the development of this web app because we already had knowledge of this language from other subjects.
We found it to be an accessible language capable of fulfilling all the app's requirements, including using APIs such as the one from Wikidata.
| _React.js_ | We decided to use React.js because it is one of the most popular Javascript libraries used nowadays.
Although none of us were familiar with it, we thought it would make programming the front-end part of the app better and easier for us.
| _Mongodb_ | For the database aspect of the app, we opted for Mongodb as we believe it is a well-suited option for storing the data necessary for the design and development of the app.
| _SPARQL_ | To generate the questions and answers for the game, we will use SPARQL in Wikidata as it is a great source of information to provide
different types of questions to the users, making the game versatile and non-repetitive.
| _Users login_ | When a user logs into the application, 10 questions will be automatically generated and saved in the database. The decision was made based on the performance demonstrated compared to the other options.
|===


=== Package division

[options="header",cols="1,2"]
Expand All @@ -34,4 +38,5 @@ ifndef::imagesdir[:imagesdir: ../images]
- _UserService_: Manages user-related operations like password hashing, and password and username validation. It also contains the model of the information that the application stores for each user.
| _Webapp_ | It is responsible for creating the web application´s user interface and involves various functionalities such as rendering views, handling user interactions and communicating with backend services.
It uses React as the base framework, and html and css to manage the visual appearance of the application.
| _LoadTests_ | Handles load tests to test the functionality and performance of the application.
|===
6 changes: 5 additions & 1 deletion docs/src/10_quality_requirements.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ The main quality objectives of the project will be:
* Functionality: The system will offer a set of features and tools to fulfill user needs.
* Performance: The system will provide fast and effective responses to the user.
* Maintainability: The system will be easy to maintain, upgrade or extend, without putting the whole project at risk.
* Security: The system will ensure the privacy and integrity of user data.
* Security: El sistema será seguro para las contraseñas, ya que están hasheadas, y tendrá seguridad contra inyección en URL.

=== Quality Tree

Expand All @@ -28,6 +28,8 @@ We will categorize the quality scenarios into three main types: usage, change, a
| Players | A player wants to start a game | Performance | Game Interface | The system creates the game | Game creation time less than 0.5s
| Players | A player wants to answer a question | Performance | Game Interface | The system updates the question interface | Question update time less than 0.5s
| Players | A player wants to login with username and password | Security | User Interface | The system stores these credentials | These credentials will be encrypted to maintain their security.
| Players | A player wants to access his personal game history | Performance | The system will show the personal game history | These games will be showned in less than 1s
| Players | A player wants to see the global ranking | Ranking Interface | The system will show the global ranking ordered by number of correct answers | All user's ranking will be showned ni less than 1.5s
|===

==== Change scenarios
Expand All @@ -45,4 +47,6 @@ We will categorize the quality scenarios into three main types: usage, change, a
|===
| Source | Stimulus | Attribute | Artifact/Environment | Reply | Response measure
| Game error | An error occurs during the creation of a game | Failure | Game Interface | The system doesn't create the game | The system will alert the user of the error in the creation
| Question error | A user wants to play a category mode y no hay preguntas de esa categoría | Failure | Game Interface | The system doesn't create the question | The system will alert the user of the error
| Record error | An error occurs durante el acceso al historial de un usuario | Failure | Record Interface | The system wont show the record | The system will alert the user with a internall server error
|===

0 comments on commit 1b5757e

Please sign in to comment.