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

El proyecto trata de una aplicación de compra y venta de objetos, llamada DeDe, cuyo codigo fuente sera realizado con "TypeScript". Estará enfocada al mercado electrónico y dará soporte a la realización de pedidos asociados a una cuenta de usuario concreta.

Objetivos de Negocio:

-A corto plazo: Realizar una documentación adecuada de manera que se cumplan las expectativas y necesidades del proyecto.

-A largo plazo: Poder realizar una aplicación de manera que cumpla todos los objetivos de usabilidad para poder realizar compra/venta de playeros de una manera mas cómoda, sencilla y accesible.

1.1. Vista de Requerimientos

-Se necesitara una pequeña base de Typescript para la implementación de código de la aplicación y el uso de react para la implementación de cara al usuario.

-Para realizar el control de versiones es necesario el uso de git, herramienta muy util para trabajos de gran tamaño permitiendo el uso de varias ramas para no alterar los prototipos del proyecto.

-Será necesario emplear un navegador y disponer de un proveedor de internet para poder acceder a dede_es3a y utilizar toda la funcionalidad de la que dispone.

-El sistema permitirá al usuario realizar una búsqueda mediante la que filtrar los artículos mostrados según su nombre/descripción.

-Dede_es3a dispondrá de un carrito en el que almacenar artículos y cuyo contenido podrá ser consultado por el usuario.

-Se dará al usuario la posibilidad de tanto borrar como añadir elementos al carrito.

-Permitirá el registro de usuarios mediante formulario siempre y cuando sus credenciales no cincidan con las de otro usuario.

-Dede_es3a permitirá el inicio de sesión de usuarios mediante formulario si las credenciales coinciden con la BDD.

-Se dispondrá de una lista de pedidos por usuario en la que se almacenarán sus correspondientes pedidos.

-Para la realización de un pedido será necesario: un usuario al que asociarlo y especificar una dirección para el envío.

-Dede_es3a proporcionará al usuario una forma de calcular automáticamente el precio del pedido en función de la dirección de envío.

1.2. Metas de calidad

Table 1. Metas de calidad
Meta de Calidad Motivación Prioridad del ED Prioridad del Cliente

Seguridad

El objetivo es el tratamiento de la información privada de una manera descentralizada asegurando la privacidad y seguridad del cliente

Alta

Alta

Usabilidad

Todos los usuarios deben poder utilizarlo, tengan conocimientos previos sobre la aplicación o no

Alta

Alta

Escalabilidad

Realizar una compra y cualquier otra operación realizable en la aplicación debe ser sencilla para un usuario, haciendo que los tiempos de respuesta y de carga sean mas reducidos

Alta

Alta

Accesibilidad

La aplicación debe ser accesible en todo momento sin importar el navegador que esté utilizando el usaurio

Media

Alta

Interoperabilidad

El equipo de desarrollo debe tener siempre presente el foro de la asignatura mediante el cual poder estar al corriente de cualquier problema que le pueda surgir al resto de grupos o preguntar ellos cualquier duda que tengan

Media

Media

1.3. Partes interesadas (Stakeholders)

Table 2. Stakeholders
Role/Name Expectations

Equipo de desarrollo

Esperan poder obtener una aplicacíon correcta y usable.

Cliente

Sus expectativas son poder realizar una compra en la aplicación de una manera sencilla y accesible.

Equipos de desarrollo paralelos

Buscarán poder establecer interoperabilidad entre su sistema y el nuestro.

Stakeholders primarios:

Equipo de desarrollo: que deben conocer la arquitectura de TypeScript, React y Solid.Deben trabajar de manera que se documente todo el código para facilitar el entendimiento por parte de los demás miembros del grupo. Deben realizar reuniones para plantear las arquitecturas a usar. Por ejemplo: Para el desarrollo de Diagramas de secuencia.

Cliente: quien interactuaría con la version final de la aplicacíon para la realización de compra de Objetos.

Stakeholders secundarios:

Equipos de desarrollo paralelos: en nuestro caso, tenemos una cercanía con otros grupos que están implementando sistemas similares al nuestro, lo cual, nos permite poder preguntar/pedir consejo en caso de considerarlo oportuno.

