Merge branch 'develop' into Despliegue

.github/workflows/pruebaDeploy.yml

@@ -2,7 +2,6 @@ name: CI for ASW2122
 on:
   release:
     types: [published]
-
 jobs:
   docker-push-webapp:
     name: Push webapp Docker Image to GitHub Packages

docs/01_introduction_and_goals.adoc

@@ -10,10 +10,10 @@ El objetivo final de la aplicación es crear un sistema de venta online que resp
 Los requisitos más importantes son:
 
 * Los clientes deben tener la posibilidad de seleccionar y encargar productos para comprarlos.
-* Se calcularán los costes de envío consultando la dirección del usuario en su POD (calculando los costes en función de la distnacia del centro de distribución a la dirección del usuario). Este cálculo se llevará a cabo una vez el cliente haya seleccionado los productos a comprar.
-* Se mostrarán los costes finales de los productos a comprar por un cliente. Una vez el cliente decida comprarlos, se registrará la venta como realizada y se pasará a su envío.
+* Se calcularán los costes de envío consultando la dirección del usuario en su POD (calculando los costes en función de la distnacia del centro de distribución a la dirección del usuario). Este cálculo se llevará a cabo una vez el cliente haya seleccionado los productos a comprar y para ello ha de estar registrado en la aplicación.
+* Se mostrarán los costes finales de los productos a comprar por un cliente. Una vez el cliente decida comprarlos, se registrará la venta como realizada y "se pasará a su envío".
 * Los clientes podrán en todo momento ver sus pedidos realizados.
-* El desarrollo de la aplicación será mediante React y TypeScript para el Front-end y Node.js y Express para el Back-end.
+* El desarrollo de la aplicación será mediante React y TypeScript para el Front-end y Node.js y Express para el Back-end además de MongoDb para la gestión de la base de datos.
 * La aplicación deberá ser accesible y estar desplegada usando un sistema de integración continua. La tecnología de despliegue se especificará en el punto 4.
 
 La tienda online desarrollada se encargará de vender juguetes infantiles.
@@ -26,15 +26,15 @@ La tienda online desarrollada se encargará de vender juguetes infantiles.
 === Objetivos de calidad
 
 
-Los cinco objetivos de calidad para la arquitectura que hemos decido seguir (basandonos en nuestras capacidades y los requisitos de la aplicación) son los siguientes. Junto con ellos se muestra una breve descripción de lo que pretendemos conseguir con cada uno de ellos y la prioridad que le damos:
+Los cinco objetivos de calidad para la arquitectura que hemos decido seguir (basándonos en nuestras capacidades y los requisitos de la aplicación) son los siguientes. Junto con ellos se muestra una breve descripción de lo que pretendemos conseguir con cada uno de ellos y la prioridad que le damos:
 
 [options="header",cols="1,2,2"]
 |===
 |Prioridad|Objetivo de calidad|Descripción del objetivo
 | _1_ | _Usabilidad_ | _El sistema deberá ser fácil de usar y no requerir de conocimientos específicos o complejos para poder realizar compras. Se debería poder añadir a un encargo, comprar y ver pedidos realizados sin mayor complicación._
 | _2_ | _Comprensibilidad_ | _El sistema deberá ser fácil de entender por los usuarios, en todo momento deben saber cómo funciona la aplicación con poco esfuerzo. Los elementos gráficos ayudarán a la Comprensibilidad._
-| _3_ | _Seguridad_ | _El sistema deberá ser seguro en cuanto a los datos personales de cada usuario y también en lo que se refiere a la navegabilidad por la aplicación._
-| _4_ | _Testabilidad_ | _El sistema deberá ser testable para poder comprobar que el funcionamiento es el correcto. También influye en otros atributos de calidad como la seguridad._
+| _3_ | _Seguridad_ | _El sistema deberá ser seguro en cuanto a los datos personales de cada usuario y también en lo que se refiere a la navegabilidad por la aplicación, gestión de imágenes de los productos, etc._
+| _4_ | _Testabilidad_ | _El sistema deberá ser testable para poder comprobar que el funcionamiento es el correcto. También influye en otros atributos de calidad como la seguridad. Se realizarán pruebas unitarias, de aceptación y de carga para asegurar este campo._
 | _5_ | _Atractivo_ | _El sistema tendrá una interfaz atractiva, es decir, la interfaz ayudará en aspectos como la usabilidad o comprensibilidad y no entorpecerá el uso de la aplicación por parte de los usuarios._
 |===
 

docs/02_architecture_constraints.adoc

@@ -18,29 +18,29 @@ technical constraints, organizational and political constraints and
 conventions (e.g. programming or versioning guidelines, documentation or naming conventions)
 ****
 
