1. Introducción y objetivos

DeDethlon es un sistema de venta online creado para una empresa de venta de productos relacionados con el deporte. La aplicación respeta la privacidad de los clientes siguiendo los principios SOLID.

Por tanto, el sistema no almacenará información de los clientes, obtendrá aquella para la que los usuarios den permiso.

1.1. Descripción de los requisitos

Los requisitos funcionales que ofrecerá nuestra aplicación serán los siguientes:

  • Los usuarios podrán seleccionar y encargar productos a comprar.

  • El sistema se encargará de calcular los costes de envío dependiendo de la distancia que haya entre el centro de distribución y la dirección que tenga el usuario en su pod.

  • El sistema mostrará costes finales de toda la compra y cuando el usuario acepte, registrará el evento que simula la venta realizada y se procederá al envío.

  • Los usuarios podrán visualizar los pedidos realizados.

1.2. Objetivos de calidad

Prioridad Meta Motivación

1

Calidad

La aplicación debe satisfacer las necesidades del usuario, con un correcto funcionamiento.

2

Usabilidad

La aplicación debe ser fácilmente usable por cualquier usuario, con mucha o poca experiencia.

3

Privacidad

La aplicación debería utilizar la información de los usuarios estrictamente necesaria.

1.3. Partes interesadas

Rol/Nombre Expectaciones

Profesores

Esperan una aplicación que sea completamente funcional y que cumpla con los requisitos de la asignatura.

Equipo de desarrollo

Esperan aprender las tecnologías necesarias para desarrollar un proyecto.

Clientes

Se encargarán de probar que la aplicación realmente le ofrece los servicios que se expongan.

2. Restricciones de la arquitectura

2.1. Restricciones técnicas

Restricción Descripción

Solid

Para proteger la privacidad del usuario estamos obligados a usar los pods de SOLID

React

El front end de la tienda debe estar realizado con la biblioteca React

Typescript

El único lenguaje de programación usado debe ser Typescript

GitHub

Para la gestión del código, tareas y seguimiento general del proyecto se debe usar GitHub

2.2. Restricciones organizativas

Nombre Responsabilidad

Tiempo

El tiempo del que disponemos es limitado y tiene que ser repartido con más asignaturas, además para la parte de código disponemos de menos de 2 meses

Equipo de 5 personas

Somos 5 personas con disparidad de horarios y de tiempo disponible lo cual dificulta la organización

2.3. Restricciones Convenios

Nombre Responsabilidad

Documentación en arc42

La documentación debe seguir la plantilla de arc42

Idioma

Tanto el proyecto como la documentación serán realizados en idioma español

Coste de herramientas

Toda herramienta o servicio que se use en el proyecto debe ser gratuita o disponer de licencia educativa

3. Contexto y Alcance del Sistema

3.1. Contexto de negocio

Business Context
Cliente

El usuario o cliente es una persona interesada en acceder a nuestra página para ver y potencialmente comprar alguno de nuestros productos.

DeDe-Website

Representa nuestro producto, la página web, donde se alojan los productos y donde los clientes pueden hacer sus pedidos.

User Pod

Consiste en un almacén de datos descentralizado bajo la especificación Solid y cuyo propietario (el cliente) puede permitir el acceso a parte de la información para el correcto funcionamiento de nuestra página web.

3.2. Contexto técnico

El producto consiste en una página web comercial alojada en un servidor/nodo y que se comunica con el backend (DeDe-RestApi), que encuentra en otro nodo, mediante protocolo HTTPS. Además, para respetar la privacidad de nuestros consumidores, hacemos uso de las especificaciones Solid. Para obtener esta característica, nuestro frontend se comunica con el proveedor del Pod del usuario.

Finalmente, existe una base de datos MongoDB para el almacenamiento de datos.

Technical Context

4. Estrategia de solución

4.1. Decisiones tecnológicas

Las tecnologías usadas en nuestra aplicación van a ser las siguientes:

  • React: es una biblioteca de código abierto de JavaScript diseñada para crear interfaces de usuario y también simplifica la portabilidad de la aplicación entre plataformas. Con esta herramienta vamos a crear la interfaz de usuario de nuestra aplicación.

  • GitHub: herramienta donde guardaremos el código de nuestra aplicación.

  • Solid: nuestra aplicación tiene que seguir estos principios de descentralización de la información del usuario.

  • MongoDB: es una base de datos orientada a documentos. Esto quiere decir que en lugar de guardar los datos en registros, guarda los datos en documentos. Una de las diferencias con las bases de datos relacionales, es que no necesita seguir ningún esquema. Esta clasificado como una base de datos NoSql.

  • MVC: es un patrón que seguiremos en nuestra aplicación. Es un patrón arquitectónico usado para aplicaciones que necesitan una interfaz de usuario.

  • Typescript: es el lenguaje que usamos en nuestra aplicación.

  • Tailwind UI: es el frameworks de CSS que vamos a utilizar en la aplicación.

  • API Shippo: es una api que se usa para calcular los costes de envio. Se elije porque tiene su propia blioteca para node y permite consultar los costes de envio sin necesidad de validar direcciones o preocuparse de impuestos y tasas de aduanas. También dispone de un entorno de pruebas gratuito.

  • Gatling: programa para realizar los test de carga.

