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

Una empresa de venta de productos busca originar un sistema de venta online denominado DeDe (Decentralized Delivery). Estará centrada en la venta de productos informáticos de diferentes ámbitos (como ratones, teclados…​). Este sistema busca priorizar la privacidad de los clientes a través de los principios SOLID. El sistema obtendrá la información de los clientes de los pods de los usuarios siempre que éstos den los permisos necesarios al sistema de venta. Se distinguirá entre usuarios normales y adminstradores. Éstos pueden, además de acceder a la tienda, crear, modificar y eliminar los productos de la base de datos. Los usuarios eligirán los productos que formarán parte de su carro de compra. Cada usuario tiene su propio carro individual.

1.1. Integrantes

  • Ana Fernández Ostio

  • Darío Martínez Bajo

  • Efrén García Valencia

  • Adrián Santamarina Romero

  • Rubén Rubio el Castillo

1.2. Profesores a cargo de la asignatura

  • Hugo Lebredo Buján

  • Jose Emilio Labra Gayo

  • Pablo González

  • Irene Cid Roco

1.3. Información general de los requisitos

A continuación se muestran los requisitos que se puedes encontrar en nuestra aplicación. Se dividen en obligatorios y opcionales

Requisitos obligatorios implementados
  • El sistema recreará un sistema de compra online donde los usuarios podrán elegir y solicitar productos a comprar.

  • Una vez que el usuario escoja los productos a llevar, el sistema calculará los costes de envío mirando la dirección deseada del usuario en su pod y estableciendo los costes de acuerdo a la distancia del centro de distribución a dicha dirección.

  • Se mostrarán los costes finales de los productos a comprar y, una vez que el usuario tome la decisión de comprarlos, registrará el evento que indicará que la venta ha sido completada y se pasará al envío.

  • Los usuarios podrán visualizar los pedidos realizados

  • Se construirá la aplicación usando el framework React y Typescript.

  • El producto acabado tiene que ser accesible y estar desplegado utilizando un sistema de integración continua y un servicio de hosting.

Requisitos opcionales considerados
  • Rol de gestores que puedan realizar diferentes acciones como gestión de inventario, cambios de precios, quitar ítems del catálogo, etc.

  • Se añade tambien una vista en el que el administrador pueda ver todos los pedidos que se han realizado.

  • Un usuario puedde actuzalziar el nombre de este dentro de la aplicación

1.4. Objetivos de calidad

Objetivos de calidad Motivación Importancia

Eficiencia

La aplicación utilizará la menor cantidad de recursos posibles para generar las respuestas a las peticiones, mejorando así los tiempos de respuesta

Media

Seguridad

El usuario debe tener la certeza de que su información personal esté segura para ganar su confianza

Alta

Robustez

Se ha de manejar correctamente las excepciones para evitar que el usuario tenga una experiencia desagradable usando la aplicación

Alta

Privacidad

Solamente el usuario debería tener acceso a su información privada, sin que haya terceras partes implicadas

Alta

Transparencia

Todo lo que se haga en el proyecto permanecerá en un repositorio público para que otra gente lo pueda tener como referencia

Media

Comodidad

La aplicación ha de ser fácil de manejar para gente no experimentada

Alta

1.5. Stakeholders

Rol/Nombre Expectations

Equipo de desarrollo

Aprender a trabajar en equipo con gente que no conocen y familiarizarse con las tecnologías solicitadas en el curso

Empresa de venta de productos (cliente)

Una aplicación funcional que satisfaga los requisitos solicitados, especialmente aquellos relacionados con la seguridad

Cliente

Poder entrar a la aplicación para realizar las compras que desean de forma segura y cómoda. Introducirán sus productos en un carro de la compra.

Administrador

Tener el control de una aplicación robusta y eficiente que incluya la posiblidad de crear, modificar, eliminar productos, ver los usuarios y pedidos

Inrupt/Empathy

Entidades colaboradoras del concurso SOLID en el que se puede presentar el proyecto desarrollado durante el curso

2. Restricciones de Arquitectura

Table 1. Restricciones técnicas
Restricción Descripción

Typescript

