About arc42

arc42, the template for documentation of software and system architecture.

Template Version 8.2 EN. (based upon AsciiDoc version), January 2023

Created, maintained and © by Dr. Peter Hruschka, Dr. Gernot Starke and contributors. See https://arc42.org.


1. Introducción y Objetivos (wiq_es04c) 🎇

El proyecto de wiq_es04c es un proyecto desarrollado en la asignatura Arquitectura del Software. Consiste en la creación de una aplicación 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.

La aplicación tendrá su base para las preguntas y las respuestas en Wikidata, la base de conocimiento editada en colaboración.

1.1. Requisitos Funcionales 🛠️

  • Los usuarios se deberán loggearse en la página; esto servirá para tener registro de una serie de parámetros, como puede ser las veces que se ha jugado.

  • Se podrán responder preguntas autogeneradas y se verá si han acertado o fallado, así como la respuesta correcta.

  • Las preguntas deberán ser respondidas en un tiempo límite.

  • Las preguntas seguirán la misma estructura: 1 pregunta correcta y 3 incorrectas, generadas automáticamente.

  • Los usuarios podrán consultar datos sobre su cuentas, como pueden ser las veces que han jugado o el número de preguntas que han acertado o fallado.

1.2. Atributos de Calidad 👑

Prioridad Objetivo Descripción

1

Usabilidad

Todos los usuarios deben poder usar la aplicación sin tener en cuenta sus limitaciones.

2

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.

3

Eficiciencia

Los tiempos entre operaciones han de ser asumibles.

4

Fiabilidad

Los datos usados en la aplicación deben ser los correctos.

5

Privacidad

Los datos sensibles de los usuarios deben estar restringidos al mismo usuario.

1.3. Stakeholders 👨‍👩‍👦‍👦

Role/Name Contact Expectations

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. Serán los encargados de la arquitectura, la documentación y la codificación.

Profesores

Jose Emilio Labra Gayo

Supervisores de los avances y encargados de evaluar la aplicación final y el desarrollo de la misma.

Usuario

Jugador de la aplicación

Personas que puedan interactuar tanto con el registro de usuarios como con el juego en sí y pueda completar correctamente una partida.

HappySw

Empresa responsable

Empresa contratada, cuyo trabajo sera el desarrollo del juego de la mano del equipo de desarrollo.

RTVE

Empleador

Interesados en la creacion del juego e impulsores de su creacion.

2. Restricciones de arquitectura ⛔

Restricciones

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.

3. Alcance del sistema y Contexto 💭

3.1. Contexto de negocio 💰

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

Agente externo Entradas Salidas

Usuario

Datos registro, datos login, respuesta a cada pregunta

Preguntas, histórico

Wikidata

Items (elementos) de Wikidata

Petición a la API de Wikidata

3.2. Contexto técnico 🔧

Diagrama de contexto técnico

4. Estrategia de Solución 📚

4.1. 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ó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):

Decision Como llegar

Usabilidad

La aplicacion seguira los principios basicos de usabilidad y estos seran testeados en diferentes escenarios.

Mantenibilidad

El sistema sera mantenible gracias a la mantenibilidad de sus subsistemas.

Eficiciencia

Para que la aplicacion sea rapida se usaran la base de datos y no se tendran que generar datos en caliente que pueden perjudicar a los tiempo de carga.

Fiabilidad

Todos los datos mostrados seran correctos y para esta comprobacion se usara la base de datos de Wikidata y sus entidades e ID’s asociados.

Privacidad

Los datos de los usuarios seran privados y no seran accesibles a ningun usuario.

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

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:

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.

5. Vista de Bloque de Construcción (EN desarollo) 🗳️

Building Block View

5.1. Sistema general de caja blanca 📏

Este diagrama del sistema general muestra una descripción del sistema con los componentes básicos.

Whitebox Overall System
Bloques de Construcción Contenidos
  • User Interface (Frontend)

  • Logica de Negocio(Backend)

  • Base datos

  • API Preguntas

Interfaces Importantes

EN DESARROLLO.

5.1.1. <Interfaz Gráfica>

UI Descripción

Proposito / Responsabilidad

La Interfaz de Usuario (UI) - Black Box 1 es responsable de proporcionar una interfaz interactiva y amigable para los usuarios finales. Sirve como el punto principal de interacción entre la aplicación y los usuarios, y facilita la experiencia general del usuario.

Interface(s)

Interfaz de Entrada del Usuario: Acepta la entrada del usuario a través de varios controles, como botones, formularios y campos de entrada. Interfaz de Visualización: Renderiza y muestra información al usuario, incluyendo datos, mensajes y elementos visuales.

Caracteristicas de Calidad / Rendimiento

Capacidad de Respuesta: La UI debe responder de manera rápida a las interacciones del usuario para garantizar una experiencia fluida y eficiente. Accesibilidad: Adhiere a los estándares de accesibilidad para proporcionar una experiencia inclusiva para los usuarios.

5.2. <Loggin>

Su función principal es permitir el acceso a los usuarios a la aplicación , y guardar los resultados de estos.

