Merge pull request #254 from Arquisoft/develop

Despliegue + tests

.github/workflows/heroku_copy.yml

@@ -0,0 +1,35 @@
+name: Despliegue en Heroku (rama de desarrollo)
+
+on:
+  push:
+    branches: [ uo271411-pruebas-heroku ]
+  pull_request:
+    branches: [ uo271411-pruebas-heroku ]
+
+jobs:
+  heroku-restapi:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v2
+      - uses: akhileshns/[email protected] # This is the action
+        with:
+          heroku_api_key: ${{secrets.HEROKU_API_KEY}}
+          heroku_app_name: "dede-es3a-restapi" #Must be unique in Heroku
+          heroku_email: ${{secrets.HEROKU_EMAIL}}
+          usedocker: true
+          appdir: "restapi" # <- This will point to the api folder in your project
+          branch: "uo271411-pruebas-heroku"
+
+  heroku-webapp:
+    needs: [heroku-restapi]
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v2
+      - uses: akhileshns/[email protected] # This is the action
+        with:
+          heroku_api_key: ${{secrets.HEROKU_API_KEY}}
+          heroku_app_name: "dede-es3a" #Must be unique in Heroku
+          heroku_email:  ${{secrets.HEROKU_EMAIL}}
+          usedocker: true
+          appdir: "webapp" # <- This will point to the api folder in your project
+          branch: "uo271411-pruebas-heroku"  

docs/01_introduction_and_goals.adoc

@@ -1,46 +1,49 @@
 [[section-introduction-and-goals]]
 
 
-[role="arc42help"]
-****
-		
-****
 == 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.
+-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.
+
 
-[role="arc42help"]
-****
-****
 
 === 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.
-	-Dede_es3a dará al usuario la posibilidad de añadir elementos al carrito.
-	-Dede_es3a dará al usuario la posibilidad de borrar elementos del carrito.
-	-Dede_es3a permitirá el registro de usuarios mediante formulario siempre y cuando el usuario no sea existente.
-	-Dede_es3a permitirá el registro de usuarios mediante formulario si las credenciales coinciden con la BDD.
-	-Dede_es3a dispondrá de uan lista de pedidos por usuario en la que se almacenará los pedidos realizados por el usuario.
-
-[role="arc42help"]
-****
-****
+-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.
+
+-Dede_es3a dará al usuario la posibilidad de añadir elementos al carrito.
+
+-Dede_es3a dará al usuario la posibilidad de borrar elementos del carrito.
+
+-Dede_es3a permitirá el registro de usuarios mediante formulario siempre y cuando el usuario no sea existente.
+
+-Dede_es3a permitirá el registro de usuarios mediante formulario si las credenciales coinciden con la BDD.
+
+-Dede_es3a dispondrá de una lista de pedidos por usuario en la que se almacenará los pedidos realizados por el usuario.
+
 === Metas de calidad
+
+.Metas de calidad
 [options="header",cols="1,2,1,1"]
 |===
 |Meta de Calidad|Motivación|Prioridad del ED| Prioridad del Cliente
@@ -51,18 +54,15 @@ Objetivos de Negocio:
 |Modificabilidad|La arquitectura debe ser fácil de modificar, agregando nuevas características o cambiando las existentes|Media|Media
 |===
 
-[role="arc42help"]
-****
 
-****
 === 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.
+|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.
 |===
 
 Administradores: se encargan de modificar precios, calcular inventarios, ver todos los pedidos realizados o 
@@ -73,4 +73,4 @@ todo el código para facilitar el entendimiento por parte de los demás miembros
 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.
+de Objetos.

docs/02_architecture_constraints.adoc

@@ -17,6 +17,7 @@ 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 .
 ****
+.Restricciones técnicas
 [options="header",cols="1,2"]
 |===
 |Restricción|Descripción
@@ -26,6 +27,7 @@ Tabla con todas las restricciones técnicas junto con una breve descripción .
 |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.
 |===
 
 === Restricciones de negocio
@@ -37,11 +39,11 @@ Son las restricciones de negocio para el desarrollo del sistema.
 .Form 
 Tabla con todas las restricciones de negocio junto con una breve descripción .
 ****
-
+.Restricciones de negocio
 [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.
+|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.
 |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.
-|===
+|===

docs/03_system_scope_and_context.adoc

@@ -1,82 +1,33 @@
 [[section-system-scope-and-context]]
 == Alcance y Contexto del Sistema
 
-[role="arc42help"]
-****
-.Contents
-System scope and context - as the name suggests - delimits your system (i.e. your scope) from all its communication partners
-(neighboring systems and users, i.e. the context of your system). It thereby specifies the external interfaces.
-
-If necessary, differentiate the business context (domain specific inputs and outputs) from the technical context (channels, protocols, hardware).
-
-.Motivation
-The domain interfaces and technical interfaces to communication partners are among your system's most critical aspects. Make sure that you completely understand them.
-
-.Form
-Various options:
-
-* Context diagrams
-* Lists of communication partners and their interfaces.
-****
-
-
 === Contexto de negocio
-
-[role="arc42help"]
-****
-.Contents
-Specification of *all* communication partners (users, IT-systems, ...) with explanations of domain specific inputs and outputs or interfaces.
-Optionally you can add domain specific formats or communication protocols.
-
-.Motivation
-All stakeholders should understand which data are exchanged with the environment of the system.
-
-.Form
-All kinds of diagrams that show the system as a black box and specify the domain interfaces to communication partners.
-
-Alternatively (or additionally) you can use a table.
-The title of the table is the name of your system, the three columns contain the name of the communication partner, the inputs, and the outputs.
-****
 image:03_diagramaContextoNegocio.png["Diagrama de contexto"]
 
 *   **Cliente**
 
-	Usuarios finales de la aplicación. Son los clientes que van a realizar las compras.
+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.
+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)
+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.
+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.
+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.
+Nuestro sistema se conectará con diferentes empresas de mensajería para poder calcular los costes de envío de los pedidos.
 
 === Contexto técnico
 
