Merge branch 'develop' into sonia

README.md

@@ -15,15 +15,20 @@ This repo is a basic application composed of several components.
 
 Both the user and auth service share a Mongo database that is accessed with mongoose.
 
+## Members of the group
+  Adrián Santamarina
+
 ## Quick start guide
 
+## Team Members
+### David Gonzalez
+
 ### Using docker
 
 The fastest way for launching this sample project is using docker. Just clone the project:
 
 ```sh
-git clone https://github.com/Arquisoft/wiq_es05c.git
-```
+git clone https://github.com/Arquisoft/wiq_es05c.git 
 
 and launch it with docker compose:
 
@@ -112,4 +117,3 @@ This action uses three secrets that must be configured in the repository:
 - DEPLOY_KEY: key to authenticate the user in the remote machine.
 
 Note that this action logs in the remote machine and downloads the docker-compose file from the repository and launches it. Obviously, previous actions have been executed which have uploaded the docker images to the GitHub Packages repository.
- 

docs/package.json

@@ -4,12 +4,11 @@
     "description": "Npm project just for the docs",
     "main": "index.js",
     "scripts": {
-      "build": "shx rm -rf build && asciidoctor -D build -a imagesdir=./images -r asciidoctor-diagram index.adoc && shx cp -R images build",
-      "deploy": "gh-pages -d build"
+        "build": "shx rm -rf build && asciidoctor -D build -a imagesdir=./images -r asciidoctor-diagram index.adoc && shx cp -R images build",
+        "deploy": "gh-pages -d build"
     },
     "dependencies": {
-      "gh-pages": "^3.2.3",
-      "shx": "^0.3.3"
+        "gh-pages": "^3.2.3",
+        "shx": "^0.3.3"
     }
-  }
-
+}

docs/src/01_introduction_and_goals.adoc

@@ -15,6 +15,10 @@ These include
 * relevant stakeholders and their expectations
 ****
 
+WIQ is a Web application requested by RTVE, in order to create an experimental online version of a question and
+answer contest similar to “Saber y Ganar”. 
+The development of said application has been entrusted to our company, HappySw.
+
 === Requirements Overview
 
 [role="arc42help"]
@@ -41,6 +45,12 @@ See https://docs.arc42.org/section-1/[Introduction and Goals] in the arc42 docum
 
 ****
 
+The main requirements to be met by our application will be:
+
+* A registration/access system in which users will be able to consult their participation history.
+* A random question generator to avoid repeating questions.
+* A base game mode, in which there will be a time limit to answer each question.
+
 === Quality Goals
 
 [role="arc42help"]
@@ -63,6 +73,15 @@ If you as an architect do not know how the quality of your work will be judged..
 A table with quality goals and concrete scenarios, ordered by priorities
 ****
 
+[options="header",cols="1,2"]
+|===
+|Goals | Description
+| Usability | The user must be able to use the system in a simple and intuitive way, so that a good experience is provided.
+| Accesibility | The system should provide the necessary help to the user to be able to navigate through the program without any doubt.
+| Privacy | The system must ensure the privacy of users. In addition, they will not see the history of other users.
+| Performance | The application must have good performance, without excessive loading times.
+|===
+
 === Stakeholders
 
 [role="arc42help"]
@@ -85,9 +104,11 @@ These stakeholders determine the extent and the level of detail of your work and
 Table with role names, person names, and their expectations with respect to the architecture and its documentation.
 ****
 
-[options="header",cols="1,2,2"]
+[options="header",cols="1,2"]
 |===
-|Role/Name|Contact|Expectations
-| _<Role-1>_ | _<Contact-1>_ | _<Expectation-1>_
-| _<Role-2>_ | _<Contact-2>_ | _<Expectation-2>_
+|Role/Name | Expectations
+| HappySw | Interested in making the application work as well as possible to please users and their contractors.
+| Developer Team | Interested in improving their skills by completing this application.
+| RTVE | Interested in the social and financial success of the application.
+| Users | Interested in the application being entertaining and simple.
 |===

docs/src/02_architecture_constraints.adoc

@@ -1,27 +1,30 @@
-ifndef::imagesdir[:imagesdir: ../images]
-
 [[section-architecture-constraints]]
 == Architecture Constraints
 
