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.

Note

This version of the template contains some help and explanations. It is used for familiarization with arc42 and the understanding of the concepts. For documentation of your own system you use better the plain version.

1. Introducción y Metas

Describe los requerimientos relevantes y las directrices que los arquitectos de software y el equipo de desarrollo deben considerar. Entre estas se incluyen:

  • Objetivos empresariales subyacentes, características esenciales y requerimientos funcionales para el sistema

  • Metas de calidad para la arquitectura

  • Las partes interesadas pertinentes y sus expectativas

El propósito de este proyecto es mejorar una aplicación existente de preguntas y respuestas, donde los usuarios deben responder correctamente entre varias opciones, de las cuales solo una es la correcta. La aplicación se basa en imágenes, presentando a los jugadores diversas temáticas sobre las cuales deberán responder preguntas relacionadas con el contenido visual.

Como nueva funcionalidad, este proyecto integrará un modelo de lenguaje (LLM) que permitirá ofrecer pistas a los jugadores. Estas pistas estarán basadas en la imagen y en el contexto de la pregunta, ayudando a los usuarios a deducir la respuesta correcta sin revelar directamente la solución. Esto no solo aumentará la accesibilidad y la experiencia del usuario, sino que también fomentará el aprendizaje y el razonamiento.

1.1. Requerimientos Funcionales

Contenido

Descripción corta de los requerimientos funcionales, motivaciones, extracto (o resumen) de los requerimientos. Ligar a los documentos de requerimientos determinados (Con número de versión e información de donde encontrarla).

Motivación

Desde el punto de vista de los usuarios finales un sistema es creado o modificado para mejorar el soporte a una actividad de negocio o incrementar su calidad

Forma

Descripción corta textual, probablemente en un formato de caso de uso tabular. Si existen documentos de requerimientos esta vista debe referir a dichos requerimientos

Mantenga estos extractos tan cortos como sea posible. Encuentre el balance entre la legibilidad y la redundancia de este documento respecto a los documentos de requerimientos que se encuentren relacionados.

Más infromación

Ver Introduction and Goals en la documentación de arc42.

Los requerimientos funcionales describen que debe hacer el sistema.

  1. Interfaz de usuario

    1. El sistema contará con un frontend web

    2. El frontend mostrará imágenes

    3. El frontend mostrará respuestas

  2. Sistema de preguntas y respuestas

    1. El sistema generará automáticamente preguntas a partir de Wikidata

    2. El sistema creará una respuesta correcta para cada pregunta

    3. El sistema generará respuestas incorrectas para cada pregunta

    4. Los usuarios podrán contestar a las preguntas dentro de un plazo de tiempo determinado

    5. El sistema debe garantizar que no se repitan preguntas en una misma sesión de juego

  3. Sistema de pistas

    1. El sistema contará con un sistema de pistas

    2. El sistema permitirá a los usuarios solicitar pistas de forma opcional, sin obligarles a usarlas

    3. El sistema de pistas permitirá a los usuarios obtener pistas sobre las imágenes

    4. Las pistas se generarán utilizando un LLM

    5. El sistema generará las pistas mediante la información de Wikidata

  4. Registro e historial del usuario

    1. Los usuarios deberán poder registrarse

    2. Los usuarios registrados deberán poder consultar su histórico de participación

    3. El histórico mostrará

      1. Número de juegos jugados

      2. Preguntas falladas

      3. Pregunatas acertadas

  5. APIs

    1. El sistema permitirá acceder a la información del usuario mediante una API

    2. El sistema permitirá acceder a la información de las preguntas mediante una API

1.2. Requerimientos No Funcionales

Los requerimientos no funcionales describen cómo debe comportarse el sistema y aspectos técnicos.

  1. Disponibilidad y despliegue

    1. La web deberá estar desplegada

    2. La web deberá estar disponible en la web

  2. Rendimiento y tiempos de respuesta

    1. El sistema deberá generar automáticamente las preguntas en tiempo razonable (<1s)

    2. Las pistas deben generarse en un tiempo óptimo para no afectar la experiencia del usuario

    3. Los tiempos de carga del sistema deben ser mínimos para garantizar una experiencia fluida

  3. Escalabilidad y mantenimiento

    1. El sistema debe poder escalar para soportar un gran número de usuarios concurrentes

    2. El uso del LLM y Wikidata debe ser eficiente en términos de consumo de recursos

    3. La arquitectura del sistema debe ser modular, permitiendo la fácil actualización de preguntas, pistas o la integración de otros modelos de IA en el futuro

  4. Seguridad y acceso

    1. El sistema debe asegurar que los datos de los usuarios estén protegidos

    2. Solo los usuarios autenticados podrán acceder a su historial de participación

    3. La API debe contar con mecanismos de autenticación y control de acceso

  5. Accesibilidad y Usabilidad

    1. El diseño debe ser intuitivo y accesible

    2. La interfaz debe ser responsiva

1.3. Metas de Calidad

Contenido

Las tres metas de calidad principales (o hasta cinco) cuyo cumplimiento sea de la mayor importancia para las principales partes interesadas. Nos referimos a las metas de calidad para la arquitectura. No confundir con las metas del proyecto. No necesariamente son idénticas.

Considera este resumen de posibles temas (basado en la norma ISO 25010):

Categories of Quality Requirements
Motivación

Debe conocer las metas de calidad de las partes interesadas más importantes, ya que ellos influenciarán las decisiones arquitectónicas principales. Asegúrese de ser muy concreto con las descripciones, evitando buzzwords. Si como arquitecto no conoce la calidad de su trabajo, será juzgado…​

Forma

Una tabla con metas de calidad y escenarios concretos, ordenados por prioridades

Caracteristica de calidad Prioridad Motivación Escenario

Usabilidad

Alta

El sistema debe de ser intuitivo para que todos los usuarios usen la aplicacion.

Si un usuario no entiende la aplicacion y no encuentra lo que necesita es posible que este deje de utilizar nuestra aplicacion

Rendimiento

Alta

La aplicacion deberá realizar la mayoria de las peticiones dentro de un marco de tiempo razonable y no debera verse afectado cuando haya varios usuarios utilizando el sistema.

Si en algun momento un usuario o varios no reciben respuesta del sistema dentro de un marco de tiempo razonable es posible que piensen que no funciona y dejen de usarla

Fiabilidad

Alta