4.2. Objetivos de calidad

Privacidad

Queremos que nuestra aplicación sea un lugar seguro, así que nos centraremos en la privacidad de los usuarios y de sus datos. Debemos almacenar la menor cantidad de información del usuario, ya que esto aumenta su privacidad y reduce la posibilidad de que el usuario sea atacado.

Usabilidad

Un objetivo de nuestra aplicación es que sea usable, es decir, que sea facil de entender y usar. La usabilidad es la disciplina que estudia la forma de diseñar aplicaciones para que los usuarios puedan interactuar con ellos de la forma más fácil, cómoda e intuitiva posible

Para conseguir este objetivo tenemos que crear nuestra aplicación realizando un diseño centrado en el usuario, es decir, nuestra aplicación esta diseñada por y para el usuario.

Eficiencia

Necesitamos que nuestra aplicación sea eficiente, es decir, que haga lo que nosotros queremos que haga y no otra cosa. Desde el punto de vista del usuario, esto significa que cuando entre en la aplicación, se encuentre lo que el queria y no le sea dificil encontrar lo que necesitaba, ya que si no el usuario optara por abandonar la aplicación.

Robustez del sistema

Un sistema robusto es un sistema fuerte, sin debilidades ni vacíos de seguridad. La robustez en un programa informático hace referencia a su capacidad para hacer frente a errores mientras se está ejecutando.

Para cumplir este objetivo, tendremos que crear nuestra aplicación centrándonos en que cuando el usuario la utilice no encuentre errores, o en caso de encontrarlos, que no afecten al correcto funcionamiento de la aplicación.

4.3. Decisiones organizativas

  • Uso de ramas: para desarrollar la documentación hemos creado un rama doc, sobre la que realizaremos los cambios individualmente y haremos un pullRequest sobre la rama dev. Finalmente, cuando la documentación este completa la pasaremos a la rama Master, que es la rama principal del proyecto.

  • Issues: para organizar las distintas tareas que tenemos que realizar para continuar con nuestra aplicación.

  • Discussions: usamos esta funcionalidad de gitHub para dejar constancia de deciones importantes (modelo de datos por ejemplo) y para realizar votaciones.

  • Tableros del proyecto: es una manera de que todo el equipo pueda ver como van las tareas pendientes. Es decir, se puede ver que tareas aún no se han empezado, cuáles están en proceso y cuáles ya se han finalizado. Hemos decidido tener varios tableros para el desarrollo del proyecto.

    • Tablero general: que es donde hemos colocado los issues de la documentación, y donde colocaremos los issues que correspondan con tareas generales del proyecto.

    • Tablero frontEnd: donde colocaremos todos los issues relacionados con la parte de desarrollo del frontEnd.

    • Tablero backEnd: donde colocaremos todos los issues relacionados con la parte de desarrollo del backEnd

    • Tablero base de datos: donde colocaremos todos los issues relacionados con la creación y gestión de la base de datos.

5. Vista de bloque de creación

5.1. Sistema general de caja blanca

El diagrama que esta a continuacion muestra una descripcion general de los componentes básicos de la aplicación, y muestra la descomposición estática de cada nivel del sistema, y la dependencia entre ellos.

Diseño general del sistema

5.2. Nivel 1

El sistema general se representa en una caja blanca y se compone de diferentes elementos como la caja negra y los bloques de construcción. El usuario interactúa con su propio Pod sobre el cual tiene control y en el que estan sus datos. El usuario realiza operaciones como crear o modificar los permisos sobre sus datos. También interactúa con la aplicación , que se representa como un cuadro negro en este diagrama. Por otro lado, la aplicación interactúa con el Pod para poder acceder a los archivos que se encuentran en él, pudiendo guardar y cargar datos.

Nivel 1

5.3. Nivel 2

Busca intercomunicar la interfaz de usuario ("Front End"), la lógica de negocio ("Back End") y el sistema de autenticación. El Front End necesita los servicios de la capa "Back End" para que le envíe datos y resultados de acciones para que pueda mostrárselos al usuario. Por otro lado, el "Front End" interactúa con el sistema de autenticación para que el usuario pueda iniciar sesión con su WebID o a través de un proveedor. Y el "Back End" también está relacionado con el sistema de autenticación, para poder acceder a los datos del POD del usuario que se encuentra actualmente en sesión.

