Merge pull request #273 from Arquisoft/develop

Develop

docs/01_introduction_and_goals.adoc

@@ -6,12 +6,11 @@ El proyecto trata de una aplicación de compra y venta de objetos, llamada DeDe,
 
 Objetivos de Negocio: 
 
--A corto plazo: Realizar una documentación adecuada de manera que se cumplan las 
-expectativas y necesidades del proyecto.
+-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.
+cómoda, sencilla y accesible.
 
 
 
@@ -31,46 +30,55 @@ 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.
 
--Dede_es3a dará al usuario la posibilidad de añadir elementos al carrito.
+-Se dará al usuario la posibilidad de tanto borrar como añadir elementos al carrito.
 
--Dede_es3a dará al usuario la posibilidad de borrar elementos del carrito.
+-Permitirá el registro de usuarios mediante formulario siempre y cuando sus credenciales no cincidan 
+con las de otro usuario.
 
--Dede_es3a permitirá el registro de usuarios mediante formulario siempre y cuando el usuario no sea existente.
+-Dede_es3a permitirá el inicio de sesión de usuarios mediante formulario si las credenciales coinciden con la 
+BDD.
 
--Dede_es3a permitirá el registro 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.
 
--Dede_es3a dispondrá de una lista de pedidos por usuario en la que se almacenará los pedidos realizados por el usuario.
+-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.
 
 === Metas de calidad
 
 .Metas de calidad
 [options="header",cols="1,2,1,1"]
 |===
 |Meta de Calidad|Motivación|Prioridad del ED| Prioridad del Cliente
-|Privacidad |El objetivo es el tratamiento de la información privada de una manera descentralizada asegurando la privacidad del cliente|Alta|Alta
+|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
-|Eficiencia |Realizar una compra debe ser sencilla para un usuario, haciendo que los tiempos de respuesta y de carga sean mas reducidos|Alta|Alta
-|Testabilidad|Los componentes principales deben de poder ser testeados y arreglados con facilidad|Alta|Baja
-|Modificabilidad|La arquitectura debe ser fácil de modificar, agregando nuevas características o cambiando las existentes|Media|Media
+|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
 |===
 
-
 === Partes interesadas (Stakeholders)
 .Stakeholders
 [options="header",cols="1,2"]
 |===
 |Role/Name|Expectations 
-|Administradores |Realizar una administración cómoda y sin inconvenientes.
 |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.
 |===
 
-Administradores: se encargan de modificar precios, calcular inventarios, ver todos los pedidos realizados o 
-realizar pedidos a proveedores
+Stakeholders primarios:
 
-Equipo de desarrollo: Que deben conocer la arquitectura de TypeScript, React y Solid.Deben trabajar de manera que se documente
+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.
+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.

docs/02_architecture_constraints.adoc

@@ -28,6 +28,7 @@ Tabla con todas las restricciones técnicas junto con una breve descripción .
 |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.
 |===
 
 === Restricciones de negocio
@@ -43,7 +44,8 @@ Tabla con todas las restricciones de negocio junto con una breve descripción .
 [options="header",cols="1,2"]
 |===
 |Restricción|Descripción
-|Equipo| El equipo esta formado por 5 personas con las que apenas hemos interactuado con anterioridad. Además de esto, 2 miembros del equipo abandonaron el proyecto.
+|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.
 |===

docs/03_system_scope_and_context.adoc

@@ -8,10 +8,6 @@ image:03_diagramaContextoNegocio.png["Diagrama de contexto"]
 
 Usuarios finales de la aplicación. Son los clientes que van a realizar las compras.
 
-*   **Administrador**
-
-Usuario que va a poder gestionar la aplicación: dar de alta productos, actualizar los stocks, revisar los pedidos, etc.
-
 *	**DeDe**
 
 Nuestro sistema de venta online (Decentralized Delivery)

docs/04_solution_strategy.adoc

@@ -6,7 +6,7 @@ Para el desarrollo de este proyecto viene impuesta como restricción la utilizac
 
 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á 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.
+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. 
 

docs/05_building_block_view.adoc

@@ -15,7 +15,7 @@ Bloques de construcción contenidos::
 -  **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
+-	Para conectar con las diferentes empresas de mensajería se utilizarán las APIS que suministren estos servicios.
 
 
 
