Documentacion mejorada

docs/src/01_introduction_and_goals.adoc

@@ -30,7 +30,7 @@ Los objetivos de calidad en orden de prioridad son los siguientes:
 |===
 | Objetivo | Escenario | Prioridad
 | Usabilidad | La aplicación contará con una interfaz clara y fácil de entender, permitiendo a cualquier usuario jugar sin dificultades. | Alta
-| Disponibilidad | La aplicación estará disponible durante al menos el 98% del tiempo para permitir a los usuarios jugar la mayor cantidad de tiempo posible minimizando interrupciones dejando unas 3 horas y media de mantenimiento semanales. | Alta
+| Disponibilidad | La aplicación estará disponible durante al menos el 95% del tiempo para permitir a los usuarios jugar la mayor cantidad de tiempo posible minimizando interrupciones dejando unas 8 horas y media de mantenimiento semanales. | Alta
 | Rendimiento | Los usuarios tendrán tiempos de respuesta cortos por parte del sistema contando con un máximo de 2 segundos para garantizar una mejor experiencia durante el juego. | Media/Alta
 | Mantenibilidad | La aplicación debe programarse de manera que no genere muchos problemas hacer un cambio. | Media
 | Accesibilidad | Cualquier usuario tendrá las mismas oportunidades que el resto sin importar sus capacidades físicas o cognitivas. | Media

docs/src/02_architecture_constraints.adoc

@@ -35,4 +35,6 @@ y la disponibilidad.
 reduciendo drásticamente el uso de software bajo licencia.
 * El uso de Wikidata reducirá la carga de trabajo de la aplicación, al no tener
 que trabajar sobre una base de datos local.
+* Al usar la api de Wikidata somos dependientes de su disponiblidad y en caso 
+de fallar tambien fallaria nuestra aplicación.
 

docs/src/03_system_scope_and_context.adoc

@@ -37,9 +37,12 @@ Para el desarrollo de este proyecto, utilizaremos la API de Wikidata tanto para
 | React
 | Librería JavaScript que nos permitirá construir la interfaz de la aplicación.
 
-| MongoDB
+| MongoDB Cloud
 | Base de datos NoSQL.
 
 | Node.Js
 | Entorno de servidor para tratar los endpoints.
+
+| Azure
+| Usado para el despliegue de la aplicación en la nube.
 |===

docs/src/04_solution_strategy.adoc

@@ -11,14 +11,14 @@ Para desarrollar la aplicación, seleccionamos las siguientes tecnologías:
 * JavaScript: Es un lenguaje de programacion orientado a objetos, ​ basado en prototipos, imperativo, débilmente tipado y dinámico.
 * Node.js: Es una entorno de ejecucion muy conocido para el desarrollo del back-end de aplicaciones web
 * Wikidata: Base de conocimientos que usaremos para realizar las preguntasd de nuestra aplicación.
-* MongoDB: Es un sistema de base de datos NoSQL, orientado a documentos y de código abierto.
+* MongoDB Cloud: Es un sistema de base de datos NoSQL, orientado a documentos y de código abierto.
 * GitHub: Es una plataforma para alojar proyectos utilizando el sistema de control de versiones Gitç
 * Microsoft Azure: Es una plataforma de servicios en la nube que usaremos para el despliegue de la aplicación.
 
 === Descomposición de alto nivel
 
 ==== Herramientas de diagramado
-Usaremos VisualParadigm y Draw.io para la creacion de diagramas para la documentacion.
+Usaremos PlantUML, VisualParadigm y Draw.io para la creacion de diagramas para la documentacion.
 
 === Enfoques para lograr objetivos de máxima calidad
 
@@ -47,8 +47,8 @@ Usaremos VisualParadigm y Draw.io para la creacion de diagramas para la document
 | Optimizaremos las consultas a Wikidata y el codigo para minimzar los tiempos de respuesta.
 
 | Disponibilidad 
-| La aplicación estará disponible durante al menos el 98% del tiempo para permitir a los usuarios jugar la mayor cantidad de tiempo posible. 
-| Se minimizaran interrupciones dejando unas 3 horas y media de mantenimiento semanales. 
+| La aplicación estará disponible durante al menos el 95% del tiempo para permitir a los usuarios jugar la mayor cantidad de tiempo posible. 
+| Se minimizaran interrupciones dejando unas 8 horas y media de mantenimiento semanales. 
 |===
 
 === Decisiones de organizacion
@@ -57,4 +57,8 @@ Usaremos VisualParadigm y Draw.io para la creacion de diagramas para la document
 - *Problemas:* Todos los problemas encontrados y las tareas encomendads se documentarán como "issues" en GitHub.
 - *GitHub:* Con esta herramienta conseguiremos trabajar cooperativamente y usar las herramientas que ofrece para juntar los proyectos de los diferentes integrantes del equipo.
 - *Comunicacion*: Para la comunicación entre los integrantes del equipo, usaremos tanto la aplicacion de mensajeria móvil "WhatsApp", como "Discord".
-
+- *Revisiones periódicas*: Para hacer una en común de lo realizado, decisiones del trabajo que se iba a realizar a posterior, apertura y asignación de issues (apertura también de issues que se pudieran incorporar de cara al futuro). También lse llevan a cobo reuniones extraordinarias para cercionarnos que cumpliamos con todo correctamente en cada entrega. 
+- *Actas*: Realización de hay un acta por cada reunión realizada, incluidas las extraordinarias, en ellas especificábamos los miembros que acudieron, la revisión de logros de lo llevado desde la última reunión, la toma de decisiones y las issues asignadas a cada persona. 
+- *No división entre front y back*: Para trabajar todos los miembros en ambas partes y principalmente para no vernos limitados a que las personas dedicadas al front tengan que adaptarse a los tiempos y esperar a que se tenga terminado el back y de esta manera hacer un trabajo más fluido.
+- *Ramas*: Se decidió crear una rama para cada miembro del equipo, una rama Dev en la que volcaríamos el trabajo de cada rama individual y que posteriormente iría a máster. También se podrían crear otras ramas si se considerase necesario.  
+- *Issues*: Las issues deben estan asignadas al menos a un par de personas para garantizar su desarrollo.

