From f8333fcf9c41850c15faec2108ecebeaa9b67df1 Mon Sep 17 00:00:00 2001 From: uo277310 Date: Fri, 3 May 2024 17:38:24 +0200 Subject: [PATCH 01/12] =?UTF-8?q?Actualizados=20puntos=201-5=20de=20docume?= =?UTF-8?q?ntaci=C3=B3n?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/src/01_introduction_and_goals.adoc | 2 +- docs/src/02_architecture_constraints.adoc | 2 ++ docs/src/04_solution_strategy.adoc | 6 ++-- docs/src/05_building_block_view.adoc | 4 ++- docs/src/06_runtime_view.adoc | 43 +++++++++++++++-------- 5 files changed, 37 insertions(+), 20 deletions(-) diff --git a/docs/src/01_introduction_and_goals.adoc b/docs/src/01_introduction_and_goals.adoc index b70cee55..2928773f 100644 --- a/docs/src/01_introduction_and_goals.adoc +++ b/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 diff --git a/docs/src/02_architecture_constraints.adoc b/docs/src/02_architecture_constraints.adoc index 9a255e79..db7c5664 100644 --- a/docs/src/02_architecture_constraints.adoc +++ b/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. diff --git a/docs/src/04_solution_strategy.adoc b/docs/src/04_solution_strategy.adoc index fcb62493..c8938fb0 100644 --- a/docs/src/04_solution_strategy.adoc +++ b/docs/src/04_solution_strategy.adoc @@ -18,7 +18,7 @@ Para desarrollar la aplicación, seleccionamos las siguientes tecnologías: === 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 diff --git a/docs/src/05_building_block_view.adoc b/docs/src/05_building_block_view.adoc index f57007d7..ab8a0147 100644 --- a/docs/src/05_building_block_view.adoc +++ b/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 diff --git a/docs/src/06_runtime_view.adoc b/docs/src/06_runtime_view.adoc index 7724db85..034c2c48 100644 --- a/docs/src/06_runtime_view.adoc +++ b/docs/src/06_runtime_view.adoc @@ -5,28 +5,41 @@ ifndef::imagesdir[:imagesdir: ../images] === Registro en la aplicación -[plantuml,"Sequence diagram",png] +[plantuml,"Registro",png] ---- actor User participant App -database DB +participant Gateway +participant UserService +database DBuser User -> App: Selecciona opción de registro User <-- App: Muestra pantalla de registro User -> App: Ingresa datos de registro -App -> DB: Comprueba los datos -App <-- DB: Valida los datos +App -> Gateway: Envía los datos +Gateway -> UserService: Envía los datos +UserService -> UserService: Comprueba los datos + alt usuario válido - App -> DB: Guarda datos de registro - App <-- DB: Confirma registro + + UserService -> DBuser: Guarda datos de registro + UserService <-- DBuser: Confirma registro + Gateway <-- UserService : Confirma registro + App<-- Gateway: Confirma registro User <-- App: Confirma Registro -alt usuario inválido + +else usuario no valido + + Gateway <-- UserService: Deniega registro + App <-- Gateway: Deniega registro User <-- App: Deniega registro + +end ---- === Inicio de sesión en la aplicación -[plantuml,"Sequence diagram",png] +[plantuml,"Login",png] ---- actor User participant App @@ -48,7 +61,7 @@ else credenciales inválidas === Generacion de preguntas -[plantuml,"Sequence diagram",png] +[plantuml,"Generacion",png] ---- participant WApi database DB @@ -61,7 +74,7 @@ loop cada 2 segundos === Respuesta a una pregunta -[plantuml,"Sequence diagram",png] +[plantuml,"Respuesta",png] ---- actor User participant App @@ -99,7 +112,7 @@ else tiempo finalizado === Consulta del historial de usuarios -[plantuml,"Sequence diagram",png] +[plantuml,"Usuarios",png] ---- actor User participant App @@ -113,7 +126,7 @@ User <-- App: Muestra el historial de usuarios === Consulta del historial de preguntas generadas -[plantuml,"Sequence diagram",png] +[plantuml,"Preguntas",png] ---- actor User participant App @@ -127,7 +140,7 @@ User <-- App: Muestra el historial de preguntas generadas === Consulta del historial de jugadas -[plantuml,"Sequence diagram",png] +[plantuml,"Jugadas",png] ---- actor User participant App @@ -141,7 +154,7 @@ User <-- App: Muestra el historial de jugadas === Consulta del ranking -[plantuml,"Sequence diagram",png] +[plantuml,"Ranking",png] ---- actor User participant App @@ -155,7 +168,7 @@ User <-- App: Muestra el ranking === Cambio de ajustes de partida -[plantuml,"Sequence diagram",png] +[plantuml,"Ajustes",png] ---- actor User participant App From 2c7cc3bc4f05a48de223b3efc5a850bb15515fe9 Mon Sep 17 00:00:00 2001 From: Laura Menendez <124043624+uo283055@users.noreply.github.com> Date: Fri, 3 May 2024 17:56:46 +0200 Subject: [PATCH 02/12] Update 09_architecture_decisions.adoc --- docs/src/09_architecture_decisions.adoc | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/src/09_architecture_decisions.adoc b/docs/src/09_architecture_decisions.adoc index e5506a82..3ab4ff91 100644 --- a/docs/src/09_architecture_decisions.adoc +++ b/docs/src/09_architecture_decisions.adoc @@ -10,8 +10,9 @@ ifndef::imagesdir[:imagesdir: ../images] Tambien hay personas del equipo de desarrollo familiarizadas con el uso de esta libreria, por lo que pueden ayudar al resto del equipo con la implementacion del front-end. |Javascript |Elegimos seguir con Javascript para el desarrollo de esta aplicación web porque ya teniamos conocimientos de este lenguaje. Tambien porque es un lenguaje ampliamente conocido por su uso en aplicaciones web, permitiendo mejoras en la interfaz de usuario y paginas web dinámicas. -|Mongodb |Para el back-end hemos decidido usar la base de datos NoSQL Mongodb, creemos que es una opcion adecuada para almacenar los datos necesarios para el desarrollo de la -aplicacion. +|Mongodb Cloud| Lo consideramos más práctico puesto que todos los cambios hechos eran visibles por todos los miembros del grupo, especialmente a la hora de necesitar añadir datos por ejemplo para hacer pruebas o para las bases de las preguntas usadas para generar las preguntas completas de wikidata, de esta manera no necesitábamos añadirlos los cuatro en local para probar la aplicación. |Node.js |Para interactuar con la base de datos decidimos usar Node.js. Es una entorno de ejecucion muy conocido para el desarrollo del back-end de aplicaciones web, por lo que creemos que es buena idea usarlo. +|Microservicios|Permite descomponer la aplicación en distintos componentes independientes, que fecilitan la escalabilidad y el despliegue independiente. También resulta mas sencillo a la hora de su mantenimiento. +|Azure|A pesar de que no tenemos una gran experiencia con Azure, contamos con más conocimiento sobre esta plataforma en comparación con otros competidores, ya que ha sido utilizada anteriormente en otras asignaturas de esta carrera. |=== From 0e8029260e013e4a859018f28a900c3676712959 Mon Sep 17 00:00:00 2001 From: Laura Menendez <124043624+uo283055@users.noreply.github.com> Date: Fri, 3 May 2024 18:00:32 +0200 Subject: [PATCH 03/12] Update 03_system_scope_and_context.adoc --- docs/src/03_system_scope_and_context.adoc | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/docs/src/03_system_scope_and_context.adoc b/docs/src/03_system_scope_and_context.adoc index 2da7ae5e..49725ab2 100644 --- a/docs/src/03_system_scope_and_context.adoc +++ b/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. |=== From 83b68dd8166f3c71c997e9f5aaa8ecf02d5626f6 Mon Sep 17 00:00:00 2001 From: Laura Menendez <124043624+uo283055@users.noreply.github.com> Date: Fri, 3 May 2024 18:21:46 +0200 Subject: [PATCH 04/12] Update 04_solution_strategy.adoc --- docs/src/04_solution_strategy.adoc | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/docs/src/04_solution_strategy.adoc b/docs/src/04_solution_strategy.adoc index c8938fb0..e17c8449 100644 --- a/docs/src/04_solution_strategy.adoc +++ b/docs/src/04_solution_strategy.adoc @@ -11,7 +11,7 @@ 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. @@ -57,4 +57,8 @@ Usaremos PlantUML, VisualParadigm y Draw.io para la creacion de diagramas para l - *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. From 54b7c0b49948bbac6dcdb49776b178f6482fc770 Mon Sep 17 00:00:00 2001 From: uo277310 Date: Fri, 3 May 2024 18:28:34 +0200 Subject: [PATCH 05/12] Actualizados diagramas de secuencia --- docs/src/06_runtime_view.adoc | 162 ++++++++++++++++++++++++---------- 1 file changed, 115 insertions(+), 47 deletions(-) diff --git a/docs/src/06_runtime_view.adoc b/docs/src/06_runtime_view.adoc index 034c2c48..edb5325d 100644 --- a/docs/src/06_runtime_view.adoc +++ b/docs/src/06_runtime_view.adoc @@ -43,33 +43,55 @@ end ---- actor User participant App -database DB - -User -> App: Ingresa credenciales de inicio de sesión -App -> DB: Verifica cerdenciales -App <-- DB: Válida las credenciales -alt credenciales válidas - User <-- App: Confirma inicio de sesión - alt usuario que nunca habia iniciado sesion - App -> DB: Crea ranking para el usuario - App -> DB: Pide datos de los records de todos los usuarios - App <-- DB: Devuelve datos de los records de todos los usuarios - App -> DB: Actualiza los rankings de todos los usuarios -else credenciales inválidas - User <-- App: Deniega inicio de sesión +participant Gateway +participant AuthService +database DBuser + +User -> App: Ingresa credenciales +App -> Gateway: Envía los datos +Gateway -> AuthService: Envía los datos +AuthService-> DBuser: Comprueba los datos + +alt usuario válido + + AuthService<-- DBuser: Confirma login + Gateway <-- AuthService: Confirma login + App<-- Gateway: Confirma login + User <-- App: Confirma login + +else usuario no valido + AuthService <-- DBuser : Deniega login + Gateway <-- AuthService: Deniega login + App <-- Gateway: Deniega login + User <-- App: Deniega login + +end ---- === Generacion de preguntas [plantuml,"Generacion",png] ---- -participant WApi -database DB - -loop cada 2 segundos - WApi -> DB: Genera una pregunta y la guarda +database DBquestions +participant CreateService +participant Gateway +participant QuestionGeneratorService +database DBquestiongenerator + +loop cada 60 segundos + CreateService -> DBquestions: Pide plantilla de pregunta + CreateService <-- DBquestions: Devuelve plantilla de pregunta + CreateService -> CreateService: Genera una pregunta + Gateway <-- CreateService: Envía la pregunta generada + Gateway -> QuestionGeneratorService: Envía la pregunta generada + QuestionGeneratorService-> DBquestiongenerator: Envía la pregunta generada + DBquestiongenerator-> DBquestiongenerator: Guarda la pregunta generada alt mas de 500 preguntas generadas - WApi -> DB: Borra la pregunta que más tiempo lleva guardada + DBquestiongenerator-> DBquestiongenerator: Borra la pregunta que más tiempo lleva guardada + else pregunta existente + DBquestiongenerator-> DBquestiongenerator: Actualiza la pregunta + end +end ---- === Respuesta a una pregunta @@ -78,36 +100,51 @@ loop cada 2 segundos ---- actor User participant App -participant WApi -database DB +participant Gateway +participant GeneratedQuestionService +database DBquestions +participant QuestionGeneratorService +database DBquestiongenerator +participant RecordService +database DBrecords User -> App: Pide una pregunta -App -> DB: Pide una pregunta -App <-- DB: Devuelve una pregunta generada +App -> Gateway: Pide una pregunta +Gateway-> QuestionGeneratorService: Pide una pregunta +QuestionGeneratorService -> DBquestiongenerator: Pide una pregunta +QuestionGeneratorService <-- DBquestiongenerator: Devuelve una pregunta generada +Gateway <-- QuestionGeneratorService : Devuelve una pregunta generada +App <-- Gateway: Devuelve una pregunta generada User <-- App: Muestra pregunta con opciones +Gateway -> GeneratedQuestionService: Envía la pregunta generada +GeneratedQuestionService-> DBquestions: Guarda la pregunta generada alt tiempo no finalizado User -> App: Selecciona opción de respuesta - App -> DB: Verifica respuesta seleccionada - App <-- DB: Confirma la respuesta - App -> DB: Guarda o actualiza la pregunta con su respuesta correcta + App -> App: Verifica respuesta seleccionada alt respuesta correcta alt ultima pregunta User <-- App: Muestra mensaje de respuesta correcta y finaliza el juego - App -> DB: Guarda los datos de la partida + App -> RecordService: Envía los datos de la partida + RecordService -> DBrecords: Guarda los datos de la partida User <-- App: Muestra los datos de la partida else no ultima pregunta User <-- App: Muestra mensaje de respuesta correcta y continua el juego + end else respuesta incorrecta alt ultima pregunta - User <-- App: Muestra mensaje de respuesta correcta y finaliza el juego - App -> DB: Guarda los datos de la partida + User <-- App: Muestra mensaje de respuesta incorrecta y finaliza el juego + App -> RecordService: Envía los datos de la partida + RecordService -> DBrecords: Guarda los datos de la partida User <-- App: Muestra los datos de la partida else no ultima pregunta - User <-- App: Muestra mensaje de respuesta correcta y continua el juego + User <-- App: Muestra mensaje de respuesta incorrecta y continua el juego + end + end else tiempo finalizado - User <-- App: Finaliza el juego - App -> DB: Guarda los datos de la partida + App -> RecordService: Envía los datos de la partida + RecordService -> DBrecords: Guarda los datos de la partida User <-- App: Muestra los datos de la partida +end ---- === Consulta del historial de usuarios @@ -116,12 +153,20 @@ else tiempo finalizado ---- actor User participant App -database DB +participant Gateway +participant UserService +database DBuser +alt usuario admin User -> App: Selecciona opción de ver el historial de usuarios -App -> DB: Consulta el historial de usuarios -App <-- DB: Devuelve el historial de usuarios +App -> Gateway: Pide el historial de usuarios +Gateway -> UserService: Pide el historial de usuarios +UserService -> DBuser: Pide todos los usuarios +UserService <-- DBuser: Devuelve todos los usuarios +Gateway <-- UserService: Devuelve todos los usuarios +App <-- Gateway: Devuelve todos los usuarios User <-- App: Muestra el historial de usuarios +end ---- === Consulta del historial de preguntas generadas @@ -130,12 +175,20 @@ User <-- App: Muestra el historial de usuarios ---- actor User participant App -database DB +participant Gateway +participant GeneratedQuestionService +database DBgeneratedquestions +alt usuario admin User -> App: Selecciona opción de ver el historial de preguntas generadas -App -> DB: Consulta el historial de preguntas generadas -App <-- DB: Devuelve el historial de preguntas generadas +App -> Gateway: Pide el historial de preguntas generadas +Gateway -> GeneratedQuestionService: Pide el historial de preguntas generadas +GeneratedQuestionService -> DBgeneratedquestions: Pide todas las preguntas generadas +GeneratedQuestionService <-- DBgeneratedquestions: Devuelve todas las preguntas generadas +Gateway <-- GeneratedQuestionService: Devuelve todas las preguntas generadas +App <-- Gateway: Devuelve todas las preguntas generadas User <-- App: Muestra el historial de preguntas generadas +end ---- === Consulta del historial de jugadas @@ -144,11 +197,17 @@ User <-- App: Muestra el historial de preguntas generadas ---- actor User participant App -database DB +participant Gateway +participant RecordService +database DBrecord User -> App: Selecciona opción de ver el historial de jugadas -App -> DB: Consulta el historial de jugadas -App <-- DB: Devuelve el historial de jugadas +App -> Gateway: Pide el historial de jugadas +Gateway -> RecordService: Pide el historial de jugadas +RecordService-> DBrecord: Pide todas las jugadas +RecordService<-- DBrecord: Devuelve todas las jugadas +Gateway <-- RecordService: Devuelve todas las jugadas +App <-- Gateway: Devuelve todas las jugadas User <-- App: Muestra el historial de jugadas ---- @@ -158,11 +217,17 @@ User <-- App: Muestra el historial de jugadas ---- actor User participant App -database DB +participant Gateway +participant RankingService +database DBranking User -> App: Selecciona opción de ver el ranking -App -> DB: Consulta el ranking -App <-- DB: Devuelve el ranking +App -> Gateway: Pide el ranking +Gateway -> RankingService: Pide el ranking +RankingService-> DBranking: Pide todos los rankings +RankingService<-- DBranking: Devuelve todos los rankings +Gateway <-- RankingService: Devuelve todos los rankings +App <-- Gateway: Devuelve todos los rankings User <-- App: Muestra el ranking ---- @@ -172,9 +237,12 @@ User <-- App: Muestra el ranking ---- actor User participant App -database DB +participant Navegador User -> App: Selecciona opción de ajustes de partida -App -> User: Muestra ajustes de partida actuales +App-> Navegador: Pide los ajustes de partida actuales +App <-- Navegador: Devuelve ajustes de partida actuales +User <-- App: Muestra ajustes de partida actuales User -> App: Cambia ajustes de partida actuales +App-> Navegador: Guarda ajustes de partida actuales ---- \ No newline at end of file From 159ad1f45a583eae6fee1329f518a8467cd739c3 Mon Sep 17 00:00:00 2001 From: uo277310 Date: Fri, 3 May 2024 18:38:58 +0200 Subject: [PATCH 06/12] =?UTF-8?q?A=C3=B1adido=20riesgo?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/src/11_technical_risks.adoc | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/src/11_technical_risks.adoc b/docs/src/11_technical_risks.adoc index 1ab6c35f..5e69b285 100644 --- a/docs/src/11_technical_risks.adoc +++ b/docs/src/11_technical_risks.adoc @@ -13,6 +13,7 @@ La lista de riesgos es la siguiente: | Trabajo en equipo | Trabajar en equipo nos puede ser complicado al no haber hecho nunca un proyecto tan grande de esta manera. | Mantener una buena comunicación y ser colaborativos. | Reuniones poco productivas | Perder mucho tiempo en reuniones y no conseguir avances puede generar problemas. | Hacer una pequeña preparación de estas para saber que temas tratar en concreto. | Abandono de un miembro | Que un miembro deje el trabajo significaría tener que repartir sus tareas y que aumente la carga de trabajo. | Asignar cada tarea a más de una persona e intentar ayudar para evitar un abandono. +| Fallo de servicios externos | Un servicio externo utilizado en la aplicación cómo Wikidata o Azure dejan de funcionar durante un tiempo. | Estar atentos a las novedades de los mismos e intentar que funcione de nuevo lo antes posible. |=== La lista de deudas técnicas es la siguiente: From a6cd834318e868f91eda0be841cc2d9bee66ecd6 Mon Sep 17 00:00:00 2001 From: Laura Menendez <124043624+uo283055@users.noreply.github.com> Date: Fri, 3 May 2024 18:41:48 +0200 Subject: [PATCH 07/12] Update 05_building_block_view.adoc --- docs/src/05_building_block_view.adoc | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/docs/src/05_building_block_view.adoc b/docs/src/05_building_block_view.adoc index ab8a0147..69c5a663 100644 --- a/docs/src/05_building_block_view.adoc +++ b/docs/src/05_building_block_view.adoc @@ -68,7 +68,7 @@ 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 @@ -76,6 +76,13 @@ Los otros dos microservicios son "QuestionGenerator" y "Record". Cada uno de ell |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._ From f049682655af37cff35f4ee8c6454517ab578474 Mon Sep 17 00:00:00 2001 From: uo277310 Date: Fri, 3 May 2024 18:46:46 +0200 Subject: [PATCH 08/12] Modificadas descripciones de los tests --- docs/src/12_testing.adoc | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/docs/src/12_testing.adoc b/docs/src/12_testing.adoc index 9d7e42e5..b05950b8 100644 --- a/docs/src/12_testing.adoc +++ b/docs/src/12_testing.adoc @@ -6,10 +6,16 @@ Se llevarán a cabo pruebas unitarias, E2E y de carga para garantizar la ejecuci === Tests Unitarios -En nuestro proyecto, los tests unitarios son fundamentales para garantizar la correcta funcionalidad de cada componente del código. Cada función, método o clase será probado exhaustivamente para asegurar su integridad y rendimiento. +En nuestro proyecto, los tests unitarios son fundamentales para garantizar la correcta funcionalidad de cada componente del código. Cada función, método o clase será probado exhaustivamente para asegurar su integridad y rendimiento. Se intenta tener en todo momento un coverage al menos del 80% y que las pruebas comprueben todas las posibles opciones. En la parte del front y en el gateway utilizamos mocks para su realización. === E2E. Tests de integración -Buscaremos garantizar que la aplicación sea fácil de usar para proporcionar una experiencia satisfactoria al usuario. Nos centraremos en verificar diversas funcionalidades, desde la jugabilidad hasta acciones como el registro e inicio de sesión. Simularemos interacciones que haría un usuario real para asegurar que la aplicación sea intuitiva y funcione correctamente. +Buscaremos garantizar que la aplicación sea fácil de usar para proporcionar una experiencia satisfactoria al usuario. Nos centraremos en verificar diversas funcionalidades, desde la jugabilidad hasta acciones como el registro e inicio de sesión. Simularemos interacciones que haría un usuario real para asegurar que la aplicación sea intuitiva y funcione correctamente. +Las funcionalidades probadas han sido: + +*Registro +*Login +*Registro + Login +*Mostrado del juego. === Tests de carga Hemos realizado inicialmente una prueba con un usuario por segundo durante 60 segundos de tal forma que quedaría en un computo total de 60 usuarios. La prueba consiste en logearse, jugar una partida, consultar todos los apartados de la barra de navegación, cambiar los ajustes bajando el numero de preguntas y volviendo a jugar una partida. From 38a4b3386004ee2f1193c5f0a5e954d935721ae2 Mon Sep 17 00:00:00 2001 From: Laura Menendez <124043624+uo283055@users.noreply.github.com> Date: Fri, 3 May 2024 18:49:15 +0200 Subject: [PATCH 09/12] Update 10_quality_requirements.adoc --- docs/src/10_quality_requirements.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/src/10_quality_requirements.adoc b/docs/src/10_quality_requirements.adoc index dec923c5..dd84fb43 100644 --- a/docs/src/10_quality_requirements.adoc +++ b/docs/src/10_quality_requirements.adoc @@ -13,7 +13,7 @@ Los requisitos de calidad son la piedra angular del desarrollo de nuestro proyec |Disponibilidad|La aplicación deberá permanecer disponible en el mayor ratio de tiempo posible, proporcionando así una experiencia satisfactoria al público de la misma que pueda disfrutar de ella cuando deseen.||* |Seguridad|Se asegurará la protección de los datos sensibles de los usuarios así como se dará garantía de que los datos almacenados a modo de registro hisrórico de puntuaciones permanecerán inmutables. Se bloquearán los accesos no autorizados a la aplicación.||* |Rendimiento|Trataremos de minimizar los tiempos de respuesta por parte del sistema tratando así de garantizar la mejor experiencia por parte del usuario.|SC2|* -|Variedad y Precisión|Las preguntas y las respuestas generadas por nuestra aplicación deberán caracterizarse por tener la mayor precisión posible para garantizar que la respuesta correcta sea única. Además deberán abarcar diversos temas para no crear un juego de preguntas monotemáticas. |SC3| +|Variabilidad y Precisión|Las preguntas y las respuestas generadas por nuestra aplicación deberán caracterizarse por tener la mayor precisión posible para garantizar que la respuesta correcta sea única. Además deberán abarcar diversos temas para no crear un juego de preguntas monotemáticas. |SC3| |Accesibilidad|Aseguraremos una experiencia satisfactoria para todo tipo de usuario por lo que nuestra aplicación pondrá especial atención a la accesibilidad de la misma, previniendo las posibles dificultades que le podrían surgir a los distintos grupos de usuarios según sus capacidades físicas y/o cognitivas. |SC4|* |=== From 8cbe63e48a71dbdd3b7f7df47076cd544955e063 Mon Sep 17 00:00:00 2001 From: luismi <79699435+uo277310@users.noreply.github.com> Date: Fri, 3 May 2024 18:49:35 +0200 Subject: [PATCH 10/12] Update 12_testing.adoc --- docs/src/12_testing.adoc | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/src/12_testing.adoc b/docs/src/12_testing.adoc index b05950b8..f7a941b7 100644 --- a/docs/src/12_testing.adoc +++ b/docs/src/12_testing.adoc @@ -10,12 +10,12 @@ En nuestro proyecto, los tests unitarios son fundamentales para garantizar la co === E2E. Tests de integración Buscaremos garantizar que la aplicación sea fácil de usar para proporcionar una experiencia satisfactoria al usuario. Nos centraremos en verificar diversas funcionalidades, desde la jugabilidad hasta acciones como el registro e inicio de sesión. Simularemos interacciones que haría un usuario real para asegurar que la aplicación sea intuitiva y funcione correctamente. -Las funcionalidades probadas han sido: +Las funcionalidades probadas han sido: -*Registro -*Login -*Registro + Login -*Mostrado del juego. +* Registro +* Login +* Registro + Login +* Mostrado del juego === Tests de carga Hemos realizado inicialmente una prueba con un usuario por segundo durante 60 segundos de tal forma que quedaría en un computo total de 60 usuarios. La prueba consiste en logearse, jugar una partida, consultar todos los apartados de la barra de navegación, cambiar los ajustes bajando el numero de preguntas y volviendo a jugar una partida. From d0fce0107cf92b68bcc55d9905c17070fb27b002 Mon Sep 17 00:00:00 2001 From: Laura Menendez <124043624+uo283055@users.noreply.github.com> Date: Fri, 3 May 2024 18:58:47 +0200 Subject: [PATCH 11/12] Update 13_glossary.adoc --- docs/src/13_glossary.adoc | 3 --- 1 file changed, 3 deletions(-) diff --git a/docs/src/13_glossary.adoc b/docs/src/13_glossary.adoc index c195d6a6..43c65fbc 100644 --- a/docs/src/13_glossary.adoc +++ b/docs/src/13_glossary.adoc @@ -7,9 +7,6 @@ ifndef::imagesdir[:imagesdir: ../images] |=== | Término | Definición -| BodyQuestions -| Los diferentes cuerpos que vamos a utilizar de las preguntas base. - | TypeQuestions | Las distintas categorias que hay de preguntas. From 0920984bbfd65a45e15350aa114a2d979a73bd4d Mon Sep 17 00:00:00 2001 From: uo277310 Date: Fri, 3 May 2024 18:59:54 +0200 Subject: [PATCH 12/12] Actualizacion nombres diagramas --- docs/src/06_runtime_view.adoc | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/src/06_runtime_view.adoc b/docs/src/06_runtime_view.adoc index edb5325d..44e648b0 100644 --- a/docs/src/06_runtime_view.adoc +++ b/docs/src/06_runtime_view.adoc @@ -5,7 +5,7 @@ ifndef::imagesdir[:imagesdir: ../images] === Registro en la aplicación -[plantuml,"Registro",png] +[plantuml,"Registro usuario",png] ---- actor User participant App @@ -39,7 +39,7 @@ end === Inicio de sesión en la aplicación -[plantuml,"Login",png] +[plantuml,"Login usuario",png] ---- actor User participant App @@ -70,7 +70,7 @@ end === Generacion de preguntas -[plantuml,"Generacion",png] +[plantuml,"Generacion preguntas",png] ---- database DBquestions participant CreateService @@ -96,7 +96,7 @@ end === Respuesta a una pregunta -[plantuml,"Respuesta",png] +[plantuml,"Respuesta pregunta",png] ---- actor User participant App @@ -149,7 +149,7 @@ end === Consulta del historial de usuarios -[plantuml,"Usuarios",png] +[plantuml,"Historial usuarios",png] ---- actor User participant App @@ -171,7 +171,7 @@ end === Consulta del historial de preguntas generadas -[plantuml,"Preguntas",png] +[plantuml,"Historial preguntas",png] ---- actor User participant App @@ -193,7 +193,7 @@ end === Consulta del historial de jugadas -[plantuml,"Jugadas",png] +[plantuml,"Historial jugadas",png] ---- actor User participant App @@ -213,7 +213,7 @@ User <-- App: Muestra el historial de jugadas === Consulta del ranking -[plantuml,"Ranking",png] +[plantuml,"Ranking usuarios",png] ---- actor User participant App @@ -233,7 +233,7 @@ User <-- App: Muestra el ranking === Cambio de ajustes de partida -[plantuml,"Ajustes",png] +[plantuml,"Ajustes partida",png] ---- actor User participant App