Arreglada la documentacion

.gitignore

@@ -1,4 +1,5 @@
 node_modules
 coverage
 docs/build
-.idea
+.idea
+.vscode

README.md

@@ -10,20 +10,20 @@ Enlace a grafana: (http://20.77.40.187:9091/)
 Equipo de Desarrollo
 - Zohaib Aktar Kausar -> <a href="https://github.com/Verzidee"><img src="https://img.shields.io/badge/perfil-Verzidee-black"></a> 
 - Yago Navajas González -> <a href="https://github.com/yagonavajas"><img src="https://img.shields.io/badge/perfil-yagonavajas-purple"></a> 
-- Santiago Lopez Laso -> <a href="https://github.com/Santiago21112001"><img src="https://img.shields.io/badge/perfil-Santiago21112001-green"></a>
+- Santiago López Laso -> <a href="https://github.com/Santiago21112001"><img src="https://img.shields.io/badge/perfil-Santiago21112001-green"></a>
 
 Estos son los componentes que componen la aplicación web.
 
-- **Servicio de Gateway**. Servicio Express expuesto al público que actúa como un proxy hacia los servicios subyacentes.
-- **Servicio de Usuarios**. Servicio Express encargado de registrar nuevos usuarios en el sistema.
-- **Servicio de Autenticación**. Servicio Express que se ocupa de verificar la identidad de los usuarios.
-- **Servicio de Historial**. Servicio Express que gestiona los registros de juegos jugados por los usuarios.
-- **Servicio de Preguntas**. Servicio Express que se encarga de la generación de preguntas y de realizar consultas a la API de Wikidata.
-- **Aplicación Web**. Aplicación web desarrollada en React que interactúa con el Servicio Gateway para ofrecer funcionalidades de inicio de sesión, registro de nuevos usuarios, la posibilidad de jugar y la opción de revisar las estadísticas de juegos anteriores.
+- **gatewayservice**. Servicio Express expuesto al público que actúa como un proxy hacia los servicios subyacentes.
+- **userservice**. Servicio Express encargado de registrar nuevos usuarios en el sistema.
+- **authservice**. Servicio Express que se ocupa de verificar la identidad de los usuarios.
+- **historyservice**. Servicio Express que gestiona los registros de juegos jugados por los usuarios.
+- **questionservice**. Servicio Express que se encarga de la generación de preguntas y de realizar consultas a la API de Wikidata.
+- **webapp**. Aplicación web desarrollada en React que interactúa con el Servicio Gateway para ofrecer funcionalidades de inicio de sesión, registro de nuevos usuarios, la posibilidad de jugar y la opción de revisar las estadísticas de juegos anteriores.
 
-La arquitectura de la aplicación está compuesta por microservicios. Cada servicio utiliza una base de datos diferente.
+La arquitectura de la aplicación está compuesta por microservicios. Cada servicio utiliza una tabla privada en la base de datos.
 
-Documentacion: https://arquisoft.github.io/wiq_es04d/
+Documentación: https://arquisoft.github.io/wiq_es04d/
 
 ## Guía rápida para empezar
 
@@ -55,9 +55,9 @@ Primero, inicia la base de datos. Instala y ejecuta Mongo o ejecútalo usando do
 
 También puedes usar servicios como Mongo Atlas para ejecutar una base de datos Mongo en la nube.
 
-Ahora, lanza los servicios de autenticación, usuario y puerta de enlace. Solo ve a cada directorio y ejecuta `npm install` seguido de `npm start`.
+Ahora, lanza los siguientes servicios: gateway, questionservice, authservice, historyservice y userservice. Solo ve a cada directorio y ejecuta `npm install` seguido de `npm start`.
 
-Por último, ve al directorio de la aplicación web y lanza este componente con `npm install` seguido de `npm start`.
+Por último, ve al directorio de webapp y lanza este componente con `npm install` seguido de `npm start`.
 
 Después de que todos los componentes se hayan lanzado, la aplicación debería estar disponible en localhost en el puerto 3000.
 

docs/images/06_sequence-diagram1.plantuml

@@ -0,0 +1,38 @@
+@startuml Diagrama de secuencia plantuml
+actor Usuario
+participant webapp
+participant gatewayservice
+participant authservice
+participant questionservice
+database mongodb
+Usuario -> webapp: inicio sesión
+webapp --> Usuario: pedir nombre/contraseña
+Usuario -> webapp: dar nombre/contraseña
+webapp -> gatewayservice: verificar usuario
+gatewayservice -> authservice: verificar usuario
+authservice -> mongodb: verificar usuario
+mongodb --> authservice: verificación correcta
+authservice --> gatewayservice: verificación correcta
+gatewayservice --> webapp: verificación correcta
+webapp --> Usuario: inicio sesión correcto
+Usuario -> webapp: acceder al juego
+webapp -> gatewayservice: pedir preguntas
+gatewayservice -> questionservice: pedir preguntas
+questionservice -> mongodb: pedir preguntas
+mongodb --> questionservice: dar preguntas
+questionservice --> gatewayservice: dar preguntas
+gatewayservice --> webapp: dar preguntas
+webapp --> Usuario: mostrar primera pregunta
+Usuario -> webapp: responder
+webapp -> webapp: verificar respuesta
+webapp --> Usuario: indicar si es respuesta correcta o incorrecta
+webapp --> Usuario: mostrar siguiente pregunta
+Usuario -> webapp: responder
+webapp -> webapp: verificar respuesta
+webapp --> Usuario: indicar si es respuesta correcta o incorrecta
+webapp --> Usuario: mostrar pregunta n
+Usuario -> webapp: responder pregunta n
+webapp -> webapp: verificar respuesta
+webapp --> Usuario: indicar si es respuesta correcta o incorrecta
+webapp --> Usuario: mostrar número de aciertos y fallos
+@enduml

docs/images/06_sequence-diagram2.plantuml

@@ -0,0 +1,25 @@
+@startuml Diagrama de secuencia plantuml
+actor Usuario
+participant webapp
+participant gatewayservice
+participant authservice
+participant questionservice
+actor wikidata as "Wikidata"
+database mongodb
+Usuario -> webapp: acceder al juego
+webapp -> gatewayservice: pedir preguntas
+gatewayservice -> questionservice: pedir preguntas
+questionservice -> mongodb: pedir preguntas
+mongodb --> questionservice: no hay suficientes preguntas
+webapp --> webapp: retraso preguntas
+webapp --> Usuario: mensaje de espera
+questionservice -> wikidata: hacer consulta
+wikidata --> questionservice: devolver resultados
+questionservice -> questionservice: transformar resultados en preguntas
+questionservice -> mongodb: guardar preguntas
+mongodb --> questionservice: dar preguntas
+questionservice --> gatewayservice: dar preguntas
+gatewayservice --> webapp: dar preguntas
+webapp --> Usuario: quitar mensaje de espera
+webapp --> Usuario: mostrar primera pregunta
+@enduml

docs/index.adoc

@@ -11,7 +11,7 @@ include::src/config.adoc[]
 :revdate: January 2023
 :revremark: (based upon AsciiDoc version)
 // toc-title definition MUST follow document title without blank line!
-:toc-title: Indice
+:toc-title: Índice
 
 //additional style for arc42 help callouts
 ifdef::backend-html5[]

docs/src/01_introduction_and_goals.adoc

@@ -3,20 +3,20 @@ ifndef::imagesdir[:imagesdir: ../images]
 [[section-introduction-and-goals]]
 == Introducción y Objetivos 🎇
 
-El proyecto de WIQ 4D es un proyecto desarrollado en la asignatura Arquitectura del Software. Consiste en la creación de una aplicación web al estilo "Saber y Ganar". Es decir, es un juego de preguntas de cultura general generadas de forma automatica con ayuda de Wikidata, la base de conocimiento editada en colaboración..
+El proyecto de WIQ 04D es un proyecto desarrollado en la asignatura Arquitectura del Software. Consiste en la creación de una aplicación web al estilo "Saber y Ganar". Es decir, es un juego de preguntas de cultura general generadas de forma automática con ayuda de Wikidata, una base de conocimiento que puede ser leída y editada por humanos y por máquinas.
 
-Los desarrolladores de la aplicacion son por Zohaib Akhtar Kausar, Yago Navajas González y Santiago López Laso. 
+Los desarrolladores de la aplicación son Zohaib Akhtar Kausar, Yago Navajas González y Santiago López Laso.
 
 === Requisitos Funcionales
 
 ****
-* Los usuarios se deberán loggearse en la página; esto servirá para tener registro de una serie de parámetros, como puede ser las veces que se ha jugado. 
-* Se podrán responder preguntas autogeneradas y se verá si han acertado o fallado, así como la respuesta correcta.
-* Las preguntas deberán ser respondidas en un tiempo límite.
+* Los usuarios deberán iniciar sesión en la página; esto servirá para tener registro de una serie de parámetros, como puede ser las veces que se ha jugado. 
+* Se podrán responder preguntas autogeneradas y se mostrará si han acertado o fallado, así como la respuesta correcta.
+* Las preguntas deberán ser respondidas dentro de un tiempo límite.
 * Las preguntas seguirán la misma estructura: 1 pregunta correcta y 3 incorrectas, generadas automáticamente.
-* Los usuarios podrán consultar datos sobre su cuentas, como pueden ser las veces que han jugado o el número de preguntas que han acertado o fallado. 
-* Existirá un ranking que ordenará a los 10 mejores jugadores en función de una métrica.
-* Se podrán acceder a los servicios de la aplicación a traves de una API REST.
+* Los usuarios podrán consultar datos sobre sus cuentas, como las veces que han jugado o el número de preguntas que han acertado o fallado.
+* Existirá un ranking que ordenará a los 10 mejores jugadores según una métrica determinada.
+* Se podrá acceder a los servicios de la aplicación a través de una API REST
 
 
 ****
@@ -27,10 +27,10 @@ Los desarrolladores de la aplicacion son por Zohaib Akhtar Kausar, Yago Navajas
 |===
 | Prioridad | Objetivo | Descripción
 | 1 | Usabilidad | Todos los usuarios deben poder usar la aplicación sin tener en cuenta sus limitaciones.
-| 2 | Mantenibilidad | El código y documentación de la aplicación ha de estar conformado de tal forma que sea factible hacer cambios y ampliaciones en la aplicación.
-| 3 | Eficiciencia | Los tiempos entre operaciones han de ser asumibles.
-| 4 | Fiabilidad | Los datos usados en la aplicación deben ser los correctos.
-| 5 | Privacidad |  Los datos sensibles de los usuarios deben estar restringidos al mismo usuario.
+| 2 | Rendimiento | Los tiempos entre operaciones han de ser asumibles, aun teniendo varios usuarios usando la aplicación a la vez.
+| 3 | Seguridad |  Los datos sensibles de los usuarios deben estar restringidos al mismo usuario.
+| 4 | Mantenibilidad | El código y documentación de la aplicación ha de estar conformado de tal forma que sea factible hacer cambios y ampliaciones en la aplicación.
+| 5 | Portabilidad | La aplicación web es compatible con los navegadores web más utilizados (Chrome, Firefox, Safari, Edge).
 |===
 
 
@@ -39,11 +39,12 @@ Los desarrolladores de la aplicacion son por Zohaib Akhtar Kausar, Yago Navajas
 [options="header",cols="1,2,2"]
 |===
 |Role/Name|Contact|Expectations
-| Equipo de Desarrollo | Yago Navajas Gonzalez -> [email protected] +
-Zohaib Akhtar Kausar -> [email protected] +
-Santiago Lopez Laso -> [email protected] | Los estudiantes que llevarán a cabo el desarrollo de la aplicación. Serán los encargados de la arquitectura, la documentación y la codificación.
+| Equipo de Desarrollo | Yago Navajas González +
+Zohaib Akhtar Kausar +
+Santiago López Laso  | Los estudiantes que llevarán a cabo el desarrollo de la aplicación. Serán los encargados de la arquitectura, la documentación y la codificación.
 | Profesores | Jose Emilio Labra Gayo | Supervisores de los avances y encargados de evaluar la aplicación final y el desarrollo de la misma.
-| Usuario | Jugador de la aplicación | Personas que puedan interactuar tanto con el registro de usuarios como con el juego en sí y pueda completar correctamente una partida.
-| HappySw | Empresa responsable | Empresa contratada, cuyo trabajo sera el desarrollo del juego de la mano del equipo de desarrollo.
+| Usuario | Jugador de la aplicación | Personas que puedan interactuar tanto con el registro de usuarios como con el juego en sí y completar correctamente una partida.
+| HappySw | Empresa responsable | Empresa contratada, cuyo trabajo será el desarrollo del juego de la mano del equipo de desarrollo.
+| Wikidata | Proveedor de la información de las preguntas | Si la aplicación tiene éxito, para Wikidata es publicidad gratis. Por tanto, le interesa este proyecto.
 | RTVE | Empleador | Interesados en la creación del juego e impulsores de su desarrollo.
 |===

docs/src/02_architecture_constraints.adoc

@@ -2,26 +2,11 @@ ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-architecture-constraints]]
 == Restricciones de arquitectura ⛔
