1. Introducción y Objetivos
DeDe (Decentralized Delivery) es un sistema de venta online a crear por una empresa de venta de productos. Esta estará basada en los principios SOLID, y estará diseñada de tal manera que cualquier persona podrá acceder a la tienda virtual con un sistema que asegurará la privacidad y la seguridad.
1.1. Descripción general de los requisitos
-
Requisitos funcionales:
-
El sistema emulará un sistema de compra online donde los usuarios finales podrán seleccionar y encargar productos a comprar.
-
Una vez que el usuario seleccione los productos a comprar, el sistema calculará los costes de envío consultando la dirección deseada del usuario en su pod y calculando los costes de acuerdo a la distancia del centro de distribución a dicha dirección.
-
El sistema mostrará los costes finales de los productos a comprar y una vez que el usuario decida comprarlos, registrará el evento que simulará que la venta ya ha sido realizada y se procederá al envío correspondiente.
-
El sistema permitirá a los usuarios visualizar los pedidos realizados.
-
-
Requisitos no funcionales:
-
La aplicación debe ser implementada utilizando el framework React y Typescript.
-
La aplicación deberá ser accesible y estar desplegada utilizando un sistema de integración continua.
-
El sistema debe de ser compatible con el proyecto SOLID.
-
1.2. Objetivos de calidad
Ordenados de mayor a menor prioridad:
| ID | Objetivo | Descripción |
|---|---|---|
RC1 |
Privacidad |
El sistema deberá prestar especial atención a la seguridad y al respeto de la privacidad de los usuarios |
RC2 |
Usabilidad |
La aplicación debe ser fácil e intuitiva de usar para todos los usuarios, estos no deberían de tener dudas de cómo se usa. |
RC3 |
Rendimiento |
La aplicación deberá de tener una capacidad de respuesta lo suficientemente rápida. |
RC4 |
Mantenible |
El sistema seguirá unos estándares los cuales permitirán que los cambios que se quieran realizar sean fáciles de integrar. |
RC5 |
Calidad |
Se creará un sistema con calidad, testeando este con diferentes pruebas unitarias y con personas reales antes de la solución final. |
1.3. Stakeholders
| Role/Nombre | Contacto | Expectativas |
|---|---|---|
Clientes |
Profesores de la asignatura de Arquitectura del Software |
Son los encargados de supervisar el proyecto, asegurándose de que este cumpla los requisitos establecidos |
Usuarios |
Usuarios de la aplicación |
Interés en la aplicación final y el uso de esta |
Equipo de desarollo |
Equipo encargado de llevar a cabo el desarrollo de la aplicación (en este caso, el grupo ES5-C) |
Desarrollo de una aplicación segura, que respete la privacidad y con los requisitos establecidos, utilizando las nuevas tecnologías |
Profesores |
Supervisión de como se lleva a cabo el proyecto |
Prestación de ayuda al equipo de desarrollo y correcciones. |
2. Restricciones de la Arquitectura
2.1. Restricciones técnicas
| Restricción | Descripción |
|---|---|
Despliegue |
La aplicación debe de estar desplegada |
SOLID - PODs |
La aplicación debe de ser compatible con la tecnología SOLID, almacenando los datos en los PODs de los usuarios. |
Pruebas |
Se deben realizar pruebas a lo largo del desarrollo del sistema para comprobar ek buen funcionamiento de este. |
Docker |
El sistema tiene que poder ser desplegable en contenedores Docker. |
Git (GitHub) |
El sistema va a ser alojado en un repositorio público compartido por los compañeros y por los profesores de la asignatura. |
2.2. Restricciones organizativas
| Restricción | Descripción |
|---|---|
Tiempo (fecha de entrega) |
La aplicación debe estar acabada y desplegada para la fecha de entrega asignada. |
Equipo |
Los equipos están formados por miembros de 5 o 6 personas. |
2.3. Convenios
| Restricción | Descripción |
|---|---|
Presupuesto |
Las herramientas usadas son gratuitas. |
arc42 |
La documentación debe seguir arc42. |
3. Alcance y Contexto del Sistema
El objetivo principal de este proyecto es crear un sistema para gestionar una empresa de venta de ropa, respetando la privacidad de los clientes siguiendo los principios SOLID y almacenando los datos de estos en pods. Un pod es un espacio de almacenamiento propio de cada usuario donde se guarda su información.
3.1. Business Context
| Socio de comunicación | Entradas | Salidas |
|---|---|---|
Pod |
Datos descentralizados de cada usuario |
|
DeDe |
Información de los usuarios de los pods |
Interfaz para realizar la compra |
Usuario |
Interfaz para realizar compra o gestionar su cuenta |
Datos sobre él mismo (siempre que de los permisos necesarios) |
3.2. Contexto Técnico
| Tecnología | Descripción | SOLID |
|---|---|---|
Usados para respetar la privacidad de los clientes |
MongoDB |
Sistema de base de datos NoSQL usado para almacenar los datos de los usuarios |
TypeScript |
Lenguaje de programación usado para desarrollar la aplicación. Superconjunto de Javascript |
React |
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 |
Heroku |
Plataforma como servicio de computación en la Nube que soporta distintos lenguajes de programación |
4. Estrategia de Solución
4.1. Decisiones tecnológicas
Se usarán las siguientes tecnologías a lo largo del desarollo del prollecto.
Tecnología |
Razón |
TypeScript |
Usado como lenguaje principal para el desarollo del sistema |
React |
Usado para el desarrollo de la aplicación web |
Node.js |
Entorno de ejecución para JavaScript |
MongoDB |
Usado para almacenar los datos de los usuarios |
Heroku |
Usado para desplegar la aplicación web |
MapBox Api |
Calcula la distancia desde el centro de distribución hasta el cliente |
4.2. Decisiones organizativas
Se tendrán en cuenta los siguientes aspectos desde el punto de vista organizativo
Reuniones |
Realizaremos una reunión semanal en la que cada componente del grupo indcará lo que ha hecho respecto a la anterior reunión, lo que hará antes de la siguiente reunión y si algún factor le esta bloqueando en su tranajo. |
GitHub |
Cada componente del grupo trabajará en su propia rama . Así mismo tendremos una rama develop para juntar las ramas individuales del proyecto en desarrollo, y una rama master en la cual se encontrará el producto final. |
4.3. Objetivos de calidad
Objetivo de calidad |
Razón |
Usabilidad |
El usuario tiene que aprender a usar la aplicación fácilmente y la interfaz debería de ser intuitiva |
Robustez |
El usuario espera NO encontrar errores ni bugs mientras navega por la aplicación |
Privacidad |
El usuario debe sentir que sus datos van a ser usados de una manera que garantice su seguridad |
5. Vista de bloque de creación
5.1. Sistema general de caja blanca
Este es un esquema de cómo es la aplicación en el nivel más general
El usuario interacciona con la aplicación, y esta, con el POD del usuario, la base de datos de Mongo y la API Distance Matrix de Google.
5.2. Nivel 2
5.2.1. Servidor de DeDe
La aplicación consta de dos partes, el front, hecho en React con el cual el usuario va a interactuar, y el back, hecho en Node.js que se encargará de hacer cualquier consulta con la base de datos, el POD del usuario o la API.
5.3. Nivel 3
Front end y back end desarrollado
6. Vista de Tiempo de Ejecución
6.1. Iniciar sesión
-
Inicio de sesión en la aplicación web
6.2. Comprar producto
-
Compra de un producto en la aplicación web
7. Vista de Despliegue
La aplicación se desplegará utilizando la plataforma Heroku
Para que la aplicación funcione correctamente primero hay que desplegar el docker del back, es decir, la API REST de la aplicación, y luego el docker del front, la aplicación web.
Se realizarán consultas a la API de MapBox.
La base de datos estará alojada en la nube de MongoDB.
Por último, tendremos los distintos PODs de SOLID de los usuarios.
8. Conceptos Transversales
8.1. Modelo de Dominio
En nuestro caso, solo tendremos un Centro de Distribución para todos nuestros pedidos, facilitando así el añadir un producto no siendo necesario buscar el centro más cercano ni nada por el estilo.
8.2. Seguridad
La aplicación es segura debido a que el usuario tiene el control sobre los datos que usa la aplicación. Además se controlará el acceso a la aplicación mediante un sistema de roles.
8.3. Logging
El usuario se identificará en la aplicación con su usuario y contraseña utilizando el logger de SOLID. Si la identificación es correcta se le redirigirá a la vista correspondiente. En caso contrario se mostrará un mensaje de error y seguirá en la vista de identificación.
8.4. Internacionalización
La aplicación estará en idioma español, no se realizará en otro idioma.
8.5. Test Carga Añadir Al Carrito
Resultado del test de carga que simula el añadir un producto al carrito
8.6. Test Login
Resultado del test de carga que simula el proceso de login
8.7. Test Carga Ver Perfil
Resultado del test de carga que simula el ver el perfil del usuario
9. Decisiones de Diseño
| Contexto | Decision |
|---|---|
Debemos almacenar los datos de la cuenta del usuario para validar cuando estos se logean que es una cuenta existente y para almacenar las nuevas cuentas que los usuarios creen. Así almacenaremos también información relativa a los productos que ofrecerá nuestra web o los pedidos |
Hemos decidido almacear dichos datos en una base de datos centralizada. Finalmente utilizaremos MongoDB como base de datos. |
Necesitamos una API la cual nos calcule la distancia entre el centro de distribución y la localización del cliente. |
Utilizaremos la API de Mapbox para calcular el coste de envío del pedido |
Necesitamos obtener los datos de la dirección del usuario que realiza el pedido sin almacenarlos en la base de datos |
Utilizaremos un sistema basado en PODS para obtener estos datos del cliente. |
10. Requisitos de calidad
10.1. Árbol de calidad
10.2. Escenarios de calidad
| Escenario | Atributo calidad | Prioridad |
|---|---|---|
El sistema no guardará los datos personales del cliente cuando este se registre |
Privacidad |
Alta |
La aplicación deberá ser intuitiva y contar con una interfaz clara que mantenga los estándares de otras webs como ubicación de componentes como el carrito y otras funciones |
Usabilidad |
Alta |
Los errores detectados deberán ser fácilmente solucionables |
Mantenibilidad |
Alta |
La aplicación tendrá tiempos de espera razonables ante las interacciones del cliente |
Rendimiento |
Baja |
Será fácil hacer pruebas para probar el correcto funcionamiento de la aplicación |
Testeabilidad |
Media |
11. Riesgos y deuda técnica
Lista de riesgos:
-
Falta de experiencia con los framework React y React Native. Tendremos que documentarnos antes de empezar a usarlo. Para ello veremos los videos recomendados en clase y mantendremos una buena comunicación para que los bloqueos técnicos de un integrante puedan ser rápidamente suplidos gracias a la ayuda del equipo.
-
Poca experiencia con JavaScript y experiencia nula con Node.js. Tendremos que informarnos de su funcionamiento antes de comenzar a utilizarlos.
-
Poca experiencia y poca información sobre como utilizar los PODs de SOLID.
-
Deuda técnica: Tendremos que estar atentos constantemente para reducir al máximo la deuda técnica, ya que el no prestarle atención podría conllevar un crecimiento exponencial de la misma que podría dar lugar a bloqueos que podemos evitar prestándole atención a que la deuda no se dispare.
-
Heroku: Falta de experiencia del equipo realizando despliegues de aplicación con heroku.
12. Glosario
| Term | Definition |
|---|---|
SOLID |
Proyecto de descentralización de datos cuyo objetivo es que el sea usuario quien decide dónde almacenar sus datos. |
Pod |
Almacenamiento personal de datos alojado en un servidor elegido por el usuario. |
Descentralizado |
Los usuarios pueden elegir donde almacenar sus datos |
MongoDB |
Sistema de base de datos NoSQL, orientado a documentos y de código abierto. |
NoSql |
Base de datos no relacional |
API |
Protocolo que se utiliza para diseñar el software de las aplicaciones. |
React |
Biblioteca Javascrypt que nos ayuda a crear interfaces de usuario de forma sencilla. |
Heroku |
Plataforma que nos permite desplegar nuestra aplicación |
Whitebox |
Componente que muestra componentes que tiene dentro de el |
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.