Merge pull request #32 from Arquisoft/documentation

Documentation

.vscode/settings.json

@@ -0,0 +1,3 @@
+{
+    "asciidoc.antora.enableAntoraSupport": true
+}

docs/src/01_introduction_and_goals.adoc

@@ -1,96 +1,49 @@
 ifndef::imagesdir[:imagesdir: ../images]
 
 [[section-introduction-and-goals]]
-== Introduction and Goals (wiq_es04c)
+== Introducción y Ojetivos (wiq_es04c)
 
-Trabajo realizado por David Alvarez, Zohaib Akhtar Kausar, Sara Lamuño Garcia, Yago Navajas Gonzalez y Santiago Lopez Laso.
+nombre_del_proyecto es un proyecto desarrollado en la asignatura  Arquitectura del Software. Consiste en la creacion de una aplicacion web al estilo "Saber y Ganar". Es decir, es un juego de preguntas de cultura general.
 
+Los desarrolladores de la aplicacion son por David Álvarez Díaz, Zohaib Akhtar Kausar, Sara Lamuño García, Yago Navajas González y Santiago López Laso.
 
-[role="arc42help"]
-****
-Describes the relevant requirements and the driving forces that software architects and development team must consider. 
-These include
+La aplicacion tendra su base para las preguntas y las respuestas en Wikidata , la base de conocimiento editada en colaboracion.
 
-* underlying business goals, 
-* essential features, 
-* essential functional requirements, 
-* quality goals for the architecture and
-* relevant stakeholders and their expectations
-****
 
-=== Requirements Overview
+=== Requisitos Funcionales
 
