Arquisoft · CANCI0 · Feb 6, 2024 · Feb 6, 2024 · Feb 6, 2024 · Feb 6, 2024
diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml
@@ -3,7 +3,8 @@ name: Deploy on release
 on:
   release:
     types: [published]
-
+    branches:
+      - master
 jobs:
   unit-tests:
     runs-on: ubuntu-latest

diff --git a/.vscode/settings.json b/.vscode/settings.json
@@ -0,0 +1 @@
+{}
diff --git a/README.md b/README.md
@@ -6,7 +6,7 @@
 |Martín Cancio Barrera | UO287561 | [Mi github](https://github.com/CANCI0)
 |Iyán Fernández Riol | UO288231 | [Mi github](https://github.com/iyanfdezz)
 |Rodrigo García Iglesias | UO276396 | [Mi github](https://github.com/Rodrox11)
-|Miguel Olamendi Alonso | UO285032 | [Mi github](https://github.com/uo285032)
+|Alfredo Jirout Cid | UO288443 | [Mi github](https://github.com/uo288443)
 
 ## Introduction to our project
 [![Deploy on release](https://github.com/Arquisoft/wiq_es1a/actions/workflows/release.yml/badge.svg)](https://github.com/Arquisoft/wiq_es1a/actions/workflows/release.yml)

diff --git a/docs/images/UML.png b/docs/images/UML.png
diff --git a/docs/images/businesscontext.png b/docs/images/businesscontext.png
diff --git a/docs/images/technicalcontext.png b/docs/images/technicalcontext.png
diff --git a/docs/package-lock.json b/docs/package-lock.json
diff --git a/docs/package.json b/docs/package.json
@@ -4,12 +4,11 @@
     "description": "Npm project just for the docs",
     "main": "index.js",
     "scripts": {
-      "build": "shx rm -rf build && asciidoctor -D build -a imagesdir=./images -r asciidoctor-diagram index.adoc && shx cp -R images build",
-      "deploy": "gh-pages -d build"
+        "build": "shx rm -rf build && asciidoctor -D build -a imagesdir=./images -r asciidoctor-diagram index.adoc && shx cp -R images build",
+        "deploy": "gh-pages -d build"
     },
     "dependencies": {
-      "gh-pages": "^3.2.3",
-      "shx": "^0.3.3"
+        "gh-pages": "^3.2.3",
+        "shx": "^0.3.3"
     }
-  }
-
+}
diff --git a/docs/src/01_introduction_and_goals.adoc b/docs/src/01_introduction_and_goals.adoc
@@ -3,91 +3,76 @@ ifndef::imagesdir[:imagesdir: ../images]
 [[section-introduction-and-goals]]
 == Introduction and Goals
 
-[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
-****
+WIQ! is a project developed for the subject "Software Architecture" of the Computer Engineering degree of the School of Computer Engineering of the University of Oviedo. This project is based on the wiq project, made available to the students by the teachers of the subject.
+WIQ! has been commissioned to the company HappySw by RTVE, with the aim of recreating its famous quiz show Saber y ganar in a web version accessible to everyone. This project will be carried out by the development team is formed by:
 
-=== Requirements Overview
+* Martín Cancio Barrera, mailto:[email protected][_UO287561_].
 
-[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).
+* Iyán Fernández Riol, mailto:[email protected][_UO288231_].
 
-.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.
+* Rodrigo García Iglesias, mailto:[email protected][_UO276396_].
 
-.Form
-Short textual description, probably in tabular use-case format.
-If requirements documents exist this overview should refer to these documents.
+* Alfredo Jirout Cid, mailto:[email protected][_UO288443_]. 
 
-Keep these excerpts as short as possible. Balance readability of this document with potential redundancy w.r.t to requirements documents.
+WIQ! is a software by means of which users can emulate being the participants of the quiz show Saber y ganar, which has numerous functionalities:
 
+* Play several of the game modes seen on the show.
 
-.Further Information
+* Register to be able to keep track of their statistics in the game
 
-See https://docs.arc42.org/section-1/[Introduction and Goals] in the arc42 documentation.
+* Play with friends
 
-****
+* Adjust the themes of the questions, the answer time, the number of questions...
+***
 
-=== Quality Goals
+=== Requirements Overview
 
-[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.
+* The system will have at least one web frontend that will be deployed and accessed via the web.
+* Users will be able to register in the system and consult the history of their participation in the system: number of games, number of correct/failed questions, times, etc.
+* Questions will be automatically generated from Wikidata data.
+* Questions must be answered within a given time limit.
+* Each question will have one correct answer and several incorrect or distracting answers. Both correct and incorrect answers will be generated automatically.
+* The system shall allow access to user information through an API.
+* The system shall allow access to the information of the generated questions through an API.
 
-Consider this overview of potential topics (based upon the ISO 25010 standard):
+=== Quality Goals
 
-image::01_2_iso-25010-topics-EN.drawio.png["Categories of Quality Requirements"]
+[options="header"]
+|===
+| Priority | Quality Goal | Motivation
 
-.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...
+| *1*
+| *_Usability_*
+| The application should be intuitive for users, making it easy for them to interact with the application regardless of their skills.
 
-.Form
-A table with quality goals and concrete scenarios, ordered by priorities
-****
+| *2*
+| *_Mantainability_*
+| The application must have a well-defined and structured design, so that it is easy to make modifications and/or extensions.
+
+| *3*
+| *_Privacy_*
+| The application must guarantee the privacy of its users' information, with mechanisms in place to prevent intrusions into the system.
+|===
 
 === Stakeholders
 
-[role="arc42help"]
-****
-.Contents
-Explicit overview of stakeholders of the system, i.e. all person, roles or organizations that
+[options="header"]
+|===
+|Role/Name|Contact|Expectations 
 
-* 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
+| *_Students (HappySw)_*
+| Martín Cancio Barrera, Iyán Fernández Riol, Rodrigo García Iglesias and Alfredo Jirout Cid
+| The students are the developers of the application. They are in charge of the complete development, which will improve their programming and teamwork skills.
 
-.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.
+| *_Users_*
+| Anyone who uses the application
+| Users are the ones who will ultimately use the application, so it must be intuitive and easy to understand.
 
-.Form
-Table with role names, person names, and their expectations with respect to the architecture and its documentation.
-****
+| *_Teachers_*
+| José Emilio Labra Gayo, Pablo González González, Jorge Álvarez Fidalgo and  Cristian Augusto Alonso. 
+| They are the supervisors of the project, and will help the students toensure that the project comes to fruition.
 
-[options="header",cols="1,2,2"]
-|===
-|Role/Name|Contact|Expectations
-| _<Role-1>_ | _<Contact-1>_ | _<Expectation-1>_
-| _<Role-2>_ | _<Contact-2>_ | _<Expectation-2>_
+| *_RTVE_*
+| RTVE
+| They are the main stakeholders in the application, as they are the ones who commissioned it, so that their viewers can use it.
 |===
diff --git a/docs/src/02_architecture_constraints.adoc b/docs/src/02_architecture_constraints.adoc
@@ -3,25 +3,23 @@ ifndef::imagesdir[:imagesdir: ../images]
 [[section-architecture-constraints]]
 == Architecture Constraints
 
+|===
+| *_Architecture constraint_* | *_Description_*
 
-[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.
+| *_Tecnología de Desarrollo_* | The application must be developed using web technologies compatible with RTVE's requirements and standards.
 
-.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.
+| *_Plataforma de Implementación_* | The application must be implemented on a web hosting platform that meets RTVE's performance, security and scalability requirements.
 
-.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)
+| *_Cumplimiento de Normativas de Privacidad_* | The architecture must ensure compliance with data privacy regulations, such as GDPR, to protect users' information.
 
+| *_Compatibilidad con Navegadores_* | The application should be compatible with a wide range of popular web browsers to ensure a consistent user experience.
 
-.Further Information
+| *_Seguridad de la Información_* | Strong security measures, such as user authentication, access control and data encryption, must be implemented to protect users' confidential information.
 
-See https://docs.arc42.org/section-2/[Architecture Constraints] in the arc42 documentation.
+| *_Escalabilidad_* | The architecture must be scalable to handle increased user traffic without compromising performance.
 
-****
+| *_Mantenibilidad del Código_* | Software development practices that promote clean and well-documented code should be followed to facilitate future upgrades and maintenance.
+
+| *_Tiempo de Desarrollo_* | The application must be developed within a specific time frame, which may influence architectural decisions and technology selection.
+
+|===
diff --git a/docs/src/03_system_scope_and_context.adoc b/docs/src/03_system_scope_and_context.adoc
@@ -3,73 +3,8 @@ ifndef::imagesdir[:imagesdir: ../images]
 [[section-system-scope-and-context]]
 == System Scope and Context
 
-
-[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.
-
-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>**
+image::businesscontext.png[Business context]
 
 === 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::technicalcontext.png[Technical Context]
diff --git a/docs/src/04_solution_strategy.adoc b/docs/src/04_solution_strategy.adoc
@@ -3,30 +3,26 @@ ifndef::imagesdir[:imagesdir: ../images]
 [[section-solution-strategy]]
 == Solution Strategy
 
+Elaboramos una aplicacíon en la que los usuarios pueden registrarse para jugar, donde en cada juego tendran que responder varias preguntas, de distintas categorias, donde se guardará
+un ranking con la máxima puntuación del usuario y se podrá comparar con otros usuarios, también tendra una sección que indique su promedio de aciertos y en que categoría acierta más preguntas.
 
-[role="arc42help"]
-****
-.Contents
-A short summary and explanation of the fundamental decisions and solution strategies, that shape system architecture. It includes
+.Tecnologías usadas para llevar a cabo:
 
-* technology decisions
-* decisions about the top-level decomposition of the system, e.g. usage of an architectural pattern or design pattern
-* decisions on how to achieve key quality goals
-* relevant organizational decisions, e.g. selecting a development process or delegating certain tasks to third parties.
+* MongoDB: MongoDB es una base de datos NoSQL de código abierto que utiliza un modelo de datos basado en documentos para el almacenamiento y recuperación de información.
+* React JS: Es un framework creado por Facebook ampliamente utlizado para crear componentes de la interfaz de usuario. Escogido por el gran volumen de documentación y ser el framework utilizado durante los anteriores cursos.
+* WikiData: Es una base de conocimientos gratuita modificada por seres humanos como por máquinas, y es de donde obtendremos nuestras preguntas.
+* Microsoft Azure: plataforma de computación en la nube que proporciona servicios de infraestructura, plataforma y software como servicio para alojar, administrar y escalar aplicaciones y servicios en línea.
 
-.Motivation
-These decisions form the cornerstones for your architecture. They are the foundation for many other detailed decisions or implementation rules.
+.Diseño
+La página web diseñada está compuesta por un frontend en React, un backend en Node.js y está documentada usando Asciidoc. Cada usuario tendrá su propia cuenta donde se guardará su información. Las decisiones relacionadas con el diseño se detallan en el punto 9.
 
-.Form
-Keep the explanations of such key decisions short.
+.Seguridad
+Garantizamos la seguridad del usuario
 
-Motivate what was decided and why it was decided that way,
-based upon problem statement, quality goals and key constraints.
-Refer to details in the following sections.
+.Testabilidad
+Se realizarán pruebas para cada parte individual de la aplicación, garantizando así el correcto funcionamiento de los diferentes modulos tanto individualmente como de forma conjunta.
 
+.Interfaz
+La interfaz gráfica será elegida entre todos los miembros del equipo, aportando cada uno algún boceto o idea, los cuales serán puestos en común y se decidirá cual se ajusta mejor a la apicación esperada y que elementos de dichos bocetos resultan más adecuados.
+Para ello se tendrá en cuenta la usabilidad y las necesidades de los difentes tipos de usuarios.
 
-.Further Information
-
-See https://docs.arc42.org/section-4/[Solution Strategy] in the arc42 documentation.
-
-****
diff --git a/docs/src/07_deployment_view.adoc b/docs/src/07_deployment_view.adoc
@@ -43,6 +43,7 @@ See https://docs.arc42.org/section-7/[Deployment View] in the arc42 documentatio
 ****
 
 === Infrastructure Level 1
+image::UML.png[UML]
 
 [role="arc42help"]
 ****
@@ -60,14 +61,16 @@ _**<Overview Diagram>**_
 
 Motivation::
 
-_<explanation in text form>_
+_<Simple structure of how the different parts of the application would work>_
 
 Quality and/or Performance Features::
 
-_<explanation in text form>_
+_<We will have a link to wikidata that will be where we get the different questions, in addition a registration and persistence layer of user and registration data, finally they will be united in the link layer and this will be the one that is directly related to the application>_
 
 Mapping of Building Blocks to Infrastructure::
-_<description of the mapping>_
+_<Quiestion Generator: give us the questions posible answers
+  User service: All the options that users needs
+  Register: create new acounts or login with one>_
 
 
 === Infrastructure Level 2