1. Introducción y objetivos.
DeDe es una aplicación descentralizada de compra, que almacena los datos de los usuarios que acceden a esta en pods. Estos pods están creados para que no sea el propio sistema el que almacene la información privada de cada cliente, sino que cada cliente tenga su información y de permisos para acceder a ella cuando se den permisos.
El principal objetivo de la aplicación es mantener la privacidad de los clientes que quieran realizar compras en nuestra tienda, por lo que en los pods previamente explicados, solo se almacenará información imprescindible para cada usuario.
1.1. Requisitos básicos.
1.2. Objetivos de calidad.
| Prioridad | Objetivo | Descripción |
|---|---|---|
1 |
Privacidad |
Al ser una aplicación descentralizada, cada usuario tendrá su espacio personal, por lo que sus datos no se verán comprometidos. |
2 |
Usabilidad |
La aplicación tiene que ser intuitiva de cara al usuario, para que no sea una mala experiencia el uso de nuestra tienda. Cosas como hacer pedidos o ver los datos personales debe ser accesible. |
3 |
Testeabilidad |
La aplicación se debe de poder probar usando pruebas unitarias. Tiene que ser lo más importante para garantizar que los demás puntos cumplan correctamente su funcionamiento. |
4 |
Funcionalidad |
Ya que la aplicación es una tienda, interesa que los clientes estén satisfechos con las funcionalidades que ofrece, no solo para que ellos sigan usando nuestra tienda sino también que la recomienden a otros posibles clientes. |
5 |
Rendimiento |
Una aplicación de tienda no puede tener muchos tiempos de espera entre las diferentes acciones que ofrece, ya que haría que los usuarios dejen de usarla. |
1.3. Stakeholders.
| Rol/Nombre | Descripción | Expectativas |
|---|---|---|
Equipo de desarrollo |
Adrián Fernández Alonso, Álex Caso Díaz, Diego Martínez Menéndez, Diego Villa García y Pedro Zahonero Mangas |
Encargados de realizar la aplicación intentando cumplir los requisitos. Es importante la comunicación y el compromiso con el proyecto. |
Usuarios |
Cuaquier usuario al repositorio y testeadores del proyecto utilizados para las pruebas de usabilidad. |
Se podrán realizar todos requisitos básicos. Además es importante que el funcionamiento de la aplicación sea fluído para que estos usuarios estén contentos. |
Profesorado |
Pablo González González, José Emilio Labra Gayo, Irene Cid Rico y Hugo Lebrado Bujan y |
Encargados de supervisar el desarrollo de nuesta tienda. |
2. Restricciones de Software
| Restricción | Explicación |
|---|---|
Arc42 |
Usando la plantilla AsciiDoctor junto al modelo Arc42 para crear la documentación del proyecto. |
SOLID |
Debemos crear una aplicación que cuente con un sistema de persistencia descentralizado, por lo que usaremos SOLID. |
Typescript |
Utilizar este lenguaje para facilitarnos el uso de enlaces dinámicos, ya que en años anteriores se usaba Javascript. |
GIT |
Ya que este será un proyecto incremental en el que trabajaremos varias personas, usaremos Git para el control de versiones. |
2.1. Restricciones de Implementación
| Restricción | Explicación |
|---|---|
Descentralización del sistema |
Ya que cada usuario de la tienda puede crearse una cuenta para navegar en la tienda, sus datos estarán almacenados en servidores independientes (Pods). |
Separación de datos |
Todos los datos de todos los usuarios tienen que estar en un servicio distinto a los datos de la aplicación. |
2.2. Restricciones de Organización
| Restricción | Explicación |
|---|---|
Documentación de la App incremental |
Ya que la aplicación puede cambiar durante el desarrollo, la documentación debe de ir incrementando a la vez que esta. |
Entregar Implementación de manera periódica |
Ya que la aplicación irá añadiendo funcionalidades a lo largo de su desarrollo, debemos comprobar que este software es funcional. |
Redacción de actas semanales |
Todas las semanas se realizará un acta indicando qué se ha hecho desde la última reunión y qué se hará hasta la siguiente. |
3. Alcance del sistema y contexto
3.1. Contexto empresarial
Gracias an diagrama podemos entender cual es el funcionamiento de la aplicación, pues en el primer plano podemos encontrar a DeDe, el alma del proyecto. Es manejada por el usuario y rebibe los datos que se le proporcionan tanto de forma directa por el usuario, o a través de su POD. A su vez, DeDe almacena la información en una base de datos, donde cuando lo vé necesario, extrairá información.
También se puede ver como la aplicación tiene un flujo de unidireccional con API, pues la aplicación, si es necesario, puede realizar peticiones a través de recursos externos.
| Entidad | Entrada | Salida |
|---|---|---|
Usuario |
El usuario recibirá como entrada el servicio de la aplicación, la comunicación se establecerá con una web adaptable para distintos dispositivos. |
El usuario proporcionará la mayor parte de la entrada de la aplicación, además de indicar su Pod. |
Pod |
El pod almacena información del usuario. |
El pod le enviará a la aplicación la información requerida. |
DeDe |
Recibe las peticiones del usuario y extrae de la base de datos los recursos para su funcionamiento. |
Porporcionará el servicio al usuario y almacenará el resultado en la base de datos. |
Base de datos |
La base de datos recibirá los datos que la app necesité tener almacenado. |
La base de datos envía la información a la aplicación cuando este lo necesite. |
3.2. Contexto técnico
Si queremos profundizar más en el asunto, nos encontramos con el funcionamiento más técnico de DeDe:
DeDe es un sistema descentralizado que sigue la arquitectura SOLID, es decir, cada usuario posee de sus propios datos. Cada usuario tendrá vinculado un POD de SOLID, el cual sirve para guarda sus datos personales. Los demás datos son almacenados en una base de datos en MongoDB.
| Interfaz técnica | Descripción |
|---|---|
EasyPost |
API utilizada para añadir opciones de envio a productos. |
MongoDB |
Base de datos NoSQL orientado a documentos y de código abierto. |
Solid |
Arquitectura que ayudará a tener un código mas limpio, mantenible y escalable. |
TypeScript |
Lenguaje usado para programar la aplicación tanto el front-end como el back-end. |
4. Estrategia de solución
4.1. Tecnologías
Para el desarrollo de la aplicación se hará uso de las siguientes tecnologías:
| Tecnología | Objetivo y utilidad |
|---|---|
Librería para facilitar la construcción de interfaces de usuario. Además es una de las restricciones del proyecto. |
|
Lenguaje de programación que se usará para el proyecto, y otra de las restricciones. Extiende JavaScript permitiendo tipos estáticos. |
|
Plataforma de desarrollo colaborativo basada en control de versiones Git. |
|
Especificación que permite a los usuarios guardar sus datos en pods personales de manera descentralizada en lugar de en los servidores de aplicaciones tradicionales. Los clientes podrán guardar su dirección en sus pods y podrán dar permiso a DeDe para acceder a ella. |
|
Sistema de bases de datos NoSQL. Nos es especialmente útil dado que permite almacenar datos en ficheros JSON, que facilita su manipulación en React. |
|
Entorno en tiempo de ejecución para la capa de servidor. Permite gestionar las conexiones a la aplicación a partir de eventos. |
5. Vista de bloque de creación
5.1. Sistema general de caja blanca
5.2. Nivel 1
- Bloques contenidos
-
-
Dede: bloque que representa la aplicación.
-
5.3. Nivel 2
5.3.1. Dede
5.4. Nivel 3
5.4.1. GUI (Interfaz Gráfica de Usuario)
5.4.2. Capa de Datos
6. Vista en tiempo de ejecución
6.1. Añadir producto al carrito
6.2. Eliminar producto del carrito.
6.3. Inicio de sesión
6.4. Registrarse en el sistema
6.5. Ver pedidos del usuario
6.6. Ver ventas realizadas
7. Vista de despliegue
El usuario se conectará a la aplicación web (alojada en Heroku) desde el navegador, donde iniciará sesión. Los datos de la identidad del cliente están alojados en MongoDB. El backend también está alojado en Heroku. A la hora de realizar un pedido y de forma opcional, el usuario podrá acceder a su POD (alojado en un servidor de PODs externo) para obtener la dirección de envío. Para ello el usuario deberá haber añadido la dirección de su POD al registrarse en la aplicación.
8. Conceptos Transversales
8.1. Modelo de dominio
8.2. Experiencia de usuario
La interfaz de usuario deberá ser intuitiva, limpia y sencilla para facilitar al usuario el uso de la web, y que solo se preocupe en buscar los productos que quiera y pagarlos. La web estará, en principio, en castellano; ya que la tienda venderá productos dentro de España
8.3. Seguridad y consistencia
Nuestro programa está hecho de tal que garantiza la protección de los datos personales de los clientes de nuestra tienda online. Nos aseguramos de que ningún usuario sin permisos de administrador, pueda conseguir dichos permisos con relativa facilidad, siendo identificados los administradores por sus respectivos identificadores privados.
Esta seguridad no afecta para nada en la consistencia de la aplicación, los datos no se ven perjudicados en ningún momento.
8.4. Implementación
La aplicación web deberá ser persistente, guardanto tanto los datos de los productos como los de los usuarios para que se pueda acceder a ellos en cualquier momento. Para ello será clave el uso de MondoDB.
Se contará con un control de pedidos por parte de los clientes para poder registrar sus compras. Todas estás compras quedarán almacendas en la base de datos, tanto para el cliente que ha realizado su pedido, como para el administrador del sitio web, el cual tendrá control absoluto de todos los pedidos que se han solicitado en la aplicación, pudiendo modificar su estado en función de como se encuentre el pedido (procesando, enviado, recibido, etc.).
9. Decisiones de diseño
| Decisión | Ventajas | Desventajas |
|---|---|---|
Bcrypt |
Nos permite guardar las contraseñas de los usuarios de una manera segura. |
Ninguna |
Heroku |
Plataforma que permite alojar la apliacación de forma segura, estable y rápida de forma gratuita. |
No se puede almacenar archivos en el servidor. |
MongoDB |
Es de código abierto, sencillo uso con Node.js y varios miembros del equipo ya han trabajado con ella. |
Los datos serán limitados al formato JSON, por lo que su tiempo de procesamiento se eleva a mayor tamaño de datos. |
Mongoose |
Permite realizar la interacción con la base de datos de una manera sencilla. |
Ninguna |
React |
Enfocado principalmente para el desarollo de un buen Frondend. |
Poca familiarización con esta librería. |
SOLID |
Permite obtener las direcciones de los usuarios y obtener todo tipo de información de sus perfiles públicos. |
Es una tecnología que se exprime poco, hay pocas guías útiles y es complicada de utilizar por los problemas que tiene el sitio web de SOLID. |
Typescript |
Es capaz de realizar enlaces dinámicos, cosa que otros lenguajes como JS no son capaces de hacer. |
Poca familiarización con el lenguaje. |
10. Requisitos de calidad
Esta sección amplía el punto 1.2 Objetivos de calidad, describiendo los requisitos de calidad de nuestra aplicación. Los requisitos se representarán en un diagrama de árbol, 10.1 Árbol de calidad, y se explicarán en una tabla, 10.2 Escenarios de calidad.
10.1. Árbol de calidad
10.2. Escenarios de calidad
| ID | Requisito de calidad | Escenario de calidad | Prioridad |
|---|---|---|---|
1-PRI |
Privacidad |
Los datos privados de los usuarios son exclusivamente de los datos necesarios, y de forma descentralizada. |
Alta / Alta |
1-USA |
Usabilidad |
Realizaremos un cuestionario a distintas personas son capaces de resolver algún uso de la aplicación en concreto. Debemos de tener un 4 sobre 5 o más. |
Alta / Alta |
2-USA |
Usabilidad |
Las personas con daltonismo pueden usar perfectamente la aplicación al usarse tonos blancos y azules. |
Alta / Alta |
3-USA |
Usabilidad |
Los usuarios no tienen porque volver a poner la dirección donde quiere el pedido, con Solid lo hace de forma fácil y rápida. |
Alta / Alta |
1-SEG |
Seguridad |
Los datos del usuario no deben ser prestados a un tercero. |
Alta / Alta |
2-SEG |
Seguridad |
No se trabaja con booleanos para garantizas si un usuario tiene privilegios o no, se usa por tokens. |
Alta / Alta |
1-DIS |
Disponibilidad |
La aplicación está desplegada mediante Heroku, lo cuál hace que se pueda entrar siempre a la aplicación. |
Media / Alta |
1-TES |
Testabilidad |
La aplicación debe estar probada correctamente para evitar fallos, por lo que mediante la herramienta codecov mediremos el % de código probado. |
Media / Alta |
1-MAN |
Mantenibilidad |
Utilizaremos Sonarcloud para medir la calidad del código y debemos mantener una nota A en todos los apartados. |
Media / Alta |
2-MAN |
Mantenibilidad |
El código de la aplicación debe escribirse de manera que pueda modificarse y reutilizarse fácilmente. Además, es importante que los errores del sistema se puedan solucionar fácilmente. |
Media / Media |
1-Int |
Interoperabilidad |
Nuestro sistema debería poder trabajar con los mismos datos descentralizados de los usuarios que se pueden usar en otras aplicaciones. |
Media / Media |
1-POR |
Portabilidad |
Debemos probar la aplicación en los distintos navegadores (Google chrome, Mozilla Firefox y Microsoft Edge) y en los distintos dispositivos. |
Baja / Baja |
1-POR |
Portabilidad |
Debemos probar la aplicación en los distintos navegadores (Google chrome, Mozilla Firefox y Microsoft Edge) y en los distintos dispositivos. |
Baja / Baja |
11. Riesgos y deudas técnicas
| Riesgo | Explicación | Solución |
|---|---|---|
Falta de compatibilidad con otras aplicaciones. |
Falta de compatibilidad con el resto de aplicaciones si no utilizan el mismo formato de datos para la dirección que nuestra aplicación. |
Establecer un modelo de datos concreto. |
Carga de trabajo superior a la que la aplicación pueda soportar. |
La aplicación puede tener un número de peticiones superior a la que pueda soportar, lo que puede acarrear problemas. |
Realizar pruebas en la aplicación con cargas mayores de las esperadas. |
Caída del sistema de PODS. |
Inrupt puede sufrir alguna caída, haciendo que la utilización de la aplicación mediante PODS puede quedar inutilizada. |
Para solucionarlo, la aplicación permitirá al usuario su utilización sin ser usuario de PODS. |
| Deuda Técnica | Explicación |
|---|---|
Posibles fallos de las distintas bibliotecas que utilizamos. |
Las distintas bibliotecas que utilizamos podrían contener ciertos errores que impliquen fallos en nustra aplicación. |
Dependencia en Heroku para el despliegue. |
Una caída de Heroku implicaría que nuestra aplicación dejaría de estar operativa mientras dure dicha caída. |
No realizar pruebas de gatling |
No se podrá medir el nivel de "estrés" que puede soportar nuestro proyecto, por lo que no sabremos su tiempo de respuesta ante miles de consultas masivas. |
12. Glosario
| Termino | Definición |
|---|---|
Bcrypt |
Dependencia que nos permite crear para cada contraseña un hash distinto y así encriptarlas de manera segura. |
Caja Blanca (WhiteBox) |
Componente utilizado en los diagramas para referirnos a la parte visible de un componente. |
Caja Negra (BlackBox) |
Componente utilizado en los diagramas para referirnos a la parte no visible de un componente, por lo que suele ramificarse a partir de una caja blanca. |
Cors |
Dependencia para que tanto la aplicación de nodejs como la aplicacion de react puedan interactuar. |
Docker |
Docker es un proyecto que automatiza el despliegue de aplicaciones dentro de contenedores de software, proporcionando una capa adicional de abstracción y automatización de virtualización de aplicaciones en múltiples sistemas operativos. |
Dotenv |
Dependencia para externalizar en un archivo ciertos strings. |
Express |
Infraestructura de aplicaciones web para Node.js que nos permite realizar las peticiones en el back end. |
EasyPost |
API utilizada para añadir opciones de envio a productos, así como calcular distancia y precio de envio. |
HTTP |
Protocolo de transferencia de hipertexto utilizado para comunicar equipos en la red. |
Heroku |
Heroku es una plataforma como servicio (PaaS) de computación en la Nube que soporta distintos lenguajes de programación. |
Jest |
Librería para la realización de los tests de backend. |
MongoDB |
MongoDB es un programa de base de datos NoSQL que en vez de guardar datos en tablas guarda datos en estructuras BSON (similar a JSON). |
Mongoose |
Biblioteca que nos permite conectar con MongoDB desde Express. |
MUI |
Material UI es una biblioteca de componentes para la interfaz de usuario. |
Node.js |
Node.js es un entorno en tiempo de ejecución multiplataforma para la capa del servidor diseñado para crear aplicaciones escalables, permitiéndote establecer y gestionar múltiples conexiones al mismo tiempo. |
PlantUML |
Herramienta utilizada para la creación de diagramas a partir de un lenguaje de texto. |
Pod |
Pod es un contenedor, en el que se presenta un conjunto de datos al usuario. |
Principios SOLID |
SOLID se compone de una serie de principios y de buenas prácticas que os permiten administrar la mayoría de problemas de diseño de software permitiendonos tener un código más limpio, más mantenible, más escalable a futuro y menos propenso a errores. |
React |
React es una biblioteca Javascript 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. |
React Router Dom |
Librería para implementar la navegación entre URLs. |
React Split |
Librería para dividir la pantalla en varias partes con una barra deslizable para cambiar el tamaño. |
SOLID |
SOLID (Social online data) es una tecnología para organizar datos, aplicaciones e identidades en la web. |
Supertest |
Librería para realizar las pruebas de las peticiones del backend. |
Typescript |
TypeScript es un lenguaje de programación libre y de código abierto desarrollado y mantenido por Microsoft. Es un superconjunto de JavaScript, que esencialmente añade tipos estáticos y objetos basados en clases. |
13. Anexo
En este Anexo se mostrarán diferentes aspectos de la aplicación que ayudarán a entender partes que no hayan quedado explicadas por completo o que no corresponden a ninguno de los puntos de la documentación.
13.1. Modelo de datos
En el modelo de datos de nuestra aplicación, al estar usando MongoDB, tenemos 3 colecciones diferentes quue almacenan los elementos con los que interactúa la aplicación. Son las siguientes:
13.1.1. Pedidos
Son los pedidos que se realizan en la aplicación. Tiene los siguientes campos
13.1.2. Productos
Son los productos que se pueden comprar en la tienda.
13.1.3. Usuarios
Son los usuarios registrados en la página, ya sean administradores o usuarios normales.
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.