Nuevo lenguaje de programación para todos los integrantes del grupo.

React

Libreria JavaScript requerido para construir interfaces de usuario para la web. Aplicación nueva que nunca usamos.

SOLID

Principios y tecnologia que nos ayudará a organizar apps, al igual que react, tenemos que investigar sobre ello ya que es la primera vez que la usamos.

Table 2. Restricciones de organización
Restricción Descripción

Equipo

Grupo conformado por 5 personas que no habian trabajado juntos antes.

Tiempo

Fecha de entrega limite al final de semestre, 2 horas semanales con el profesor y reuniones del equipo semanales de 1 a 2 horas.

Table 3. Restricciones de documentación
Restricción Descripción

Arc42

Recomendado para realizar la documentación.

PlantUML

Programa que permite diseñar y realizar diagramas, generándolos a través de un texto escrito

3. Alcance y contexto del sistema

En Dede se le ha dado mas importancia a la seguridad y privacidad de nuestros clientes, por lo que para cumplir esto dos atributos de calidad, se seguirán los principios de SOLID utilizando PODS. Un POD es un lugar seguro donde el usario podrá alamacenar la informacion que desee y dar autorización a la aplicación para que se utilice la información que sea necesaria. Cada usuario tendrá un POD propio donde colocará principalmente sus datos personales y la dirección de envío. También hay mas seguridad ya que la contraseña del usuario del será cifrada para despues ser almacenada en la Base de Datos

3.1. Contexto de negocio

Diagrama Contexto Negocio

Comunicaciones Entradas Salidas

Usuario

Interacciones con la aplicación

Respuestas a esas interacciones

POD del Usuario

La inforamción relativa a cada usuario para respetar su privacidad

Información que necesite la aplicación siempre cuando el usuario lo permita

DeDe

Venta de productos

Información que recibe de las APIs y de la base de datos

Base de datos

Peticiones por parte de la aplicación DeDe

Respuesta de la información almacenada en esta base de datos

EasyPost

Dirección de envío

Precio de envío desde el almacén

PostImages

Imágenes para mostrar

Imágenes necesarias para mostrar en la Aplicación

3.2. Contexto técnico

Se utiliza una arquitectura SOLID para respetar la privacidad del usuario, en este caso la direccion de envio de este.

Tecnología Descripción

POD

Lugar donde se almacena la información de cada cliente

DeDe

Aplicación descentralizada

EasyPost

API usada para calcular los precios de envio

PostImages

API que guarda las imagenes y las descarga para su uso en la aplicación

TypeScript

Lenguaje utilizado para el desarrollo de la aplicación

React

Libreria utilizada para generar de las interfaces de la aplicación

4. Soluciones de estretegia

4.1. Restricciones tecnologicas

  • React: libreria de acceso libre que en este caso se utilizara con TypeScript diseñada para que el diseño de las interfaces web sean más fáciles.

  • Pod Solid: almacenamiento de la inforamción personal de cada usuario.

  • TypeScript: lenguaje de programación con el que está desarrollada la aplicación.

4.2. Deciones tecnologicas

  • Node.js: entorno en tiempo de ejecución multiplataforma, de código abierto, para la capa del servidor basado en el lenguaje de programación JavaScript, asíncrono, con E/S de datos en una arquitectura orientada a eventos y basado en el motor V8 de Google.

  • MongoDB: sistema de base de datos NoSQL orientado a documentos. Además MongoDB es de código abierto por lo que se permite una mayor libertad de creación de documentos

  • MUI: Libreria de libre acceso para construir los diferentes componentes que utiliza la aplicación. La mayoria de componentes que se utilizan en nuestra aplicación son de esta librería y son personalizados según se necesita el formato de este.

  • Docker: Automatizacion del despligue medainte contenedores, se han creado dos contenedores, uno para la parte de 'front-end' y otro para 'back-end'

  • AWS: Depligue de la página.

  • EasyPost: API que calcula el precio de envío en funcion de una dirección

  • PostImages: API utilizada para poder utilizar las imagenes en nuestra aplicación.

  • SuperTest y Jest: Utilizado para poder realziar las diferentes pruebas.

