1. Introducción
1.1. Introducción y objetivos
Este proyecto nace con el objetivo principal de construir una tienda online que permita a los usuarios la compra de licores y bebidas espiritosas al precio mas competitivo. Como objetivos secundarios: - aprendizaje de tecnologias como typescript, react, solid... - mejorar nuestras habilidades sociales y de trabajo en equipo. El principal objetivo es el de agrupar una gran variedad de bebidas alcoholicas de la mejor calidad y al precio mas asequible. De esta forma cualquier persona mayor de edad puede disfrutar de un trago agradable de forma cómoda. Los requisitos funcionales son los típicos de cualquier tienda online común. Principalmente: - El sistema simulara una tienda online en la que los usuarios podran seleccionar y encargar bebidas alcoholicas. - El sistema calculará los costes de envio en función de las caracteristicas del mismo. - El sistema mostrará los costes finales y permitirá al usuario finalizar su compra - El usuario podrá visualizar sus pedidos. - El usuario podrá visualizar un catálogo de bebidas clasificadas en categorias. - El administrador podrá añadir nuevos productos. - El administrador podrá visualizar los pedidos realizados.
1.2. Atributos de calidad
| Atributos | Descripción |
|---|---|
Usabilidad |
Es de gran importancia que la aplicación sea entendida con gran facilidad con el objetivo principal de maximizar las ventas. |
Disponibilidad |
Tratandose de una tienda es fundamental que los servicios que esta ofrece estén disponibles el mayor tiempo posible. |
Seguridad |
La confidencialidad de los datos de nuestro clientes es una prioridad. |
Testeabilidad |
De cara al correcto desarrollo y funcionamiento, consideramos importante tener presente las pruebas en todas las etapas del trabajo y facilitar todo lo posible su construcción y uso. |
1.3. Stakeholders
| Role/Nombre | Expectaciones |
|---|---|
Profesores |
Interesados en el desarrollo de la funcionalidad, arquitectura y documentación de la aplicación. |
Clientes Potenciales |
A los que va destinado el producto final y para los que van destinados los requisitos funcionales. |
Miembros del grupo del desarrollo |
Como estudiantes confiamos en mejorar nuestras habilidades sobre las tecnologías tratadas en este trabajo y obtener un resultado satisfactorio. |
Otros estudiantes |
Esperan una buena aplicación que puedan tomar como ejemplo y obtener información util que pueda ser reutilizada en proximos proyectos. |
2. Requisitos de arquitectura
2.1. Restricciones técnicas
| Restricción | Explicación |
|---|---|
Docker |
Contenedores docker empleados para el despliegue de la aplicación. |
Solid app |
Tecnología fundamental para poder garantizar la confidencialidad de los datos manejados de forma que se conforma una red de persistencia descentralizada. |
Typescript |
Lenguaje de programacion empleado para la implementación de la lógica de negocio del sistema. |
React |
Es la librería que sera utilizada para la construcción del front-end del sistema. |
Node.js |
Es un entorno en tiempo de ejecución multiplataforma para la capa del servidor basado en el lenguaje de programación JavaScript |
2.2. Organización
| Restricción | Explicación |
|---|---|
Tiempo / planificación |
El sistema debe de cumplir con los requisitos funcionales planteados antes de la última entrega de la asignatura. Asi como cumplir con las entregas parciales solicitadas. |
Control de versiones |
Como decisión impuesta se debe utilizar control de versiones con git para gestionar el desarrollo del proyecto. |
Equipo fijo |
El equipo es impuesto por la organización de la asignatura, tanto su tamaño como sus integrantes. |
2.3. Normas
| Restricción | Explicación |
|---|---|
Ley orgánica de protección de datos |
A nivel de cumplimiento de la legislación española debemos tener especial cuidado en el trato de los datos sensibles de los usuarios de nuestra aplicación. |
Idioma |
Se empleará el idioma castellano tanto en la documentación como en la implementación de la aplicación aunque se podrá internacionalizar en un futuro._ |
Arc42 |
Como decisión impuesta debemos seguir esta plantilla para la realización de esta documentación. |
3. System Scope and Context
3.1. Business Context
3.1.1. Leyenda:
DeDe
Canal de comunicación entre el usuario y el sistema. El sistema muestra al usuario los productos disponibles que puede comprar.
Pod de Solid
El usuario contará con su propio Pod, donde almacenará su información personal. DeDe, con permiso del usuario, accederá a la misma para conocer sus datos personales.
Base de datos MongoDB
La base de datos MongoDB contendrá el catálogo de productos que ofrece DeDe.
Plataforma de pago
El sistema incluye una plataforma de pago (ficticia en nuestro caso) que permite llevar a cabo la compra de los productos deseados.
API envío
El sistema utilizará una API que permitirá al usuario escoger entre diferentes portadores.
3.2. Technical Context
La aplicación se basa en un sistema descentralizado para la cual se usó la tecnología SOLID que permite garantizar la confidencialidad de los datos manejados de forma que se conforma una red de persistencia descentralizada. Cada usuario es propietario de su información personal la cual se gestionará mediante un SOLID POD. De esta manera es el propio usuario el que decide qué datos son públicos o privados y con quien los comparte. Por temas de eficiencia algunos de los datos se guardarán en una base de datos, en este caso MongoDB.
La aplicación esta implementada utilizando el framework React, que 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, y Typescript, que es un superconjunto de JavaScript, que esencialmente añade tipos estáticos y objetos basados en clases.
4. Solución Estratégica
| Tecnología | Descripción |
|---|---|
Typescript |
Es un lenguaje de programación orientado a objetos, que permite crear aplicaciones web más dinámicas y escalables. Es una restricción del proyecto |
React |
Es una librería de JavaScript que permite crear interfaces de usuario sencillas y dinámicas. Es una restricción del proyecto |
Node.js |
Es un entorno de ejecución de JavaScript en un entorno de servidor. Es una restricción del proyecto |
Boostrap |
Es una librería de diseño de páginas web que nos permite crear interfaces de usuario sencillas y dinámicas. |
SOLID |
Es un proyecto de descentralización de datos en la web. Es una restricción del proyecto |
Git |
Es un sistema de control de versiones de software. Es una restricción del proyecto |
GitHub |
Es una plataforma de control de versiones Git. Es una restricción del proyecto |
MongoDB |
Es una base de datos NoSQL orientada a documentos. |
Heroku |
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. La usamos para el despliegue de nuestra aplicación. |
Shippo API |
API que usamos para calcular el coste de los envíos. |
5. Building Block View
5.1. Nivel 1
En este nivel aparecen los grandes protagonistas de nuestro sistema.
| Nombre | Descripción |
|---|---|
NoVendoAgua |
Aplicación desarrollada con el propósito de que haga las veces de licorería online. |
POD SOLID |
El usuario almacenará su información confidencial aquí. |
MongoDB |
Servirá para almacenar información sobre los productos y pedidos de la tienda. |
5.2. Nivel 2
Este nivel desglosa el módulo NoVendoAgua en dos subapartados.
| Nombre | Descripción |
|---|---|
WebApp |
Parte frontal de la aplicación. El usuario se conecta a ella y ésta le ofrece una vista del sistema. |
RESTAPI |
Encargada de la conexión con los sistemas de persistencia, así como de la lógica de negocio. |
6. Vista en tiempo de ejecución
6.1. Regitsro de usuario
6.2. Autentificación del usuario
6.3. Filtrado de productos
6.4. Añadir productos al carrito
6.5. Eliminar productos del carrito
6.6. Tramitar pedido
7. Deployment View
7.1. Infrastructura Level 1
7.2. Objetivo
El objetivo de esta estructura de despliegue es conseguir un sistema descentralizado. Con las premisas de almacenar los mínimos datos de los usuarios, la privacidad de dicha información asi como la seguridad de la misma.
7.3. Calidad y/o Características de Actuación
Al tratarse de una tienda online, es nuestra prioridad producir un front-end que cuente con las caracteristicas de una aplicación usable. Además de un back-end que cumpla con los requisitos de calidad propuestos, asi como un minimo de rendimiento. Con el objetivo de desarrollar el condigo más limpio y eficiente posible usaremos codecov. Se trata de un software que permite monitorizar el codigo que esta siendo ejecutado en las pruebas y el que no. Asi se puede comprabar que elementos son los menos testeados para ponerle solución y mejorar la calidad del código.
7.4. Mapeo de bloques de construcción para infraestructura
| Atributos | Descripción |
|---|---|
devices |
son los dispositivos desde los que los usuarios pueden acceder a nuestra aplicación. Al tratarse de una aplicación web, los dispositivos podran ser cualquiera que pueda navegar por internet. |
browsers |
software que emplean los usuarios para visualizar el contenido de nuestra aplicación web. Deberá ser compatibles con los mas utilizados (Chrome, Firefox, Safari, Microsoft edge). |
web server |
es el servidor que dará host a nuestra aplicación web. |
Base de datos |
es la base de datos en la que persistiremos los datos de nuestra aplicación. |
SOLID |
Donde almacenaremos (de forma segura) los datos de los usuarios en PODs. |
PODs |
contendrá los datos de cada usuario concreto de forma que exitira un POD por usuario. |
8. Conceptos transversales
8.1. Modelo de dominio
8.2. Experiencia de usuario
8.3. Internacionalización
8.4. Seguridad y Privacidad
8.5. Pruebas
9. Decisiones de diseño
-
El idioma de la documentación será el castellano, pues es el lenguaje nativo de los miembros del equipo y nos resultará más claro y comprensible en este idioma.
-
Uso de la bilbioteca Boostrap para la elaboración de las hojas de estilo de tal forma que nuestra aplicación resulte más atractiva visualmente para los usuarios.
-
Uso de la bilbioteca React Hot Toast con el objetivo de que el usuario sea máx consciente de las acciones que realiza a lo largo del tiempo que permanezca en la página mediante notificaciones.
-
Uso de la bilbioteca Yup para informar al usuario en el momento del login y registro la longitud y características mínimas que han de cumplir su nombre de usuario y contraseña.
-
Dado que nuestro proyecto será creado junto al proyecto Solid, algunos de nuestros datos serán almacenados en los Solid Pods. Junto a esto, la base de datos que utilizaremos será no relacional (documental), concretamente MongoDB en la nube. El principal motivo de esta decisión es la sinergia con la que cuenta esta base de datos con el lenguaje de desarrollo del proyecto.
-
La delegación del cálculo de costes de envío según las caracteristicas concretas de cada compra será delegada a Shippo. Mediante su API obtenemos datos del envio tales como los costes y la duración del mismo. Elegimos su API ya que solo nos pide dirección de origen, dirección de destino y poco más para proporcionarnos los datos de distintas compañias de reparto.
-
Uso de la plataforma Heroku para el despliegue de la aplicación. Elegida por tener un uso mas simple que sus alternativas y ser mas practico al darnos una ip estatica en contraposición con AWS. Tambien por la existencia de más ejemplos de despliegues de aplicaciones similares a la nuestra en esta plataforma.
-
Emplear los servicios de gestión de contenidos multimedia que proporciona la herramienta cloudinary. Esta decisión está motivada sobretodo por la mala experiencia subiendo las imagenes a Heroku. Por ello, y en adición a ahorranos la memoria que pueda ocupar el contenido multimedia de la aplicación, decidimos subir nuestras imagenes a la nube de cloudinary y accederlas mediante una URI.
10. Requerimientos de Calidad
10.1. Árbol de calidad
10.2. Escenarios de calidad
| Atributos de Calidad | Escenarios de Calidad | Prioridad |
|---|---|---|
Usabilidad |
Los usuarios deben saber manejarse por la aplicación fácilmente con el objetivo de que comprar cualquier tipo de producto sea una tarea fácil y rápida. A pesar de esto, no necesitamos que sea muy elevado ya que se trata de un proyecto universitario, no va a ser usado por personas ajenas. |
Baja |
Privacidad |
El objetivo principal que desemaos alcanzar es la protección de los datos de usuarios finales para así se llevar a cabo la descentralización de datos personales y con ello mejorar el nivel de privacidad de los usuarios. |
Alta |
Testeabilidad |
Realización de pruebas unitarias, pruebas de aceptación y de carga para comprobar el correcto funcionamiento de la aplicación |
Media |
Robustez |
La aplicación debe ser robusta para que los productos mantengan sus características únicas |
Media |
Rendimiento |
El tiempo en que un usuario tarda en realziar alguna petición no los consideramos tan importante como pueden ser otros atributos. Aún así, si creemos que debemos proporcionar un rendimiento aceptable para que al usuario no le resulte largo y desaprovechado el tiempo que esté en nuestra aplicación |
Baja |
11. Riesgos y deuda técnica
Por una parte, entenderemos riesgos como aquellas circunstancias potenciales negativas que aún no han ocurrido. A continuación indicamos los riesgos identificados, así como medidas propuestas para paliarlos o mitigarlos.
| Riesgo | Medida propuesta |
|---|---|
Uno o más miembros del equipo podrían abandonar la asignatura |
Asignaremos varias personas a cada tarea, especialmente a las que resultan críticas |
Carecemos de experiencia en las tecnologías incluídas en las restricciones |
De forma paralela a desarrollar la documentación, realizaremos acciones formativas aprovechando la gran cantidad de recursos existentes en Internet |
La entrega es en mayo de 2022 y puede que no lleguemos a tiempo |
Celebraremos reuniones semanales donde analizar el estado actual del proyecto y ajustaremos el volumen de trabajo conforme a ello |
Por otra parte, consideramos la deuda técnica como algo inevitable en nuestro proyecto. Por falta de conocimiento o por llegar apurados a un plazo puede que no siempre desarrollemos software óptimo. Para evitar que esto nos lastre en el futuro:
-
Volveremos frecuentemente sobre nuestro código, refactorizándolo siempre que sea necesario.
-
Llevaremos a cabo revisiones de código entre miembros del equipo por medio de la funcionalidad de pull requests de Github.
12. Glosario
Término |
Definición |
Solid |
Proyecto de descentralización de datos en la web que permiten al usuario final decidir dónde se van a almacenar sus datos mejorando así la privacidad. |
TypeScript |
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. |
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. |
Stakeholder |
Entidad que afecta, es afectado o puede contribuir al sistema y su arquitectura, entendiendose entidad como persona, organizacion, empresa, etc. |
MongoDB |
Sistema de base de datos NoSQL, orientado a documentos y de código abierto.MongoDB guarda estructuras de datos BSON (una especificación similar a JSON) con un esquema dinámico, haciendo que la integración de los datos en ciertas aplicaciones sea más fácil y rápida. |
Docker |
Conjunto de plataformas que utilizan la virtualización para entregar software en paquetes denominados contenedores. |
Node.js |
Entorno de tiempo de ejecución JavaScript de código abierto que ejecuta código JavaScript fuera de un navegador web. |
POD |
Los pods, personal online data stores, son como servidores web personales seguros para tus datos. Puedes almacenar cualquier tipo de información en un Pod de Solid, utilizando formatos y protocolos de datos estándar, abiertos e interoperables. Además, controlas el acceso a los datos de tu Pod y decides con quién quieres compartir qué datos. Puedes revocar el acceso en cualquier momento. |
Bootstrap |
Framework muy popular que facilita el desarrollo web ofreciendo clases predefinidas en CSS y JavaScript. |
MongoDB |
Base de datos documental. |
Express |
Es un marco de aplicación web de back-end para Node.js diseñado para crear aplicaciones web y API. |
Shippo |
Compañía de software estadounidense que ayuda a las empresas de comercio electrónico a integrar el envío con múltiples transportistas a través de su API y aplicación web. |
Heroku |
Heroku es una plataforma como servicio de computación en la Nube que soporta distintos lenguajes de programación. |
Cloudinary |
Cloudinary es una empresa de tecnología SaaS. La empresa ofrece servicios de gestión de imágenes y vídeos basados en la nube. |
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.