Merge pull request #138 from Arquisoft/develop

Mergear para lanzar el release

docs/04_solution_strategy.adoc

@@ -6,6 +6,7 @@
 ** MongoDB como base de datos NoSQl.
 ** Expres JS como framework de Node JS.
 ** Framework React para crear las interfaces de usuario.
+*** Material UI (MUI) como librería de React para la creación de componentes.
 ** Node JS como entorno de ejecución.
 ** Typescript como lenguaje de programación: MERN exige trabajar con JavaScript, pero Typescript añade una capa extra de tipado estático, que vendrá bien para prevenir errores.
 * SOLID para preservar la privacidad de los datos del usuario.

docs/06_runtime_view.adoc

@@ -2,18 +2,78 @@
 == Runtime View
 
 === Escenario 1. Registrarse como un nuevo usuario
-Para registrarse como nuevo usuario en la aplicación, tendrás que dar permiso al Pod con tus datos
-para permitir al servicio conocer tus nombre, apellidos y direccion. Esto nos servirá para poder
-calcular los gastos de envío propios de enviar un producto al domicilio del usuario
+Para registrarse, el usuario deberá rellenar el formulario correspondiente. Una vez hecho, se guardarán en 
+la base de datos solo los datos necesarios. El resto de datos personales serán almacenados en el POD.
 
+[plantuml,"escenario1",png]
+----
+actor Usuario
+entity Webapp
+entity Restapi
+database POD
+database MongoDB
+Usuario -> Webapp: Rellenar formulario signup
+Webapp -> Restapi: Envía los datos
+Restapi -> POD: Envía datos personales
+Restapi -> MongoDB: Envía datos necesarios
+Webapp <-- Restapi: Devuelve token
+Usuario <- Webapp: Notifica al usuario
+----
 
-=== Escenario 2. Comenzar un nuevo pedido
-Para comenzar un nuevo pedido, has de loggearte en la web, con los datos requeridos que previamente 
-has proporcionado mediante el Pod, y comenzar a añadir productos a tu pedido
+=== Escenario 2. Iniciar sesión
 
+[plantuml,"escenario2",png]
+----
+actor Usuario
+entity Webapp
+entity Restapi
+database POD
+database MongoDB
+Usuario -> Webapp: Rellenar formulario login
+Webapp -> Restapi: Envía los datos
+Restapi -> POD: Valida los datos
+POD --> Restapi: Devuelve los datos privados
+Restapi -> MongoDB: Valida los datos
+MongoDB --> Restapi: Devuelve los datos correspondientes
+Restapi --> Webapp: Devuelve token 
+Webapp -> Usuario: Notifica al usuario
+----
 
+El usuario deberá rellenar el formulario correspondiente para iniciar sesión. Los datos serán enviados y validados y finalmente se le notificará al usuario si ha introducido los datos correctamente.
 
 === Escenario 3. Realizar un pedido
 Se empezarán a añadir los productos deseados al pedido y una vez se hayan añadido todos 
 los productos necesarios, podrás finalizar el pedido y se enviará a la direccion proporcionada
-por el pod
+por el pod.
+
+=== Escenario 4. Vista de productos
+Una vez en la vista de tienda, se pueden realizar varias operaciones, como ver detalles, filtrar 
+productos, buscar por nombre y añadir al carrito.
+[plantuml,"vistaProductos",png]
+----
+actor Usuario
+participant Tienda
+participant Carrito
+Usuario -> Tienda: accede
+Usuario -> Tienda: aplica filtros
+Usuario -> Tienda: detalles producto
+Tienda -> Tienda: mostrar detalles
+Usuario -> Tienda: añadir carrito
+Tienda -> Carrito: añade producto
+----
+
+=== Escenario 5. Información sobre pods
+Desde la vista de registro se puede navegar hasta una pantalla que contiene información sobre
+los pods que se utilizan en la aplicación.
+[plantuml,"vistaPods",png]
+----
+actor Usuario
+participant Sing_Up
+participant Info_Pods
+Usuario -> Sing_Up: accede
+Usuario -> Sing_Up: info Pods
+Sing_Up -> Info_Pods: redirige
+Usuario -> Info_Pods: volver a sing up
+Info_Pods -> Sing_Up: redirige
+----
+

docs/08_concepts.adoc

@@ -1,49 +1,41 @@
 [[section-concepts]]
-== Cross-cutting Concepts
+== Conceptos transversales
 
-=== Interfaz de usuario
+=== Modelo de dominio de la aplicación
 
-image:PrototipoInicio.png["Prototipo de la pantalla principal"]
+image:ModeloDominio.png["Modelo de dominio"]
 