4.3. Decisiones de organización

  • Revisiones y reuniones acordadas con antelación se realizarán a través de la aplicación Microsoft Teams.

  • Mensajería instantanea para acordar aquellas reuniones que se realicen de forma online, también para avisar de cambios pequeños.

  • GitHub para reflejar el trabajo que se esta realizando de varias formas:

    • Rama individual para cada uno, donde deberá realizar su trabajo. Rama Developer donde se iran incluyendo los cambios de todos los miembros para despues poder realizar de una manera más sencilla los cambios a master.

    • Uso de wikis para recoger todo lo acordado en las reuniones y del registro arquitéctonico.

    • Uso de issues para indicar las cosas que tiene que realizar cada miembro del equipo.

    • Uso de Actions para commprobar el correcto funcionamiento de la aplicación

    • Uso de Tableros para controlar como esta siendo el desarrollo del trabajo, se dividieron en 4 tableros:

      • FrontEnd

      • BackEnd

      • Documentación

      • Despliegue

5. Building Block View

5.1. 5.1. Whitebox Overall System

El siguiente diagrama permite mostrar las distitnas capas de la aplicación y la manera en la que el usuario interactúa con ella:

Building block view - Whitebox Overall System

Motivación

El usuario tendrá un POD con el que la aplicación recogerá su información de contacto para calcular el coste de los gastos de envío de los productos. A parte de esto, el usuario podrá interactuar con la aplicación para registrarse y poder realizar pedidos con los productos que desee.

Cajas negras

Descripción

Usuario

Interactúa con la aplicación y es propietario de un POD con su información de contacto.

DeDe

Sistema que permite a los usuarios realizar los pedidos con los productos que desee.

POD

POD del usuario que contiene su informaciñon personal.

5.2. 5.2. Nivel 1

Motivación

El usuario de la aplicación interactuará con la WebApp de la misma, es decir, el frontend de la aplicación y éste a su vez intercambia las entradas que recibe de parte del usuario con la API Rest que persiste dichos datos en la BBDD.

Nombre

Responsabilidad

WebApp

Frontend de la aplicación con la que el usuario interactúa.

API

API Rest de la apliación que conforma el backend de la aplicación, al que se le harán peticiones y se relaciona con la BBDD.

BBDD

Base de datos donde se persiste la información que maneja la aplicación.

5.3. 5.3. Nivel 2

Motivación

Se definen las distintas páginas de la aplicación en la WebApp con las que el usuario interactuará para realizar sus pedidos, cada una de estas páginas intercambiará datos con el API Rest, conformado por los Routes, Controllers y Models descritos en la parte inferior.

Log-In

El usuario podrá iniciar sesión en la aplicación con sus datos de registro.

Registro

El usuario podrá registrarse introduciendo sus datos, para posteriormente iniciar sesión.

Productos

Listado de productos que el usuario podrá añadir al carrito, y posteriormente realizar un pedido.

Home

Página principal de la aplicación

Carrito

Carrito de la compra donde se guardan los productos que el usuario quiere.

Pago

Pantalla de pago de la aplicación para realizar el mismo.

Routes

Rutas del backend para hacer las peticiones correspondientes, a éstas se le añaden las funcionalidades a través del controlador.

Controller

Define las funciones que se van a enrutar e interactúa con los modelos de la BBDD.

Model

Modelos definidos en la BBDD, se encargan de persistir los datos.

6. Runtime View

A continución se muestran diferentes escenarios que se puedene encontrar en la aplicación

6.1. Añadir productos

El administrador rellenará un formulario con los detalles del producto que se mandará a la aplicación. Desde ahí se manda la información necesaria a la base de datos para que se almacene el nuevo producto correctamente.

Añadir productos

6.2. Administrar productos

El administrador podra administrar todos los productos de la web. Se le mostrará una tabla con todos los productos, su información, stock y con dos opciones, editar el producto o eliminarlo.

Administrar productos

6.3. Eliminar productos

El administrador podra eliminar el producto que desee desde la misma ventana donde se administran los productos.La aplicación borrará el producto seleccionado.