2. Restricciones de la Arquitectura

Contents

Se trata de cualquier requisito que restrinja a los arquitectos del software en su libertad de diseño, toma de decisiones sobre la implementación o sobre el proceso del desarrollo.

2.1. Restricciones técnicas

Contents

Son las restricciones tecnicas que tendrá el equipo a lo largo del desarrollo.

Form

Tabla con todas las restricciones técnicas junto con una breve descripción .

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

React

Usaremos react para la creación del Frontend de la Aplicación.

TypeScript

TypeScript es un lenguaje de programación tipado que se basa en JavaScript.

SOLID

Solid permite a los usuarios almacenar sus datos de forma segura en almacenes de datos descentralizados llamados Pods.

Git

El código ha de ser subido a un repositorio remoto en GitHub.

PlantUML

Herramienta de código abierto que permite la creación de diagramas de forma textual.

Draw.io

Herramienta que permite la creación de diagramas de forma gráfica.

Material ui

Es una biblioteca de código abierto que implementa el lenguaje visual de «materiales» de Google en sus componentes React.

Heroku

Plataforma necesaria para realizar el despliegue de nuestra aplicación en la nube.

2.2. Restricciones de negocio

Contents

Son las restricciones de negocio para el desarrollo del sistema.

Form

Tabla con todas las restricciones de negocio junto con una breve descripción .

Table 4. Restricciones de negocio
Restricción Descripción

Equipo

El equipo estaba inicialmente formado por 5 personas con las que apenas hemos interactuado con anterioridad. Además de esto, 2 miembros del equipo abandonaron el proyecto.

Horarios

Todos somos estudiantes con más asignaturas o incluso que trabaja mientras cursa esta asignatura.

Límite de tiempo

Cada entrega tiene una fecha de entrega bastante cercana a la anterior.

Conceptos necesarios

Tal y como ha sido establecido en el plan de negocio, es imprescindible la utilización de React, SOLID y TypeScript para el desarrollo del sistema.

3. Alcance y Contexto del Sistema

3.1. Contexto de negocio

Diagrama de contexto

  • Cliente

Usuarios finales de la aplicación. Son los clientes que van a realizar las compras.

  • DeDe

Nuestro sistema de venta online (Decentralized Delivery)

  • Base de datos

Se guardará aquí toda la información necesaria para el funcionamiento de la aplciación: pedidos de los usuarios, productos, etc.

  • POD

El sistema se conectará con el POD del usuario para obtener los datos de su dirección, ya que por privacidad no se almacenarán estos datos en nuestra aplicación.

  • Empresas de Mensajería

Nuestro sistema se conectará con diferentes empresas de mensajería para poder calcular los costes de envío de los pedidos.

3.2. Contexto técnico

Nuestra tienda DeDe se debe cumplir los principios SOLID de descentralizacion de datos personales mediante el almacenamiento de estos en PODs independientes para cada usuario, el proveedor de PODs para DeDe será Inrupt. El front-end estara desarrollado mediante el framework React implementando componentes ya desarrollados o bien creados por nosotros mismos,el lenguaje para el desarrollo de las diversas funcionalidades de las pantallas sera TypeScript. Por la parte del back-end, nuestro SGDB es Mongo.db y mediante Node.js express realizaremos todas las transacciones a la base de datos, en la misma almacenaremos los datos de los productos y de los usuarios registrados en DeDe.

4. Estrategia de la solución

Para el desarrollo de este proyecto viene impuesta como restricción la utilización de React, TypeScript y SOLID. No hay imposición en cuento a la base de datos a utilizar. Se ha decidito optar por seguir la arquitectura MERN. Es un conjunto de marcos/tecnologías utilizados para el desarrollo web de aplicaciones que consta de MongoDB, React, Express y Node como sus componentes.

Para el Front-End se utilizará React, una librería desarrollada y mantenida por Facebook. El elemento más importante de React es el componente, que es en esencia una pieza de la interfaz de usuario. Al diseñar una aplicación con React, lo que estamos haciendo es crear componentes independientes y reusables que nos permiten crear interfaces de usuario más complejas.