-image:PrototipoProductos.png["Prototipo de la pantalla de vista de productos"]
 
-image:PrototipoPerfil.png["Prototipo de la pantalla del perfil"]
+.Table
+[options="header", cols="1,2"]
+|===
+| Nombre | Descripción 
+| POD | Es el elemento encargado de almacenar toda la información del usuario, que con su permiso podremos utilizar para realizar el envío del pedido. Para ello tendrá que darnos su consentimiento mediante el log in de SOLID.
+| Cliente | Realizará el pedido y nos facilitará sus datos personales (nombre, DNI, dirección) para poder realizar el envío.
+| Pedido | Contendrá todos los productos que el cliente haya elegido, y serán enviados a la dirección correspondiente.
+| Producto | Puede ser un pincho (bocata), una bebida o todo lo que este a disposición del cliente para ser añadido al pedido.
+|===
 
-[role="arc42help"]
-****
-.Content
-Este apartado contendrá la información principal de los elementos o conceptos 
-protagonistas en la aplicación.
 
-.Motivation
-Definir un modelo de dominio de la aplicación para ilustrar las entidades que 
-formarán partede nuestra app y la interacción entre ellos.
-****
+=== Interfaz de usuario
 
-=== Domain model
+image:PrototipoInicio.png["Prototipo de la pantalla principal"]
 
-image:domainModel.png["Example UML Diagram"]
+image:PrototipoProductos.png["Prototipo de la pantalla de vista de productos"]
 
+image:PrototipoPerfil.png["Prototipo de la pantalla del perfil"]
 
 
-=== Concepto 1
+=== Seguridad
 
-Producto: Es el principal actor de la aplicación y serán los productos que
-el usuario podrá añadir a su pedido, en el caso de nuestra aplicación, serán
-pinchos (bocatas) 
+Es parte fundamental de la aplicación el intercambio de datos y el procesamiento de estos de forma segura. Parte de esta seguridad viene dada por el uso de SOLID, que almacena los datos asegurando su seguridad.
 
-=== Concepto 2
+=== Pruebas funcionales
 
-Pedido: Contiene todos los productos que el cliente haya seleccionado y serán
-enviados al domicilio que figura en el Pod del usuario, calculando el precio del
-pedido en funcion del domicilio del cliente
+La aplicación deberá ser probada mediante el uso de tests creados para comporobar el funcionamiento, ayudándonos a determinar la correcta implementación de esta.
 
-=== Concepto 3
+=== Privacidad
 
-Cliente: Persona física que interactua con la aplicación
+Se deverá mantener en todo momento la privacidad de los datos personales del usuario. Esto se hará gracias al uso de los PODs de SOLID, que nos permite almacenar datos de manera descentralizada. Nuestro equipo se compromete a no almacenar ninguno de estos datos sensibles en nuestra base de datos.
 
-=== Concepto 4
- Pod: Estructura que utiliza nuestra arquitectura SOLID para guardar los datos del cliente
- para que la aplicación pueda utilizar estos datos, el cliente tendráa que darle permisos al 
- servicio
 

docs/09_design_decisions.adoc

@@ -4,8 +4,8 @@
 [options="header",cols="1,2,3,4"]
 |===
 |Decisión|Importancia|Consecuencias|Justificación
-| Uso de MERN | Toda la aplicación se basa en esto | No hay marcha atrás, quitando la base de datos, toda la aplicación depende de esta decisión | Nos da una base sólida para el proyecto, su uso es muy cómodo y se ajusta a lo buscado
-| Uso de MongoDB | La parte importante la aplicación, los productos, dependen de esta decisión | Un mal uso de la base de datos temprano puede traer consigo cambios muy grandes en el futuro | Es más fácil de utilizar junto al resto de tecnologías seleccionadas que el resto de las bases de datos
-| Temática de la tienda | La aplicación ha de girar en torno a esta temática | Si hubiera que cambiar la temática, habría que tocar diseños, clases, base de datos… | Nos pareció una temática adecuada
-| Uso de SOLID | Los datos del usuario serán tratados a través de pods | Si quisiéramos quitar SOLID, tendríamos que rehacer todo lo relacionado con la obtención de los datos del usuario | Es una buena forma de preservar la privacidad del usuario y sus datos.
+| Uso de MERN Stack | Muy alta dado que esta decisión marca las tecnologías y la forma en la que vamos a utilizarlas | A pesar de que toda la aplicación dependa de esto, el uso de MERN nos proporciona una buena versatilidad a la hora de programar y una estructura de diseño completa | Hemos decidido usarla debido a que nos proporciona una base sólido para la realización del proyecto y se ajusta a las necesidades del proyecto.
+| MongoDB | Todos lo relativo a los datos y a su gestión depende de esta decisión | Un mal uso de la base de datos temprano puede traer consigo cambios muy grandes en el futuro | Es más fácil de utilizar junto al resto de tecnologías seleccionadas que el resto de las bases de datos
+| Temática de la tienda | La aplicación ha de girar en torno a esta temática | Si hubiera que cambiar la temática, habría que tocar diseños, clases, base de datos… | Nos pareció una temática adecuada.
+| Uso de SOLID | Los datos del usuario serán tratados a través de pods, donde se guardará información del usuario, manteniendo así su privacidad. | Si quisiéramos quitar SOLID, tendríamos que rehacer todo lo relacionado con la obtención de los datos del usuario | Es una buena forma de preservar la privacidad del usuario y sus datos.
 |===