Eliminar productos

6.4. Administrar pedidos

El administrador podra administrar todos los pedidos de la web. Se le mostrará una tabla con todos los pedidos y su información.

Administrar pedidos

6.5. Filtro de productos

El usuario tras realizar el login en la aplicación y ver los diferentes productos que hay, podrá utilizar los filtros situados en la parte izquierda de la página para realizar una búsqueda más precisa. Tras selccionar los filtros que el usuario vea convenientes. La aplicación pedirá a la base de datos donde se encuentren todos los productos, aquellos que el filtro muestre. Tras ello, la base de datos, retornara los productos que cumplan esos filtros a la aplicación. La aplicación mostrará los productos al usuario.

Filtro productos

6.6. Compra de productos

El usuario tras haber añadido uno o varios productos al carrito de la compra irá a dicho carrito y comprará los productos, la aplicación gestionará la forma de pago y consultará el Pod del usuario para extraer la información necesaria.

Compra productos

6.7. login

El usuario debe introducir sus credenciales en la aplicación y estas serán validadas con la vase de datos, si son correctas accederá a la aplicacion con su cuentas y sino se le mostrará un mensaje de error Login

6.8. Cerrar sesión

Una vez que haya acabado, el usuario podra cerrar sesión para no mantener su cuenta activa Login

6.9. Mostrar historial de ventas administador

El administrador pedirá el historial de ventas a la base de datos. Mostrar historial de ventas administrador

6.10. Mostrar historial de pedidos del usuario

El usuario pedirá el historial de sus compras a la base de datos. Mostrar historial de pedidos del usuario

6.11. Modificar perfil

El usuario podrá modificar su perfil ya sea cambiando su nombre o apellidos directamente o solicitando un cambio de contraseña. El correo no podrá ser modificado. Modificar perfil

7. Perspectiva de Despliegue

7.1. Tecnologías

  • Los datos del usuario serán almacenados en un POD. El entorno de desarollo empleado para el trabajo será Node.js, mientras que emplearemos MongoDB como base de datos principal.

7.2. Infraestructura

  • Interfaz de usuario: Desarrollada como un conjunto de componentes de React

  • Logica de negocio: Funcionamiento de la aplicación

  • Persistencia: basada en una API REST y MongoDB

7.3. Diagrama de Despliegue

Despliegue

8. Conceptos transversales

8.1. Modelo de dominio

Modelo de datos

8.2. Comentarios del modelo

Dos matizaciones importantes:

  • La primera es que como se puede comprobar en la página web no hay reviews. Eso es que en backend está implementado pero en el front no se incluyó por problemas en el desarrollo. Como sigue siendo una parte de la aplicación de la cual además se hacen tests sobre ello pues se dejan en el diagrama.

  • También con el carro de compra desde el backend tenemos código para guardarlo en la base de datos pero al final no se almacena en MongoDB.

8.3. Internacionalización

La aplicación está construida sobre el lenguaje castellano.

8.4. Seguridad

La seguridad es uno de los aspectos fundamentales de la aplicación. Por ello se aplicarán los principios SOLID y el uso de pods para almacenar la información personal del cliente. Para poder garantizar la seguridad al usuario con sus contraseñas estas serán cifradas.

8.5. Consistencia

Otro aspecto fundamental que perseguimos es garantizar que los datos de los clientes no se corrompan al emplear su aplicación, sin importar el problema que ocurra.

8.6. Usabilidad

Queremos garantizar el tener una interfaz de usuario que resulte cómoda al usuario para que así en un futuro vuelva a emplear la aplicación para sus futuras compras.

8.7. Manejo de excepciones

Se incluirá el código necesario para manejar y capturar los errores procedentes de las diferentes partes de la aplicación. De ser necesario, se le informará al cliente con el mensaje que corresponda.

8.8. Manejo de sesión

Se manejarán las sesiones a través del uso de tokens asignados a cada usuario registrado.

8.9. Estándares de código

El crear código limpio que siga unas estructuras y patrones definidos es base fundamental para crear código que se pueda actualizar en un futuro. Queremos garantizar crear una aplicación al nivel que se puede esperar de un equipo de formado por Ingenieros Informáticos del Software.