El sistema debe de estar disponible para el usuario la mayoria de las veces que el usuario quiera utilizarla (> 99% de las veces)

Si un usuario quiere entrar en el sistema pero este no esta disponible en varias ocasiones en las que lo intente esto podria llevarnos a que ese usuario no vuelva a intentarlo cuando si que este disponible perdiendo un potencial usuario

Compatibilidad

Media

El sistema debera poder utilizarse en todos los navegadores, ya sean Chrome, Firefox…​

Los usuarios usan diversos buscadores, si un usuario que dispone de un Mac intenta acceder a nuestro sistema pero este o no funciona o se encuentra todo descolocado el usuario es probable que no lo intente con otro buscador y que perdamos a un usuario

1.4. Partes interesadas (Stakeholders)

Contenido

Vista detallada de las partes intersadas del sistema, es decir, toda persona, rol u organización que:

  • Debe conocer la arquitectura

  • Debe estar convencida de la arquitectura

  • Tiene que trabajar con la arquitectura o con el código

  • Necesitan la documentación de la arquitectura para su trabajo

  • Intervienen en las decisiones acerca del sistema o su desarrollo

Motivación

Debe conocer a todas las partes involucradas en el desarrollo del sistema o que son afectadas por el sistema. De otro modo, se topará con sorpresas desagradables durante el proceso de desarrollo. Estas partes relacionadas o stakeholders determinarán la extensión y el nivel de detalle del trabajo y sus resultados

Forma

Tabla con nombres de los roles, personas, y sus expectativas con respecto a la arquitectura y su documentación

Rol/Nombre Contacto Expectativas

RTVE

Equipo de RTVE

Esperamos que RTVE nos facilite la suficiente informacion de que se espera de la aplicacion

Equipo de desarrollo

Alberto Martinez Olivar - uo282069@uniovi.es
Pablo Jose Perez Diaz - uo282440@uniovi.es
Marcos Gonzalez Garcia - uo282587@uniovi.es
Javier Monte Guillem - uo283951@uniovi.es
Pelayo Palacios Suarez - uo274408@uniovi.es
Celia Bobo Rodriguez Noriega - uo222898@uniovi.es

Se espera que el grupo de desarrollo realice todas las actividades asignadas a tiempo y en caso de no realizarlas en el plazo asignado que esten finalizadas lo antes posible. Tambien se espera que el equipo de desarrollo aprenda lo suficiente de las tecnlogias escogidas para que puedan realizar correctamente el sistema deseado.

Empathy

https://www.empathy.ai/

Esperamos que empathy mantenga disponible su LLM lo maximo posble para que podamos realizar este proyecto con su tecnologia.

Usuarios

Todo usuario que utilice la aplicación

Se espera que los usuarios ayuden a los desarrolladores avisando en caso de encontrar algun error o bug para poder solucionarlos rapidamente.

Profesores

Jose Emilio Labra Gayo - labra@uniovi.es
Irene Cid Rico - cidirene@uniovi.es
Diego Martín Fernández - martinfdiego@uniovi.es
Pablo González González - gonzalezgpablo@uniovi.es

Son los encargados de evaluar el proyecto realizado por el equipo de desarrollo, asi como la organización del grupo, y el trabajo cooperativo de todos los miembros del equipo.

2. Restricciones de la Arquitectura

Contenido

Cualquier requerimiento que restrinja a los arquitectos de software en la libertad de diseño y la toma de decisiones sobre la implementación o el proceso de desarrollo. Estas restricciones a veces van más allá de sistemas individuales y son válidos para organizaciones y compañías enteras.

Motivación

Los arquitectos deben saber exactamente sus libertades respecto a las decisiones de diseño y en dónde deben apegarse a restricciones. Las restricciones siempre deben ser acatadas, aunque en algunos casos pueden ser negociables.

Forma

Tablas de restricciones con sus explicaciones. Si se requiere, se pueden subdividir en restricciones técnicas, organizacionales y/o políticas y convenciones (por ejemplo, guías de versionado o programación, convenciones de documentación o nombrado).

Further Information

Consulta Architecture Constraints

Antes de detallar la arquitectura del sistema, es fundamental definir las restricciones que condicionan su diseño e implementación. Estas restricciones pueden derivar de decisiones tecnológicas, organizativas, limitaciones del negocio o requisitos legales que deben cumplirse. A continuación, se presentan los principales aspectos que influirán en el desarrollo del sistema.

2.1. Restricciones Tecnológicas

Restricción Explicación

Wikidata

La información de las preguntas será generada automáticamente a partir de los datos de Wikidata.

LLM

Será posible interactuar con la aplicación en cada pregunta para poder obtener pistas sobre las mismas. Para ello se utilizará un modelo de lenguaje (LLM).

Frontend

El sistema contará al menos con un frontend web que mostrará las imágenes, preguntas y respuestas.

Despliegue

La web deberá estar desplegada y accesible a través de la Web.

Pruebas

El proyecto deberá incluir distintos tipos de pruebas para garantizar el resultado esperado y un producto de calidad (pruebas de aceptación, de carga, cobertura, etc.).

2.2. Restricciones Organizativas

Restricción Explicación

Tiempo

El proyecto debe ser desarrollado antes de la fecha límite de entrega de este cuatrimestre. El tiempo estará repartido en 2 horas de trabajo presencial en clase de laboratorio cada semana y trabajo individual.

Tamaño del Equipo

El equipo está compuesto por 6 miembros, por lo que será necesario mantener una buena cooperación durante el desarrollo del proyecto.

Reuniones

El equipo se reunirá al menos una vez a la semana para poner en común el trabajo realizado y organizar futuras tareas.

Actas

En cada reunión se deberá crear un acta donde queden reflejados los miembros del equipo que participaron, las decisiones que han sido tomadas durante la sesión y la organización y reparto de tareas para la semana siguiente.

GitHub

Se utilizará GitHub para coordinar el trabajo del proyecto, realizar un seguimiento de los cambios y gestionar el flujo de trabajo.

2.3. Convenciones

Restricción Explicación

ARC42

La documentación debe seguir la estructura de ARC42.

Idioma

El proyecto será desarrollado en español.

3. Alcance y Contexto del Sistema

Contenido

El alcance y contexto del sistema - como lo sugiere el nombre - delimita al sistema (es decir, el alcance) de todos sus socios de comunicación (Usuarios y sistemas vecinos, es decir, el contexto del sistema). Con ello se especifican las interfaces externas.