La utilización de MongoDB como base de datos nos supone además una ventaja ya que en la asignatura de Sistemas Distribuidos e Internet también se utilizará, por lo que podemos reutilizar los conocimientos que se adquirirán para el desarrollo de este proyecto.

Node es un entorno de ejecución que permite la ejecución de un programa escrito en JavaScritp. Utiliza una arquitectura de E/S basada en eventos y sin bloqueos, lo que nos ayudará a que la aplicación sea escalable y rápida.

Express es un framework para crear aplicaciones web, APIs y web services. Así como Node está destinado a ejecutar JavaScript del lado servidor, pero no para desarrollar sitios web, Express está destinado justo a esto, a crear sitios web.

Para conseguir la máxima disponibilidad de la aplicación en vez de utilizar servidores propietarios se desplegará en la nube. Queda pendiente la decisión de en que nube en concreto se desplegará la aplicación.

La privacidad de los datos de los usuarios se garantizará con la utilización de Solid. Solid es una especificación que permite a la gente guardar sus datos en almacenes descentralizados llamados Pods.

5. Vista de bloques

5.1. Sistema general

Diagrama de contexto

Motivacion

Se muestra aquí el diagrama de alcance y contexto de nuestra aplicación.

Bloques de construcción contenidos
  • DeDe: Nuestro sistema de venta online (Decentralized Delivery)

  • Base de datos: Se guardará aquí toda la información necesaria para el funcionamiento de la aplicación: pedidos de los usuarios, productos, etc.

  • POD: El sistema se conectará con el POD del usuario para obtener los datos de su dirección, ya que por privacidad no se almacenarán estos datos en nuestra aplicación.

  • Empresas de Mensajería: Nuestro sistema se conectará con diferentes empresas de mensajería para poder calcular los costes de envío de los pedidos.

Interfaces importantes
  • Para conectar con las diferentes empresas de mensajería se utilizarán las APIS que suministren estos servicios.

5.2. Nivel 2

Diagrama de detalle nivel 1

Motivacion

Se muestra aquí el detalle de nuestra aplicación Dede.

Bloques de construcción contenidos
  • Front-End: Nuestra interfaz de usuario. Se utilizara React.

  • Back-End: Aquí se implementará toda la lógica de negocio de la aplicación relacionada con el acceso y gestión de los datos almacenados.

Interfaces importantes
  • Gracias a la API (api.ts), podremos conectar el Back-End y el Front-End

5.3. Nivel 3

Diagrama de detalle nivel 2

Motivacion

Se muestra aquí el detalle de la división en módulos del Back-End

Bloques de construcción contenidos
  • Main: En módulo principal del Back-End. Comunica el Front-End con los diferentes módulos que componen el Back-End

  • BBDD: Se encarga de la comunicación con al base de datos.

  • Solid: Interactuará con el Pod del usuario.

  • Envíos: Se conectará con las diferentes empresas de mensajería para calcular el importe de los envíos (APIMapBox).

Interfaces importantes
  • Para conectar con las diferentes empresas de mensajería se utilizarán las diferentes APIS que ofrezcan dichas empresas

  • Para conectar con el POD del usuario se utilizarán las librerías facilitadas por Inrupt.

6. Vista de Ejecución

6.1. Proceso de Login

El segundo escenario muestra el proceso de "Login". Para ello, el usuario debe introducir los datos en el formulario, esos datos serán verificados y si son correctos volverá a la pantalla de inicio con la sesión iniciada.

Login diagrama

6.2. Proceso de compra

El primer escenario muestra el proceso de compra de un producto. Para ello, el usuario debe conectarse con su cuenta y seleccionar la talla correspondiente para que se añada al carrito de la compra.

Compra diagrama

6.3. Cálculo de los gastos de envío

El tercer escenario nos muestra el proceso de cálculo de los costes de envío de un pedido. Tras finalizar el usuario el pedido, DeDe solicita al POD del usuario la dirección de envío del usuario. Con esta dirección solicita a la empresa de mensajería el importe de los gastos de envío. Una vez obtenido este importe le devuelve al usuario el importe total del pedido, con los gastos de envío incluidos. Si el usuario confirma el pedido DeDe procede a almacenarlo en la base de datos y muestra al usuario la confirmación del envío.