-Restricciones tecnicas
+Restricciones técnicas
 [options="header",cols="1,2"]
 |===
-|Restriccion|Explicacion
-|Implementacion| La aplicacion estará formada por un front-end utilizando React  con TypeScript y un back-end utilizando NodeJS con Express
-|Seguridad| Para mantener la privacidad de los usuarios se almacenará toda su información privada en pods.
-|Despliegue| La aplicacion será accesible de manera continua y utilizará un sistema de integracion continuo.
+|Restricción|Explicación
+|Implementación| La aplicación estará formada por un front-end utilizando React con TypeScript y un back-end utilizando NodeJS con Express
+|Seguridad| Para mantener la privacidad de los usuarios se almacenará toda su información privada en PODs.
+|Despliegue| La aplicación será accesible de manera continua y utilizará un sistema de integracion continuo.
 |===
 
 Restricciones organizacionales
 [options="header",cols="1,2"]
 |===
 |Restriccion|Explicacion
 |Equipo|  -Alejandro Galán Freire - Aarón García García - Mario Lada Martínez - Jorge López Peláez - Rafael Muñiz Reguera.
-|Configuracion y control del repositorio| Toda la aplicacion se encuentra en un repositorio privado de github donde existe una rama develop general y cada persona del equipo trabajará desde una rama propia.
-|Fecha limite| La fecha limite del proyecto es el 2 de mayo.
+|Configuracion y control del repositorio| Toda la aplicación se encuentra en un repositorio privado de github donde existe una rama develop general donde se irá uniendo el trabajo de todos y cada persona del equipo trabajará desde una rama propia. Cada miembro puede tener varias ramas ya que se creará una por funcionalidad nueva a implementar.
+|Fecha límite| La fecha límite del proyecto es el 4 de mayo.
 |===
 
 Convenciones
 [options="header",cols="1,2"]
 |===
-|Convencion|Explicacion
-|Documentacion de la arquitectura| Estructura basada en la plantilla arc42.
-|Convenciones de codificacion| El proyecto utiliza las convenciones de codigo para el lenguaje de TypeScript y utilizará la guía de estilo de Node.
+|Convención|Explicación
+|Documentación de la arquitectura| Estructura basada en la plantilla arc42.
+|Convenciones de codificación| El proyecto utiliza las convenciones de código para el lenguaje de TypeScript y utilizará la guía de estilo de Node.
 |Idioma| Español.
 |===

docs/04_solution_strategy.adoc

@@ -3,39 +3,32 @@
 Como base, vamos a utilizar el lenguaje de programación TypeScript, impuesto en los requisitos de diseño. Es, en esencia, un superconjunto de JavaScript que añade tipado. 
 Para realizar nuestro sistema de ventas hemos decidido utilizar la MERN stack. Esto incluye los siguientes tecnologías:
 
-- MongoDB: Es una base de datos NoSQL que facilita el trabajo con el Back-End. Es una decisión de diseño propia
-- Express js: Es un marco que se ha superpuesto a Node JS y se puede utilizar para crear el Back-End de nuestra web. Fue precisamente creado
-para la creación de sitios web.
-- React JS: Es un framework creado por Facebook ampliamente utlizado para crear componentes de la interfaz de usuario. Es un requisito de diseño por lo que no tenemos
-nada que decidir.
+- MongoDB: Es una base de datos NoSQL que facilita el trabajo con el Back-End. Es una decisión de diseño propia.
+- Express js: Es un marco que se ha superpuesto a Node JS y se puede utilizar para crear el Back-End de nuestra web. Fue precisamente creado para la creación de sitios web.
+- React JS: Es un framework creado por Facebook ampliamente utlizado para crear componentes de la interfaz de usuario. Es un requisito de diseño por lo que no tenemos nada que decidir.
 - Node JS: Es un entorno de ejecución de JavaScript que permite ejecutar JavaScript del lado del servidor y no en un navegador.
 
 .Diseño
 Hemos utilizado pricipalmente el Modelo Vista Controlador con el fin de generar un proyecto claramente estructurado y fácilmente ampliable.
 
 .Usabilidad
-Para alcanzar la mayor usabilidad posible de nuestra web, intentaremos cumplir con todos los criterios de usabilidad que sabemos hasta el momento y la comprobaremos
-en diferentes validadores de internet. Intentaremos disponer el contenido de la manera más intuitiva posible, haciendo pruebas con usuarios a medida que vamos desarollando la
-aplicación para intentar sacarle el máximo partido.
+Para alcanzar la mayor usabilidad posible de nuestra web, intentaremos cumplir con todos los criterios de usabilidad que sabemos hasta el momento y la comprobaremos en diferentes validadores de internet. Intentaremos disponer el contenido de la manera más intuitiva posible, haciendo pruebas con usuarios a medida que vamos desarollando la aplicación para intentar sacarle el máximo partido.
 
 .Comprensibilidad
 No tenemos una gran cantidad de requisitos funcionales por lo que podemos producir una solución sencilla de utilizar y comprensible
 
 .Seguridad
