Arquisoft · uo285427 · Mar 1, 2024 · Feb 9, 2024 · Feb 9, 2024 · Feb 11, 2024
diff --git a/docker-compose.yml b/docker-compose.yml
@@ -11,6 +11,50 @@ services:
     networks:
       - mynetwork
 
+  recordservice:
+    container_name: recordservice-${teamname:-defaultASW}
+    image: ghcr.io/arquisoft/wiq_es6b/recordservice:latest
+    profiles: ["dev", "prod"]
+    build: ./questions/recordservice
+    depends_on:
+      - mongodb
+    ports:
+      - "8006:8006"
+    networks:
+      - mynetwork
+    environment:
+      MONGODB_URI: mongodb://mongodb:27017/recorddb
+
+  createservice:
+    container_name: createservice-${teamname:-defaultASW}
+    image: ghcr.io/arquisoft/wiq_es6b/createservice:latest
+    profiles: ["dev", "prod"]
+    build: ./questions/createservice
+    depends_on:
+      - mongodb
+    ports:
+      - "8005:8005"
+    networks:
+      - mynetwork
+    environment:
+      MONGODB_URI: mongodb://mongodb:27017/questiondb
+
+
+  answerservice:
+    container_name: answerservice-${teamname:-defaultASW}
+    image: ghcr.io/arquisoft/wiq_es6b/answerservice:latest
+    profiles: ["dev", "prod"]
+    build: ./questions/answerservice
+    depends_on:
+      - mongodb
+    ports:
+      - "8004:8004"
+    networks:
+      - mynetwork
+    environment:
+      MONGODB_URI: mongodb://mongodb:27017/questiondb
+
+
   authservice:
     container_name: authservice-${teamname:-defaultASW}
     image: ghcr.io/arquisoft/wiq_es6b/authservice:latest
@@ -55,6 +99,8 @@ services:
     environment:
       AUTH_SERVICE_URL: http://authservice:8002
       USER_SERVICE_URL: http://userservice:8001
+      QUES_SERVICE_URL: http://createservice:8005
+      ANSW_SERVICE_URL: http://answerservice:8004
 
   webapp:
     container_name: webapp-${teamname:-defaultASW}

diff --git a/docs/images/05_bbv_level02.jpg b/docs/images/05_bbv_level02.jpg
diff --git a/docs/images/05_bbv_level03.jpg b/docs/images/05_bbv_level03.jpg
diff --git a/docs/images/05_bbv_scopecontext.jpg b/docs/images/05_bbv_scopecontext.jpg
diff --git a/docs/images/07-Deploy-View.png b/docs/images/07-Deploy-View.png
diff --git a/docs/images/08-Dominio.jpeg b/docs/images/08-Dominio.jpeg
diff --git a/docs/images/08-MindMapConceptosTransversales.png b/docs/images/08-MindMapConceptosTransversales.png
diff --git a/docs/images/08-capas.png b/docs/images/08-capas.png
diff --git a/docs/images/10_qr_tree.jpg b/docs/images/10_qr_tree.jpg
diff --git a/docs/src/01_introduction_and_goals.adoc b/docs/src/01_introduction_and_goals.adoc
@@ -1,93 +1,50 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-introduction-and-goals]]
-== Introduction and Goals
+== Introducción y Objetivos
 
-[role="arc42help"]
-****
-Describes the relevant requirements and the driving forces that software architects and development team must consider. 
-These include
+WIQ se trata de una aplicación web desarrollada por HappySw para RTVE que permite a los usuarios jugar online a un juego de preguntas y respuestas.
 
-* underlying business goals, 
-* essential features, 
-* essential functional requirements, 
-* quality goals for the architecture and
-* relevant stakeholders and their expectations
-****
+Los usuarios tienen la posibilidad de responder a estas preguntas seleccionando una de las opciones proporcionadas y ganar premios por cada acierto. También podrán ver su histórico de participaciones e intentar mejorarlas.
 
-=== Requirements Overview
+Tanto preguntas cómo las respuestas son generadas de manera automática a partir de los datos de Wikidata para evitar su posible desactualización.
 
-[role="arc42help"]
-****
-.Contents
-Short description of the functional requirements, driving forces, extract (or abstract)
-of requirements. Link to (hopefully existing) requirements documents
-(with version number and information where to find it).
+=== Descripción general de los requisitos
 
-.Motivation
-From the point of view of the end users a system is created or modified to
-improve support of a business activity and/or improve the quality.
+Los requisitos principales son:
 
-.Form
-Short textual description, probably in tabular use-case format.
-If requirements documents exist this overview should refer to these documents.
+* Debe poder accederse al juego a través de la Web.
+* Los usuarios deben poder registrarse, acceder mediante sus credenciales y consultar el histórico de su participación en el sistema.
+* Las preguntas y sus posibles respuestas deben ser generadas automáticamente a partir de los datos de Wikidata.
+* Debe haber un tiempo máximo para contestar a cada pregunta.
+* Cada pregunta debe tener una única respuesta correcta y varias incorrectas.
+* Se debe poder acceder a la información de los usuarios y de las preguntas a través de un API.
 