Cálculo de los gastos de envío

6.4. Proceso de envío

El último diagrama se corresponde con el proceso de envío al usuario del pedido desde la aplicación. Para ello, debe realizar el pedido una vez finalizado el proceso de compra.

Envio diagrama

7. Vista de Despliegue

7.1. Nivel de Infraestructura 1

DiagramaDespliegue

Motivacion

Se ha intentado plantear el sistema de la manera más descentralizada posible y mantener la privacidad del usuario de manera más optima posible.

Caracteristicas de calidad y/o rendimiento

Como nuestro objetivo es tener un sistema optimo tanto en cuanto a rendimiento como seguridad y otras características, se ha intentado buscar y comenzar a usar la mejor infraestructura posible.

Mapeo de Bloques de Construccion a Infraestructura

Building Block

Mapping

MongoDB

La base de datos elegida que estara dentro de un servidor y sera usada por la aplicacion.

RestAPI

Interfaz entre sistemas para el intercambio de peticiones.

WebApp

La parte donde el usuario podra interactuar, el cual ejecuta el navegador web.

Web browser

Depende de la eleccion del usuario, y unica forma de acceder a la aplicacion.

POD

"Almacenes" para guardar los datos de los usuarios de forma segura.

APIMapBox

API para calculo de coordenadas y simulación de envío de paquetes.

Imgur

Será usado un repositorio a parte para guardar las imágenes de los diferentes artículos de la aplicación.

8. Conceptos Transversales (Cross-cutting)

8.1. Modelo del dominio

Dede es una aplicación de compra de calzado, todo está enlazado con un diagrama de Entidad-Relación(ER-Diagram):

ER Diagram

Table 5. Modelo de dominio
Name Descripción

Productos

Almacena los zapatos registrados en la tienda

Usuario

Cliente el cuál accede a la aplicación y se registra para realizar compras.

Pedidos

Recoge la información del pedido para realizar el reparto.

8.2. Interfaz de usuario

Para realizar la Interfaz de usuario de nuestra aplicación usaremos React. React es una biblioteca de Javascript de código abierto con la que se pueden crear numerosas interfaces de usuario facilitando el desarrollo de aplicaciones en una sóla página. React es mantenido por Facebook y la comunidad de software libre.

8.3. Optimización de TypeScript y CSS

La opción más sencilla: estilos en línea. No aporta toda la flexibilidad de CSS, pero si aporta un estilo básico con una especificidad de nivel superior. Cada elemento React HTML tiene una propiedad de estilo que permite un objeto con todo el estilo que hayas planteado con anterioridad.Los objetos pueden tener este aspecto:

Example css

8.4. Base de datos

Hemos decidido usar como base de datos "MongoDB" la cual es una base de datos que usamos en otras asignaturas y podremos manejarnos de una manera más fluida que con otras bases de datos. MongoDB ofrece una gran escalabilidad y flexibilidad, así como un modelo de consultas e indexación avanzado.

9. Decisiones de Diseño

9.1. Utilizar MongoDb

MongoDB es un sistema de base de datos NoSQL, orientado a documentos y de código abierto.En lugar de guardar los datos en tablas, tal y como se hace en las bases de datos relacionales,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. MongoDB es una base de datos adecuada para su uso en producción y con múltiples funcionalidades.

9.2. Utilizar Git para el control de versiones

Usaremos git para realizar el control de versiones. Con git, trabajaremos cada uno de los miembros del equipo sobre la rama "develop",rama que creamos con anterioridad. Sobre esa rama iremos creando diferentes subramas con nombres como "uoXXXX-<cambio a realizar>". Una vez terminada esa subrama realizaremos un merge sobre develop, para finalmente realizar un merge sobre la rama master.

Git es una herramienta que nos sirve de mucha utilidad para no pisar el trabajo de los demás miembros del equipo.

9.3. Utilizar React para el FrontEnd

