Version final de la documentación antes de la primera entrega

docs/src/02_architecture_constraints.adoc

@@ -3,10 +3,6 @@ ifndef::imagesdir[:imagesdir: ../images]
 [[section-architecture-constraints]]
 == Restricciones de la arquitectura
 
-
-[role="arc42help"]
-****
-
 Las restricciones de la arquitectura de este proyecto son las siguientes:
 
 |===
@@ -40,4 +36,3 @@ 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.
 
-****

docs/src/03_system_scope_and_context.adoc

@@ -3,21 +3,14 @@ ifndef::imagesdir[:imagesdir: ../images]
 [[section-system-scope-and-context]]
 == Alcance y contexto del sistema
 
-
-
-[role="arc42help"]
-****
 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.
 
 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. 
 
-****
 
 
 === Contexto de negocio
 
-[role="arc42help"]
-****
 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. 
 
@@ -26,13 +19,10 @@ que le llevó completarlo.
 
 Aparte de eso también tendrán la opción de visualizar el listado completo de usuarios registrados hasta la fecha. 
 
-****
 
 
 === Contexto técnico 
 
-[role="arc42help"]
-****
 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 
@@ -56,6 +46,3 @@ haremos uso de Node.js y la implementación de microservicios para el back-end.
 | Node.Js
 | Entorno de servidor para tratar los endpoints.
 |===
-
-****
-

docs/src/04_solution_strategy.adoc

@@ -50,29 +50,3 @@ Usaremos VisualParadigm y Draw.io para la creacion de diagramas para la document
 - *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".
 
-[role="arc42help"]
-****
-.Contents
-A short summary and explanation of the fundamental decisions and solution strategies, that shape system architecture. It includes
-
-* 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.
-
-.Motivation
-These decisions form the cornerstones for your architecture. They are the foundation for many other detailed decisions or implementation rules.
-
-.Form
-Keep the explanations of such key decisions short.
-
-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.
-
-
-.Further Information
-
-See https://docs.arc42.org/section-4/[Solution Strategy] in the arc42 documentation.
-
-****

docs/src/05_building_block_view.adoc

@@ -2,52 +2,12 @@ ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-building-block-view]]
 
-
 == Building Block View
 
-[role="arc42help"]
-****
-.Content
-The building block view shows the static decomposition of the system into building blocks (modules, components, subsystems, classes, interfaces, packages, libraries, frameworks, layers, partitions, tiers, functions, macros, operations, data structures, ...) as well as their dependencies (relationships, associations, ...)
-
-This view is mandatory for every architecture documentation.
-In analogy to a house this is the _floor plan_.
-
-.Motivation
-Maintain an overview of your source code by making its structure understandable through
-abstraction.
-
-This allows you to communicate with your stakeholder on an abstract level without disclosing implementation details.
-
-.Form
-The building block view is a hierarchical collection of black boxes and white boxes
-(see figure below) and their descriptions.
-
-image::05_building_blocks-EN.png["Hierarchy of building blocks"]
-
-*Level 1* is the white box description of the overall system together with black
-box descriptions of all contained building blocks.
-
-*Level 2* zooms into some building blocks of level 1.
-Thus it contains the white box description of selected building blocks of level 1, together with black box descriptions of their internal building blocks.
-
-*Level 3* zooms into selected building blocks of level 2, and so on.
-
-
-.Further Information
-
-See https://docs.arc42.org/section-5/[Building Block View] in the arc42 documentation.
-
-****
-
 === Whitebox Overall System
 
-[role="arc42help"]
-****
 A continuación se muestra el diagrama que muestra una vista completa y genérica de lo que será la estructura de la aplicación en su entorno. Se divide en tres principales componentes que mediante interacciones detalladas en los siguientes apartados lograrán una ejecución correcta del sistema. It contains
 
-****
-
 _**Diagrama de vista general**_
 
 image::05_bbv_scopecontext.jpg["Overview"]
@@ -67,12 +27,9 @@ Bloques contenidos::
 === Level 2
 ==== White Box _WIQ_
 
-[role="arc42help"]
-****
 En este apartado pasaré a describir en forma de "white box", bloque que en el diagrama de vista general hacía referencia a la aplicación al completo de manera genérica. En esta vista divisoria de la estructura de la aplicación ya comenzamos a distinguir componentes más concretos. 
 
 * "WebApp" es el componente con el que interactúa el usuario cuando entra en la aplicación y que trabaja con los demás componentes de este diagrama. "Users Management" se trata del microservicio encargado, como su nombre indica, del manejo de los usuarios, tanto los nuevos como los ya registrados en nuestro sistema. "Question Manager" se trata del conjunto de servicios encargado de la generación de preguntas.
-****
 
 image::05_bbv_level02.jpg["Level2"]
 
@@ -87,10 +44,10 @@ image::05_bbv_level02.jpg["Level2"]
 
 image::05_bbv_level03.jpg["Level3"]
 