-
-
-=== Restricciones Técnicas
 [options="header",cols="1,2"]
 |===
 |Restricción|Descripción
-|API Wikidata|El número de consultas en un tiempo espcifico es la mayor limitacion de la API, junto con la disponibilidad de los datos. Esto puede afectar a tiempos de carga, por ejemplo.
-|Git|Conflictos al realizar trabajo por separado por parte de mas de un miembro sobre un mismo recurso.
-|GitHub|La falta de experiencia puede conducir a problemas en la gestion del proyecto asi como en su despliegue y lo que ello conlleva.
+|Wikidata|Se debe usar Wikidata para obtener la información de las preguntas. El número de consultas en un tiempo específico es la mayor limitación de la API, junto con la disponibilidad de los datos. Esto puede afectar a tiempos de carga, por ejemplo.
+|Git|Conflictos al realizar trabajo por separado por parte de más de un miembro sobre un mismo recurso.
+|GitHub|La falta de experiencia puede conducir a problemas en la gestión del proyecto así como en su despliegue y lo que ello conlleva.
 |Integración continua/despliegue continuo (CI/CD)|Restricciones en la configuración de pipelines de CI/CD para automatizar las pruebas, compilaciones y despliegues de la aplicación en el servidor Docker, lo que podría afectar la velocidad y la frecuencia de las entregas de nuevas características o correcciones de errores.