Para crear la parte de "User Interface" usaremos React, una herramienta que nos ayudará a crear interfaces de usuario interactivas de forma sencilla diseñando vistas simples para cada estado en la que se encuentre la aplicación. Nos permite crear componentes encapsulados que manejen su propio estado, para convertirlos en interfaces de usuario más complejas.

9.4. Utilizar Imgur como repositorio de imágenes remoto

Para evitar que las imágenes que utilizamos en la aplicación dependan de proveedores externos a nosotros, las almacenaremos en Imgur, repositorio online gratuito para todo tipo de contenido audiovisual. De esta forma, sabremos que siempre tendremos disponibles estas imágenes.

10. Requerimientos de Calidad

La calidad es la habilidad de un producto o servicio de cumplir las necesidades, requisitos y expectativas del cliente. Para lograrlo, tendremos que ire cumplimentando una serie de requisitos que nos permitirán alcanzar y/o aumentar esta habilidad.

10.1. Árbol de calidad

En esta sección se muestra un diagrama de árbol de calidad para el sistema desarrollado. A medida que el proyecto vaya avanzando, se irá ampliando este diagrama hasta alcanzar las hojas, que serán los escenarios de calidad que describiremos en el siguiente apartado. Además, se incluirán enlaces en el árbol a los escenarios de la siguiente sección.

Calidad diagrama

10.2. Escenarios de calidad

Table 6. Escenarios de calidad
Requerimiento Descripción

Escalabilidad

Debido a la sencillez de las operaciones implementadas, en caso de incrementar funcionalidad con tallas y colores, no habría repercusión alguna en rendimiento de cara a realizar pedidos.

Seguridad

Para la realización de cualquier pedido, así como la consulta de información personal, el usuario deberá estar registrado (usuario y contraseña válidas) e iniciar sesión con las mismas.

Usabilidad

La aplicación tiene una interfaz y manejo intuitivos, de fácil uso similar a otros sistemas conocidos como Adidas o Nike.

Accesibilidad

Cualquier usuario, puede interactuar con la página sin problemas. En cualquier momento el usuario puede acceder desde Heroku sin importar el navegador.

Interoperabilidad

De encontrarse con cualquier problema, el equipo de desarrollo dispone de un foro en el que preguntar/consultar sus dudas o las de otros equipos de trabajo.

11. Riesgos y deuda técnica

Los riesgo durante un proceso de desarrollo están siempre presentes, no obstante, su identificación y registro son cruciales para el bienestar de cualquier proyecto. En esta sección, iremos dejando constancia de todos y cada uno de los riesgo que se hayan encontrado así como las deudas técnicas que hayan podido o puedan surgir debido a malas decisiones. Realizar esta tarea correctamente implicará un crecimiento beneficioso tanto para el proyecto como para el equipo de desarrollo.

A continuación se muestra una tabla [Table 7] en la que se irán recogiendo todos los riesgos y en la [Table 8] las deudas técnicas que se hayan ido identificando a lo largo del proceso de desarrollo. Están ordenados de mayor a menor prioridad.

Table 7. Lista de riesgos
Riesgo Descripción Prioridad

Diagramas del proyecto

Un postulado erróneo de éstos diagramas puede dar lugar a una construcción errónea del sistema derivando en cambios cuya dificultad probablemente sea proporcional al tiempo que se haya estado desarrollando el proyecto.

Alta

Abandono de dos miembros

No solo con la implicación que conlleva si no también con el código que hicieron, el cual contenía un montón de errores haciendo que fuese complicado su arreglo.

Alta

Conocimiento de SOLID

Una nueva tecnología con la que ninguno hemos trabajado y de la que no hay mucha información.

Media

Conocimiento de TypeScript

Ninguno de los miembros había realizado uso del lenguaje.

Media

Fechas límite

Tiempo para realizar las implementaciones limitado.

Baja

Table 8. Lista de deudas técnicas
Deuda técnica Descripción Prioridad

Investigación sobre el entorno de trabajo

Una amplia búsqueda de información acerca de cómo trabajar con Typescript, Solid y React facilitará enormente el trabajo una vez iniciada la implementación ya que no será sobre territorio desconocido.