-[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.
-
-Keep these excerpts as short as possible. Balance readability of this document with potential redundancy w.r.t to requirements documents.
-
+* Los usuarios se deberan loggear en la pagina, esto servira para tener registro de unas serie de parametros, como puede ser las veces que se ha jugado. 
+* Se podran responder preguntas autogeneradas y ver si han acertado fallado asi como la respuesta correcta.
+* Las preguntas deberan ser respondidas en un tiempo limite.
+* Las preguntas seran seguiran la misma estructura: 1 pregunta correcta y 3 incorrectas, generadas automaticamente.
+* Los usuarios prodran consultar datos sobre su cuentan, como pueden ser las veces que han jugado o el numero de preguntas que han acertadoo fallado. 
 
-.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"]
+=== Atributos de Calidad
 
-.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...
+[options="header",cols="1,2,2"]
+|===
+|Prioridad | Objetivo | Descripcion
+| 1 | Usabilidad | Todos los usuarios deben poder usar la aplicacion sin tener en cuenta sus limitaciones.
+| 2 | Privacidad |  Los datos sensibles de los usuarios deben estar restingidos al mismo usuario.
+| 3 |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.
+| 4 | Eficiciencia | Los tiempos entre operaciones han de ser asumibles.
+| 5 | Fiabilidad | Los datos usados en la aplicación deben ser los correctos.
+|===
 
-.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
-
-.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.
-****
-
 [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] +
+David Álvarez Díaz -> [email protected] +
+Zohaib Akhtar Kausar -> [email protected] +
+Sara Lamuño García -> [email protected] +
+Santiago Lopez Laso -> [email protected] | Los estudiantes que llevarán a cabo el desarrollo de la aplicación. Seran los encargados de la arquitectura, la documentación y la codificación.
+| Profesores | [email protected] | Supervisores de los avances y encargados de evaluar la aplicacion final y el desarrollo de la misma.
 |===

docs/src/02_architecture_constraints.adoc

@@ -1,27 +1,12 @@
 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
+[options="header",cols="1,2"]
+|===
+|Restricción|Descripción
+|Wikidata|Se usará la API de WIkidata para generar las preguntas automáticamente.
+|Git|Control de versiones del proyecto. 
+|GitHub|Portal donde se guardará el código fuente del proyecto.
+|===

docs/src/03_system_scope_and_context.adoc

@@ -3,73 +3,15 @@ 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>**
-
-=== 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>**
+=== 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|Ítems(elementos) de Wikidata|Petición a la API de Wikidata
+|===
+
+=== Contexto técnico
+
+image::diagrama_contexto_tecnico.drawio.png["Diagrama de contexto técnico"]

docs/src/04_solution_strategy.adoc

@@ -24,6 +24,87 @@ 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.
 
+Decisiones tecnológicas
+
+Hemos decidido realizar la parte de Front-End con React y la parte de Back-End con la estructura de los microservicios. 
+El despliegue se realizará a través de una máquina virtual de Azure, con ayuda de Docker y GitHub Actions.
+
+[options="header",cols="1,2"]
+|===
+|Aplicación
+|Breve explicación
+|React
+|Biblioteca de JavaScript que nos servirá para realizar las interfaces de usuario necesarias para el Front-End.
+|Microservicios
+|Aquí es donde se unirá el uso de la API (Application Programming Interface) de WikiData, la cual nos sacará los datos para las preguntas y las respuestas
+de la aplicación con el proyecto en sí.
+|Azure
+|Plataforma para la creación de la máquina virtual que servirá para desplegar la aplicación.
+|Docker
+|Encargado de dividir el contenido del proyecto en diversos contenedores (en nuestro caso 4) y sea más fácil de manipular el contenido de dicho proyecto.
+|GitHub Actions
+|Nos servirá para el despliegue del proyecto, pero de forma automática en vez de desplegarlo todo a mano. Cabe a destacar que también están implementados
+unos test para asegurar el correcto despliegue del proyecto.
+|===
+
+Decisiones de cómo llegar a las metas principales (En desarrollo):
+[options="header",cols="1,2"]
+|===
+|Usabilidad
+|
+|Privacidad
+|
+|Mantenibilidad
+|
+|Eficiciencia
+|
+|Fiabilidad
+|
+
+|===
+
+
+
+Decisiones organizativas
+
+En la primera semana nos hemos dividido en dos equipos con el objetivo de tocar todas las partes del proyecto. La estructura de los equipos es la siguiente:
+
+----
+-> Equipo documentación
+     Sara Lamuño García -> [email protected] 
+     Yago Navajas Gonzalez -> [email protected]
+-> Equipo desarrollo del proyecto
+     David Álvarez Díaz -> [email protected]
+     Zohaib Akhtar Kausar -> [email protected]
+     Santiago Lopez Laso -> [email protected]
+----
+
+La realización de las actas de las reuniones diarias se le ha asignado la tarea a Sara Lamuño García.
+
+En las siguientes semanas habrá rotación o cambio de miembros en ambos equipos.
+
+En la segunda semana hemos decidido ponernos de manera más profunda con la documentación, asignando diferentes apartados de esta a cada miembro del equipo:
+
+[options="header",cols="1,2"]
+|===
+| Miembro
+| Documentación
+| Sara Lamuño García
+| 4, 6, 12
+| Yago Navajas Gonzalez
+| 1, 8, 9
+| David Álvarez Díaz
+| 5, 7
+| Zohaib Akhtar Kausar
+| 10, 11
+| Santiago Lopez Laso
+| 2, 3
+|===
+
+Se han creado el mismo número de Issues como apartados de la documentación hay para asignarla a cada miembro.
+
+En cuanto al despliegue de la aplicación se van a arreglar los errores que salen en los test al intentar desplegarla, ya que se han cambiado
+algunos valores predefinidos, por lo que los test también predefinidos fallarán.
 
 .Further Information
 

docs/src/06_runtime_view.adoc

@@ -58,8 +58,52 @@ Alice -> Bob: Another authentication Request
 Alice <-- Bob: another authentication Response
 ----
 
-=== <Runtime Scenario 2>
+[plantuml,"Sequence diagram",png]
+Diagrama de secuencia con plantuml (se contempla sólo el uso correcto de la aplicación)
+----
+actor usuario
+actor system
+database bbdd as "bbdd"
+actor juego
+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
 
-=== ...
+----
 
-=== <Runtime Scenario n>
+=== <Runtime Scenario 2>
+-------------------------------------------------------------------------------------------------------------------------------------
+| -> Diagrama de secuencia                                                                                                          |
+| -> Descripción: diagrama de los usos básicos en la aplicación, como inicio de sesión, empezar a jugar y contestar las preguntas.  |
+| -> Aspectos notables:                                                                                                             |
+|    - El usuario tiene que estar autentificado en la aplicación para poder entrar al juego.                                        |
+|    - Los usuarios estarán en una base de datos para recoger los datos de manera más sencilla.                                     |
+|    - En el diagrama se pone la opción de respuesta correcta, pero si fuera incorrecta también se seguiría jugando.                |
+-------------------------------------------------------------------------------------------------------------------------------------
+image::Digrama de secuencia Juego de preguntas.jpg["Diagrama de secuencia"]
+
+=== <Runtime Scenario 3>
+--------------------------------------------------------------------------------------------------------------------------------------
+| -> Diagrama de casos de uso                                                                                                        |
+| -> Descripción: diagrama básico de los distintos casos de uso que hay en el proyecto                                               |
+| -> Aspectos notables:                                                                                                              |
+|    - El caso de uso de iniciar sesión del usuario está relacionado con el caso de uso de autentificar sesión del sistema,          |
+|    - ya que para que el usuario pueda iniciar sesión debe de estar autentificado.                                                  |
+|    - Lo mismo ocurre con el caso de uso de contestar preguntas del usuario con el caso de uso de verificar respuestas del sistema, | 
+|    - ya que para que el usuario pueda contestar preguntas, el sistema primero debe de verificar si dicha respuesta es correcta     |
+|    - o no para pasar a la siguiente pregunta.                                                                                      |
+--------------------------------------------------------------------------------------------------------------------------------------
+
+image::Diagrama de casos de uso para el juego de palabras.jpg["Diagrama de caso de uso"]