-|Máquina Virtual Azure|Esta plataforma impone límites a la cantidad de recursos que podemos usar con la licencia de estudiantes, por lo que debemos ir con cuidado de cuando tenemos la máquina encendida para no agotar el crédito.
-|===
-
-
-=== Resticciones organizacionales
-[options="header",cols="1,2"]
-|===
-|Restricción | Descripción
-|Horarios y Disponibilidad| Los diferentes compromisos personales y académicos de los miembros del grupo pueden dificultar la coordinación de horarios para reuniones y sesiones de trabajo en equipo.
-|Expectativas y motivación| Los miembros del equipo tienen distintas expectativas sobre el trabajo y esto afecta a la dedicacion que realizan.
-|Politicas de la Universidad|Las entregas de otra asignaturas se interponen en la realización del trabajo y puede derivar en una falta de tiempo para realizarlo.
-|Diferencias en el nivel de habilidades técnicas|A pesar de no ser muy acusadas si que existen diferencias que pueden afectar en una distribucion igualitaria del trabajo.
 |===

docs/src/03_system_scope_and_context.adoc

@@ -4,25 +4,4 @@ ifndef::imagesdir[:imagesdir: ../images]
 == Alcance del sistema y Contexto 💭
 
 === Contexto de negocio
-image::03_diagrama_contexto_negocio.png["Diagrama de contexto de negocio"]
-En esta tabla se muestra el contexto de negocio de la aplicación. Las entradas son los mensajes que van desde el agente externo hacia la aplicación, y las salidas son los mensajes que van desde la aplicación hacia al agente externo.
-[options="header",cols="1,2,3"]
-|===
-|Agente externo|Entradas|Salidas
-|Usuario|Datos registro, datos login, respuesta a cada pregunta|Preguntas, historial
-|Wikidata|Items (elementos) de Wikidata|Petición a la API de Wikidata
-|===
-
-=== Contexto técnico
-
-image::03_diagrama_contexto_tecnico.png["Diagrama de contexto técnico"]
-|===
-
-|Agente externo|Entradas|Salidas
-|Usuario|Datos registro, datos login, respuesta a cada pregunta|Preguntas, historial
-|WIQ|Peticiones del usuario | Respuesta a las peticiones
-|WebApp| Entradas del usuario | Salidas de WIQ
-|Wikidata| Peticiones de datos | Datos 
-|Base de datos|Nuevos usuarios, preguntas de Wikidata y respuestas del usuario| Validación de usuarios, nuevas preguntas de Wikidata e historial
-|Máquina Virtual| Petición de Despliegue | Despliegue 
-|===
+image::03_diagrama_contexto_negocio.drawio.png["Diagrama de contexto de negocio"]