diff --git a/images/08_diagrama_modelo_dominio.png b/images/08_diagrama_modelo_dominio.png new file mode 100644 index 0000000..54fe0a4 Binary files /dev/null and b/images/08_diagrama_modelo_dominio.png differ diff --git a/images/10_Arbol_de_calidad.jpg b/images/10_Arbol_de_calidad.jpg new file mode 100644 index 0000000..bc70eea Binary files /dev/null and b/images/10_Arbol_de_calidad.jpg differ diff --git a/images/Diagrama de casos de uso para el juego de palabras.jpg b/images/Diagrama de casos de uso para el juego de palabras.jpg new file mode 100644 index 0000000..d002bc2 Binary files /dev/null and b/images/Diagrama de casos de uso para el juego de palabras.jpg differ diff --git a/images/Digrama de secuencia Juego de preguntas.jpg b/images/Digrama de secuencia Juego de preguntas.jpg new file mode 100644 index 0000000..c48c265 Binary files /dev/null and b/images/Digrama de secuencia Juego de preguntas.jpg differ diff --git a/images/diagrama_contexto_tecnico.drawio.png b/images/diagrama_contexto_tecnico.drawio.png new file mode 100644 index 0000000..e5f0cf8 Binary files /dev/null and b/images/diagrama_contexto_tecnico.drawio.png differ diff --git a/index.html b/index.html index c7e6b49..dd142f8 100644 --- a/index.html +++ b/index.html @@ -444,18 +444,18 @@

arc42 T
Table of Contents
-
  • 8. Cross-cutting Concepts +
  • 8. Conceptos Transversales
    • -
  • 9. Architecture Decisions
    • -
  • 10. Quality Requirements +
  • 9. Decisiones de Arquitectura
    • +
  • Requisitos de Calidad 🌟 + +
    • +
  • Risks and Technical Debts 🚀 +
    • -
  • 11. Risks and Technical Debts
    • -
  • 12. Glossary
    • @@ -549,138 +563,89 @@

    arc42 T
    -

    1. Introduction and Goals (wiq_es04c)

    +

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

    -
    -
    -
    -
    -

    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

      -
      • -
    -
    -
    -
    -
    -

    1.1. Requirements Overview

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

    +

    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.

    -

    Keep these excerpts as short as possible. Balance readability of this document with potential redundancy w.r.t to requirements documents.

    +

    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.

    -
    Further Information
    -

    See Introduction and Goals in the arc42 documentation.

    -
    -
    -
    +

    La aplicacion tendra su base para las preguntas y las respuestas en Wikidata , la base de conocimiento editada en colaboracion.

    -

    1.2. Quality Goals

    -
    -
    -
    -
    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):

    -
    -
    -
    -Categories of Quality Requirements -
    -
    -
    -
    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…​

    -
    -
    -
    Form
    -

    A table with quality goals and concrete scenarios, ordered by priorities

    -
    -
    -
    -
    -
    -

    1.3. Stakeholders

    -
    +

    1.1. Requisitos Funcionales

    +
    -
    -
    Contents
    -

    Explicit overview of stakeholders of the system, i.e. all person, roles or organizations that

    -
    • -

      should know the architecture

      +

      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.

    • -

      have to be convinced of the architecture

      +

      Se podran responder preguntas autogeneradas y ver si han acertado fallado asi como la respuesta correcta.

    • -

      have to work with the architecture or with code

      +

      Las preguntas deberan ser respondidas en un tiempo limite.

    • -

      need the documentation of the architecture for their work

      +

      Las preguntas seran seguiran la misma estructura: 1 pregunta correcta y 3 incorrectas, generadas automaticamente.

    • -

      have to come up with decisions about the system or its development

      +

      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.

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

    +
    +

    1.2. Atributos de Calidad

    + +++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    PrioridadObjetivoDescripcion

    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.

    +
    +

    1.3. Stakeholders

    @@ -696,14 +661,18 @@

    1.3. Stakeholders

    - - - + + + - - - + + +

    <Role-1>

    <Contact-1>

    <Expectation-1>

    Equipo de Desarrollo

    Yago Navajas Gonzalez → UO287746@uniovi.es
    +David Álvarez Díaz → UO283196@uniovi.es
    +Zohaib Akhtar Kausar → UO291060@uniovi.es
    +Sara Lamuño García → UO283706@uniovi.es
    +Santiago Lopez Laso → UO277369@uniovi.es

    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.

    <Role-2>

    <Contact-2>

    <Expectation-2>

    Profesores

    labra@uniovi.es

    Supervisores de los avances y encargados de evaluar la aplicacion final y el desarrollo de la misma.
    @@ -712,129 +681,79 @@

    1.3. Stakeholders

    -

    2. Architecture Constraints

    +

    2. Restricciones de arquitectura

    -
    -
    -
    -
    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 Architecture Constraints in the arc42 documentation.

    -
    -
    -
    + + ++++ + + + + + + + + + + + + + + + + + + + + +
    Table 1. Restricciones
    RestricciónDescripció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.

    3. System Scope and Context

    -
    -
    -
    -
    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 Context and Scope in the arc42 documentation.

    -
    -
    -
    -

    3.1. Business Context

    -
    -
    +

    3.1. Contexto de negocio

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

    +

    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.

    + +++++ + + + + + + + + + + + + + + + + + + + +
    Agente externoEntradasSalidas

    Usuario

    Datos registro, datos login, respuesta a cada pregunta

    Preguntas, histórico

    Wikidata

    Ítems(elementos) de Wikidata

    Petición a la API de Wikidata

    -

    3.2. Technical Context

    -
    +

    3.2. Contexto técnico

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

    +Diagrama de contexto técnico
    -
    -
    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>

    @@ -879,6 +798,149 @@

    4. Solution Strategy

    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.

    +
    + ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    AplicaciónBreve 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):

    +
    + ++++ + + + + + + + + + + + + + + + + + + + + + + + + +
    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 -> UO283706@uniovi.es