-
-[role="arc42help"]
-****
-.Contents
-Any requirement that constraints software architects in their freedom of design and implementation decisions or decision about the development process. These constraints sometimes go beyond individual systems and are valid for whole organizations and companies.
-
-.Motivation
-Architects should know exactly where they are free in their design decisions and where they must adhere to constraints.
-Constraints must always be dealt with; they may be negotiable, though.
-
-.Form
-Simple tables of constraints with explanations.
-If needed you can subdivide them into
-technical constraints, organizational and political constraints and
-conventions (e.g. programming or versioning guidelines, documentation or naming conventions)
-
-
-.Further Information
-
-See https://docs.arc42.org/section-2/[Architecture Constraints] in the arc42 documentation.
-
-****
+1.Technical Constraints
+[options = "header", cols = "1,2"]
+|===
+| Constraint | Description
+| Docker | Software that allows automating the deployment of applications. The application will be running on a Docker host.
+| React | JavaScript library required for building user interfaces for the web. 
+| MongoDB | Default choice for non-relational database selected for the task.
+|===
+
+2.Organizational Constraints
+[options = "header", cols = "1,2"]
+|===
+| Constraint | Description
+| Team | A team formed by 5 individuals who will need to learn to work and coordinate together.
+| Time | We need to learn how to manage time effectively as we must optimize the time between meetings, in-class work, and homework. The lack of experience and the learning curve associated with new technologies can lead to issues.
+| New Technologies | The majority of technologies are new to us, and we need to learn how to work with them.
+| Communication Difficulties | The lack of familiarity within the team can lead to misunderstandings or a lack of communication and coordination.
+|===
+
+3.Convention Constraints
+[options = "header", cols = "1,2"]
+|===
+| Constraint | Description
+| Documentation | Arc42 is a template for architecture documentation. It is the one we should use to generate the documentation.
+| Code | The code should follow an order that does not pose any problem when understanding it for another team member.
+| Structure | The project must follow a fixed structure, both the documentation and the code must be done under the same standards.
+|===

docs/src/03_system_scope_and_context.adoc

@@ -47,10 +47,16 @@ Alternatively (or additionally) you can use a table.
 The title of the table is the name of your system, the three columns contain the name of the communication partner, the inputs, and the outputs.
 
 ****
+In our business setting, we have developed a web application called WIQ, where users engage in a question-based game. 
+This application draws inspiration from the renowned Spanish television program "Saber y Ganar," providing users with an interactive and entertaining experience.
 
-**<Diagram or Table>**
 
-**<optionally: Explanation of external domain interfaces>**
+
+* Users authenticate themselves within the system using their personal information.
+* The application offers a question-based game similar to "Saber y Ganar" .
+* The primary objective of the project is to provide an interactive and enjoyable platform for users to engage in question and answer contests, promoting both entertainment and learning.
+* Users have access to various metrics regarding their participation, including the number of games played, correct and incorrect answers, and time spent on each question.
+
 
 === Technical Context
 
@@ -68,8 +74,13 @@ together with a mapping table showing the relationships between channels and inp
 
 ****
 
-**<Diagram or Table>**
-
-**<optionally: Explanation of technical interfaces>**
-
-**<Mapping Input/Output to Channels>**
+[options="header",cols="1,2"]
+|===
+|Technologies |Description
+| JavaScript | A fundamental programming language for web development. It's used to create logic and interactivity in web and mobile applications.
+| React | A JavaScript framework used to build interactive and dynamic user interfaces. It's especially popular for developing single-page applications (SPAs).
+| MongoDB |  A NoSQL database that uses JSON documents to store data. It's widely used in web and mobile applications, especially those requiring flexible and fast scalability.
+| NodeJS | JavaScript runtime environment
+| Docker | A container platform that simplifies the deployment and management of applications. It allows packaging an application and all its dependencies into lightweight, 
+portable containers, making it easy to deploy across different development and production environments.
+|===

docs/src/04_solution_strategy.adoc

@@ -1,32 +1,23 @@
-ifndef::imagesdir[:imagesdir: ../images]
-
 [[section-solution-strategy]]
 == Solution Strategy
 
+=== Technology Decisions
+The following technologies are used in the development of our application:
+* *React*: JavaScript library for building efficient user interfaces.
+* *JavaScript*: Chosen language for application development.
+* *GitHub*: Platform that allows us to have a repository where to develop the project and perform different actions such as creating issues or tasks.
+* *MongoDB*: Non-relational database we will use for the project.
+* *Docker*: Virtualization platform where we will deploy the project.
+* *Wikidata*: Wikidata is a knowledge base that provides data sources, used to obtain information for the game. In this case, it is mandatory.
 