+Nota: la versión descrita en la imagen superior está abierta a modificaciones durante el desarrollo del proyecto.
+
 ==== White Box _Users Management_
 
-[role="arc42help"]
-****
 Este esquema concreta la estructura interna del bloque "Users Management" 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. 
 
 El diagrama se divide en cuatro principales componentes que interactuan de manera secuencial mediante dos principales "caminos" de ejecución teniendo siempre en común el uso de la base de datos para garantizar la persistencia de nuestro sistema.
@@ -103,20 +60,13 @@ El diagrama se divide en cuatro principales componentes que interactuan de maner
 |Database|Se encarga de almacenar información de la aplicación para garantizar la persistencia de la misma (p.e: usuarios, contraseñas, registro histórico de puntuaciones...).
 |===
 
-****
-
 
 ==== White Box _Question Manager_
 
-[role="arc42help"]
-****
 Este segundo esquema trata de describir con mayor hondura el funcionamiento interno del bloque "Question Manager". Esta funcionalidad se divide en dos microservicios y ambos interactúan directamente con la API de WikiData para extraer de este servicio externo la información trascendental y necesaria para producir nuevos interrogantes (preguntas) y nuevas respuestas a los mismos.
 
 |===
 |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.
 |Answer Service|Servicio encargado de, trabajando de igual manera que el servicio anterior, generar las respuestas (tanto la correcta como las incorrectas) a las preguntas planteadas por el anterior microservicio.
 |===
-
-****
-

docs/src/07_deployment_view.adoc

@@ -2,94 +2,24 @@ ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-deployment-view]]
 
-(En desarrollo)
-
 == Deployment View
 
-[role="arc42help"]
-****
-.Content
-The deployment view describes:
-
- 1. technical infrastructure used to execute your system, with infrastructure elements like geographical locations, environments, computers, processors, channels and net topologies as well as other infrastructure elements and
-
-2. mapping of (software) building blocks to that infrastructure elements.
-
-Often systems are executed in different environments, e.g. development environment, test environment, production environment. In such cases you should document all relevant environments.
-
-Especially document a deployment view if your software is executed as distributed system with more than one computer, processor, server or container or when you design and construct your own hardware processors and chips.
-
-From a software perspective it is sufficient to capture only those elements of an infrastructure that are needed to show a deployment of your building blocks. Hardware architects can go beyond that and describe an infrastructure to any level of detail they need to capture.
-
-.Motivation
-Software does not run without hardware.
-This underlying infrastructure can and will influence a system and/or some
-cross-cutting concepts. Therefore, there is a need to know the infrastructure.
-
-.Form
-
-Maybe a highest level deployment diagram is already contained in section 3.2. as
-technical context with your own infrastructure as ONE black box. In this section one can
-zoom into this black box using additional deployment diagrams:
-
-* UML offers deployment diagrams to express that view. Use it, probably with nested diagrams,
-when your infrastructure is more complex.
-* When your (hardware) stakeholders prefer other kinds of diagrams rather than a deployment diagram, let them use any kind that is able to show nodes and channels of the infrastructure.
-
-
-.Further Information
-
-See https://docs.arc42.org/section-7/[Deployment View] in the arc42 documentation.
-
-****
-
-=== Infrastructure Level 1
-
-[role="arc42help"]
-****
-Describe (usually in a combination of diagrams, tables, and text):
-
-* distribution of a system to multiple locations, environments, computers, processors, .., as well as physical connections between them
-* important justifications or motivations for this deployment structure
-* quality and/or performance features of this infrastructure
-* mapping of software artifacts to elements of this infrastructure
-
-For multiple environments or alternative deployments please copy and adapt this section of arc42 for all relevant environments.
-****
-
-_**<Overview Diagram>**_
-
-Motivation::
-
-_<explanation in text form>_
-
-Quality and/or Performance Features::
-
-_<explanation in text form>_
-
-Mapping of Building Blocks to Infrastructure::
-_<description of the mapping>_
-
-
-=== Infrastructure Level 2
-
-[role="arc42help"]
-****
-Here you can include the internal structure of (some) infrastructure elements from level 1.
-
-Please copy the structure from level 1 for each selected element.
-****
-
-==== _<Infrastructure Element 1>_
-
-_<diagram + explanation>_
+=== Infrastructura Nivel 1
 
-==== _<Infrastructure Element 2>_
+image::07-Deploy-View.png["Vista de despliegue"]
 
-_<diagram + explanation>_
+Características de calidad::
 
-...
+La aplicación garantizará un correcto funcionamiento y respuesta independientemente del número de usuarios quela utilicen simúltaneamente para ofrecer una experiencia óptima.
 