-Keep these excerpts as short as possible. Balance readability of this document with potential redundancy w.r.t to requirements documents.
+=== Objetivos de calidad
 
+Los objetivos de calidad en orden de prioridad son los siguientes:
 
-.Further Information
-
-See https://docs.arc42.org/section-1/[Introduction and Goals] in the arc42 documentation.
-
-****
-
-=== Quality Goals
-
-[role="arc42help"]
-****
-.Contents
-The top three (max five) quality goals for the architecture whose fulfillment is of highest importance to the major stakeholders. 
-We really mean quality goals for the architecture. Don't confuse them with project goals.
-They are not necessarily identical.
-
-Consider this overview of potential topics (based upon the ISO 25010 standard):
-
-image::01_2_iso-25010-topics-EN.drawio.png["Categories of Quality Requirements"]
-
-.Motivation
-You should know the quality goals of your most important stakeholders, since they will influence fundamental architectural decisions. 
-Make sure to be very concrete about these qualities, avoid buzzwords.
-If you as an architect do not know how the quality of your work will be judged...
-
-.Form
-A table with quality goals and concrete scenarios, ordered by priorities
-****
+[options="header",cols="1,3,1"]
+|===
+| 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
+| Seguridad | La información de los usuarios estará protegida previniendo al máximo los accesos no autorizados y las posibles violaciones de datos. | Media/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
+| Accesibilidad | Cualquier usuario tendrá las mismas oportunidades que el resto sin importar sus capacidades físicas o cognitivas. | Media
+|===
 
 === Stakeholders
 
-[role="arc42help"]
-****
-.Contents
-Explicit overview of stakeholders of the system, i.e. all person, roles or organizations that
-
-* should know the architecture
-* have to be convinced of the architecture
-* have to work with the architecture or with code
-* need the documentation of the architecture for their work
-* have to come up with decisions about the system or its development
-
-.Motivation
-You should know all parties involved in development of the system or affected by the system.
-Otherwise, you may get nasty surprises later in the development process.
-These stakeholders determine the extent and the level of detail of your work and its results.
-
-.Form
-Table with role names, person names, and their expectations with respect to the architecture and its documentation.
-****
+Los stakeholders de la aplicación junto con sus expectativas son:
 
 [options="header",cols="1,2,2"]
 |===
-|Role/Name|Contact|Expectations
-| _<Role-1>_ | _<Contact-1>_ | _<Expectation-1>_
-| _<Role-2>_ | _<Contact-2>_ | _<Expectation-2>_
+| Rol | Contacto | Expectativas
+| Cliente | RTVE | Tener una aplicación que permita acceder a un juego de preguntas y respuestas.
+| Compañia desarrolladora | HappySw | Satisfacer al cliente.
+| Desarrolladores | Sergio Díaz, Laura Menéndez, Jesús García, Luis Miguel Gómez y Emilio García | Crear una aplicacion que cumpla los requisitos del cliente.
+| Coordinadores | Jose Emilio Labra Gayo y Jorge Álvarez Fidalgo | Proporcionar soporte a los desarrolladores para que consigan su objetivo.
+| Usuarios | Cualquiera que acceda a la aplicación | Poder jugar a un juego de preguntas y respuestas.
+| Tecnologías usadas | JavaScript, React, Wikidata, Node.js, MongoDB, Azure... | Conseguir promoción debido a su uso en diferentes proyectos.
 |===
diff --git a/docs/src/02_architecture_constraints.adoc b/docs/src/02_architecture_constraints.adoc
@@ -1,27 +1,38 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-architecture-constraints]]
-== Architecture Constraints
+== Restricciones de la arquitectura
 
+Las restricciones de la arquitectura de este proyecto son las siguientes:
 
-[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.
+|===
+| Restricción | Explicación
 
-.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.
+| Uso de Wikidata
+| Se debe usar obligatoriamente la API de Wikidata para obtener los datos necesarios
+para generar las preguntas y las respuestas dentro del juego.
 
-.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)
+| Despliegue
+| La aplicación deberá consistir en una aplicación web, no pudiendo ser una aplicación
+móvil o de escritorio.
 
+| Acceso a datos mediante APIs
+| El acceso a datos relacionados con los usuarios que participan y las respuestas
+a las preguntas deberá realizarse con una API.
 
-.Further Information
+| Presupuesto reducido
+| El presupuesto para el proyecto es limitado, reduciéndose únicamente a lo que
+cada desarrollador esté dispuesto a desembolsar de su propio bolsillo.
+|===
 
-See https://docs.arc42.org/section-2/[Architecture Constraints] in the arc42 documentation.
 