-Garantizamos la seguridad del usuario mediante el uso de PODs, citados en los requisitos del sistema. 
+Garantizamos la seguridad del usuario mediante el uso de PODs, citados en los requisitos del sistema. También la aplicación será segura al introducir la información confidencial en un fichero .env el cual será privado.
 
 
 .Testabilidad
 Testabilidad, la arquitectura permitirá probar fácilmente todos los componentes principales del sistema.
 
 .Desarrollo
-El sistema va a ser desarrollado completamente por el equipo (utilizando debidamente los recursos mencionados) dividiendo el trabajo en dos partes claras: Front-End y Back-End. En cualquier caso, se irán compartiendo 
-todos los avances y cualquier duda intentando seguir una metodología ágil.
+El sistema va a ser desarrollado completamente por el equipo (utilizando debidamente los recursos mencionados) dividiendo el trabajo en dos partes claras: Front-End y Back-End. En cualquier caso, se irán compartiendo todos los avances y cualquier duda intentando seguir una metodología ágil a través de reuniones frecuentes.
 
 .Estructura
-El sistema de ventas se compondrá de diversas páginas web implementadas mediante TypeScript y React principalmente. La página principal desplegará diferentes categorías de 
-juguetes y un conjunto de juguetes destacados. Tendremos acceso a nuestro carrito y a nuestra cuenta, con lo que también podemos ver pedidos realizados anteriormente. Una vez 
-entras en una categoría de juguetes se desplegarán todos aquellos que estén presentes en la base de datos. También es posible utilizar el buscador para encontrar un determinado juguete.
+El sistema de ventas se compondrá de diversas páginas web implementadas mediante TypeScript y React principalmente. La página principal desplegará diferentes categorías de juguetes y un conjunto de juguetes destacados (o filtrados por categorías). Tendremos acceso a nuestro carrito y a nuestra cuenta, con lo que también podemos ver pedidos realizados anteriormente. Una vez entras en una categoría de juguetes se desplegarán todos aquellos que estén presentes en la base de datos.
 
 .Interfaz
 La interfaz gráfica se implementará desde el Front-End y se intentará cumplir la máxima usabilidad posible, teniendo en cuenta cualquier tipo de usuario

docs/05_building_block_view.adoc

@@ -94,7 +94,7 @@ Juguete se encarga de administrar a los productos que forman parte de nuestro si
 [options="header",cols="1,2"]
 |===
 |Interfaz|Descripción
-| _Cloudinary_ | _Almacén que se encargará de guardar las imágenes de los juguetes en la nube, de tal manera que tengamos un almacén seguro._ 
+| _Cloudinary_ | _Almacén que se encargará de guardar las imágenes de los juguetes en la nube, de tal manera que tengamos un almacén seguro. Es un servicio que siempre está corriendo y que nos aporta usabilidad y escalabilidad._ 
 |===
 
 === Pedido (caja negra)
@@ -128,7 +128,7 @@ according the the following black box template:
 
 
 ==== Bloque de construcción - Nivel 2
-Nosotros decidimos organizar nuestra REST API a través de modelos que definen las entidades tal y como serán en la base de datos, repositorios que serán los encargados de trabajar con la misma y por último los routes que se encargan de gestionar las peticiones.
+Nosotros decidimos organizar nuestra REST API a través de modelos que definen las entidades tal y como serán en la base de datos y los routes que se encargan de gestionar las peticiones así como el acceso a datos.
 
 [role="arc42help"]
 ****
@@ -142,16 +142,17 @@ Leave out normal, simple, boring or standardized parts of your system
 === Usuario (caja blanca)
 image:UsuarioBloqueConstruccion.png["Hierarchy of building blocks"]
 
-Modelo usuario se encarga de definir la estructura que el usuario tendrá en nuestra base de datos. Este modelo es usado por RepositorioUsuario, ya que este será necesario para acciones como pueden ser añadir a un usuario. Por último, el routeUsuario que es el que se encarga de gestionar las peticiones recibidas tendrá que comunicarse con el repositorio, ya que estas peticiones requerirán acceso a datos.
+Modelo usuario se encarga de definir la estructura que el usuario tendrá en nuestra base de datos. Este modelo es usado por el routeUsuario que es el que se encarga de gestionar las peticiones recibidas y del acceso a datos como puede ser encontrar,
+añadir un usuario, etc.
 
 === Juguete (caja blanca)
 image:JugueteBloqueConstruccion.png["Hierarchy of building blocks"]
 