8.10. Persistencia

Uso de una base de datos MongoDB para gestionar la parte de almacenamiento y modificación de los productos informáticos en la tienda.

8.11. Prototipado de la aplicación

El formato que se ha escogido para realizar los prototipos de la aplicacion es que esta sea fácil de usar y a la vez siga la forma del resto de aplicaciones del mismo tipo de esta.

8.12. Generación de pruebas

Consideramos fundamental el uso de pruebas unitarias para verificar el correcto funcionamiento de la aplicación.

Para comenzar tenemos la página inicial, esta estara compuesta por aquellos productos que tengan un descuento o sean top ventas de la aplicación.

Página inicio

También se podrá tener acceso a la vista de los productos, la cual ofrece una serie de categorías por si se está buscando algo en especifico.

Catalogo de Productos

Una vez se este en la aplicacion se podran realizar varias cosas:

Desde el punto de vista de un cliente:

  • Realizar LogIn en la aplicacion: Para poder acceder a la aplicación es necesario indicar el nombre de email de este como la contraseña que haya indicado anteriormente.

Página login

  • Realizar un registro en nuestra aplicación, para ello se deberán indicar unos cuantos campos acerca de la informacion peronal de este.

Registro aplicación

  • Comprobar los articulos que se desean comprar por parte del cliente

Registro aplicación

  • Realizar el pago del carrito del usuario

Ventana Pego

  • Ver mis pedidos realizados

Mis pedidos

  • Actualización del perfil

Ventana Pego

Desde el punto de vista de Administrador:

  • Ver todos los pedidos que se han realizado desde la aplicación

Pedidos como Admin

  • Ver todos los usuarios registrados en la aplicación, asi como tener un botón para asignar a otro administrador

Productos como Admin

  • Crear un nuevo producto

Añadir productos

  • Ver todos los productos que exiten en la app:

Productos como Admin

  • Actualizar los valores de productos ya existentes

Actualizar Productos como Admin

9. Decisiones de diseño

Restricciones técncias, es decir, se obliga a que el equipo de desarrollo trabaje con las diferentes decisiones:

Restricciones Ventajas Desventajas

React

Facilidad para realizar las interfaces de usuario

Framework nuevo para todo el equipo

TypeScript

Lenguaje más familiriarizado, no permite fallos en los tipos

Lenguaje con el que no se ha trabajado

Almacenamiento de las direcciones en PODs

Seguridad para el usaurio

Poco conocimiento del funcionamiento

Jest

Compatible con TypeScript

Nunca se ha trabajado con ello, puede llegar a tardar mucho en devolver el resultado de los tests

Las siguientes decisiones de diseño tomadas por el equipo de desarrollo, van ordenadas de mayor a menor prioridad:

Decisiones Ventajas Desventajas Link

MongoDB

Forma sencilla de almacenar la información que necesita la aplicación

Transacciones no soportadas

DA #01

Axios

Forma sencilla de conseguir datos de la Base de Datos

Al procesar mucha información este puede llegar a subir el tiempo de respuesta para el cliente

DA #02

MUI

Se puede personalizar según el cliente quiera conveniente

Pruebas de aceptación son dificiles de realizar

DA #03

PostIamges

Fácil colocación de las imagenes en la aplicación

Para el administrador de la aplicación puede llegar a costarle asociar una imagen a la página web

DA #05

SweetAlert2

Modales con mejor diseño que los que nos pueden ofrecer MUI

Se necesita instalar una nueva dependecia al sistema

DA #06

UUID

El código que llega a generar es improbable que se vuelva a repetir

El código para el adminsitrador en el caso de los productos, podria llegar a ser muy largo

DA #07

Mongoose

Facilita la conexion con la base de datos

Nunca ha sido utilizado

DA #08

Express

Facilita el diseño la aplicación de forma sencilla y rápida

Primera vez que se ha trabajado

DA #09

NodeJS

Failita el trbajo a la hora de pedir datos a la base de datos

Es necesario aprender como funciona este sistema

DA #10

AWS

