1.4. Restricciones técnicas
-1.5. Restricciones de organización
+2.1. Restricciones de organización
2.2. Technical Context
+3.2. Technical Context
2.2. Technical Context
3. Estrategia de solución
+4. Estrategia de solución
3.1. Decisiones Tecnológicas
+4.1. Decisiones Tecnológicas
-
@@ -1019,13 +1025,13 @@
3.1. Decisiones Tecnológicas
3.2. Motivaciones
+4.2. Motivaciones
Hemos escogido TypeScript por su mayor parecido a Java, ya que nuestro equipo en su mayoría lo domina. En cuanto React nos basemos en que facilmente se puede crear interfaces. El resto de tecnologías son las más óptimas y las prestablecidas, en el proyecto. Realmente estamos a la espera de los resultados de estas decisiones, ya que en su mayoría son tecnologías desconocidas para el equipo.
3.3. Decisiones sobre cómo alcanzar los objetivos clave de calidad
+4.3. Decisiones sobre cómo alcanzar los objetivos clave de calidad
-
@@ -1041,7 +1047,7 @@
3.3. De
3.4. Decisiones organizativas:
+4.4. Decisiones organizativas:
-
@@ -1060,310 +1066,117 @@
3.4. Decisiones organizativas:
4. Building Block View
+5. Building block view
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.
-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.
-The building block view is a hierarchical collection of black boxes and white boxes -(see figure below) and their descriptions.
-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.
-See Building Block View in the arc42 documentation.
-4.1. Whitebox Overall System
-Here you describe the decomposition of the overall system using the following white box template. It contains
--
-
-
-
an overview diagram
-
- -
-
a motivation for the decomposition
-
- -
-
black box descriptions of the contained building blocks. For these we offer you alternatives:
----
-
-
-
use one table for a short and pragmatic overview of all contained building blocks and their interfaces
-
- -
-
use a list of black box descriptions of the building blocks according to the black box template (see below). -Depending on your choice of tool this list could be sub-chapters (in text files), sub-pages (in a Wiki) or nested elements (in a modeling tool).
-
-
- -
-
-
-
(optional:) important interfaces, that are not explained in the black box templates of a building block, but are very important for understanding the white box. -Since there are so many ways to specify interfaces why do not provide a specific template for them. - In the worst case you have to specify and describe syntax, semantics, protocols, error handling, - restrictions, versions, qualities, necessary compatibilities and many things more. -In the best case you will get away with examples or simple signatures.
-
-
<Overview Diagram>
--
-
- Motivation -
-
-
<text explanation>
-
- - Contained Building Blocks -
-
-
<Description of contained building block (black boxes)>
-
- - Important Interfaces -
-
-
<Description of important interfaces>
-
-
Insert your explanations of black boxes from level 1:
-If you use tabular form you will only describe your black boxes with name and -responsibility according to the following schema:
-5.1. Whitebox Overall System
Name | -Responsibility | +Nombre | +Descripción |
---|---|---|---|
<black box 1> |
-<Text> |
+Wikidata |
+Para formular las preguntas se extrará información de WikiData a través de su API. |
+
Base de datos |
+Se guarda información importante, como los datos de los usuarios y sus historiales. |
+||
WebApp |
+Permite a los usuarios registrarse e identificarse, además de iniciar la aplicación. |
||
<black box 2> |
-<Text> |
+Cliente |
+Accede a la aplicación y interactúa con ella a través de la interfaz de usuario. |
If you use a list of black box descriptions then you fill in a separate black box template for every important building block . -Its headline is the name of the black box.
-4.1.1. <Name black box 1>
-Here you describe <black box 1> -according the the following black box template:
--
-
-
-
Purpose/Responsibility
-
- -
-
Interface(s), when they are not extracted as separate paragraphs. This interfaces may include qualities and performance characteristics.
-
- -
-
(Optional) Quality-/Performance characteristics of the black box, e.g.availability, run time behavior, ….
-
- -
-
(Optional) directory/file location
-
- -
-
(Optional) Fulfilled requirements (if you need traceability to requirements).
-
- -
-
(Optional) Open issues/problems/risks
-
-
<Purpose/Responsibility>
-<Interface(s)>
-<(Optional) Quality/Performance Characteristics>
-<(Optional) Directory/File Location>
-<(Optional) Fulfilled Requirements>
-<(optional) Open Issues/Problems/Risks>
-4.1.2. <Name black box 2>
-<black box template>
-4.1.3. <Name black box n>
-<black box template>
-4.1.4. <Name interface 1>
-…
-4.1.5. <Name interface m>
- -4.2. Level 2
-Here you can specify the inner structure of (some) building blocks from level 1 as white boxes.
-You have to decide which building blocks of your system are important enough to justify such a detailed description. -Please prefer relevance over completeness. Specify important, surprising, risky, complex or volatile building blocks. -Leave out normal, simple, boring or standardized parts of your system
-4.2.1. White Box <building block 1>
-…describes the internal structure of building block 1.
-<white box template>
-4.2.2. White Box <building block 2>
-<white box template>
-…
-4.2.3. White Box <building block m>
-<white box template>
-5.2. Blackbox Overall System
+Nombre | +Descripción | +
---|---|
Sistema |
+Maneja toda la aplicación y se comunica con todos los otros sistemas. |
+
4.3. Level 3
-Here you can specify the inner structure of (some) building blocks from level 2 as white boxes.
-When you need more detailed levels of your architecture please copy this -part of arc42 for additional levels.
-4.3.1. White Box <_building block x.1_>
-Specifies the internal structure of building block x.1.
-<white box template>
-4.3.2. White Box <_building block x.2_>
-<white box template>
-4.3.3. White Box <_building block y.1_>
-<white box template>
+5.3. Level 1
+Nombre | +Descripción | +
---|---|
Interfaz de usuario |
+Toda la parte gráfica de la aplicación y que se comunica con el usuario. Se comunica con la parte lógica de la aplicación a base de eventos producidos por el usuario. |
+
Lógica de aplicación |
+Lleva a cabo todos los cálculos necesarios para el funcionamiento de la aplicación. También se comunica con los sistemas para conseguir la información necesaria. |
+
5.4. Level 2
+Nombre | +Descripción | +
---|---|
Lógica |
+La parte central de la aplicación. Se comunica con todos los sistemas excepto con la base de datos. Para acceder a los datos se comunica con la capa de persistencia. |
+
Persistencia |
+Se comunica con la base de datos para conseguir o añadir información. |
+
5. Runtime View
+6. Runtime View
5. Runtime View
5.1. <Runtime Scenario 1>
+6.1. <Runtime Scenario 1>
-
@@ -1450,21 +1263,21 @@
5.1. <Runtime Scenario 1>
5.2. <Runtime Scenario 2>
+6.2. <Runtime Scenario 2>
5.3. …
+6.3. …
5.4. <Runtime Scenario n>
+6.4. <Runtime Scenario n>
6. Deployment View
+7. Deployment View
6. Deployment View
6.1. Infrastructure Level 1
+7.1. Infrastructure Level 1
6.1. Infrastructure Level 1
6.2. Infrastructure Level 2
+7.2. Infrastructure Level 2
6.2. Infrastructure Level 2
6.2.1. <Infrastructure Element 1>
+7.2.1. <Infrastructure Element 1>
En el siguiente diagrama se ve más a fondo el despliegue de nuestra aplicación, se puede ver el uso de docker como forma de contenedor para después desplegarlo en Azure Cloud.
6.2.1. <Infrastructure Element 1>
6.3. Modelo de dominio
+7.3. Modelo de dominio
Este es el modelo inicial de nuestra aplicación, pero evolucionará con el tiempo.
6.3. Modelo de dominio
6.4. Arquitectura principal
+7.4. Arquitectura principal
Hemos decidido utilizar una arquitectura de microservicios, dividiendo la aplicación en módulos. Estos módulos a su vez, se estructurarán con el patrón MVC.
6.5. Reglas al usar una tecnología específica:
+7.5. Reglas al usar una tecnología específica:
Realmente no sabemos demasiado sobre las tecnologías elegigidas, con la evolución del equipo mejoraremos esta sección.
6.6. Reglas de implementación
+7.6. Reglas de implementación
Como es un proyecto en equipo creemos que la colaboración es lo más importante, por eso hemos decidido comentar lo máximo posible nuestro propio código para que sea entendible por otras personas/compañeros de equipo.
6.7. Interfaz de usuario.
+7.7. Interfaz de usuario.
Queremos crear una aplicación accesible para todos los usuarios, que sea simple de entender y de jugar, que lo máximo que tengas que pensar sean las preguntas del juego.
6.8. Privacidad
+7.8. Privacidad
Los usuarios se tienen que autenticar para poder utilizar la aplicación, además sus contraseñas están encriptadas.