-****
+Consecuencias de las limitaciones:
+
+* La aplicación web deberá estar suficientemente optimizada para su uso en
+navegadores, atendiendo a aspectos relacionados con el rendimiento, la usabilidad
+y la disponibilidad.
+* El presupuesto reducido implicará un uso mayor de herramientas de código abierto,
+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.
+
diff --git a/docs/src/03_system_scope_and_context.adoc b/docs/src/03_system_scope_and_context.adoc
@@ -1,75 +1,48 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-system-scope-and-context]]
-== System Scope and Context
+== Alcance y contexto del sistema
 
+Nuestro proyecto, denominado "WIQ", consiste en una simulación inspirada en el famoso juego de RTVE  "Saber y Ganar" (más información en: https://www.rtve.es/play/videos/saber-y-ganar/), en el cual los concursantes tienen la oportunidad de hacerse con una cantidad de dinero en función del número de respuestas acertadas a preguntas de diversas temáticas, con un límite establecido de tiempo para cada una de ellas.
 
-[role="arc42help"]
-****
-.Contents
-System scope and context - as the name suggests - delimits your system (i.e. your scope) from all its communication partners
-(neighboring systems and users, i.e. the context of your system). It thereby specifies the external interfaces.
+La aplicación permitirá a los usuarios no solo acumular dinero al participar en la funcionalidad básica de juego de preguntas y respuestas, si no que cuenta también con otras funcionalidades como poder consultar su historial de juegos y el listado completo de usuarios registrados. 
 
-If necessary, differentiate the business context (domain specific inputs and outputs) from the technical context (channels, protocols, hardware).
 
-.Motivation
-The domain interfaces and technical interfaces to communication partners are among your system's most critical aspects. Make sure that you completely understand them.
 
-.Form
-Various options:
+=== Contexto de negocio
 
-* Context diagrams
-* Lists of communication partners and their interfaces.
+Al acceder a la página principal de la aplicación, los usuarios podrán ver una interfaz que les permitirá iniciar sesión para acceder a su cuenta. En caso de ser su primera vez y no tener cuenta, tendrá la opción de registrarse. Una vez autenticados, los usuarios se encontrarán con la opción tanto empezar un nuevo juego como de ver su historial 
+de jugadas anteriores. 
 
+Dentro del historial, este le mostrará el número de partidas totales realizadas y por cada una de ellas la fecha en la que se jugó, el número de respuestas acertadas, el dinero conseguido y el tiempo total 
+que le llevó completarlo.
 
-.Further Information
+Aparte de eso también tendrán la opción de visualizar el listado completo de usuarios registrados hasta la fecha. 
 
-See https://docs.arc42.org/section-3/[Context and Scope] in the arc42 documentation.
 
-****
 
+=== Contexto técnico 
 
-=== Business Context
+Para el desarrollo de este proyecto usaremos la API de Wikidata tanto para generar automaticamente las preguntas como para obtener 
+las respuestas correctas a las mismas. 
+Respecto al lenguaje de programación se usará JavaScript, utilizando React para el desarrollo del front-end. Además 
+haremos uso de Node.js y la implementación de microservicios para el back-end. Respecto a la base de datos usaremos una NonQL como MongoDB. 
 
-[role="arc42help"]
-****
-.Contents
-Specification of *all* communication partners (users, IT-systems, ...) with explanations of domain specific inputs and outputs or interfaces.
-Optionally you can add domain specific formats or communication protocols.
+|===
+| Interfaz técnica | Explicación
 
-.Motivation
-All stakeholders should understand which data are exchanged with the environment of the system.
+| Wikidata
+| API usada para generar automáticamente las preguntas y obtener su respuesta.
 
-.Form
-All kinds of diagrams that show the system as a black box and specify the domain interfaces to communication partners.
+| JavaScript
+| Lenguaje principal de la aplicación.
 
-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.
+| React
+| Librería JavaScript que nos permitirá construir la interfaz de la aplicación.
 
-****
+| MongoDB
+| Base de datos NoSQL.
 
-**<Diagram or Table>**
-
-**<optionally: Explanation of external domain interfaces>**
-
-=== Technical Context
-
-[role="arc42help"]
-****
-.Contents
-Technical interfaces (channels and transmission media) linking your system to its environment. In addition a mapping of domain specific input/output to the channels, i.e. an explanation which I/O uses which channel.
-
-.Motivation
-Many stakeholders make architectural decision based on the technical interfaces between the system and its context. Especially infrastructure or hardware designers decide these technical interfaces.
-
-.Form
-E.g. UML deployment diagram describing channels to neighboring systems,
-together with a mapping table showing the relationships between channels and input/output.
-
-****
-
-**<Diagram or Table>**
-
-**<optionally: Explanation of technical interfaces>**
-
-**<Mapping Input/Output to Channels>**
+| Node.Js
+| Entorno de servidor para tratar los endpoints.
+|===