-==== _<Infrastructure Element n>_
+Mapeo de bloques de construcción a la infraestructura::
+|===
+|Elemento| Descripción
+|WebApp| Se trata del frontend de la aplicación que será desplegado en el navegador.
+|GateWay| Funciona de interemediario conectando la WebApp con los diferentes microservicios, conectando así todos los componentes.
+|Services| Son los microservicios encargados de implementar las diferentes funcionalidades de la aplicación.
+|MongoDB| Es la base de datos elegida para el almacenaje de la información crucial de la aplicación.
+|Client| Navegador con el que interactúa el usuario para hacer uso de la aplicación.
+|===
 
-_<diagram + explanation>_
+(En desarrollo)

docs/src/08_concepts.adoc

@@ -6,15 +6,13 @@ ifndef::imagesdir[:imagesdir: ../images]
 
 === Descripción de conceptos
 ==== Dominio
-[role="arc42help"]
-****
+
 * *Dinamismo en temáticas:* En la aplicación, el juego desarrollado te permite contestar a una gran variedad de preguntas específicas de distintas temáticas como años, lugares y autores de todas las distintas áreas existentes como historia, geografía y música entre otras.
 * *Registro de actividad:* La aplicación permitirá al usuario registrado ver todo su historial de jugadas realizadas, así como los detalles de cada una: fecha en la que se jugó, número de aciertos/fallos, dinero conseguido y tiempo total de finalización.
-****
+
 
 ==== Experiencia de usuario (UX)
-[role="arc42help"]
-****
+
 * *Intefaz usable:* 
 |===
 | Facilidad de uso
@@ -28,29 +26,31 @@ ifndef::imagesdir[:imagesdir: ../images]
 |===
 
 * *Inmediata retroalimnetacion:* El usuario verá de forma inmediata si ha acertado o no la pregunta contestada. Así como el historial de jugadas estará actualizado en todo momento.
-****
+
 
 ==== Seguridad y protección
-[role="arc42help"]
-****
+
 * *Control de acceso seguro:* Seguridad en la autenticación del usuario, comprobando que sean correctos los datos introducidos y no dejando entrar en caso contrario.
 * *Registro de actividad:* La aplicación está hecha para garantizar la protección de los usuarios respecto a las contraseñas, las cuales se encripta. También el historial de jugadas esta protegido ya que cada usuario solo puede ver su propio historial.
-****
+
 
 ==== "Under-the-hood"
-[role="arc42help"]
-****
+
 * *Persistencia:* Tanto los datos del usuario como de las jugadas quedarán almacenados asegurando su integridad y disponilibilidad.
 * *Mantenibilidad:* El código está escrito de forma clara y legible, se sigue un enfoque modular que permitirá la facilidad en su mantenimiento a la hora de tener que corregir fallos o añadir alguna mejora. 
 * *Extensibilidad:* Aplicación construida de forma que se podrá añadir de una forma sencilla nuevas funcionalidades en el futuro sin afectar en gran manera a partes ya existentes.
-****
+
 
 ==== Desarrollo
-[role="arc42help"]
-****
+
 * *Implementación:* Para la creación de esta aplicación se usará el lenguaje de programación JavaScript, para el front-end se utilizará React, Node.js y la construccion de microservicios para el back-end y MongoDB para la gestion de la base de datos NoSQL.
 * *Pruebas:* Se llevarán a cabo pruebas unitarias, de integración, de aceptación, de capacidad/rendimiento y de regresión, todas ellas siguiendo los principios FIRST(Fast, Independent, Repeatable, Self-Checking y Timely) para garantizar la ejecución correcta de todas las funcionalidades de la aplicación. 
-****
+
+
+==== Estilo arquitectonico
+
+* *Capas:* Se utilizara un diseño basado en capas: presentacion, negocio y persistencia.
+
 
 === Mapa de conceptos
 image::08-MindMapConceptosTransversales.png["Mind Map conceptos transversales"]

docs/src/09_architecture_decisions.adoc

@@ -15,33 +15,3 @@ aplicacion.
 |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.
 |===
-
-[role="arc42help"]
-****
-.Contents
-Important, expensive, large scale or risky architecture decisions including rationales.
-With "decisions" we mean selecting one alternative based on given criteria.
-
-Please use your judgement to decide whether an architectural decision should be documented
-here in this central section or whether you better document it locally
-(e.g. within the white box template of one building block).
-
-Avoid redundancy. 
-Refer to section 4, where you already captured the most important decisions of your architecture.
-
-.Motivation
-Stakeholders of your system should be able to comprehend and retrace your decisions.
-
-.Form
-Various options:
-
-* ADR (https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions[Documenting Architecture Decisions]) for every important decision
-* List or table, ordered by importance and consequences or:
-* more detailed in form of separate sections per decision
-
-.Further Information
-
-See https://docs.arc42.org/section-9/[Architecture Decisions] in the arc42 documentation.
-There you will find links and examples about ADR.
-
-****