@@ -27,11 +27,11 @@ image:05_diagramaDetalleNivel1.png["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.
+-  **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::
--	Existirá una API que comunicará el Back-End y el Front-End
+-	Gracias a la API (api.ts), podremos conectar el Back-End y el Front-End
 
 
 === Nivel 3
@@ -46,7 +46,7 @@ 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.
+-  **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

docs/06_runtime_view.adoc

@@ -1,19 +1,47 @@
 [[section-runtime-view]]
 == Vista de Ejecución
+=== 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.
+
+[plantuml,"Login_diagrama",png]
+----
+@startuml
+actor Usuario
+entity DeDe
+entity inrupt.net
+Usuario-> DeDe: Petición de autenticación
+DeDe-> inrupt.net: Comprobación de credenciales
+alt usuario existe
 
+    inrupt.net -> DeDe:Devuelve al usuario
+    DeDe->Usuario:Redirección a página principal con usuario identificado
+	
+else usuario no existe
+    inrupt.net -> DeDe: Mensaje de error
+end
+@enduml
+----
 === 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.
 
-image:DiagramaCompra.png["DiagramaCompra"]
-
-=== 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.
-
-image:DiagramaLogin.JPG["LogIn"]
+[plantuml,"Compra_diagrama",png]
+----
+@startuml
+actor Usuario
+entity DeDe
+database MONGODB
+Usuario-> DeDe: Añadir productos al carrito
+DeDe-> Usuario: Pedir datos necesarios para compra
+Usuario-> DeDe:Introducción datos necesarios
+DeDe-> MONGODB: Comprobación datos
+MONGODB-> DeDe:  Devuelve información necesaria
+DeDe-> Usuario: Notificación de la compra
+@endtuml
+----
 
 === 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.
@@ -24,5 +52,31 @@ image:06_diagramaSecuenciaEnvio.png["Cálculo de los gastos 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.
 
-image:DiagramaEnvio.png["Envio"]
+[plantuml,"Envio_diagrama",png]
+----
+@startuml
+
+participant Shoes
+activate Shoes
+Shoes -> BBDD: addOrder()
+activate BBDD
+BBDD --> Shoes: order created
+deactivate BBDD
+
+Shoes -> Deliver: order()
+activate Deliver
+
+Deliver -> User: notify()
+activate User
+
+Deliver --> User: items sent
+deactivate User
+
+Deliver --> Shoes: items sent
+deactivate Deliver
+deactivate Shoes
+
+@enduml
+----
+
 

docs/09_design_decisions.adoc

@@ -28,3 +28,9 @@ Para crear la parte de "User Interface" usaremos React, una herramienta que nos
 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.
+
+=== 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.

docs/10_quality_scenarios.adoc

@@ -8,15 +8,50 @@ La calidad es la habilidad de un producto o servicio de cumplir las necesidades,
 
 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.
 
-image:DiagramaCalidad.png["DiagramaArbolCalidad"]
+[plantuml,"Calidad_diagrama",png]
+----
+@startuml
+left to right direction
+
+rectangle Calidad
+
+rectangle "Escalabilidad" as E
+rectangle "Interoperabilidad" as I
+rectangle "Seguridad" as S
+rectangle "Usabilidad" as U
+rectangle "Accesibilidad" as A
+
+rectangle "Despliegue en Heroku" as DH
+rectangle "Compatibilidad entre navegadores" as CN
+rectangle "Foro de la asignatura" as FR
+rectangle "Login" as LG
+rectangle "Privacidad de POD" as PD
+rectangle "Operaciones sencillas aisladas" as OP
+
+
+Calidad --> A
+Calidad --> E
+Calidad --> I
+Calidad --> S
+Calidad --> U
+
+A --> DH
+S --> LG
+S --> POD
+I --> FR
+E --> OP
+
+@enduml
+----
 
 === Escenarios de calidad
 .Escenarios de calidad
 [options="header",cols="1,2"]
 |===
 |Requerimiento|Descripción
-| Privacidad | La aplicación no accede a los datos del usuario sin permisos, solo los necesarios para algunas funciones concretas. 
-| Usabilidad| La aplicación tiene una interfaz y manejo intuitivos, de uso fácil.
-| Accesibilidad| Cualquier usuario, puede interactuar con la página sin problemas. Nuestro objetivo es seguir unas pautas de accesibilidad Web.
-| Disponibilidad| En cualquier momento que el usuario desee interactuar con la aplicación, podrá hacerlo y se ejecutará eficientemente.
+| 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.
 |===

docs/11_technical_risks.adoc

@@ -20,6 +20,9 @@ A continuación se muestra una tabla [Table 7] en la que se irán recogiendo tod
 [options="header",cols="1,2,3"]
 |===
 | 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. | Media
-| 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. | Baja
+| 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
 |===

docs/12_glossary.adoc

@@ -1,6 +1,6 @@
 [[section-glossary]]
 == Glosario
-****
+
 .Glosario
 [options="header",cols="1,3"]
 |===