+     Yago Navajas Gonzalez -> UO287746@uniovi.es
+-> Equipo desarrollo del proyecto
+     David Álvarez Díaz -> UO283196@uniovi.es
+     Zohaib Akhtar Kausar -> UO291060@uniovi.es
+     Santiago Lopez Laso -> UO277369@uniovi.es
    +
    +
    +
    +

    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:

    +
    + ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    MiembroDocumentació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

    See Solution Strategy in the arc42 documentation.

    @@ -1270,17 +1332,70 @@

    6.1. <Runtime Scenario 1>

    Sequence diagram
    +
    +

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

    6.2. <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.                |
    +
    +
    +
    +
    +Diagrama de secuencia +
    -
    -

    6.3. …​

    -
    -

    6.4. <Runtime Scenario n>

    +

    6.3. <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.                                                                                      |
    +
    +
    +
    +
    +Diagrama de caso de uso +
    +
    @@ -1453,124 +1568,48 @@

    7.2.3. <Infrastructure Element n>

    -

    8. Cross-cutting Concepts

    +

    8. Conceptos Transversales

    -
    -
    -
    -
    Content
    -

    This section describes overall, principal regulations and solution ideas that are relevant in multiple parts (= cross-cutting) of your system. -Such concepts are often related to multiple building blocks. -They can include many different topics, such as

    -
    -
    -
      -
    • -

      models, especially domain models

      -
      • -
    • -

      architecture or design patterns

      -
      • -
    • -

      rules for using specific technology

      -
      • -
    • -

      principal, often technical decisions of an overarching (= cross-cutting) nature

      -
      • -
    • -

      implementation rules

      -
      • -
    -
    -
    -
    Motivation
    -

    Concepts form the basis for conceptual integrity (consistency, homogeneity) of the architecture. -Thus, they are an important contribution to achieve inner qualities of your system.

    -
    -
    -

    Some of these concepts cannot be assigned to individual building blocks, e.g. security or safety.

    -
    -
    Form
    -

    The form can be varied:

    -
    -
    -
      -
    • -

      concept papers with any kind of structure

      -
      • -
    • -

      cross-cutting model excerpts or scenarios using notations of the architecture views

      -
      • -
    • -

      sample implementations, especially for technical concepts

      -
      • -
    • -

      reference to typical usage of standard frameworks (e.g. using Hibernate for object/relational mapping)

      -
      • -
    +

    Estos conceptos todavia no han sido aprobados ni implemenmtados pero dan una idea general al proyecto.

    +
    +

    8.1. Modelo de Dominio

    -
    Structure
    -

    A potential (but not mandatory) structure for this section could be:

    +

    Esta es una primera version del modelo del dominio muy simple para hacerse una idea como funcionara la aplicacion.

    -
    -
      -
    • -

      Domain concepts

      -
      • -
    • -

      User Experience concepts (UX)

      -
      • -
    • -

      Safety and security concepts

      -
      • -
    • -

      Architecture and design patterns

      -
      • -
    • -

      "Under-the-hood"

      -
      • -
    • -

      development concepts

      -
      • -
    • -

      operational concepts

      -
      • -
    +
    +

    8.2. Experiencia de Usuario

    -

    Note: it might be difficult to assign individual concepts to one specific topic -on this list.

    +

    El usuario sera capaz de interactura con una aplicacion web donde se podra registrar y jugar al juego de manera sencilla.

    -Possible topics for crosscutting concepts -
    -
    -
    -
    Further Information
    -

    See Concepts in the arc42 documentation.

    +Modelo de dominio simple provisional
    -

    8.1. <Concept 1>

    +

    8.3. Seguridad

    <explanation>

    -

    8.2. <Concept 2>

    +

    8.4. Arquitectura y Patrones de Diseño

    <explanation>

    +
    +
    +

    8.5. Desarrollo

    -

    …​

    +

    <explanation>

    -

    8.3. <Concept n>

    +

    8.6. Operaciones

    <explanation>

    @@ -1579,187 +1618,192 @@

    8.3. <Concept n>

    -

    9. Architecture Decisions

    +

    9. Decisiones de Arquitectura

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

    + +++++ + + + + + + + + + + + + + + + + + + + + + + +

    Decisión

    Ventajas

    Inconvenientes

    JavaScript / React

    La base de la aplicación ya esta creada con este lenguaje y lo para la creación de sitios web es un versatil.

    La baja o nula esperiencia con el lenguaje de algunos integrantes del grupo asi como sus limitaciones tecninas.

    Microservicios

    La aplicacion se podra dividir en problemas que se podran solucionar dandole diferentes enfoques con diferentes lenguajes y metodologias.

    AL igual que el primer punto, la baja experiencia con esta forma de trabajo al cual se tendra que adaptar el grupo.

    MongoDB

    Parte de la implementacion ya está hecha. Por otra parte es de uso libre y existe bastante documentacion online para usarse correctamente

    Al igual que los dos puntos anteriores, el grupo cuenta con poca experiencia usando esta tecnología y no somos concientes de todas sus limitaciones y fortalezas.

    +
    -
    -
    Motivation
    -

    Stakeholders of your system should be able to comprehend and retrace your decisions.

    +

    Requisitos de Calidad 🌟

    +
    +

    1. Árbol de Calidad 🌳

    +
    -
    Form
    -

    Various options:

    +

    El árbol de calidad se organiza con "calidad" como raíz, desglosándose en varias ramas principales que representan categorías de calidad relevantes para el proyecto WIQ. Estas ramas incluyen:

    • -

      ADR (Documenting Architecture Decisions) for every important decision

      +

      Usabilidad 💡: Se refiere a la facilidad con la que los usuarios pueden utilizar un sistema para alcanzar sus objetivos de manera eficiente y satisfactoria. La usabilidad implica interfaces intuitivas, accesibilidad y una experiencia de usuario agradable.

      +
      • +
    • +

      Rendimiento ⚡: Evalúa la eficiencia del sistema en términos de velocidad de respuesta, consumo de recursos y escalabilidad. Un buen rendimiento asegura que el sistema puede manejar cargas de trabajo elevadas con tiempos de respuesta rápidos.

      +
      • +
    • +

      Seguridad 🔒: Implica proteger la información y los sistemas contra accesos no autorizados, divulgación, alteración o destrucción, garantizando la confidencialidad, integridad y disponibilidad de los datos.

      +
      • +
    • +

      Fiabilidad 🛡️: La capacidad del sistema de funcionar correctamente y sin fallos durante un período determinado bajo condiciones específicas. La fiabilidad se centra en la consistencia del rendimiento y la prevención de fallos.

    • -

      List or table, ordered by importance and consequences or:

      +

      Mantenibilidad 🔧: Se refiere a la facilidad con la que un sistema puede ser modificado para corregir fallos, mejorar su funcionamiento o adaptarse a un entorno cambiante. Una alta mantenibilidad facilita las actualizaciones y reduce los costos a largo plazo.

    • -

      more detailed in form of separate sections per decision

      +

      Portabilidad 🌍: La capacidad de un sistema para ser utilizado en diferentes entornos operativos con mínimas modificaciones. La portabilidad permite que el software sea compatible con diversos dispositivos, sistemas operativos o navegadores web.

    -
    -
    Further Information
    -

    See Architecture Decisions in the arc42 documentation. -There you will find links and examples about ADR.

    -
    +
    +
    +Árbol de Calidad
    -
    -

    10. Quality Requirements

    +

    2. Escenarios de Calidad

    -
    -
    -
    -
    Content
    -

    This section contains all quality requirements as quality tree with scenarios. The most important ones have already been described in section 1.2. (quality goals)

    -
    -
    -

    Here you can also capture quality requirements with lesser priority, -which will not create high risks when they are not fully achieved.

    -
    -
    -
    Motivation
    -

    Since quality requirements will have a lot of influence on architectural -decisions you should know for every stakeholder what is really important to them, -concrete and measurable.

    -
    -
    -
    Further Information
    -

    See Quality Requirements in the arc42 documentation.

    -
    -
    -
    -

    10.1. Quality Tree

    -
    -
    -
    -
    Content
    -

    The quality tree (as defined in ATAM – Architecture Tradeoff Analysis Method) with quality/evaluation scenarios as leafs.

    -
    -
    -
    Motivation
    -

    The tree structure with priorities provides an overview for a sometimes large number of quality requirements.

    -
    -
    -
    Form
    -

    The quality tree is a high-level overview of the quality goals and requirements:

    -
    +

    2.1. Usabilidad 💡

    • -

      tree-like refinement of the term "quality". Use "quality" or "usefulness" as a root

      -
      • -
    • -

      a mind map with quality categories as main branches

      +

      Escenario: Un nuevo usuario puede registrarse e iniciar a jugar en menos de 5 minutos después de su primer acceso al sitio web. La interfaz intuitiva y la guía de inicio rápido facilitan este proceso. 🚀

    -
    -

    In any case the tree should include links to the scenarios of the following section.

    -
    -
    -
    -

    10.2. Quality Scenarios

    -
    -
    -
    -
    Contents
    -

    Concretization of (sometimes vague or implicit) quality requirements using (quality) scenarios.

    -
    -
    -

    These scenarios describe what should happen when a stimulus arrives at the system.

    +

    2.2. Rendimiento ⚡

    +
    +
      +
    • +

      Escenario: El sistema responde a las solicitudes de los usuarios en menos de 2 segundos bajo condiciones normales de carga, asegurando una experiencia de juego fluida. 🏎️

      +
      • +
    -
    -

    For architects, two kinds of scenarios are important:

    +
    +

    2.3. Seguridad 🔒

    • -

      Usage scenarios (also called application scenarios or use case scenarios) describe the system’s runtime reaction to a certain stimulus. This also includes scenarios that describe the system’s efficiency or performance. Example: The system reacts to a user’s request within one second.

      +

      Escenario: Todos los datos personales de los usuarios están cifrados tanto en tránsito como en reposo, utilizando estándares de seguridad actuales para prevenir accesos no autorizados. 🔐

      • +
    +
    +
    +
    +

    2.4. Mantenibilidad 🔧

    +
    +
    • -

      Change scenarios describe a modification of the system or of its immediate environment. Example: Additional functionality is implemented or requirements for a quality attribute change.

      +

      Escenario: El sistema permite la adición de nuevas funcionalidades (como tipos de preguntas o temáticas) sin necesidad de una reestructuración mayor, promoviendo una arquitectura modular. 🛠️

    -
    -
    Motivation
    -

    Scenarios make quality requirements concrete and allow to -more easily measure or decide whether they are fulfilled.

    -
    -
    -

    Especially when you want to assess your architecture using methods like -ATAM you need to describe your quality goals (from section 1.2) -more precisely down to a level of scenarios that can be discussed and evaluated.

    -
    -
    Form
    -

    Tabular or free form text.

    +
    +

    2.5. Fiabilidad 🛡️

    +
    +
      +
    • +

      Escenario: En caso de fallo del sistema, este debe ser capaz de recuperarse y volver a estar operativo en menos de 5 minutos, garantizando una alta disponibilidad. 🔄

      +
      • +
    +
    +

    2.6. Portabilidad 🌍

    +
    +
      +
    • +

      Escenario: La aplicación web es compatible con los navegadores web más utilizados (Chrome, Firefox, Safari, Edge) en sus últimas dos versiones principales, asegurando un amplio acceso. 🌐

      +
      • +
    -
    -

    11. Risks and Technical Debts

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

    -
    -
    -
    +

    Risks and Technical Debts 🚀

    + ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
    RiesgoDescripción

    Tiempo de entrega ⏳

    Estamos limitados por el plazo de entrega y también por el tiempo que dedicaremos a trabajar en otras asignaturas.

    Proyecto grande y equipo grande 👥

    La coordinación y comunicación en un equipo grande pueden ser desafiantes.

    Diseño inadecuado o enfoque incorrecto 🎨

    La presencia de errores en etapas tempranas puede ser devastadora, ya que estas son cruciales. Un mal diseño detectado en etapas avanzadas podría ser irreparable, subrayando la importancia de una planificación y visión previsoras.

    Falta de familiaridad con las tecnologías 🔧

    El equipo comienza con conocimiento limitado sobre las herramientas necesarias, lo que puede resultar en un uso subóptimo de estas.

    Errores de implementación 🚨

    Errores no críticos en la lógica de negocio pueden permanecer ocultos por largo tiempo, afectando la calidad del sistema.

    Comunicación deficiente entre miembros 📢

    Las diferencias y desacuerdos pueden obstaculizar la colaboración efectiva, esencial para el éxito del equipo.

    Distribución desigual del trabajo ⚖️

    Una asignación desequilibrada puede sobrecargar a algunos miembros mientras deja a otros con menos responsabilidades.

    Reducción del tamaño del equipo 👥

    La salida inesperada de miembros puede desafiar la continuidad y el avance del proyecto, requiriendo adaptaciones rápidas y eficientes.

    -
    -
    -

    12. Glossary

    +

    1. Glossary

    @@ -1810,12 +1854,48 @@

    12. Glossary

    -

    <Term-1>

    -

    <definition-1>

    +

    React

    +

    Biblioteca de Javascript que se encarga en la creación de interfaces de usuario de una manera fácil. Es eficiente y se puede incorporar +al código de una forma sencilla.

    + + +

    Node.js

    +

    Entorno que usa Javascript, donde destaca en la creación de servidores web. Su programación es dirigida por eventos, es multi-plataforma, open-source +y soporta la concurrencia.

    + + +

    Microservicio

    +

    Enfoque arquitectónico, donde el software se va a dividir en servicios de tamaño pequeño, que estarán unidos por la intervención de API’s +(en nuestro caso Wikidata). Son rápidos, sencillos a la hora de su desarrollo y autonómos cuando estos están en ejecución.

    + + +

    API

    +

    O también Application Programming Interface, es un intermediario que ayuda a las diferentes aplicaciones del proyecto a posibilitar la comunicación +entre ellas. Favorece a la eficiencia y agilidad del funcionamiento de dichas aplicaciones.

    + + +

    MongoDB

    +

    Es uno de los tantos tipos de bases de datos, como MariaDB. Usa NoSQL, soporta múltiples lenguajes de programación y también soporta su funcionamiento en +gran variedad de sistemas operativos. Algo a tener en cuenta es que MongoDB realiza el guardado de datos de una forma distinta a la de las bases de datos de +tipo relacional, con tablas de datos, este lo guarda en archivos BSON, que es un derivado de JSON.

    + + +

    BSON

    +

    O Binary JSON, son los archivos que usa la base de datos MongoDB para almacenar los datos de una manera más ágil y sencilla que con las tablas. Una +curiosidad de este tipo de archivo es que no tiene un tipo de MIME definido, mientras que JSON sí que lo tiene.

    + + +

    Mongoose

    +

    Biblioteca que es encargada de crear una conexión con la base de datos MongoDB con el entorno de Node.js. Hace que el acceso y creación de los datos de MongoDB sea más fácil de realizar que con MongoDB en sí.

    + + +

    Docker

    +

    Aplicación que realiza el despliegue de cualquier aplicación en formato de contenedores, similares a los contenedores que tienen los barcos. Es open-source y permite que el proceso de desplegar una aplicación sea bastante más fácil y ordenado.

    -

    <Term-2>

    -

    <definition-2>

    +

    GitHub Actions

    +

    Plataforma que ayuda a automatizar los proyectos, haciendo posible el despliegue de estos desde el mismo Github. Soporta una gran variedad de lenguajes de +programación y sistemas operativos.

    @@ -1825,7 +1905,7 @@

    12. Glossary