-[role="arc42help"]
-****
-.Contents
-A short summary and explanation of the fundamental decisions and solution strategies, that shape system architecture. It includes
-
-* technology decisions
-* decisions about the top-level decomposition of the system, e.g. usage of an architectural pattern or design pattern
-* decisions on how to achieve key quality goals
-* relevant organizational decisions, e.g. selecting a development process or delegating certain tasks to third parties.
-
-.Motivation
-These decisions form the cornerstones for your architecture. They are the foundation for many other detailed decisions or implementation rules.
-
-.Form
-Keep the explanations of such key decisions short.
-
-Motivate what was decided and why it was decided that way,
-based upon problem statement, quality goals and key constraints.
-Refer to details in the following sections.
+=== Top-level Decomposition
 
 
-.Further Information
+=== Key quality goals
 
-See https://docs.arc42.org/section-4/[Solution Strategy] in the arc42 documentation.
 
-****
+=== Organizational decisions
+Here are the organization decisions made:
+* *Language*: We will use English as the primary language for both documentation and code.
+* *GitHub issues*: We will use GitHub issues as the main source for problem resolution, so that whenever something poses an obstacle, it will be documented in GitHub issues.
+* *GitHub projects*: GitHub projects allow us to organize work based on issues in a Kanban-style, enabling us to see issues that are in progress, those that are not, and those that are completed.

docs/src/06_runtime_view.adoc

@@ -4,62 +4,41 @@ ifndef::imagesdir[:imagesdir: ../images]
 == Runtime View
 
 
-[role="arc42help"]
-****
-.Contents
-The runtime view describes concrete behavior and interactions of the system’s building blocks in form of scenarios from the following areas:
+=== Register user
 
-* important use cases or features: how do building blocks execute them?
-* interactions at critical external interfaces: how do building blocks cooperate with users and neighboring systems?
-* operation and administration: launch, start-up, stop
-* error and exception scenarios
+image::registerSecuencia.png["Register secuence diagram image"] 
 
-Remark: The main criterion for the choice of possible scenarios (sequences, workflows) is their *architectural relevance*. It is *not* important to describe a large number of scenarios. You should rather document a representative selection.
+1. The user wants to register in the sistem
+2. The app redirects the register request to the RegisterService
+3. The register service sends to the database the data to get information about it
+4. A response is sent by the database with information about that user in process of registration
+5. The RegisterService validates if the user is correct with that info recieved
+6. If the check was afirmative then the RegisterService registre the user
+7. The RegisterService inform with the result the app
+8. Finally the app carries that result to the user 
 
-.Motivation
-You should understand how (instances of) building blocks of your system perform their job and communicate at runtime.
-You will mainly capture scenarios in your documentation to communicate your architecture to stakeholders that are less willing or able to read and understand the static models (building block view, deployment view).
 
-.Form
-There are many notations for describing scenarios, e.g.
+=== Login
 
-* numbered list of steps (in natural language)
-* activity diagrams or flow charts
-* sequence diagrams
-* BPMN or EPCs (event process chains)
-* state machines
-* ...
+image::loginSecuencia.png["Login secuence diagram image"] 
 
+1. The user wants to login his account
+2. The app redirects the login request to the LoginService
+3. The LoginService request information about that login data recieved
+4. A response is sent by the database with the requested data
+5. After checking if it's a valid login the LoginService sends a response to the app
+6. Finally the app inform the user about his login process
 
-.Further Information
 
-See https://docs.arc42.org/section-6/[Runtime View] in the arc42 documentation.
+=== Request a question
 
-****
+image::nextQuestion.png["NextQuestion secuence diagram image"] 
 
-=== <Runtime Scenario 1>
-
-
-* _<insert runtime diagram or textual description of the scenario>_
-* _<insert description of the notable aspects of the interactions between the
-building block instances depicted in this diagram.>_
-
-It is possible to use a sequence diagram:
-
-[plantuml,"Sequence diagram",png]
-----
-actor Alice
-actor Bob
-database Pod as "Bob's Pod"
-Alice -> Bob: Authentication Request
-Bob --> Alice: Authentication Response
-Alice  --> Pod: Store route
-Alice -> Bob: Another authentication Request
-Alice <-- Bob: another authentication Response
-----
-
-=== <Runtime Scenario 2>
-
-=== ...
-
-=== <Runtime Scenario n>
+1. The user asks for a new question
+2. The app redirects that request to the QuestionGenerator
+3. The QuestionGenerator generates a heather for the question
+4. The QuestionGenerator requests the correct answer to WikiData
+5. WikiData sends that answer data
+6. The QuestionGenerator builds the question with the answer and wrong options
+7. The built question is sent to the app
+8. The app shows the question to the User