Si es necesario, diferenciar el contexto de negocio (Entradas y salidas específicas del dominio) del contexto técnico (canales, protocolos, hardware).

Motivación

Las interfases de dominio y las interfases técnicas a los socios de comunicación son de los aspectos más críticos del sistema. Se debe asegurar el entendimiento de ellos.

Forma

Varias opciones:

  • Diagramas de contexto

  • Listas de socios de comunicación y sus interfases.

3.1. Contexto de Negocio

Este apartado indica cómo se va a comunicar la aplicación con los diferentes actores y servicios:

Contenido

La especificación de todos los socios de comunicación (usuarios, sistemas, …​) con explicaciones de las entradas y salidas específicas del dominio o interfases. Opcionalmente puede agregar formatos específicos de dominio o protocolos de comunicación

Motivación

Todas las partes interesadas deben entender que datos son intercambiados con el ambiente del sistema.

Forma

Cualquier forma de diagramas que muestren al sistema como una caja negra y especifiquen las interfases de dominio a los socios de comunicación.

De manera alternativa (o adicional) se puede utilizar una tabla. El título de la tabla es el nombre del sistema, las tres columnas contienen el nombre del socio de comunicación, las entradas y las salidas

Contexto negocio

  • Usuario

Persona real que utilizará la aplicación. Interactuará con ella eligiendo una de las múltiples respuestas que se le presentarán según la imagen utilizada.

  • Wikidata

Base de datos general de donde obtendremos las imágenes y datos relacionados con ellas. La aplicación se comunica y obtiene información de Wikidata a través de su API.

  • Mistral

Modelo de Lenguaje creado por Empathy. Es el modelo de lenguaje que usaremos para apoyar al usuario en caso de que necesite pistas.

3.2. Contexto Técnico

Este apartado indica cómo las diferentes partes de la aplicación se comunican entre sí:

Contenido

Las interfases técnicas (medios de transmisión y canales) enlanzando al sistema con su ambiente. De manera adicional el mapeo de las entradas/salidas específicas del dominio a los canales, es decir, una explicación acerca de que entrada/salida utiliza cual canal.

Motivación

Muchas partes relacionadas realizan decisiones arquitectónicas basadas en las interfases técnicas entre el sistema y su contexto. Especialmente los diseñadores de infraestructura o hardware deciden estas interfases técnicas.

Forma

Por ejemplo, diagramas UML de despligue describiendo los canales a sistemas vecinos, junto con una tabla de mapeo mostrando las relaciones entre los canales y las entradas/salidas.

Contexto tecnico

Participantes

Vía de comunicación

Motivo de la comunicación

Usuario - Webapp

HTTP

Interacción con la aplicación

Webapp - Gateway

HTTP

Intercambio de datos entre Frontend y Backend

Gateway - User service

HTTP

Registro

Gateway - Auth service

HTTP

Inicio de sesión

Gateway - LLM service

HTTP

Chat en tiempo real

Gateway - Query service

HTTP

Interacción con Wikidata

Query service - Wikidata

HTTPS

Obtención de imágenes y datos

User service - Mongo DB

HTTP

Registro

Auth service - Mongo DB

HTTP

Inicio de sesión

LLM service - Mistral

HTTPS

Chat en tiempo real

4. Estrategia de solución

Contenido

Un resumen corto y explicación de las estrategias y decisiones fundamentales para la solución que le dan forma a la arquitectura del sistema. Estas incluyen: * Decisiones tecnológicas * Decisiones acerca de la descomposición a alto nivel de un sistema, por ejemplo, el uso de algún patrón de diseño o de arquitectura. * Decisiones en como alcanzar metas de calidad claves * Decisiones organizacionales relevantes, como el seleccionar un proceso de desarrollo o delegar ciertas tareas a terceros. .Motivación Estas decisiones son las piedras angulares de la arquitectura. Son la base de muchas otras decisiones detalladas o reglas de implementación. .Formato Realice la explicación de las deciciones clave de manera breve.

Justifique las decisiones y porque se realizaron de esa manera, basado en el planteamiento del problema, las metas de calidad y restricciones clave. Refierase a los detalles en las secciones posteriores.

Más información