Despliegue de la aplicación web en nube

Se necesita de una cuenta especifica y ademas ,poco conocimeiento sobre este

DA #11

EasyPost

Calculo de envio para la aplicación sencillo

Puede producir errores, centro de distribución se situa en EEUU

DA #12

JSON Web Token

Guarda de forma correcta el usuario para controlar sus privilegios

Puede generar fallos de seguridad

DA #13

Decisiones Denegadas

Decisiones Ventajas Desventajas Link

Heroku

Gratuito y además existen varias formas de desplegar

Difil despliegue ya que contiene un número máximo de estos y además la documentación de errores no es concisa

DA #04

10. Requisitos de calidad

10.1. Árbol de cualidades

Árbol de cualidades

10.2. Escenarios de Calidad

Objetivos de calidad Motivación Dificultad

Eficiencia

Utilización de la menor cantidad de recursos posibles para generar las respuestas a las peticiones, mejorando así los tiempos de respuesta

Media

Modificable

La aplicacicón está dividida en dos partes, BackEnd y FrontEnd, además en ambas partes de podrá añadir nuevas funciones, tantas como el cliente quiera. La reutilización de código será importante, por ejemplo, para visualizar los pedidos, el administrador podrá ver todos los pedidos, pero un cliente solo podrá ver los suyos propios, para ello, se añadirá un filtro al código del administrador.

Fácil

Usabilidad

La aplicación será fácil de navegar, estará preparada para culaquier tipo de edad. Los usuarios en todo momento sabrán en que punto de la aplicación se encuentran.

Media

Privacidad

Solamente el usuario debería tener acceso a su información privada, sin que haya terceras partes implicadas

Media

Testabilidad

La aplicación será testeada utilizando diferentes métodos de pruebas, además de ser porbada con usuarios reales para ver si se cumple todo

Alta

11. Riesgos y deudas técnicas

Riesgos Técnicos
  • Falta de experiencia con las tecnologías, ya sea React, TypeScript o SOLID. Nunca hemos trabajado con estas tecnologías, por lo tanto, empezaremos desde cero y deberíamos realizar búsquedas de información constantes para conseguir manejarlas correctamente. Para solucionarlo hemos buscado información del campo que nos ha sido asignado cada uno y hemos hecho pruebas de funcionalidad para paliar los máximos errores posibles.

  • Posibles problemas al trabajar con GitHub. Pueden surgir problemas a la hora de subir nuestros cambios a GitHub e incluso modificar cambios ya realizados por otros compañeros, para reducir esto lo máximo posible, cada compañero trabajará en su rama y cuando se quiera realizar cambios al proyecto principal se hará un pull request para que otro miembro del equipo lo verifique.

  • Primer proyecto web con un tamaño tan grande. Si bien hemos tenido algo de experiencia con proyectos web, nunca con estas dimensiones ni tecnologías. Para paliar este riesgo, deberíamos buscar bastante información sobre cómo llevarlo a cabo e intentar familiarizarnos con esta forma de trabajo lo antes posible.

  • El tiempo. Tenemos poco tiempo para llevar a cabo los prototipos, entonces habrá que tenerlo en cuenta a la hora de desarrollar y llevar el proyecto lo más al día posible.

  • Posibles vulnerabilidades en el proyecto web. Nunca nos han hablado de este tema en ninguna otra asignatura, por tanto, habrá que tenerlo en cuenta a la hora de desarrollar. Para mitigar este riesgo hemos tenido en cuenta algunos aspectos de seguridad, como el cifrado de contraseñas o un fichero con los datos más sensibles que utilizamos en el proyecto.

Deudas Técnicas
  • Código poco claro y sin refactorizar en la parte del backend sobre la gestión de usuarios.

  • Acoplamiento en el frontend a la hora de decodificar el token de sesión, se usa un módulo específico para ello.

  • Almacenamiento de token de sesión en el localStorage, se podría guardar en un nuevo campo de la base de datos, ya que el localStorage es modificable desde el navegador

  • Faltaría refactorizar parte del código del frontend para hacerlo más claro y modificable.

  • Mejoras en la implementación del filtrado de productos en el apartado del listado de los mismos.

  • Mal uso de los tipos de TypeScript en algunas ocasiones por falta de experiencia, por ejemplo, usar el tipo "any" en casos innecesarios

  • Mostrar de una forma poco clara que se está accediendo a un servicio de terceros en el caso de los PODs de SOLID.

  • El carrito del cliente se pierde, no se mantiene por las diferentes ventanas.

  • Falta de mas pruebas sobre el código de front.

