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 🛠️
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 |
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 💰
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 🔧
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) 🗳️
5.1. Sistema general de caja blanca 📏
Este diagrama del sistema general muestra una descripción del sistema con los componentes básicos.
- 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 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.
-
-
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.
-
-
7. Vista de Despliegue 👀
7.1. Infraestructura Nivel 1 ☝️
EN DESARROLLO.
7.1.1. Diagrama de Vista General 🎀
EN DESARROLLO.
7.1.2. Motivacion 🤩
-
Disponibilidad: Se busca una aplicación que sea capaz de prestar servicio de manera continuada, con resistencia a fallos.
-
Eficiencia: Se busca una aplicación que ofreza un rendimiento óptimo para la generación de preguntas desde dispositivos con pocas capacidades.
-
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.
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.
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. |