Merge pull request #113 from Arquisoft/Fernando-Prueba

Fernando prueba

docs/src/01_introduction_and_goals.adoc

@@ -15,7 +15,7 @@ These include
 * relevant stakeholders and their expectations
 ****
 
-El objetivo es crear una aplicación web llamada WIQ_es05 basada en el programa de televisión "Saber y Ganar".
+El objetivo es crear una aplicación web llamada QuizMaster basada en el programa de televisión "Saber y Ganar".
 La aplicación permitirá registrarse a los usuarios para poder jugar. Dicho juego consiste en una serie de preguntas generadas aleatoriamente, de diferentes temáticas y respuestas, que deberán responderse en un tiempo determinado.
 Por cada respuesta correcta se obtendrá un premio.
 
@@ -53,7 +53,7 @@ See https://docs.arc42.org/section-1/[Introduction and Goals] in the arc42 docum
 * *Acceso a Información de Usuarios vía API*: Otros sistemas podrán acceder a los datos de los usuarios a través de un API.
 * *Acceso a Información de Preguntas vía API*: Otros sistemas podrán acceder a los detalles de las preguntas generadas mediante un API.
 
-Mira los https://docs.google.com/document/d/1pahOfYFY--Wi7_9bbxiKOGevB_9tOSyRm78blncgBKg/edit[Requisitos de la práctica] para obtener más información.
+Mira los (https://docs.google.com/document/d/1pahOfYFY--Wi7_9bbxiKOGevB_9tOSyRm78blncgBKg/edit)[Requisitos de la práctica] para obtener más información.
 
 
 === Metas de Calidad
@@ -80,10 +80,10 @@ A table with quality goals and concrete scenarios, ordered by priorities
 [cols="e,2e" options="header"]
 |===
 |Nombre|Descripción
-|*Usabilidad*| _La aplicación tiene que poder usarse por el mayor tipo de usuarios, promoviendo una experiencia intuitiva y accesible desde el primer contacto. Además, a medida que los usuarios interactúan más con la aplicación, esta se vuelva más fácil de usar._
-|*Rendimiento*| _El tiempo de respuesta de la aplicación debe ser rápido_
+|*Usabilidad*| _La aplicación tiene que poder usarse por el mayor tipo de usuarios, promoviendo una experiencia intuitiva y accesible desde el primer contacto.Conforme los usuarios se familiarizan y exploran más la aplicación, su uso se vuelve más intuitivo y sencillo, gracias a la curva de aprendizaje._
+|*Rendimiento*| _La aplicación debe de ofrecer un tiempo de respuesta rápido para garantizar una experiencia fluida y eficiente para los usuarios._
 |*Testeable*| _Las pruebas deben ser capaces de detectar errores de manera rápida y precisa, fáciles de mantener y actualizar a medida que el código base cambia. Esto implica que las pruebas estén bien estructuradas y documentadas._
-|*Disponibilidad*| _La aplicación debe estar disponible y caerse lo menos posible_
+|*Disponibilidad*| _Debemos asegurar que la aplicación esté funcional y operativa durante la mayor parte del tiempo._
 |===
 === Stakeholders
 
@@ -113,7 +113,7 @@ Table with role names, person names, and their expectations with respect to the
 | *Profesor* | _Aplicar correctamente los conocimientos y competencias adquiridos en la asignatura Arquitectura del Software_ | _Profesor de la asignatura_
 | *HappySw* | _Una aplicación buena para atraer al mayor número de usuarios_ | _Equipo de desarrollo_
 | *Wikidata* | _Usar su aplicacion con precaución, sin sobrecargar sus servicios_ | _Empresa que nos facilita la API para obtener información_
-| *Usuarios Registrados* | _Poder jugar en la aplicación que recrea el juego sin tener que participar en el programa._ | _Usuarios que ya han jugado anteriormente_
-| *Usuarios No Registrados* | _Poder registrarse lo más rápido posible para empezar a jugar al juego de preguntas y respuestas_ | _Usuarios que nunca jugaron antes_
+| *Usuarios Registrados* | _Poder jugar en la aplicación que recrea el juego sin tener que participar en el programa._ | _Usuarios registrados en la plataforma, pudiendo haber jugado una o más partidas._
+| *Usuarios No Registrados* | _Poder registrarse lo más rápido posible para empezar a jugar al juego de preguntas y respuestas_ | _Usuarios que nunca se han registrado antes_
 | *RTVE* | _Versión mejorada de "Saber y Ganar" para ganar mayor audiencia e interés social._ | _Dueño del producto_
 |===

docs/src/02_architecture_constraints.adoc

@@ -45,6 +45,10 @@ y realizar las pruebas pertinentes._
 
 |*Wikidata*
 |_En la asignatura se requiere que esta sea la fuente de información principal para generar aleatoriamente tanto las preguntas como las respuestas correctas e incorrectas del juego._
+
+|*APIs rest*
+|_Son una limitación por varias razones, no proporcionan seguridad avanzada, no ofrecen un esquema de datos detallados, pueden no ser ideales para
+operaciones mas complejas y requieren endpoints predefinidos._
 |===
 
 === Limitaciones organizativas
@@ -87,15 +91,12 @@ a través de nuestro grupo de WhatsApp y en casos necesarios realizamos reunione
 |Restricción |Explicación
 
 |*Diseño del software*
-|_Para lograr un buen diseño es indispensable que el código de la aplicación sea flexible, mantenible y comprensible. Además se espera un código limpio ('clean code'),
-es decir, que sea fácil de entender, mantener y modificar, y que garantize la claridad, simplicidad y legibilidad._
+|_Para lograr un buen diseño es indispensable que el código de la aplicación sea flexible, mantenible y comprensible. Además se espera un que sigamos los principios de "codigo limpio"
+en cuanto a modularidad, limpieza, nombrado de métodos y variables._
 
 |*Documentación*
 |_Para crearla usaremos la plantilla Arc42 con la finalidad de que sea sencilla y práctica._
 
-|*Accesibilidad*
-|_Nos esforzaremos para que nuestra aplicación sea accesible para todos los usuarios, independientemente de su perfil o características individuales._
-
 |*Estructura*
 |_Debe seguir una estructura de paquetes fija y bajo los mismos estandares. Los diferentes modulos estarán separados en carpetas: 'userservice' para la gestión de
 usuarios (registro y autentificación), 'questionservice' para la comunicación con wikidata y 'webapp' para el desarrollo de la aplicación. Todos estos 

docs/src/03_system_scope_and_context.adoc

@@ -85,7 +85,7 @@ together with a mapping table showing the relationships between channels and inp
 
 ****
 
-image::03_2_contexto_tecnico.png["Diagrama de contexto técnico"]
+image::03_2_contexto_tecnico2.png["Diagrama de contexto técnico"]
 
 [options="header",cols="1e,2"]
 |===
@@ -95,36 +95,38 @@ image::03_2_contexto_tecnico.png["Diagrama de contexto técnico"]
 |Contiene el frontend y backend de la aplicación.
 
 |*MongoDB*
-|Base de datos no relacional para el almacenamiento de usuarios.
+|Base de datos no relacional para el almacenamiento de usuarios y registro de sus partidas.
 
 |*Usuario*
-|El usuario final de la aplicación.
+|Persona que interactua con nuestra aplicación web a través del navegador.
 
 |*Wikidata API*
-|API de donde obtendremos las preguntas y respuesta correcta para el juego de la aplicación.
+|API de donde obtendremos las preguntas y respuestas correctas y falsas para el juego de la aplicación, todas estas preguntas serán cargadas al inicio del juego.
 
 |*Javascript*
-|Lenguaje de programación principal de la aplicación.
+|Lenguaje de programación principal de la aplicación  permite una sintaxis uniforme en toda la aplicación y facilita el mantenimiento del código. Además, al usar JavaScript en el frontend y el backend, se puede compartir lógica entre ambas partes para un desarrollo más eficiente.
 
 |*Express JS*
-|Framework para la creación de aplicaciones web en Javascript, utilizado en el backend.
+|Express es un framework de aplicación web para Node.js, que te permite crear aplicaciones web robustas y escalables en JavaScript para el backend.
 
 |*React*
 |Biblioteca de Javascript para creación de interfaces de usuario, utilizado en el frontend.
 
 |*Bootstrap*
-|Biblioteca para el diseño de aplicaciónes web.
-
+|Biblioteca de código abierto que proporciona herramientas y estilos para el diseño de aplicaciones web y sitios responsivo. Podemos crear interfaces de usuario atractivas y funcionales de manera rápida y sencilla
 
 |*webapp*
 |Módulo del sistema que se encarga de la interfaz del sistema.
 
 |*questionservice*
-|Módulo del sistema que se encarga de la creación de preguntas con la API de Wikidata.
+|Módulo del sistema que se encarga de crear preguntas obteniendo tanto preguntas como respuestas correctas e incorrectas de la API Wikidata 
 
 |*gateway*
-|Módulo del sistema que se encarga de coordinar el resto de modulos del sistmea.
+|Módulo del sistema que funcina como puerta de enlace para coordinar el resto de modulos del sistema.
 
 |*userservice*
-|Módulo del sistema que se encarga de tener los modelos y hacer las consultas para el almacenamiento correcto de los usuarios de la aplicación.
+|Módulo del sistema que se encarga de tener los modelos y hacer las consultas para el almacenamiento correcto de los usuarios de la aplicación y del registro de partidas con la ayuda de nuestra base de datos MongoDB.
+
+|*authservice*
+|Módulo del sistema que se encarga de gestionar la autenticación del usuario.
 |===

docs/src/04_solution_strategy.adoc

@@ -31,13 +31,13 @@ See https://docs.arc42.org/section-4/[Solution Strategy] in the arc42 documentat
 
 ****
 
-* *JavaScript*: Este lenguaje es muy buena opción para utilizar en proyectos en que se empleé la biblioteca REACT. Nos pareció mejor opción que otros lenguajes como TypeScript debido a que su compresión y manejo es más sencillo.
+* *JavaScript*: Este lenguaje es muy buena opción para utilizar en proyectos en que se empleé la biblioteca REACT. Nos pareció mejor opción que otros lenguajes como TypeScript debido a que su compresión y manejo es más sencillo. Además usamos Express es una infraestructura de aplicaciones web en Node.js que ofrece una solución rápida, minimalista y flexible para desarrollar aplicaciones web y móviles1
 
 * *React*: Esta libreria de JavaScript permite la creación de interfaces de usuario para la aplicacion web de forma sencilla.
 
 * *Docker*: Utilizaremos esta plataforma para desplegar la aplicacion web, de manera que puedan realizarse pruebas aisladas de esta misma.
 
-* *Firebase*: Esta API nos servirá como sistema de autenticación del usuario para poder llevar un registro de su historial de partidas, así como algunas de sus estadísticas.
+* *Mongo-DB*: Esta API nos servirá como sistema de autenticación del usuario para poder llevar un registro de su historial de partidas, así como algunas de sus estadísticas.
 
 * *Microservicios:* Enfoque arquitectónico donde el software está compuesto por pequeños servicios independientes. Lo hemos elegido debido a la facilidad para modificar una parte de la aplicación sin afectar al resto.
 

docs/src/05_building_block_view.adoc

@@ -63,7 +63,7 @@ In the best case you will get away with examples or simple signatures.
 
 ****
 
-image::05_sistema-general-caja-blanca.png["Sistema General de Caja Blanca"]
+image::05_sistema-general-caja-blanca_2.png["Sistema General de Caja Blanca"]
 
 
 Motivación::
@@ -78,13 +78,10 @@ Bloques de construcción contenidos::
 |Nombre |Responsabilidad
 
 |*Usuario*
-|_Usuario que interactua con la aplicación._
-
-|*Administrador*
-|_Persona(s) que tienen acceso completo a la aplicación y puede administrarla._
+|_Cuando alguien usa nuestra aplicación, se comunica con ella a través de Internet usando un lenguaje especial llamado HTTP. Cuando se registra en la aplicación, los datos que ingresa se guardan en una base de datos especial llamada MongoDB. Para que esto suceda, usamos una herramienta llamada Mongoose, que nos ayuda a conectarnos y comunicarnos con la base de datos de una manera fácil y segura. Entonces, cada vez que alguien se registra en nuestra aplicación, Mongoose se asegura de guardar esos datos en la base de datos para que puedan ser utilizados más tarde._
 
 |*WIQ*
-|_La propia aplicación._
+|_La propia aplicación, encargada de pedir las preguntas a wikidata para poder llevar a cabo la partida._
 
 |*Wikidata*
 |_Servicio externo desde donde obtenemos los datos para generar las preguntas._
@@ -93,7 +90,7 @@ Bloques de construcción contenidos::
 
 === Nivel 2: WIQ
 
-image::05_nivel_2.png["Nivel 2 de la aplicación: WIQ"]
+image::05_2_nivel_2.png["Nivel 2 de la aplicación: WIQ"]
 
 Bloques de construcción contenidos::
 [cols="e,2e" options="header"]
@@ -104,21 +101,27 @@ Bloques de construcción contenidos::
 |_La interfaz con la que interactua el usuario._
 
 |*gatewayservice*
-|_Servicio de puerta de enlace que actúa como intermediario entre los clientes y 	otros servicios, 
+|_Servicio de puerta de enlace que actúa como intermediario entre los usuario que quieran juagar y otros servicios, 
 reenviando las solicitudes a los servicios correspondientes y devolviendo las respuestas al cliente._
 
 |*authservice*
-|_Servicio de autenticación de usuarios._
+|_Servicio que se encarga de verificar las credenciales de los usuarios al iniciar sesión en la aplicación. Si las credenciales son correctas, se genera un token de acceso que permite al usuario autenticado acceder a partes protegidas de la aplicación._
 
 |*userservice*
-|_Servicio para registro de usuarios._
+|_Servicio que gestiona el registro de nuevos usuarios en la aplicación. Cuando un usuario se registra, se asegura de que se proporcionen los campos necesarios y luego cifra la contraseña antes de guardarla. También ofrece funciones para actualizar las estadísticas del usuario y obtener información de usuario._
 
 |*questionservice*
-|_Servicio para el manejo de datos de Wikidata._
+|_Este servicio se encarga de proporcionar preguntas y respuestas basadas en datos de Wikidata. Utiliza consultas SPARQL para obtener información de Wikidata y luego genera preguntas aleatorias basadas en estos datos para ser utilizadas en la aplicación."_
 
 |*Wikidata*
 |_Servicio externo desde donde obtenemos los datos para generar las preguntas._
 
+|*MongoDB*
+|_MongoDB es un sistema de gestión de bases de datos NoSQL utilizado en la aplicación para almacenar y organizar los datos de manera eficiente. Su responsabilidad principal es gestionar la persistencia de los datos de la aplicación, permitiendo el almacenamiento, consulta y manipulación de la información de manera escalable y flexible._
+
+|*OpenAPI*
+|_Encargado de la especificación utilizada junto a swagger para la creación de una documentacio de todos los métodos que se realizan en gateway._
+
 |===
 
 

docs/src/06_runtime_view.adoc

@@ -41,24 +41,26 @@ See https://docs.arc42.org/section-6/[Runtime View] in the arc42 documentation.
 
 Al iniciar sesión en nuestra Web App, se presentará una interfaz solicitando al usuario que ingrese los datos necesarios para comenzar a jugar. Estos datos incluirán información de identificación única, como nombre de usuario y contraseña, así como posiblemente otros detalles relevantes para el perfil del jugador.
 
-Una vez que el usuario proporciona estos datos, la Web App los enviará al servicio userService, que actuará como el backend encargado de autenticar al usuario y gestionar su sesión. userService verificará la validez de los datos proporcionados por el usuario y, si son correctos, emitirá un token de sesión único que identificará al usuario.
+Una vez que el usuario proporciona estos datos, la Web App los enviará al servicio userService a través de gatewayService, que actuará como el backend encargado de autenticar al usuario y gestionar su sesión. UserService verificará la validez de los datos proporcionados por el usuario y, si son correctos, emitirá un token de sesión único que identificará al usuario.
 
 Este token de sesión se devolverá a la Web App, donde se utilizará para mantener la sesión del usuario durante su interacción con la plataforma de juego.
 
-Una vez que el proceso de inicio de sesión se completa con éxito, la Web App cambiará su interfaz para mostrar la pantalla de inicio del juego, donde el usuario podrá acceder a las diferentes opciones de juego y comenzar a participar en las actividades disponibles.
+Una vez que el proceso de inicio de sesión se completa con éxito, la Web App cambiará su interfaz para mostrar que ha iniciado sesión correctamente.
 
-image::06_acceso2.png["Diagrama vista de tiempo de ejecución para el acceso"]
+image::06_acceso3.png["Diagrama vista de tiempo de ejecución para el acceso"]
 
 === Interacción con Preguntas
 
-Comenzaremos con la REST API que se integra con nuestra base de datos y se encargará de la obtención de la pregunta junto con sus opciones de respuestas correctas e incorrectas, proporcionando así la información necesaria para la Web App.
+Comenzaremos con la REST API que obtendrá las preguntas de Wikidata junto con sus opciones de respuestas correctas e incorrectas.
 
-Al obtener dicha información, la Web App mostrará la pregunta junto con todas las opciones de respuesta disponibles al usuario, quien podrá seleccionar una única respuesta entre las opciones proporcionadas. Una vez que el usuario ha realizado su selección, la Web App verificará la precisión de la respuesta.
+Al obtener dicha información, QuestionService se la transmitirá a GatewayService que a su vez ira mostrando en Web App pregunta por pregunta junto con todas las opciones de respuesta disponibles al usuario, quien podrá seleccionar una única respuesta entre las opciones proporcionadas. Una vez que el usuario ha realizado su selección, la Web App verificará la precisión de la respuesta.
 
 Posteriormente, basándose en la respuesta proporcionada por el usuario, la Web App ofrecerá una retroalimentación visual clara que permitirá al usuario comprender si su respuesta fue correcta o incorrecta.
 
 Por tanto, terminaremos con una retroalimentación visual por pantalla del resultado obtenido tras la respuesta del jugador.
 
+Tras esto y cuando el jugador solicite la siguiente pregunta se seguirá repitiendo el proceso de GatewayService proporcionando a WebApp una nueva pregunta hasta terminar el juego.
+
 Este flujo de interacción garantiza una experiencia de usuario fluida y comprensible, optimizando así la participación y el compromiso del usuario con la plataforma.
 
-image::06_pregunta2.png["Diagrama vista de tiempo de ejecución para la pregunta"]
+image::06_pregunta4.png["Diagrama vista de tiempo de ejecución para la pregunta"]