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
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)
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
2.1. 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
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
-
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
- 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
- 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
- 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.
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.
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.
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.
7. Vista de Despliegue
7.1. Nivel de Infraestructura 1
- 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):
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:
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.
10.2. 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.
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 |
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
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.