Alta

Sopesar las decisiones tomadas

Es conveniente que todo lo que se decida con respecto a la arquitectura del proyecto sea en base a un razonamiento y no de forma aleatoria. Así evitaremos cambios de planes en el último momento que puedan llegar a afectar negativamente al proyecto.

Media

Encriptado de contraseñas

Queda pendiente incrementar la seguridad de la aplicación almacenando las contraseñás encriptadas en base de datos.

Baja

Tallas y colores de productos

No hemos podido darle soporte a la gestión de tallas y colores de cara a los productos por falta de tiempo. No obstante, se mantendrá su visualización en la vista detalles a modo estético para que ésta no quede muy simplificada.

Baja

Rol de administrador

Para poder centrar nuestro tiempo en pulir otros campos como los tests y arreglo de bugs, queda pendiente implementar un rol de administrador desde el que gestionar Usuarios, Productos, etc.

Baja

12. Glosario

Table 9. Glosario
Término Definición

Express

Tambien conocido como Express.js. Es un framework de aplicaciones web ligero y minimalista. Proporciona un amplio conjunto de funciones para crear aplicaciones web sobre NodeJS

Git

Git es un sistema de control de versiones distribuido gratuito y de código abierto diseñado para manejar todo, desde proyectos pequeños hasta proyectos muy grandes, con rapidez y eficiencia. Más información sobre Git y el control de versiones en https://git-scm.com/book/en/v2git

Github

Github (https://github.com) es un portal para gestionar las aplicaciones que utilizan el sistema Git. Además de permitirte mirar el código y descargarte las diferentes versiones de una aplicación, la plataforma también hace las veces de red social conectando desarrolladores con usuarios para que estos puedan colaborar mejorando la aplicación. Existen otras alternativas como gitlab (https://gitlab.com) y Bitbucket (https://bitbucket.org/).

JavaScript

Es un lenguaje de programación. Se suele abreviar como JS. Para una descripción más detallada puedes visitar https://es.wikipedia.org/wiki/JavaScript. También puedes consultar estos tutoriales: https://www.w3schools.com/js/ y https://es.javascript.info/

MERN

Es un conjunto de marcos de trabajo/tecnologías utilizados para el desarrollo web de aplicaciones que consta de MongoDB, React, Express y Node como sus componentes.

MongoDB

MongoDB es una de las bases de datos NoSQL orientada a documentos. Ofrece una gran escalabilidad y flexibilidad. Más información en https://www.mongodb.com/es/

Node

También conocido como Node.js. Es un entorno en tiempo de ejecución multiplataforma, de código abierto, para la capa del servidor (pero no limitándose a ello) 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. Más información sobre node.js en https://nodejs.org/es/

POD

Acrónimo del inglés Personal Online Data. Es un contenedor digital que almacena los datos personales de un usuario. Se puede obtener un POD en https://solidproject.org/users/get-a-pod

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. Más información sobre React en https://es.reactjs.org/

SOLID

Acrónimo del inglés Social Linked Data. Es un proyecto de descentralización de datos en la web dirigido por Tim Berners-Lee (inventor de la web semántica) desarrollado en el Instituto de Tecnología de Massachusetts (MIT). El objetivo principal del proyecto es cambiar de forma radical la manera en la que las aplicaciones web funcionan hoy en día, siendo el usuario quien decide dónde almacenar sus datos, mejorando de esta forma la privacidad. Mas información sobre SOLID en https://github.com/kustomzone/awesome-solid y en https://github.com/itsee/awesome-solid. Atención: No confundir con los principios SOLID (https://es.wikipedia.org/wiki/SOLID)

PlantUML

Herramienta de código abierto que permite la creación de una gran cantidad de tipos de diagramas (UML, de despliegue, de secuencia…​) de manera textual. Se puede obtener más información en https://plantuml.com/es/

Material UI

MUI ofrece un conjunto integral de herramientas de interfaz de usuario para ayudarlo a enviar nuevas funciones más rápido. https://mui.com/

MapBox

API que ofrece servicios de cálculo de rutas de manera precisa y coordenadas. https://www.mapbox.com/

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.