docs/10_quality_scenarios.adoc

@@ -1,6 +1,8 @@
 [[section-quality-scenarios]]
 == Requerimientos de Calidad
 
+
+
 === Árbol de Calidad
 
 [plantuml,"qualityTree2",png]
@@ -10,6 +12,8 @@
 (Atributos de calidad) --> (Privacidad)
 (Atributos de calidad) --> (Seguridad)
 (Atributos de calidad) --> (Accesibilidad)
+(Atributos de calidad) --> (Portabilidad)
+(Atributos de calidad) --> (Integridad)
 ----
 
 === Escenarios de calidad
@@ -23,4 +27,6 @@
 | 3 | Privacidad | El sistema ha de respetar la privacidad de los usuarios almacenando sus datos en PODs | Alta, Alta
 | 4 | Seguridad | Deberá haber un grado de seguridad para que los usuarios no entren en una cuenta que no les pertenezca | Media, Alta
 | 5 | Accesibilidad | La aplicación deberá se accesible siguiendo las recomendaciones WCAG 2.0 (Level AAA) | Baja, Media
+| 6 | Portabilidad | La aplicación podrá ser ejecutada independientemente del dispositivo en el que se despliegue | Baja, Baja
+| 7 | Integridad | Se deberá mantener en todo momento la integridad y consistencia de los datos que maneje la aplicación | Arlta, Alta
 |==============

docs/11_technical_risks.adoc

@@ -1,7 +1,26 @@
 [[section-technical-risks]]
+
 == Riesgos y deuda técnica
-* Desconocimiento de la tecnología a usar en el desarrollo del proyecto.
-* La posibilidad de que un miembro abandonce el grupo.
-* Posible mala implementacion de la estructura de del proyecto y tener que refactorizar la mayor parte de esta.
-* Posibles fallos incontrolados o situaciones no conocidas en la aplicación.
 
+[cols="1,4"]
+.Riesgos
+|==============
+| Riesgo | Descripción
+| Uso de React | Ningún miembro del equipo ha utilizado antes este framwork, por lo que tendremos que estar constantemente informándonos
+| Uso de Typescrip | En general tenemos algún conocimiento de Javascript, pero no creemos que sea el adecuado para este proyecto.
+| Uso de MongoDB | No estamos acostumbrados a integrar en una aplicación una base de datos no relacional, por lo que necesitamos documentarnos correctamente
+| Uso de SOLID | Actualmente es la tecnología que más desconocemos, por lo que tenemos que emplear parte de nuestro tiempo en investigar cómo funciona SOLID
+| Tiempo | Hay que entregar el proyecto en una fecha determinada, por lo que la organización del equipo ha de ser crucial para llegar a tiempo
+| Trabajo en equipo | El equipo cuenta con 5 personas, por lo que se ha de mantener una buena comunicación y organización en todo momento
+| Seguridad | Es imprescindible almacenar la información sensible de los usuarios en los PODS asegurando la seguridad de los mismos.
+|==============
+
+[cols="1,4"]
+.Deudas técnicas
+|==============
+| Deuda Técnica | Descripción
+| Test | Actualmente el proyecto no cuenta con test necesarios para cubrir toda la funcionalidad de la aplicación.
+| Filtros | El código actual que actualiza la lista de productos según filtros no está bien planificado y, con la llegada de más filtros,
+quedará un código demasiado extenso
+| Clases grandes | Tenemos clases con mucha información, lo que provoca que, en una modificación que les afecte, tendremos dificultades para codificarlos
+|==============

heroku.yml

@@ -0,0 +1,9 @@
+# Reference the Dockerfiles to build into Docker images 
+build:
+  docker:
+    webapp: webapp/Dockerfile
+    restapi: restapi/Dockerfile
+run:
+  webapp: npm start
+  restapi: npm start
+