Nivel 2

Table 1. Descripción del nivel 2
Nombre Responsabilidad

Autenticación del sistema

Se encarga del inicio de sesión mediante la verificación de la cuenta del usuario.

Front End

Interactúa con el usuario final, recopila los datos de entrada proporcionados por él y muestra toda la información relacionada con las acciones realizadas por él dentro de la aplicación

Back End

Recibe los datos proporcionados por el usuario a través del módulo "Front End", los procesa y realiza las operaciones necesarias obteniendo resultados que son enviados, nuevamente, al módulo mencionado anteriormente.

5.4. Nivel 3

El tercer nivel se divide en el "Front End" en las vistas principales de inicio de sesión y las que añadiremos más adelante. Las credenciales ingresadas en "LoginView" serán verificadas por el LoginManager que es responsable de acceder al pod del usuario y permitir el acceso a la aplicación.

Nivel 3

Table 2. Descripción del nivel 3
Nombre Responsabilidad

Administrador de inicio de sesión

Administra las credenciales de inicio de sesión del usuario conectándose a su pod.

Administrador de solicitudes

Manejar la lógica para obtener los solid que tiene el usuario.

6. Runtime View

6.1. Registro de nuevo usuario

Para comprar se requiere estar registrado, un nuevo usuario elegirá la opción de registrarse, la vista le mostrará un formulario de registro que al rellenarse se manda al servidor donde se envían a la base de datos para almacenarse.

register

6.2. Añadir producto al carrito

El usuario elige un producto a añadir, se añade en el carrito

Añadir a carrito

6.3. Logeo de usuario

El usuario pulsa en el botón de loguearse, ahí introduce su nombre de usuario y contraseña, si existe el usuario en la base de datos y la contraseña es correcta, le devolverá a la página de inicio. Si no se mantendrá en la vista de login

Login

6.4. Ver carrito

Una vez un usuario esté logueado y quiera ver su carrito tendrá que darle al botón del carrito, al pulsarlo se buscarán todos los productos que tenga ese usuario y se le mostrarán por pantalla.

VerCarrito

6.5. Buscar productos

Cuando el cliente quiera buscar un tipo determinado de producto, simplemente introducirá lo que crea necesario en la barra de búsqueda. Si existe en la base de datos algún producto acorde a dicha petición, se devolverán esos productos encontrados. Si, por el contrario, no existe ningún producto, se mostrará al cliente un mensaje de que no se han encontrado los productos buscados.

Buscar

6.6. Ver pedidos

El cliente tiene que estar logueado para acceder a sus pedidos. El usuario selecciona "Ver pedido" y se le mostrará una página con todos los pedidos asociados a él.

Diagrama secuencia de la acción: Ver pedido

6.7. Leyenda

Componente

Descripción

Usuario

Usuario de la aplicación

WebApp

Parte de aplicación que se ejecuta en el navegador del cliente

RestApi

Servidor remoto de la aplicación

MongoDb

Base de datos de la aplicación

7. Deployment View

Componentes
  • Personal computer: dispositivo mediante el cual el cliente usa un navegador web y accede a la página de la aplicación.

  • Web Server: servidor en el cual se ejecuta la aplicación. Está dividido en las capas típicas de una arquitectura MVC.

  • Solid Server: servidor donde está almacenado el pod del cliente con los contenedores sobre los que tenemos permisos.

  • Shippo server: servidor de la empresa proveedora de la api de costes de envio.

diagrama despliegue

8. Conceptos transversales

8.1. Modelo de dominio

Modelo de dominio

8.2. Conceptos sobre la experiencia de usuario

DeDe presenta una interfaz que comunique de forma concisa y clara, sin abrumar al cliente, los productos que nuestra web ofrezca. Para ello, nuestro equipo se ha enfocado en crear unas pantallas simples y modernas siguiendo la filosofía de Tailwind.

8.3. Conceptos de protección y seguridad

La prioridad de DeDe es la privacidad de nuestros clientes. Con el objetivo de lograr una mayor seguridad, hacemos uso de las especificaciones Solid con lo que nuestros clientes han de tener un Solid Pod para poder realizar sus compras. El equipo de DeDe se compromete a no guardar datos sensibles de sus consumidores.

9. Decisiones de diseño

Decisión Ventajas Desventajas

MongoDB

Fácil de trabajar con json , formato nativo en javascript y base de datos rápida para esquemas sencillos

Nadie del equipo ha trabajado con ella antes, no soporta transacciones complejas

Node

Nos permite constuir una aplicación escalabale