-[role="arc42help"]
-****
-.Contents
-Technical interfaces (channels and transmission media) linking your system to its environment. In addition a mapping of domain specific input/output to the channels, i.e. an explanation with I/O uses which channel.
-
-.Motivation
-Many stakeholders make architectural decision based on the technical interfaces between the system and its context. Especially infrastructure or hardware designers decide these technical interfaces.
-
-.Form
-E.g. UML deployment diagram describing channels to neighboring systems,
-together with a mapping table showing the relationships between channels and input/output.
-
-****
-
-Pendiente
+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.

docs/04_solution_strategy.adoc

@@ -1,26 +1,6 @@
 [[section-solution-strategy]]
 == Estrategia de la solución
 
-[role="arc42help"]
-****
-.Contents
-A short summary and explanation of the fundamental decisions and solution strategies, that shape the system's architecture. These include
-
-* technology decisions
-* decisions about the top-level decomposition of the system, e.g. usage of an architectural pattern or design pattern
-* decisions on how to achieve key quality goals
-* relevant organizational decisions, e.g. selecting a development process or delegating certain tasks to third parties.
-
-.Motivation
-These decisions form the cornerstones for your architecture. They are the basis for many other detailed decisions or implementation rules.
-
-.Form
-Keep the explanation of these key decisions short.
-
-Motivate what you have decided and why you decided that way,
-based upon your problem statement, the quality goals and key constraints.
-Refer to details in the following sections.
-****
 
 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. 
 

docs/05_building_block_view.adoc

@@ -2,61 +2,8 @@
 
 
 == Vista de bloques
-
-[role="arc42help"]
-****
-.Content
-The building block view shows the static decomposition of the system into building blocks (modules, components, subsystems, classes,
-interfaces, packages, libraries, frameworks, layers, partitions, tiers, functions, macros, operations,
-datas structures, ...) as well as their dependencies (relationships, associations, ...)
-
-This view is mandatory for every architecture documentation.
-In analogy to a house this is the _floor plan_.
-
-.Motivation
-Maintain an overview of your source code by making its structure understandable through
-abstraction.
-
-This allows you to communicate with your stakeholder on an abstract level without disclosing implementation details.
-
-.Form
-The building block view is a hierarchical collection of black boxes and white boxes
-(see figure below) and their descriptions.
-
-image:05_building_blocks-EN.png["Hierarchy of building blocks"]
-
-*Level 1* is the white box description of the overall system together with black
-box descriptions of all contained building blocks.
-
-*Level 2* zooms into some building blocks of level 1.
-Thus it contains the white box description of selected building blocks of level 1, together with black box descriptions of their internal building blocks.
-
-*Level 3* zooms into selected building blocks of level 2, and so on.
-****
-
 === Sistema general
 
-[role="arc42help"]
-****
-Here you describe the decomposition of the overall system using the following white box template. It contains
-
- * an overview diagram
- * a motivation for the decomposition
- * black box descriptions of the contained building blocks. For these we offer you alternatives:
-
-   ** use _one_ table for a short and pragmatic overview of all contained building blocks and their interfaces
-   ** use a list of black box descriptions of the building blocks according to the black box template (see below).
-   Depending on your choice of tool this list could be sub-chapters (in text files), sub-pages (in a Wiki) or nested elements (in a modeling tool).
-
-
- * (optional:) important interfaces, that are not explained in the black box templates of a building block, but are very important for understanding the white box.
-Since there are so many ways to specify interfaces why do not provide a specific template for them.
- In the worst case you have to specify and describe syntax, semantics, protocols, error handling,
- restrictions, versions, qualities, necessary compatibilities and many things more.
-In the best case you will get away with examples or simple signatures.
-
-****
-
 image:05_diagramaGeneral.png["Diagrama de contexto"]
 
 Motivacion::
@@ -74,14 +21,6 @@ Interfaces importantes::
 
 === Nivel 2
 
-[role="arc42help"]
-****
-Here you can specify the inner structure of (some) building blocks from level 1 as white boxes.
-
-You have to decide which building blocks of your system are important enough to justify such a detailed description.
-Please prefer relevance over completeness. Specify important, surprising, risky, complex or volatile building blocks.
-Leave out normal, simple, boring or standardized parts of your system
-****
 
 image:05_diagramaDetalleNivel1.png["Diagrama de detalle nivel 1"]
 
@@ -97,13 +36,7 @@ Interfaces importantes::
 
 === Nivel 3
 
-[role="arc42help"]
-****
-Here you can specify the inner structure of (some) building blocks from level 2 as white boxes.
 
-When you need more detailed levels of your architecture please copy this
-part of arc42 for additional levels.
-****
 
 image:05_diagramaDetalleNivel2.png["Diagrama de detalle nivel 2"]