12. Glosario

Término Definición

arc42

Plantilla para la documentación, comunicación de software y arquitectura del sistema.

React

Biblioteca de código abierto diseñada para crear interfaces de usuario con el objetivo de facilitar el desarrollo de aplicaciones en una sola página.

TypeScript

Lenguaje de programación utilizado para desarollar la aplicación. Es un superconjunto de JavaScript, añade tipos estáticos y objetos.

Solid

Proyecto de descentralización web dirigido por Tim Berners-Lee, el objetivo es permitir que los usuarios tengan control de sus datos, incluido el acceso y ubicación de almacenamiento.

POD

Lugar donde se almacena la inforamción de cada usuario. Una vez registre la informacion, el propio usuario tendrá el control de acceso a este POD.

SonarCloud

Plataforma de análisis de código continuo y online con la que se puede analizar el proyecto y ver los resultados en la nube.

PlantUML

Herramienta de código abierto que permite a los usuarios crear diagramas a partir de un lenguaje de texto sin formato.

Prometheus

Monitor de código abierto para almacenar las métricas.

Grafana

Aplicación que permite visualizar los datos almacenados en Prometheus.

Axios

Cliente HTTP basado en promesas. Dependecia isntalada para poder realizar de una manera mas sencilla el juntar front-end y back-end de la aplicación

PostImage

Página web para poder almacenar las imagenes de los productos

MUI

Libreria de libre acceso para construir los diferentes componentes que utiliza la aplicación

GitHub

Plataforma para alojar proyectos utilizando un sistema de veriones Git

Pencil

Aplicación de escritorio en la que se puede realizar prototipos de pantallas

UUID

Librería que genera cógidos aleatorios donde la probabilidad de que uno sea repetido es mínimo

SweetAlert2

Librería de libre acceso para construir los diferentes componentes modales que se utilizan en la aplicación

NodeJs

Entorno en tiempo de ejecución multiplataforma, de código abierto, para la capa del servidor basado en el lenguaje de programación JavaScript, asíncrono, con E/S de datos en una arquitectura orientada a eventos

Express

Framework de aplicaciones web gratuito y de código abierto para Node. js. Se utiliza para diseñar y construir aplicaciones web de forma rápida y sencilla

MongoDB

Sistema de base de datos NoSQL, orientado a documentos y de código abierto

MongoDB Atlas

Sistema gestionador de base de datos que se encarga de toda la complejidad de la implementación, la gestión y la recuperación de sus implementaciones en el proveedor de servicios en la nube de su elección

Mongoose

Biblioteca de JavaScript que le permite definir esquemas con datos fuertemente tipados

AWS

Amazon Web Services es una colección de servicios de computación en la nube pública que en conjunto forman una plataforma de computación en la nube, ofrecidas a través de Internet por Amazon.com

EasyPost

API de envío para poder calcular los costes dentro de nuestra aplicación

JSON Web Token

Estándar abierto basado en JSON propuesto por IETF para la creación de tokens de acceso que permiten la propagación de identidad y privilegios o claims en inglés

Jest

Librería abierta para pruebas en JavaScript desarrollada por Facebook

Scala

Lenguaje de programación multi-paradigma diseñado para expresar patrones comunes de programación en forma concisa, elegante y con tipos seguros. Integra sutilmente características de lenguajes funcionales y orientados a objetos

About arc42

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

By Dr. Gernot Starke, Dr. Peter Hruschka and contributors.

Template Revision: 7.0 EN (based on asciidoc), January 2017

© We acknowledge that this document uses material from the arc 42 architecture template, http://www.arc42.de. Created by Dr. Peter Hruschka & Dr. Gernot Starke.