Poco conocimiento de la aplicación, poca compatibilidad entre versiones

Shippo API

Permite consultar los gastos de envio sin preocuparse de los temas legales o administrativos que conllevaría un envio real y tiene blioteca para node

Nunca se ha trabajado con ella

Tailwind CSS

Un diseño que nos gusta, buena documentación y ejemplos

Algo dificil de implementar y nunca la hemos usado

BCrypt

Librería para hacer hash de contraseñas segura y con bastantes ejemplos

Nadie la había usado antes y puede acabar utilizando muchos recursos

Jsonwebtoken

Nos permite guardar datos en los tokens y hay bastante documentación

El tamaño de los tokens puede ser muy grande

Gatling

Es el recomendado por los profesores y hay tutoriales y ejemplos

Somos nuevos con la herramienta

10. Requisitos de calidad

10.1. Árbol de calidad

Quality tree

10.2. Escenarios de calidad

  • Ref: ID para identificar cada atributo de calidad.

  • Atributo de calidad: el propio atributo de calidad que queremos conseguir.

  • Escenario de calidad: por qué creemos que nuestra aplicación cumple ese atributo o bien se comporta como esperamos.

  • Prioridad: prioridad asociada al atributo. Esta prioridad está formada por dos palabras, siendo la primera la importancia que tiene el atributo de calidad para el cliente y la segunda la dificultad de conseguir dicho atributo.

Ref Atributo de calidad Escenario de calidad Prioridad

S

Seguridad

La información proporcionada por los usuarios no puede ser vista/extraída por terceras personas.

High, High

P

Privacidad

La aplicación tendrá solamente el POD del usuario y la dirección a la que se envía, que no se asocia al usuario.

High, High

U

Usabilidad

La aplicación es intuitiva, independientemente de la habilidad del usuario, ya que es como cualquier otra aplicación de compra.

High, Medium

E

Eficiencia

Da una respuesta a lo que pide en unos dos segundos, incluso cuando hay varios usuarios a la vez durante mucho tiempo.

Medium, Medium

M

Mantenibilidad

El código está ordenado y limpio por lo que, si surge un problema, es fácil encontrar donde falla y de solucionar.

Low, Medium

11. Riesgos y Deuda Técnica

11.1. Riesgos

Riesgos Solución

Poco tiempo

Aprovechar el tiempo e intentar llevar las cosas al día

Poco conocimiento de las tecnologías que vamos a usar

Buscar información de las diferentes tecnologías y aprender a usarlas

Trabajar en equipo

Hacer reuniones habitualmente, mantener una buena comunicación y dejar el código entendible

11.2. Deuda Técnica

Deuda Técnica Solución

Token de API hardcodeado

Moverlo a el .env

Archivos javaScript

Es necesario dejarlos para que no de error al establecer el estilo tailwind

Cobertura test frontEnd

No hemos conseguido que se muestre la cobertura completa de manera correcta

Error en circleci

Al hacer commits nos hace un chequeo de circleci que no sabemos porque y por eso nos salen como inválidos algunos commits.

Paginación con ordenación

Al ordenar los productos por precio, la paginación no nos funciona correctamente.

Despliegue sin https

No hemos conseguido usar https en el despliegue por lo que no podemos acceder a los pods y en backend da un error en sonardcloud por no usar https.

12. Glosario

Término Definición

MongoDB

MongoDB es un sistema de base de datos NoSQL orientado a documentos de código abierto y escrito en C++, que en lugar de guardar los datos en tablas lo hace en estructuras de datos similares a JSON con un esquema dinámico

Json

Es un formato de texto ligero que permite intercambiar y almacenar datos.

Javascript

JavaScript es un lenguaje de programación diseñado para añadir interactividad a las páginas webs y crear aplicaciones web.

TypeScript

Es un superconjunto de JavaScript, que añade tipos estáticos y objetos basados en clases

React

React es una biblioteca Javascript de código abierto diseñada para crear interfaces de usuario

SOLID

Tecnología para organizar apps, información e identidades de forma descentralizada

Node

Es un entorno de ejecución para programas escritos en JavaScript

Pod

Contenedor de datos de un usuario el cual tiene que dar permiso para que las aplicaciones accedan a él

Shippo API

API para la consulta de gastos de envio

MongoDB Atlas

Nube de MongoDB donde está hosteada la base de datos

Tailwind CSS

Framework para la creación de interfaces de usuario

BCrypt

Librería que encripta contraseñas mediante una función hash

Jsonwebtoken

Estándar abierto basado en JSON para crear un token que sirva para enviar datos entre aplicaciones o servicios y garantizar que sean válidos y seguros, además para menaejar la autenticación

Gatling

Programa para la realización de test de carga

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.