Merge pull request #11 from Arquisoft/develop

Añadido generador preguntas por santiago

docker-compose.yml

@@ -52,6 +52,20 @@ services:
       - mynetwork
     environment:
       MONGODB_URI: mongodb://mongodb:27017/userdb
+
+  historyservice:
+    container_name: historyservice-${teamname:-wiq_es04d}
+    image: ghcr.io/arquisoft/wiq_es04d/historyservice:latest
+    profiles: ["dev", "prod"]
+    build: ./users/historyservice
+    depends_on:
+      - mongodb
+    ports:
+      - "8004:8004"
+    networks:
+      - mynetwork
+    environment:
+      MONGODB_URI: mongodb://mongodb:27017/userdb
 
   gatewayservice:
     container_name: gatewayservice-${teamname:-defaultASW}
@@ -63,6 +77,7 @@ services:
       - userservice
       - authservice
       - questionservice
+      - historyservice
     ports:
       - "8000:8000"
     networks:
@@ -71,6 +86,7 @@ services:
       AUTH_SERVICE_URL: http://authservice:8002
       USER_SERVICE_URL: http://userservice:8001
       GENERATE_SERVICE_URL: http://questionservice:8003
+      HISTORY_SERVICE_URL: http://historyservice:8004
 
   webapp:
     container_name: webapp-${teamname:-defaultASW}

docs/images/06_sequence-diagram.plantuml

@@ -0,0 +1,21 @@
+@startuml Diagrama de secuencia plantuml
+actor usuario
+actor system
+actor juego
+database bbdd as "bbdd"
+usuario -> system: inicio sesión
+system --> usuario: pedir nombre/contraseña
+usuario -> system: dar nombre/contraseña
+system -> bbdd: verificar usuario
+bbdd --> system: verificación correcta
+system --> usuario: inicio sesión correcto
+usuario -> system: acceder al juego
+system -> juego: iniciar juego
+juego --> system: generar pregunta/respuestas
+system --> usuario: mostrar pregunta/respuestas
+usuario -> system: responder
+system -> juego: verificar respuesta
+juego --> system: respuesta correcta
+system --> usuario: correcta
+system -> juego: generar siguiente pregunta/respuestas
+@enduml

docs/index.adoc

@@ -6,7 +6,7 @@
 // configure EN settings for asciidoc
 include::src/config.adoc[]
 
-= image:arc42-logo.png[arc42] Template
+= image:arc42-logo.png[arc42] Generador de preguntas
 :revnumber: 8.2 EN
 :revdate: January 2023
 :revremark: (based upon AsciiDoc version)
@@ -34,16 +34,6 @@ include::src/about-arc42.adoc[]
 // horizontal line
 ***
 
-[role="arc42help"]
-****
-[NOTE]
-====
-This version of the template contains some help and explanations.
-It is used for familiarization with arc42 and the understanding of the concepts.
-For documentation of your own system you use better the _plain_ version.
-====
-****
-
 
 // numbering from here on
 :numbered:

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 (wiq_es04d) 🎇
 
-[role="arc42help"]
-****
-Describes the relevant requirements and the driving forces that software architects and development team must consider. 
-These include
-
-* underlying business goals, 
-* essential features, 
-* essential functional requirements, 
-* quality goals for the architecture and
-* relevant stakeholders and their expectations
-****
-
-=== Requirements Overview
-
-[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).
-
-.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.
-
-.Form
-Short textual description, probably in tabular use-case format.
-If requirements documents exist this overview should refer to these documents.
+El proyecto de wiq_es04d 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.
 
-Keep these excerpts as short as possible. Balance readability of this document with potential redundancy w.r.t to requirements documents.
+Los desarrolladores de la aplicacion son por Zohaib Akhtar Kausar, Yago Navajas González y Santiago López Laso.
 
+La aplicación tendrá su base para las preguntas y las respuestas en Wikidata, la base de conocimiento editada en colaboración.
 
-.Further Information
 
-See https://docs.arc42.org/section-1/[Introduction and Goals] in the arc42 documentation.
+=== 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.
+* 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. 
 
-=== 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...
+=== Atributos de Calidad 👑
 
-.Form
-A table with quality goals and concrete scenarios, ordered by priorities
-****
-
-=== 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
+[options="header",cols="1,2,2"]
+|===
+| 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.
+|===
 
-.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.
-****
+=== Stakeholders 👨‍👩‍👦‍👦
 
 [options="header",cols="1,2,2"]
 |===
 |Role/Name|Contact|Expectations
-| _<Role-1>_ | _<Contact-1>_ | _<Expectation-1>_
-| _<Role-2>_ | _<Contact-2>_ | _<Expectation-2>_
+| 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.
+| 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.
+| RTVE | Empleador | Interesados en la creacion del juego e impulsores de su creacion.
 |===

docs/src/02_architecture_constraints.adoc

@@ -1,27 +1,27 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-architecture-constraints]]
-== Architecture Constraints
-
-
-[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.
-
-.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.
-
-.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)
-
-
-.Further Information
-
-See https://docs.arc42.org/section-2/[Architecture Constraints] in the arc42 documentation.
-
-****
+== Restricciones de arquitectura ⛔
+
+
+=== Restricciones Técnicas 📛
+[options="header",cols="1,2"]
+|===
+|Restricción|Descripción
+|API Wikidata|El numero de consultas en un tiempo espcidfico 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 um 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.
+|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.
+|Maquina Virtual Azure|Esta plataforma impone limites a la cantidad de recursos que podemos usar con la licencia de estudiantes, por lo que debemos ir con cuidado de cuando tenemos la maquina encendida para no agotar el credito.
+|===
+
+
+=== 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 miembrosd 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

@@ -1,75 +1,18 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-system-scope-and-context]]
-== System Scope and Context
+== Alcance del sistema y Contexto 💭
 
+=== Contexto de negocio 💰
+image::Diagrama de contexto de negocio.jpg["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, histórico
+|Wikidata|Items (elementos) de Wikidata|Petición a la API de Wikidata
+|===
 
-[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.
+=== Contexto técnico 🔧
 
-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:
-
-* Context diagrams
-* Lists of communication partners and their interfaces.
-
-
-.Further Information
-
-See https://docs.arc42.org/section-3/[Context and Scope] in the arc42 documentation.
-
-****
-
-
-=== Business Context
-
-[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.
-
-.Motivation
-All stakeholders should understand which data are exchanged with the environment of the system.
-
-.Form
-All kinds of diagrams that show the system as a black box and specify the domain interfaces to communication partners.
-
-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.
-
-****
-
-**<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>**
+image::Diagrama de contexto técnico.jpg["Diagrama de contexto técnico"]