-Seguimos la misma estructura que con el usuario, se define el esquema de la entidad en el ModeloJuguete, el cual es utilizado por el RepositorioJuguete que a su vez es llamado desde el routerJuguete ya que las peticiones requieren operaciones con acceso a datos (encontrar, añadir, etc).
+Seguimos la misma estructura que con el usuario, se define el esquema de la entidad en el ModeloJuguete, el cual es utilizado por el routerJuguete ya que las peticiones requieren operaciones con acceso a datos (encontrar, añadir, etc).
 En este caso el router también hace uso de la interfaz externa Cloudinary. Esta se encargará de cuando se añade un juguete, coger su imagen y guardarla en su almacén. Clodinary nos devolverá una URL propia que será el direccionamiento de la imagen que ha almacenado y que usaremos para el juguete.
 
 === Pedido (caja blanca)
 image:PedidoBloqueConstruccion.png["Hierarchy of building blocks"]
 
-Volvemos con la misma estructura, ModeloPedido define el esquema el pedido con sus atributos y restricciones que poseerá en la base de datos. Este modelo es necesario para realizar operaciones de acceso a datos, y por tanto, será requerido desde RepositorioPedido. Finalmente este es utilizado de routerPedido ya que peticiones como encontrar, añadir pedidos, etc, necesitan realizar operaciones con la base de datos. Además de a este repositorio, routerPedido hace acceso también al RepositorioJuguete y RepositorioUsuario para por ejemplo buscar los juguetes de un pedido en concreto o encontrar los pedidos de un usuario específico.
+Volvemos con la misma estructura, ModeloPedido define el esquema el pedido con sus atributos y restricciones que poseerá en la base de datos. Este modelo es necesario para realizar operaciones de acceso a datos, y por tanto, será requerido desde routerPedido ya que peticiones como encontrar, añadir pedidos, etc, necesitan realizar operaciones con la base de datos. RouterPedido hace acceso también al ModeloJuguete y ModeloUsuario para por ejemplo buscar los juguetes de un pedido en concreto o encontrar los pedidos de un usuario específico.
 En este caso el router hace acceso tambíen a una API externa que es GeoCode, import de "node-geocoder". Esta internamente recibe una dirección y puede trabajar con distintos proveedores, en nuestro caso openstreetmap. Si su base de datos encuentra la dirección especificada devolverá una serie de datos sobre la misma, como puede ser las coordenadas. Esto nos hace posible posteriormente calcular manualmente el precio por km entre dos direcciones.

docs/06_runtime_view.adoc

@@ -55,12 +55,13 @@ database Pod as "Pod del usuario" #yellow
 Usuario -> DeDe: Abre el carrito
 DeDe <-- BaseDeDatos: Devuelve contenido del carrito del usuario
 Usuario <-- DeDe: Muestra lista de juguetes del carrito
-Usuario -> DeDe: Confirma la compra de los productos
+Usuario -> DeDe: Presiona botón realizar pedido
 DeDe -> Pod: Se solicita la dirección del usuario
+Usuario -> Pod: Inicia sesión en Pod y añade su dirección en la sección "notes" del mismo
 DeDe <-- Pod: Devuelve la dirección del usuario
-DeDe -> DeDe: Crea el pedido con el coste y dirección asociados.
+DeDe -> DeDe: Muestra la dirección y se calculan gastos de envío (API GeoCode)
 Usuario <-- DeDe: Muestra el precio y la dirección.
-Usuario -> DeDe: Confirma el pedido.
+Usuario -> DeDe: Recorre pantallas de pago hasta confirmar el pedido.
 ----
 
 === Añadir productos

docs/07_deployment_view.adoc

@@ -88,7 +88,7 @@ Lugar a través del cual el usuario se comunica con nuestro sitio web
 Elementos de almacenamiento de información privada del usuario que aumentará la seguridad del mismo en nuestra aplicación. Internamente el usuario ha de crearse una cuenta con uno de los proveedores existentes y almacenar la información que el mismo desee de manera pública o privada.
 
 ==== _Auth0_
-API que permite al usuario iniciar sesión en nuestro sitio. Nos permitirá trabajar con sus datos desde la aplicación.
+API que permite al usuario iniciar sesión en nuestro sitio. Nos permitirá trabajar con sus datos desde la aplicación. Esta API además gestionará las contraseñas de los usuarios sin necesidad de tener que introducirlas en nuestra base de datos, algo que incrementará la seguridad de la aplicación.
 
 ==== _GeoCode_
 API a la que le pasas una dirección y te devuelve ciertos datos. Para nuestro proyecto son de utilidad la latitud y longitud de la misma. Se utilizará la fórmula de Haversine para calcular la distancia en km (previamente diferencia de latitudes y longitudes) entre dos ubicaciones.