docs/src/05_building_block_view.adoc

@@ -19,7 +19,9 @@ La vista general de la aplicación y de su entorno es sencilla a la par que esqu
 Bloques contenidos::
 |===
 |Nombre|Responsabilidad
+|_User_| Se trata del usuario que accede a la aplicación.
 |_WIQ_| Se trata del bloque genérico que contiene *todo* lo relativo a la aplicación que desarrollaremos.
+|_WikiData API_| Se trata de la api de Wikidata que da el contenido para la creación de las preguntas.
 |===
 
 
@@ -48,7 +50,7 @@ image::05_bbv_level03.jpg["Level3"]
 
 Este esquema concreta la estructura interna del bloque "Users Managemer" que se encarga, descrito de manera rápida y locuaz, de gestionar las credenciales, fechas de registro y peticiones de login de los usuarios ya registrados y también de aquellos que traten de registrarse por primera vez en nuestra aplicación. También está entre sus labores la de mantener un registro actualizado del ranking (porcentaje de aciertos, numero de partidas jugadas...) de cada uno de los usuarios registrado (lo hará en una base de datos dedicada específicamente a ello). 
 
-El diagrama se divide en cuatro principales componentes (_User Service_, _Authentication Service_, _Ranking Service_) que interactuan con sus respectivas bases de datos. 
+El diagrama se divide en tres principales componentes (_User Service_, _Authentication Service_, _Ranking Service_) que interactuan con sus respectivas bases de datos. 
 
 |===
 |Nombre|Responsabilidad
@@ -66,14 +68,21 @@ Este segundo esquema trata de describir con mayor hondura el funcionamiento inte
 
 Cabe destacar que los microservicios _"GeneratedQuestion Service"_ y _"Create Service"_ comparten una misma base de datos "questiondb" pero utilizan dos colecciones diferentes ("generatedquestions" y "questions" respectivamente). El microservicio "GeneratedQuestions" se encarga de almacenar preguntas completas y, solamente, las respuestas correctas de cada una de las preguntas (lo hace para poder mostrar en cierta funcionalidad del juego las preguntas que ya han sido generadas a modo de "enciclopedia"). Por otro lado el microservicio "Create Service" almacena en su base de datos las plantillas de las preguntas (p.e: "¿Cuál es la capital de ") y el "typeQuestion" (cadena de texto) que resulta relevante dentro de la lógica del microservicio para extraer la "query" (consulta de WikiData) idónea para conseguir completar la pregunta y obtener sus respuestas correctas e incorrectas.
 
-Los otros dos microservicios son "QuestionGenerator" y "Record". Cada uno de ellos utiliza una base de datos separada para almacenar: el primero de ellos las preguntas con todas sus respuestas (correcta e incorrectas); el segundo de ellos las puntuaciones de cada una de las partidas que se juegen por cada uno de los usuarios.
+Los otros dos microservicios son "QuestionGenerator" y "Record". Cada uno de ellos utiliza una base de datos separada para almacenar: el primero de ellos las preguntas con todas sus respuestas (correcta e incorrectas) que se irían generando en el "CreateService"; el segundo de ellos las puntuaciones de cada una de las partidas que se juegen por cada uno de los usuarios.
 
 |===
 |Nombre|Responsabilidad
 |Create Service|Se encarga de, gracias a la interacción con la API de WikiData, generar las preguntas que vayan a presentarse al usuario durante el transcurso de la partida en curso.
 |GeneratedQuestion Service|Se encarga de almacenar las preguntas generadas y sus respuestas correctas para mostrarlas en una especie de recopilatorio de preguntas generadas que se podrán consultar en la aplicación.
 |QuestionGenerator Service|Almacena las preguntas completas (interrogante, respuestas incorrectas y respuesta correcta) para poder mostrarlas durante la partida.
 |Record Service|Registra las estadísticas _de cada una de las partidas_ (de manera independiente para cada partida) de cada uno de los jugadores.
+|Question Database|Contiene dos colecciones, una con las bases de las preguntas para generar las preguntas completas usando la API de wikidata y la segunda para almacenar las preguntas y respuestas correctas (que corresponderían a las que le han sido mostradas al usuario). 
+|QuestionGenerator Database|Almacena las preguntas generadas de wikidata junto con su respuesta correcta y sus tres incorrectas.
+|Record Database|Almacena todas las jugadas realizadas.
 |===
 
-_Cabe destacar que hemos situado *Record Service* en el paquete relativo a las preguntas. Esto lo hemos hecho así porque creemos que mantiene mayor relación con las mismas y con el "juego" en sí, más que con el paquete relativo a la información de los usuarios. Sin embargo, la decisión contraria también tiene su lógica._
+==== Gateway Service
+Se trataría de un microservicio que hace de nexo entre los diferentes microservicos y las a estos desde el frontend
+
+
+_*Cabe destacar que hemos situado *Record Service* en el paquete relativo a las preguntas. Esto lo hemos hecho así porque creemos que mantiene mayor relación con las mismas y con el "juego" en sí, más que con el paquete relativo a la información de los usuarios. Sin embargo, la decisión contraria también tiene su lógica._