diff --git a/images/diagramaDespliegue.png b/images/diagramaDespliegue.png new file mode 100644 index 00000000..59b6fceb Binary files /dev/null and b/images/diagramaDespliegue.png differ diff --git a/index.html b/index.html index 5a486f2e..a0f80c8c 100644 --- a/index.html +++ b/index.html @@ -451,14 +451,20 @@

arc42 T
  • 1.3. Stakeholders
  • -
  • 2. Architecture Constraints
  • +
  • 2. Restricciones de arquitectura + +
  • 3. System Scope and Context
  • -
  • 4. Solution Strategy
  • +
  • 4. Estrategia de solución
  • 5. Building Block View
  • -
  • 7. Deployment View +
  • 7. Vista de Despliegue
  • 8. Cross-cutting Concepts @@ -494,7 +501,7 @@

    arc42 T
  • 10.2. Quality Scenarios
  • -
  • 11. Risks and Technical Debts
  • +
  • 11. Riesgos y deudas técnicas
  • 12. Glossary
  • @@ -709,7 +716,7 @@

    1.3. Stakeholders

    -

    2. Architecture Constraints

    +

    2. Restricciones de arquitectura

    @@ -735,9 +742,108 @@

    2. Architecture Constraints

    +
    +

    2.1. Requisitos técnicos

    + ++++ + + + + + + + + + + + + + + + + + + + + + + + + +
    ConstraintExplicación

    Wikidata

    Las preguntas serán generadas automáticamente a partir de datos de Wikidata.

    GitHub

    Usaremos GitHub para mantener el proyecto en un repositorio remoto, comunicarnos, asignar tareas y documentar las actas.

    Docker

    El proyecto será desplegado a través de Docker.

    Pruebas

    Deberán ser implementadas pruebas de cobertura, aceptación y carga.

    +
    +
    +

    2.2. Restricciones organizativas

    + ++++ + + + + + + + + + + + + + + + + + + + + +
    ConstraintExplicación

    Miembros del grupo

    El proyecto se llevará a cabo en un equipo con 6 miembros que trabajarán de forma conjunta.

    Entregas

    El trabajo conlleva un calendario de entregas específico:
    +* Documentación 0.1 será entregada en la semana 4.
    +* Prototipo 0.1 en la semana 7.
    +* Prototype 1.0 y documentación 1.0 en la semana 10.
    +* Prototipo 1.1 y documentación 1.1 en la semana 13.

    Reuniones y acta

    Es obligatorio hacer una reunión de equipo en cada clase y tomar su correspondiente acta.

    +
    +
    +

    2.3. Decisiones tomadas

    + ++++ + + + + + + + + + + + + + + + + + + + + + + + + +
    ConstraintExplicación

    Documentación

    Documentaremos el proyecto siguiendo el modelo arc42.

    Lenguajes

    Se usará NodeJS y React para implementar los distintos requisitos de la aplicación.

    Base de datos

    Se usará MongoDB como base de datos del proyecto.

    Idioma

    La documentación será en español.

    +

    3. System Scope and Context

    @@ -838,48 +944,33 @@

    3.2. Technical Context

    -

    4. Solution Strategy

    +

    4. Estrategia de solución

    -
    -
    -
    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.

      -
    • -
    +
    Solución pensada:
    +

    El programa usado como solución consiste en una página en la que los usuarios pueden crear una cuenta a la que +acceder para a una partida en la que tendran que responder varias preguntas. Se debe poder guardar tanto las preguntas como +el ratio de aciertos del usuario en una base de datos.

    -
    Motivation
    -

    These decisions form the cornerstones for your architecture. They are the foundation for many other detailed decisions or implementation rules.

    +

    Las partidas tendrán aproximadamente diez preguntas y cada pregunta mostrará cuatro opciones, siendo solo una +la respuesta correcta. Cada pregunta tendrá una duración máxima de, aproximadamente, 30 segundos. Esto fue decidido para +facilitar la generación de las preguntas y la jugabilidad.

    -
    Form
    -

    Keep the explanations of such key decisions short.

    +
    Tecnologías pensadas para su uso:
    +

    La solución pensada originalmente consiste en usar Node.js y React para llevar a cabo la programación del +sistema, usando consultas a Wikidata para realizar las preguntas y obtener las respuestas más actualizadas.

    -

    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.

    +

    El uso de Wikidata para realizar las perguntas fue una de las limitaciones impuestas sobre nuestro proyecto. El uso de React y +Node.js se debe a que el proyecto inicial dado estaba escrito usando dicho entorno y biblioteca de código y se decidió seguir usandolo +para evitar problemas debido a errores de compatibilidad si se trataban de cambiar.

    -
    Further Information
    -

    See Solution Strategy in the arc42 documentation.

    -
    -
    +

    Si bién aun estar por confirmar, también se tenía pensado el uso de MongoDB para la base de datos. Se decidió usar este tipo +de base de datos debido, en su gran mayoría, a la familiaridad con dicho sistema y debido que algunos de los objetos que se +requieren guardar es más sencillo de hacer en una base de datos NoSQL.

    @@ -1289,147 +1380,52 @@

    6.4. <Runtime Scenario n>

    -

    7. Deployment View

    +

    7. Vista de Despliegue

    -
    -
    -
    -
    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. -
    3. -

      mapping of (software) building blocks to that infrastructure elements.

      -
    4. -
    -
    -
    -

    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 Deployment View in the arc42 documentation.

    -
    -
    +

    Diagrama de despliegue

    -

    7.1. Infrastructure Level 1

    -
    -
    +

    7.1. Motivación

    -

    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>

    -
    -
    +

    El sistema se desplegara en una maquina virtual de Azure, dentro de la maquina cada micro servicio que compone la aplicación, + la base de datos y la web estarna desplegados en un contenedor docker ya que es como nos han proporcionado la integración continua inicial.

    -

    7.2. Infrastructure Level 2

    -
    -
    -
    -

    Here you can include the internal structure of (some) infrastructure elements from level 1.

    -
    +

    7.2. Características de Calidad y/o Rendimiento

    -

    Please copy the structure from level 1 for each selected element.

    -
    +

    Completar mas adelante

    -
    -

    7.2.1. <Infrastructure Element 1>

    -
    -

    <diagram + explanation>

    -
    -
    -
    -

    7.2.2. <Infrastructure Element 2>

    -
    -

    <diagram + explanation>

    -
    -
    -

    …​

    -
    -
    -
    -

    7.2.3. <Infrastructure Element n>

    -
    -

    <diagram + explanation>

    -
    +
    +

    7.3. Componentes de la infraestructura

    + ++++ + + + + + + + + + + + + + + + + +
    ElementDescription

    WebApp

    Es el frontend de nuestra aplicación al cual se accederá desde un navegador.

    ServiceGateway

    Es la REST API de nuestra aplicación a la cual se conecta WebApp y se podrá acceder desde el exterior para obtener datos de los usuarios.Esta parte junta todas las operaciones de los microservicios en un único puerto.

    -

    8. Cross-cutting Concepts

    @@ -1708,31 +1704,54 @@

    10.2. Quality Scenarios

    -

    11. Risks and Technical Debts

    +

    11. Riesgos y deudas técnicas

    -
    -
    -
    -
    Contents
    -

    A list of identified technical risks or technical debts, ordered by priority

    -
    -
    -
    Motivation
    -

    “Risk management is project management for grown-ups” (Tim Lister, Atlantic Systems Guild.)

    -
    -
    -

    This should be your motto for systematic detection and evaluation of risks and technical debts in the architecture, which will be needed by management stakeholders (e.g. project managers, product owners) as part of the overall risk analysis and measurement planning.

    -
    -
    -
    Form
    -

    List of risks and/or technical debts, probably including suggested measures to minimize, mitigate or avoid risks or reduce technical debts.

    -
    -
    -
    Further Information
    -

    See Risks and Technical Debt in the arc42 documentation.

    -
    -
    -
    + ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    Riesgos/Deudas técnicasDescripción

    Despliegue en servidor

    Puede haber errores de conexión con la máquina que despliega la aplicación. Además, si la desplegamos en servicios como Azure o AWS, la aplicación depende de una fuente externa, por lo que, podría darse la situación de no poder desplegar la web por una causa ajena.

    Inconsistencias de datos

    Al utilizar Wikidata para responder sacar la respuesta a preguntas, puede haber ciertas inconsistencias en los datos. Estos son actualizados por usuarios independientes y puede ocurrir que exista alguna respuesta que no tiene algún dato actualizado o incluso datos erróneos

    Utilizar dependencias antiguas/inseguras

    Puede ser un problema utilizar librerías o frameworks antiguos, expuestos a vulnerabilidades de seguridad o que dejen de funcionar, ya que, han sido modificados.

    Pruebas insuficientes

    No hacer las suficientes pruebas puede ser problema para el producto final de la aplicación. Son necesarias para verificar que todo funciona correctamente y como es esperado. Si no es así será detectado mediante las pruebas.

    Registro de usuarios

    Los usuarios han de poder registrarse con una contraseña asociada a su nombre de usuario, lo que puede dar lugar a problemas de seguridad si alguien quiere averiguar la contraseña de algún usuario. Por lo que se debería de garantizar el transporte de datos seguro.

    Carga muy alta de datos

    Si la aplicación llegase a tener registrados una alta carga de usuarios (millones), hay que tener en cuenta que para cada usuario habrá que guardar un histórico de todas sus partidas. Además, de guardar en la base de datos los diferentes tipos de preguntas.

    Alta demanda de peticiones

    Podría haber problemas de rendimiento si hay un número elevado de usuarios jugando al mismo tiempo. Eso podría colapsar la máquina y base de datos que dan soporte al juego.

    Usabilidad en la web

    Se intentará que la aplicación sea lo más usable posible y que pueda llegar al máximo número de personas y rangos de edad; evitando colores parecidos, mala legibilidad y haciendo la aplicación lo más intuitiva posible.