Vea [Solution Strategy en la documentación de arc42.

4.1. Decisiones tecnológicas

4.1.1. Lenguajes y Frameworks

  • TypeScript: lenguaje de programación utilizado para el desarrollo de aplicaciones web, tanto del lado del cliente como del servidor. Elegimos este lenguaje en vez de otras alternativas debido a su tipado dinámico, que facilita la detección de errores, además de la facilidad de usarlo tanto con Node como con React.

  • React: biblioteca de JavaScript ampliamente utilizada para construir interfaces de usuario dinámicas. Elegimos usarla en el proyecto ya que permite la reutilización de componentes, y, al ser muy utilizada en la actualidad, hay mucha documentación y ejemplos disponibles.

  • Express: es un framework minimalista y flexible para aplicaciones web en Node.js. Permite construir APIs y servidores web de manera sencilla y eficiente. Elegimos este framework por su sencillez y rapidez.

4.1.2. Backend y APIs

  • Node: entorno de ejecución de JavaScript en el servidor. Lo elegimos debido a que al ejecutarse en el servidor y no en el cliente es más eficiente para aplicaciones de tiempo real.

  • API SPARQL: API que permite obtener datos de WikiData mediante consultas parametrizables. Elegimos esta API debido a que otras alternativas no permiten consultas lo suficientemente específicas para generar las preguntas del juego.

  • Mistral: modelo LLM de propósito general, diseñado para adaptarse a diversas tareas. Escogimos Mistral debido a que queremos participar en el concurso de Empathy, y consideramos es la más adecuada para el tipo de preguntas que se realizarán en la aplicación. Además, hay muchos recursos educativos que facilitan su uso e integración en proyectos.

4.1.3. Despliegue

  • Azure: plataforma de computación en la nube que ofrece distintos servicios. En nuestro caso, la utilizaremos para tener una máquina virtual en la que ejecutar la aplicación. Escogimos Azure para esto ya que ya tenemos experiencia con ella, además de que tenemos crédito para Azure proporcionado por la universidad.

  • Docker: herramienta para construir aplicaciones portátiles con todas sus dependencias. Escogimos Docker por la flexibilidad para desplegar aplicaciones en distintas plataformas.

4.1.4. Bases de datos

  • MongoDB: sistema de gestión de bases de datos NOSQL que utiliza esquemas flexibles. Decidimos utilizarlo porque se ajusta a nuestras necesidades y el despliegue ya estaba configurado para él.

4.1.5. Herramientas de documentación

  • PlantUML: herramienta de creación de diagramas por texto. Decidimos utilizarlo para crear los diagramas de la documentación debido a su simplicidad.

4.1.6. Decisiones descartadas

  • Microsoft SQL Server: sistema de Gestión de Bases de Datos SQL de Microsoft. Inicialmente lo habíamos elegido porque que es la única opción que ofrece Azure para crear una base de datos en la nube, pero finalmente decidimos que MongoDB era una mejor opción puesto que el despliegue ya estaba configurado para esa base de datos.

4.2. Decisiones sobre cómo alcanzar objetivos clave de calidad

  • Usabilidad: las interfaces serán intuitivas, basándose en aplicaciones ya existentes, de modo que cualquier usuario pueda utilizarlas sin experiencia previa. Además, la comunicación con el LLM también deberá ser sencilla, de forma que todos los usuarios puedan utilizar la funcionalidad de las pistas sin tener conocimientos acerca cómo utilizar una IA.

  • Rendimiento: para mejorar el rendimiento de la aplicación se reducirán lo máximo posible el número de llamadas a la API de SPARQL para obtener los datos de WikiData y generar las preguntas.

  • Fiabilidad: con Azure podemos tener la aplicación desplegada en casi todo momento, si bien hay que tener en cuenta que las dependencias de servicios externos como MongoDB, la API de SPARQL, WikiData o la API del LLM pueden reducir la disponibilidad.

  • Compatibilidad: la aplicación deberá funcionar en los navegadores más utilizados (Chrome, Firefox, Edge…​). Para ello, evitaremos usar tecnologías específicas de un navegador concreto, así como aquellas que no estén disponibles para todos los navegadores estándar.

4.3. Decisiones organizativas

  • GithHub:

    • Issues: decidimos crear una issue por funcionalidad a desarrollar, asignando cada una a una única persona y en casos de funcionalidades más complejas a dos personas.

    • Ramas de Github: para el control de versiones decidimos utilizar ramas distintas por cada issue de GitHub a realizar, de modo que sólo haya una única persona trabajando sobre una misma rama. En caso de que varias personas trabajasen en una misma issue, decidimos crear también una rama por persona.

    • Pull Request: decidimos utilizar Pull Request para la revisión del código, asignando dos revisores por miembro del equipo para asegurar tanto una mayor calidad del código como que no sólo el desarrollador de una funcionalidad concreta conozca el código de esa parte.

  • Whatsapp: utilizamos Whatsapp como medio de comunicación entre los miembros del equipo por la comunicación instantánea que permite.

  • Reuniones semanales: una vez a la semana nos reunimos entre todos los miembros del equipo para comunicar el trabajo realizado a lo largo de la semana y comentar problemas encontrados.

5. Vista de Bloques

Contenido

La vista de bloques muestra la descomposición estática del sistema en bloques de construcción (módulos, componentes, subsistemas, clases, interfases, paquetes, bibliotecas, marcos de desarrollo, capas, particiones, funciones, macros, operaciones, estructuras de datos,…) así como sus dependencias (relaciones, asociaciones,…)

Esta vista es obligatoria para cualquier documentación de arquitectura. Es la analogía al plano de una casa.

Motivación

Mantener una visión general de su código fuente haciendo su estructura comprensible de manera abstracta.

Esto permite comunicar a las partes interesades en un nivel abstracto sin entrar en detalles de implementación.

Forma

La vista de bloques comprende una colección jerárquica de cajas negras y cajas blancas (ver figura de abajo) y sus descripciones.

Hierarchy of building blocks

Vista General comprende la descripción de Caja Blanca del sistema en general junto con las descripciones de Caja Negra de todos los bloques contenidos.

Nivel 2 hace zoom a los bloques de construcción del Nivel 1. Entonces contiene la descripción de Caja Blanca de los bloques de construcción selecionadas del nivel 1,junto con las descripciones de caja negra de sus bloques de construcción internas.

Más Información

Ver Building Block View en la documentación arc42.

5.1. Visión General

Aquí se describe la descomposición del sistema en general usando la siguiente plantilla de caja blanca. Contiene:

  • Un diagrama general

  • La motivación para la descomposición

  • Descripciones de caja negra de los bloques de construcción contenidos. Para estos se ofrecen las siguientes alternativas:

    • Usar una tabla para una revisión pragmática y corta de todos los bloques de construcción contenidos y sus interfaces

    • Usar una lista de descripciones de caja negra de los bloques de construcción acorde a la plantilla de caja negra (ver abajo). Dependiendo de la herramienta utilizada, esta lista podría constar de sub-capítulos (en archivos de texto), sub-páginas (en un wiki) o elementos anidados (en una herramienta de modelado).

  • Interfases importantes, que no están explicadas en las plantillas de caja negra de un bloque de construcción, pero que son muy importantes para entender la caja blanca. En el peor de los casos se deberá especificar y desribir la sintaxis, semántica, protocolos, manejo de errores, restricciones, versiones, calidades, compatibilidades necesarias, entre otras. En el mejor de los casos bastará con ejemplos o la firma de los mismos.

El siguiente diagrama muestra una visión general de los principales componentes del sistema y sus interacciones:

Vision general

5.1.1. Componentes que intervienen:

Componente Descripción

User

Representa el usuario final de la aplicación. Este interactua con el sistema jugando al juego de preguntas

WiChat

Es el componente principal de la aplicación. Este maneja la parte lógica del juego, la creación de preguntas a través de consultas a la API de wikidata, el envío y consultas de resultados a la base de datos, la interacción con el ranking y el login de la aplicación

Wikidata

Es un servicio externo a la aplicación, utilizado por esta, para obtener información y generar las preguntas.

Mistral

Es un servicio externo a la aplicación, utilizado por esta, para obtener pistas a partir de la información de wikidata.

5.2. Nivel 2

Visión del segundo nivel del proyecto

Nivel 2

5.2.1. Componentes que intervienen:

Componente Descripción

User

Representa el usuario final de la aplicación. Este interactua con el frontend del sistema.

Frontend

Es el componente responsable de la iterfaz de usuario con la que el usuario final llevará a cabo la interacción. Se comunica con el backend para llevar a cabo el juego.

Backend

Es el componente que manejala parte lógica del juego. También se encarga de almacenar y recuperar los datos de la base de datos. Utiliza las APIs wikidata y la correspondiente al llm.

MongoDB

Sistema de base de datos NoSQL diseñado para almacenar grandes volúmenes de datos de manera flexible y escalable.

Wikidata

Base de conocimiento colaborativa y estructurada. Almacena datos y permite la utilización de estos al proyecto. Estos datos se obtienen a través de su API.

Mistral

Modelo de lenguaje que permite a la aplicación interactuar con él a través de su API.

5.3. Nivel 3: Backend

Visión del backend del proyecto

Backend

5.3.1. Componentes que intervienen en el backend:

Componente Descripción

Gateway

Punto de acceso al backend de la aplicación. A traves de ella, el frontend se comunicará con las distintas partes del backend que intervienen en la aplicación.

User service

Servicio utilizado para el registro de nuevos usuarios en la aplicación.

Auth service

Servicio utilizado para la autenticación de usuarios en la aplicación.

LLM service

Servicio de modelo de lenguaje, utilizado para la generación de pistas a partir de la información obtenido de wikidata.

6. Vista de Ejecución

Contenido

La vista de ejecución describe el comportamiento concreto y las interacciones de los bloques del sistema en forma de escenarios de las siguientes áreas:

  • casos de uso o características importantes: ¿cómo los ejecutan los bloques?

  • interacciones en interfaces externas críticas: ¿cómo cooperan los bloques con los usuarios y sistemas vecinos?

  • operación y administración: lanzamiento, inicio, detención

  • escenarios de error y excepciones

Nota: El criterio principal para la elección de los escenarios posibles (secuencias, flujos de trabajo) es su relevancia arquitectónica. No es importante describir un gran número de escenarios. En su lugar, deberías documentar una selección representativa.

Motivación

Debes comprender cómo (instancias de) los bloques de construcción de tu sistema realizan su trabajo y se comunican en tiempo de ejecución. Principalmente capturarás escenarios en tu documentación para comunicar tu arquitectura a las partes interesadas que tienen menos disposición o capacidad para leer y entender los modelos estáticos (vista de bloques, vista de despliegue).

Formato

Existen muchas notaciones para describir escenarios, por ejemplo:

  • lista numerada de pasos (en lenguaje natural)

  • diagramas de actividad o diagramas de flujo

  • diagramas de secuencia

  • BPMN o EPCs (cadenas de procesos de eventos)

  • máquinas de estados

  • …​

Más información

Observa Runtime View en la documentacion de arc42.

6.1. <Registro de nuevo usuario>

Este diagrama de secuencia representa el flujo que tendra la peticion de un usuario para registrarse como nuevo usuario.

Registro de nuevo usuario

6.2. <Inicio de sesion>

Este diagrama de secuencia hace referencia a las llamadas entre los distintos objetos de la aplicacion web para que un usuario inicie sesion.

Inicio de sesion

6.3. <Generacion de pregunta y respuestas>

Este driagrama de secuencia resume el flujo de la aplicacion web para generar las preguntas y respuestas una vez iniciado el juego por parte del usuario.

Generacion de pregunta

6.4. <Generacion de una pista>

Este diagrama de secuencia representa como se genera una pista para una pregunta determinada tras ser solicitada por el usuario que esta jugando.

Generacion de pista

6.5. <Consulta de estadisticas>

Este diagrama de secuencia representa el flujo de la peticion de un usuario que haya iniciado sesion en el sistema y quiera saber sus estadisticas de juego.

Consulta de estadisticas

7. Vista de despliegue

Contenido

La vista de despliegue describe:

  1. La infraestructura técnica usada para ejecutar el sistema, con elementos de infraestructura como locaciones geográficas, ambientes, computadoras, procesadores, canales y topologías de red así como otros elementos de infraestructura.

  2. El mapeo de los bloques de construcción (software) en dichos elementos de infraestructura.

Comúnmente los sistemas son ejecutados en diferentes ambientes, por ejemplo, ambiente de desarrollo, de pruebas, de producción. En dichos casos deberían documentarse todos los ambientes relevantes.

Deberá documentarse la vista de despliegue de manera especial cuando el software se ejecute como un sistema distribuido con mas de una computadora, procesador, servidor o contenedor o cuando se diseñen los procesadores y chips de hardware propios.

Desde una perspectiva de software es suficiente con capturar los elementos de la infraestructura necesarios para mostrar el despliegue de los bloques de construcción. Los arquitectos de hardware pueden ir más alla y describir la infraestructura a cualquier nivel de detalle que requieran.

Motivación

El software no corre sin haardware. El hardware subyacente puede influenciar el sistema o algunos conceptos entrecruzados. Por ende, es necesario conocer la infraestructura.

Forma

Quizá el más alto nivel de diagrama de despliegue esté contenido en la sección 3.2. como contexto técnico con la propia infraestructura como UNA caja negra. En esta sección se deberá realizar un acercamiento a ésta caja negra utilizando diagramas de despliegue adicionales:

  • UML provee diagramas de despliegue para expresar la vista. Uselos, probablemente con diagramas anidados.

  • Cuando las partes relacionadas de Hardware prefieran otro tipo de diagramas además de los diagramas de despliegue, permítales usar cualquier tipo que permita mostrar los nodos y canales de la infraestructura.

Más información

Ver Deployment View en la documentación de arc42.

7.1. Nivel de Infraestructura 1

Describa (Usualmente en una combinación de diagramas, tablas y texto):

  • La distribución del sistema en múltiples ubicaciones, ambientes, computadoras, procesadores, …​ así como las conexiones físicas entre ellos

  • La motivación o justificación de importancia para la estructura de despliegue

  • Características de Calidad y/o rendimiento de la infraestructura

  • El mapeo de los artefactos de software a los elementos de la infraestructura.

Para múltiples ambientes o despliegues alternativos copie esta sección para todos los ambientes relevantes.

arquitectura
Motivación

En el anterior diagrama podemos ver que cada componente se encuentra encapsulado en un Docker que son contenedores en los que se encapsula el software para simplificar su despliegue. La interfaz de nuestra aplicación se encuentra en Webapp donde el usuario se conecta mediante un buscador desde su dispositivo. La aplicación se conecta con los servicios internos de la aplicación mediante Gatewayservice que distribuye las llamadas de la aplicación entre el resto de los servicios de la misma. Nuestra aplicacion tambien cuenta con una base de datos en la que almacenamos la información de los usuarios y de sus autenticaciones

Características de calidad/rendimiento

Gracias al uso de docker nuestro sistema es portable (podriamos cambiarlo de maquina y seguiria funcionando sin muchos cambios) y escalable ya que podemos crear nuevos contenedores y nuevas instancias en el caso de que sean necesarias. Tambien gracias a que almacenamos la base de datos dentro de la misma maquina que nuestra aplicación las llamadas a la misma seran mas rapidas que si se encontrase fuera de la misma.

Mapeo de los Bloques de Construcción a Infraestructura
Bloque de Construcción Infraestructura

WebApp

Es el frontend de nuestra aplicación

BBDD MongoDB

Es la base de datos donde almacenaremos la información de los usuarios

Gatewayservice

Es el servicio mediante el cual llamamos al resto de los servicios de la aplicacion, tanto internos como externos

authservice

Es el servicio de autenticaciones de los usuarios

userservice

Es el servicio que almacena a los usuarios

LLMService

Es el servicio que realizará las llamadas al LLM

Azure

Es el servicio que va a hostear el servidor en el que estara almacenada nuestra aplicación

LLM

Es un modelo extenso de lenguaje localizado en un servidor ajeno al que accederemos mediante una API key

Wikidata

Es una base de datos externa de la cual sacaremos las posibles preguntas de la aplicación asi como las respuestas

8. Conceptos Transversales (Cross-cutting)

Contenido

Esta sección describe de manera general, las principales ideas de solución y regulación que son relevantes en multiples partes (→ cross-cutting/transversales) del sistema. Dichos conceptos están relacionados usualmente a múltiples bloques de construcción. Pueden incluir diversos temas, tales como:

  • Modelos de dominio

  • Patrones de arquitectura o patrones de diseño

  • Reglas de uso para alguna tecnología específica.

  • Decisiones técnicas principales o generales

  • Reglas de implementación

Motivación

Conceptos que forman la base para la integridad conceptual (consistencia, homogeneidad) de la arquitectura. Entonces, son una contribución importante para alcanzar la calidad interna del sistema.

Algunos de estos conceptos no pueden ser asignados a bloques de construcción individuales (por ejemplo seguridad). Este es el lugar en la plantilla provisto para una especificación cohesiva de dichos conceptos.

Forma

La forma puede ser variada:

  • Papeles conceptuales con cualquier tipo de estructura

  • Modelo transversal (cross-cutting) de fragmentos o escenarios usando notación de las vistas arquitectónicas

  • Implementaciones de muestra, especialmente para conceptos técnicos.

  • Referencias a uso típico en frameworks estándar (por ejemplo, el uso de Hibernate para mapeo Objeto/Relacional)

Estructura

La estructura potencial (pero no obligatoria) para esta sección podría ser:

  • Conceptos de dominio

  • Conceptos de experiencia de usuario (UX)

  • Conceptos de seguridad

  • Patrones de diseño y arquitectura

  • "Bajo el capó"

  • Conceptos de desarrollo

  • Conceptos de operación

Nota: Puede ser difícil asignar conceptos individuales a un tema específico de la lista

Possible topics for crosscutting concepts
Further Information

See Concepts in the arc42 documentation.

8.1. Conceptos de dominio

En el siguiente diagrama se muestra el modelo de dominio.

diagrama clases

8.2. Conceptos de experiencia de usuario (UX)

La usabilidad es un aspecto fundamental en el diseño de cualquier aplicación, ya que influye directamente en la satisfacción de los usuarios. Crear interfaces intuitivas que permitan una interacción fluida y sin esfuerzo con el sistema es un factor clave para garantizar una experiencia positiva.

Concepto Descripción

Interfaz Usable

La aplicación debe ofrecer una experiencia clara y accesible para todos los usuarios, priorizando la facilidad de navegación y evitando sobrecargar la interfaz con elementos innecesarios.

Facilidad de Uso

Se garantizará un diseño intuitivo y limpio, con una disposición lógica de los elementos. Las funciones más importantes estarán accesibles con el menor número de interacciones posible.

Intuitiva

La interfaz debe seguir principios de usabilidad, como consistencia en los diseños, reconocimiento sobre memorización y retroalimentación visual clara.

Solidez

Se optimizará el rendimiento de la aplicación para minimizar tiempos de carga y evitar interrupciones en la experiencia de usuario. Se priorizará una arquitectura estable que prevenga errores y garantice un funcionamiento fluido.

Retroalimentación Inmediata

Tras cada respuesta, la aplicación debe proporcionar un feedback inmediato que indique si la opción seleccionada es correcta o incorrecta. Esto mejora la experiencia del usuario.

Indicadores de Progreso

Es esencial proporcionar a los usuarios una representación visual de su avance dentro del juego. Mostrar el progreso ayuda a que comprendan en qué punto se encuentran y cuánto les falta por completar.

8.3. Conceptos de seguridad

La seguridad es un aspecto esencial en el diseño de aplicaciones, ya que protege la información sensible de los usuarios y asegura la integridad de los datos. A continuación se muestran algunos conceptos clave.

Concepto Descripción

Control de Acceso Seguro

Se implementará un sistema de autenticación robusto que valide correctamente las credenciales del usuario antes de conceder el acceso. En caso de datos incorrectos, se denegará el ingreso.

Privacidad

La información de los usuarios será completamente privada y no será visible para otros usuarios.

Almacenamiento Seguro

Las contraseñas de los usuarios nunca serán almacenadas en texto plano. Se emplearán técnicas de cifrado y hash seguro para proteger la información sensible y evitar accesos no autorizados.

8.4. Conceptos de Arquitectura

  • Microservicios: La arquitectura de microservicios es un enfoque en el desarrollo de software que organiza la aplicación como una colección de servicios pequeños e independientes. Estos microservicios se comunican entre sí a través de APIs bien definidas, lo que permite que cada uno cumpla funciones específicas y se enfoque en capacidades concretas. Al adoptar este patrón de diseño, nuestra aplicación se beneficia de una estructura flexible y escalable. La separación de responsabilidades entre servicios no solo facilita el mantenimiento y las actualizaciones, sino que también permite una mayor adaptabilidad ante cambios.

8.5. Conceptos de Desarrollo

  • Integración continua: Para asegurar la calidad y la eficiencia del proceso, se implementará un sistema de Integración Continua, permitiendo que el código se despliegue de manera automática en una máquina virtual de Azure. Esta práctica no solo optimiza el flujo de trabajo, sino que también garantiza que las nuevas funcionalidades y correcciones se integren de forma rápida y segura.

  • Testing: Para garantizar la robustez y el buen funcionamiento de la aplicación, y evitar errores, realizaremos distintos tipos de pruebas, incluyendo pruebas unitarias, de aceptación, de carga y de cobertura. Dado que la aplicación consiste en un juego de preguntas, es fundamental validar tanto la lógica del cuestionario como la interacción del usuario, asegurando que la experiencia de juego sea fluida y atractiva. Esto incluye verificar que las preguntas se presenten correctamente, que las respuestas se registren adecuadamente y que el sistema funcione sin interrupciones durante las partidas. También llevaremos a cabo pruebas de usabilidad y adaptabilidad de la interfaz, garantizando que los usuarios puedan interactuar con la aplicación de manera intuitiva y satisfactoria.

9. Decisiones de Diseño

Contenido

Decisiones arquitectónicas importantes, costosas, a larga escala o riesgosas incluyendo sus razonamientos. Con "Decisiones" nos referimos a la elección de una alternativa basada en cierto criterio.

Se debe usar el juicio para decidir si una decisión arquitectónica debe ser documentada en esta sección central o si sería preferible documentarla localmente (Por ejemplo, dentro de una plantilla de caja blanca de un bloque de construcción).

Evite la redundancia. Tomar de referencia la sección 4, donde ya se capturaron las decisiones más importantes para la arquitectura.

Motivación

Las partes relacionadas del sistema deben comprender y trazar las decisiones.

Forma

Varias opciones:

  • Lista o tabla, ordenada por importancia y consecuencias o:

  • Mayor detalle en secciones separadas por cada sección.

  • Registro de Decisiones de Arquitectura (ADR por sus siglas en inglés) para cada decisión importante.

9.1. Acceso a Wikidata

Problema: Tenemos que acceder de alguna forma a las imágenes y etiquetas proporcionadas por Wikidata.

Alternativas consideradas:

  • Búsqueda con Elasticsearch via la API "wbsearchentities"

  • Búsqueda son SPARQL via endpoint propio de Wikidata

Decisión tomada: Decidimos usar el endpoint de SPARQL ya que era la forma de acceso a los datos de Wikidata que más se ajustaba a nuestro proyecto.

9.2. Modelo de lenguaje usado

Problema: Necesitamos usar un LLM en la aplicación para proporcionar un chat interactivo en tiempo real.

Alternativas consideradas:

  • Gemini de Google

  • Mistral de Empathy

Decisión tomada: El Modelo de Lenguaje que decidimos usar será Mistral de la empresa Empathy.

9.3. Despliegue

Problema: Necesitamos desplegar la aplicación para su uso.

Decisión: La aplicación se desplegará usando Docker por la flexibilidad para desplegar en distintas plataformas.

10. Requerimientos de Calidad

Esta sección describe todos los requerimientos de calidad como un árbol de calidad con escenarios. Los más importantes ya han sido descritos en la sección 1.2 (Metas de Calidad). Aquí se capturan los requerimientos de calidad con menor prioridad, que no crearán altos riesgos en caso de que no sean cubiertos con totalidad.

Motivación

Dado que los requerimientos de calidad tendrán mucha influencia en las decisiones arquitectónicas deben tomarse en cuenta los elementos importantes para las partes relacionadas que sean concretas y medibles.

Más información

Vea Quality Requirements en la documentación de arc42.

10.1. Árbol de Calidad

Contenido

El árbol de calidad (Definido en ATAM - Método de análisis de compensación de arquitectura por sus silas en inglés) con escenarios de calidad/evaluación como hojas.

Motivación

La estructura de árbol con prioridades provee un vistazo general para un gran número de requerimientos de calidad.

Formato

El árbol de calidad es un vistazo a alto nivel de las metas de calidad y requerimientos: * Un refinamiento del término de "calidad" a manera de árbol. Utilice "calidad" o "utilidad" como raíz. * Un mapa mental con categorías de calidad como ramas principales En cualquier caso incluya ligas a los escenarios de las siguientes secciones.

árbol de calidad

10.2. Escenarios de calidad

Contenido

Concretización de requerimientos de calidad (que pueden ser vagos o implícitos) utilizando escenarios de calidad. Estos escenarios describen lo que debería pasar cuando un estímulo llega al sistema. Para los arquitectos, son importantes dos tipos de escenarios: * Escenarios de uso (también llamados escenarios de aplicación o escenarios de caso de uso), que describen la reacción en tiempo de ejecución de un sistema a un determinado estímulo. Esto incluye también escenarios que describen la eficiencia o el rendimiento del sistema. Por ejemplo: El sistema reacciona a la petición de un usuario en un segundo. * Escenarios de cambios, describen la modificación del sistema a su ambiente inmediato. Por ejemplo: Cuando se implementa funcionalidad adicional o requerimientos para el cambio de un atributo de calidad.

Motivación

Los escenarios crean requerimientos de calidad concretos y permiten medirlos de manera más sencilla o decidir si han sido cumplidos. Cuando se requiere evaluar la arquitectura utilizando métodos como ATAM se necesitan describir las metas de calidad (de la sección 1.2) de manera más precisa hasta un nivel de escenarios que pueden ser discutidos y evaluados.

Formato

Texto en forma libre o tabular.

10.2.1. Escenarios de uso

Atributo de calidad

Escenario

Usabilidad

El usuario debe poder entender cómo jugar al juego en un máximo de 10 minutos sin tener conocimientos previos.

Usabilidad

El usuario debe poder pedir pistas al LLM sin tener conocimientos previos acerca de cómo utilizar una IA.

Rendimiento

El sistema debe cargar las preguntas en menos de 2s.

Compatibilidad

La aplicación debe funcionar en las versiones más nuevas de los navegadores más utilizados (Chrome, Firefox, Edge…​).

Compatibilidad

La aplicación debe funcionar en distintos dispositivos (móvil, tablet y ordenador).

Privacidad

Las contraseñas de los usuarios deben guardarse encriptadas en la base de datos.

Privacidad

El usuario sólo debe tener acceso a sus propios datos. El sistema debe evitar que un usuario logre acceder a los datos de otros usuarios.

Accesibilidad

Los textos de la interfaz deben tener un tamaño mínimo de 16px para garantizar que sean legibles.

10.2.2. Escenarios de cambios

Atributo de calidad

Escenario

Mantenibilidad

Las pruebas deben estar automatizadas de modo que cuando se añada una nueva funcionalidad se pueda comprobar fácilmente que la funcionalidad anterior sigue funcionando.

Mantenibilidad

El código debe estar bien documentado y separado en distintos módulos, permitiendo fácilmente modificaciones.

11. Riesgos y Deuda Técnica

Contenido

Una lista de los riesgos técnicos o deuda técnica identificada, ordenada por prioridad.

Motivación

"El manejo de riesgos es administración de proyectos para gente adulta" (Tim Lister, Atlantic Systems Guild.) Esto debiera ser el lema para la detección sistemática y la evaluación de riesgos y deuda técnica en la arquitectura, que será requerida por las partes relacionadas administrativas (por ejemplo, administradores de proyectoes, propietarios de producto) como parte de la planeación y medición de riesgos en general.

Forma

Lista de riesgos y/o deuda técnica, que podría incluir una medidas sugeridas para minimizar, mitigar o evitar riesgos o reducir la deuda técnica.

Más Información

Ver Risks and Technical Debt en la documentación arc42.

11.1. Riesgos

Riesgo Descripción Impacto Probabilidad Mitigación

Abandono de componentes del equipo

Si se da el caso de que uno o más componentes del equipo lo abandonan durante el desarrollo, la carga de trabajo del resto de componentes se verá aumentada.

Alto

Media

Código bien documentado y estructurado, de forma que cualquier componente, haya o no participado en esa parte del desarrollo, pueda entenderla y trabajar en ella.

Mala comunicación entre el equipo

Una comunicación deficiente entre los miembros del equipo puede generar malentendidos, retrasos y conflictos en el proyecto.

Medio

Baja

Reuniones de forma rutinaria recogiendo en acta los puntos tratados y las responsabilidades de cada miembro.

Poca experiencia en trabajos green field

El quipo cuenta con poca experiencia desarrollando proyectos de cero, así como haciendo la toma de decisiones de tecnologías a usar. Esto puede derivar en retrasos o partes del proyecto poco eficientes.

Alto

Media

Investigación y formación previa.

Seguridad en el sistema de login

El almacenamiento y tratamiento de credenciales de usuarios podría ser vulnerable.

Alto

Baja

Utilización de una encriptación segura. Normas mínimas de seguridad a la hora de establecer contraseñas.

Escalabilidad de la base de datos

Según aumentan los usuarios y el ranking de partidas, el rendimiento de la base de datos puede verse perjudicado.

Bajo

Baja

Optimización de consultas e índices adecuados.

Dependencia de la disponibilidad de la base de datos en la nube

El proyecto utiliza una base de datos alojada en la nube, por lo que introduce una dependencia de la infraestructura de la nube.

Medio

Baja

Replicación de datos mediante copias de seguridad periódicas.

Tiempos de respuesta del LLM

El modelo de lenguaje puede presentar tiempos de respuesta elevados, así como verse afectado por la alta demanda.

Bajo

Baja

Elección de modelo eficiente y optimización de consultas.

Respuestas no coherentes del LLM

El modelo de lenguaje puede generar respuestas irrelevantes, incorrectas o incoherentes.

Medio

Media

Definición de prompts adecuados.

Dependencia de la disponibilidad de la API externa

El sistema depende de una API externa para la obtención de imágenes y preguntas. Si esta API sufre caídas, el juego podría verse afectado impidiendo la carga de contenido esencial.

Alto

Baja

Evaluar APIs de respaldo o cachear las últimas respuestas de esta.

Uso concurrente de la aplicación

El uso concurrente de la aplicación puede llevar a un menor rendimiento de esta, fallos en la base de datos o la caída del sistema.

Medio

Media

Pruebas de carga y uso de cache evitando consultas repetitivas.

11.2. Deuda Técnica

Deuda Técnica Descripción Consecuencia Mitigación

Estructura de la base de datos

El modelo de datos establecido al inicio del desarrollo puede no ser óptimo para futuras expansiones del proyecto.

Problemas de rendimiento y retrasos al tener que modificar la estructura de la base de datos.

Diseñar utilizando principios de normalización.

Rendimiento del LLM

El modelo de lenguaje utilizado puede generar tiempos de respuesta elevados, así como respuestas irrelevantes al contexto.

Afecta la experiencia de usuario.

Optimización de prompts y monitoreo de rendimiento.

Ausencia de pruebas

La falta de pruebas puede provocar que cada cambio en el código pueda introducir errores sin ser detectados.

Fallos en la aplicación y difícil detección de estos.

Implementación de pruebas unitarias, de integración y automatizadas.

Código poco mantenible

El código no sigue buenas prácticas de arquitectura y estructuración.

Cualquier cambio en el código puede volverse complicado y costoso de implementar.

Desarrollar código que cumpla los principios SOLID.

12. Glosario

Contenido

Los términos de dominio y técnicos más importantes que utilizan tus partes interesadas al hablar sobre el sistema.

También puedes ver el glosario como una fuente de traducciones si trabajas en equipos multilingües.

Motivación

Debes definir claramente tus términos para que todas las partes interesadas:

  • tengan una comprensión idéntica de estos términos

  • no usen sinónimos ni homónimos

Formato

Una tabla con las columnas <Término> y <Definición>.

Potencialmente más columnas en caso de necesitar traducciones.

Más información

Observa Glossary en la documentacion de arc42.

Término Definición

API

(Interfaz de Programación de Aplicaciones) Conjunto de reglas y definiciones que permiten la comunicación entre diferentes sistemas o componentes de software.

Microservicio

Estilo arquitectónico en el que una aplicación se divide en pequeños servicios independientes que se comunican entre sí mediante APIs.

Gateway

Punto de entrada que gestiona y dirige el tráfico entre clientes y servicios, actuando como intermediario.

Front-end

Parte de una aplicación con la que interactúa el usuario, encargada de la presentación y experiencia visual.

Back-end

Parte de una aplicación que gestiona la lógica de negocio, el procesamiento de datos y la comunicación con la base de datos, funcionando en el servidor y respondiendo a las solicitudes del front-end.