5.2.1. <Api de preguntas>

Su propósito es proporcionar preguntas de manera dinámica al usuario.

EN DESARROLLO.

5.2.2. <Lógica de negocio >

Se encargará de gestionar toda la programación necesaria de cara a la lógica.

EN DESARROLLO.

5.2.3. <Base de datos>

Dará almacenamiento al sistema de manera persistente y a los récords de los usuarios.

EN DESARROLLO.

5.3. Level 2

5.3.1. White Box <Interfaz de usuario>

En desarollo.

5.3.2. White Box <Login>

En desarollo.

5.3.3. White Box <Api preguntas>

En desarollo.

5.3.4. White Box <Logica de negocio >

En desarollo.

5.4. Level 3 En desarrollo.

5.4.1. White Box <_building block x.1_>

En desarollo.

5.4.2. White Box <_building block x.2_>

En desarollo.

5.4.3. White Box <_building block y.1_>

En desarollo.

6. Vista de Ejecución 📽️

6.1. Escenario de Ejecucion1️⃣

Diagrama de secuencia plantuml

Diagrama de secuencia con plantuml (se contempla sólo el uso correcto de la aplicación)

6.2. Escenario de Ejecucion2️⃣

  • 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. Escenario de Ejecucion3️⃣

  • 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

7. Vista de Despliegue 👀

7.1. Infraestructura Nivel 1 ☝️

EN DESARROLLO.

7.1.1. Diagrama de Vista General 🎀

EN DESARROLLO.

7.1.2. Motivacion 🤩

  1. Disponibilidad: Se busca una aplicación que sea capaz de prestar servicio de manera continuada, con resistencia a fallos.

  2. Eficiencia: Se busca una aplicación que ofreza un rendimiento óptimo para la generación de preguntas desde dispositivos con pocas capacidades.

  3. Cumplimiento de Requisitos Regulatorios: El uso de Wikidata como fuente de datos en nuestra aplicación está respaldado por la necesidad de cumplir con requisitos regulatorios y normativos específicos. Esta elección se basa en las siguientes consideraciones:

    • Caracteristicas de Calidad y/o Rendimiento:

      • Rendimiento: Se busca que la aplicación tenga un rendimiento óptimo en dispositivos móviles y tablets.

      • Adaptabilidad: La aplicación tiene que ser adaptable en diferentes dispositivos para así poder garantizar su uso.

EN DESARROLLO.

7.1.3. Mapeado de Bloques de Construccion a Infraestructura 📜::

EN DESARROLLO.

7.2. Infrastructure Level 2 ☝️

EN DESARROLLO.

7.2.1. Elemento 1 de insfraestructura

EN DESARROLLO.

8. Conceptos Transversales 🧭

Estos conceptos todavía no han sido aprobados ni implementados, pero dan una idea general del proyecto.

8.1. Modelo de Dominio 🗺️

Esta es una primera versión del modelo de dominio muy simple, para hacerse una idea como funcionará la aplicación.

Modelo de dominio simple provisional

8.2. Experiencia de Usuario 👨‍🦰

El usuario será capaz de interactuar con una aplicación web, donde se podrá registrar y jugar al juego de manera sencilla.

8.3. Seguridad 🔒

En Desarrollo.

8.4. Arquitectura y Patrones de Diseño 📒

En Desarrollo.

8.5. Desarrollo ⚙️

En Desarrollo.

8.6. Operaciones 🔢

En Desarrollo.

9. Decisiones de Arquitectura 🗣️

Los enlaces proporcionan las decisiones de arquitectura via GitHub.

  • ADR 01 ‐ Diseño de BD para Generación de Preguntas

10. Requisitos de Calidad 🌟

10.1. Árbol de Calidad 🌳

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:

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

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

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

Árbol de Calidad

10.2. Escenarios de Calidad 🕹️

10.2.1. Usabilidad

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

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

10.2.3. Seguridad

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

10.2.4. Mantenibilidad

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

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

10.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. Riesgos y Deuda Técnina 🚀

Riesgo Descripció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.

Deuda Técnina Descripción

Uso del proyecto base creado por los profesores

Para no tener que realizar la creacion del proyecto hemos decidido usar el proyecto ya creado. Esto implica tener que revisar codigo ya creado y entender su funcionamiento, asi como ampliarlo con codigo propio, dando lugar a errores y perdidas de tiempo. Tambien requiere tener que aprender tecnologias nuevas y como usarlas.

Uso de React

El uso del framework nos puede facilitar el desarrolo en algunas etapas, pero nos lo puede complicar al no estar familiarizados con esta tecnologia y todas sus características.

12. Glosario ⁉️

Término Definicion

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

También llamado 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

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

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.

MySql

Es un sistema de gestión de bases de datos relacional de código abierto ampliamente utilizado que se destaca por su velocidad, confiabilidad y facilidad de uso. Permite a los usuarios almacenar, organizar y recuperar datos de manera eficiente a través de consultas estructuradas utilizando el lenguaje estándar de SQL. Es compatible con una variedad de plataformas y se utiliza en una amplia gama de aplicaciones.