Merge branch 'develop' into Valentin_Interfaz

docs/02_architecture_constraints.adoc

@@ -19,7 +19,7 @@
 |===
 |	  |Constraint|Motivation
 | OC1 | Time | The application will be developed between March 2022 and May 2022.
-| OC2 | Team | Ignacio Gomez Gasch, Valentin Dumitru, Mario Garcia Prieto, Jorge Torano Herrera, Adrian Estrada Gonzalez
+| OC2 | Team | Ignacio Gomez Gasch, Valentin Dumitru, Jorge Torano Herrera, Adrian Estrada Gonzalez
 | OC3 | Repository| The code and infomation of the whole project will be managed in GitHub in a private repository.
 
 |===

docs/06_runtime_view.adoc

@@ -1,5 +1,6 @@
 [[section-runtime-view]]
 == Runtime View
+=== Add Product to Shopping Cart
 
 === Log In / Register
 
@@ -18,17 +19,68 @@ The the runtime interactions inside the system to log or register are the follow
 === Purchase 
 image:Diagram_ASW_Runtime_Purchase.png["Hierarchy of building blocks"]
 The the runtime interactions inside the system purchase any item in our store are the following:
+[plantuml,"Diagrama Añadir producto",png]
+----
+actor Client
+participant Shopping Cart
+Client -> Shopping Cart: Authentication request
+Shopping Cart -> Client: Authentication answer
+Client -> Shopping Cart: Add products
+note across: Then, the product is stored
+Client -> Shopping Cart: Click on shopping cart
+Shopping Cart -> Client: View shopping cart
+----
 
+=== Delete Product from Shopping Cart.
 
- - First the client enters the webpage.
- - Then searches the product they want by their name or searching by category.
- - After that, the API is called and it fetches the products the user searched from the database.
- - Afterwards the user will select the items he wants to buy.
- - We look into our database to see if user exists, if exists brings back his data, if dont we store them, and after finishing, they will go to the shopping cart to conclude.
- - The api will calculate the price, and if the user modifies the products, it will calculate it again.
- - Then the user will press buy.
- - For the order to be sent, the user is required to allow the app to collect data from the POD, in this case, his credit card, adress and other relevant data. After allowed, the API stores into the database the order.
- - And finally the user is sent back to the home page.
+[plantuml,"Diagrama Eliminar Producto",png]
+----
+actor Client
+participant Shopping Cart
+Client -> Shopping Cart: Click on shopping cart
+Shopping Cart -> Cliente: View shopping cart
+Client -> Shopping Cart: Delete selected product
+note across: Then, the product is deleted
+Shopping Cart -> Client: Shopping cart is updated
+----
+
+=== Login
+
+[plantuml,"Diagrama Inicio de sesión",png]
+----
+actor Client
+participant Frontend
+participant Backend
+Client -> Frontend: Introduce email and password
+Frontend -> Backend: Login request
+alt User exists
+    Backend -> Frontend: Returns user
+    Frontend -> Cliente: Redirects home page with the user session
+else User doesn't exists
+    Backend -> Frontend: Authentication error
+end
+----
+
+=== Register
+
+[plantuml,"Diagrama Registro",png]
+----
+actor Client
+participant Frontend
+participant Backend
+Cliente -> Frontend: Introduce email, name, dni, password and confirm password
+Frontend -> Backend: Authentication request
+alt User exists
+    Backend -> Frontend: Sign up fails
+    Frontend -> Cliente: Notification to user (email in use)
+else User doesn't exists
+    Backend -> Frontend: New user registered
+    Frontend -> Cliente: Redirects login page
+end
+----
+
+
+=== View User Orders
 
 === Filter Catalog 
 image:Diagram_ASW_Runtime_FilterCatalog.png["Hierarchy of building blocks"]
@@ -40,3 +92,13 @@ The the runtime interactions inside the system purchase any item in our store ar
  - The api processes the request and answers with the items.
  - The interface updates and shows the client their desired products.
 
+[plantuml,"Ver pedidos",png]
+----
+actor Client
+participant User Interface
+database "POD"
+Client -> User Interface: View orders
+User Interface -> "POD": Obtain user orders
+"POD" -> User Interface: Return user orders
+User Interface -> Show user orders
+----

docs/07_deployment_view.adoc

@@ -3,84 +3,15 @@
 
 == Deployment View
 
-[role="arc42help"]
-****
-.Content
-The deployment view describes:
-
- 1. the technical infrastructure used to execute your system, with infrastructure elements like geographical locations, environments, computers, processors, channels and net topologies as well as other infrastructure elements and
-
-2. the mapping of (software) building blocks to that infrastructure elements.
-
-Often systems are executed in different environments, e.g. development environment, test environment, production environment. In such cases you should document all relevant environments.
-
-Especially document the deployment view when your software is executed as distributed system with more then one computer, processor, server or container or when you design and construct your own hardware processors and chips.
-
-From a software perspective it is sufficient to capture those elements of the infrastructure that are needed to show the deployment of your building blocks. Hardware architects can go beyond that and describe the infrastructure to any level of detail they need to capture.
-
-.Motivation
-Software does not run without hardware.
-This underlying infrastructure can and will influence your system and/or some
-cross-cutting concepts. Therefore, you need to know the infrastructure.
-
-.Form
-
-Maybe the highest level deployment diagram is already contained in section 3.2. as
-technical context with your own infrastructure as ONE black box. In this section you will
-zoom into this black box using additional deployment diagrams:
-
-* UML offers deployment diagrams to express that view. Use it, probably with nested diagrams,
-when your infrastructure is more complex.
-* When your (hardware) stakeholders prefer other kinds of diagrams rather than the deployment diagram, let them use any kind that is able to show nodes and channels of the infrastructure.
-****
-
 === Infrastructure Level 1
 
-[role="arc42help"]
-****
-Describe (usually in a combination of diagrams, tables, and text):
-
-*  the distribution of your system to multiple locations, environments, computers, processors, .. as well as the physical connections between them
-*  important justification or motivation for this deployment structure
-* Quality and/or performance features of the infrastructure
-*  the mapping of software artifacts to elements of the infrastructure
-
-For multiple environments or alternative deployments please copy that section of arc42 for all relevant environments.
-****
-
-_**<Overview Diagram>**_
 
 Motivation::
 
-_<explanation in text form>_
+The motivation of this deployment structure is the correct understanding of how nodes and components of the project behave and are related in runtime.
 
 Quality and/or Performance Features::
 
-_<explanation in text form>_
+The performance mainly depends on the network connection from the user and the servers on which the application runs. We cannot control those two things, but we can improve as much as possible the quality of the application by writing the cleanest possible code.
 
 Mapping of Building Blocks to Infrastructure::
-_<description of the mapping>_
-
-
-=== Infrastructure Level 2
-
-[role="arc42help"]
-****
-Here you can include the internal structure of (some) infrastructure elements from level 1.
-
-Please copy the structure from level 1 for each selected element.
-****
-
-==== _<Infrastructure Element 1>_
-
-_<diagram + explanation>_
-
-==== _<Infrastructure Element 2>_
-
-_<diagram + explanation>_
-
-...
-
-==== _<Infrastructure Element n>_
-
-_<diagram + explanation>_

docs/09_design_decisions.adoc

@@ -4,10 +4,9 @@
 [options="header",cols="1,2"]
 |===
 |Decision|Reason
-|TypeScript|It will be one of the languages ​​used in the application. One of its positive aspects is its ease of use with Solid
-|Solid|This technology will be used to store client addresses through the use of pods.
-|React|The use of this open source library is one of the requirements of the application that will be used to create the application interfaces.
 |MogoDB|This type of database is according to the requirements of the application.
-|BootStrap|As it has been/will be used in other subjects, the use of this library has been chosen, since it is also in accordance with the requirements of the application.
 |Visual Studio Code|It will be the development enviroment used by all members of the group. One of its most favorable points is the possibility of adding a wide variety of extensions that will allow the project to be carried out in a simple way
+|Cloudinary|In this platform the images of the application will be stored, making it not necessary to save them locally
+|Node Geocoder|By using this library we get the coordinates from the user address stored in your POD
+|Openstreetmap|This will be the provider that we will use in the Node Geoder api, to obtain the coordinates of the user's address
 |===

docs/10_quality_scenarios.adoc

@@ -11,12 +11,12 @@ image::Quality_Tree.png[]
 === Quality Scenarios
 [options="header",cols="1,1,1,1"]
 |===
-Priority Position|Quality attribute|Scenario|Priority
-| **1** | **Usability** | The application must be intuitive and easy to use bu most users | Very High
-| **2** | **Privay**  | The user will have the power to choose the (non-essential) information that the application shows or has | Very High
-| **3** | **Security** | The application should offer a certain security and integrity against attacks | High
-| **4** | **Modifiability** | The application code should be easily extensible to add new functionality easily | Medium
-| **5** | **Efficiency** | The application must be optimized to minimize waiting times for services | Medium
-| **6** | **Testability** | The application code should be easily testable, to facilitate testing to realiease a robust final product | Medium
+ID|Quality attribute|Scenario|Priority User/Dev
+| **U.1** | **Usability** | The application must be intuitive and easy to use bu most users | High/High
+| **P.1** | **Privacity**  | The user will have the power to choose the (non-essential) information that the application shows or has | High/High
+| **S.1** | **Security** | The application should offer a certain security and integrity against attacks | High/Medium
+| **M.1** | **Modifiability** | The application code should be easily extensible to add new functionality easily | Low/High
+| **E.1** | **Efficiency** | The application must be optimized to minimize waiting times for services | High/Medium
+| **T.1** | **Testability** | The application code should be easily testable, to facilitate testing to realiease a robust final product | Low/High
 |===
 

docs/11_technical_risks.adoc

@@ -1,17 +1,13 @@
 [[section-technical-risks]]
-== Risks and Technical Debts
 
-
-[role="arc42help"]
-****
-.Contents
-A list of identified technical risks or technical debts, ordered by priority
-
-.Motivation
-“Risk management is project management for grown-ups” (Tim Lister, Atlantic Systems Guild.) 
-
-This should be your motto for systematic detection and evaluation of risks and technical debts in the architecture, which will be needed by management stakeholders (e.g. project managers, product owners) as part of the overall risk analysis and measurement planning.
-
-.Form
-List of risks and/or technical debts, probably including suggested measures to minimize, mitigate or avoid risks or reduce technical debts.
-****
+=== Risks and Technical Debts
+[options="header",cols="1,1"]
+|===
+Risk|Trade off
+| The interface is unfriendly to users | We will have to invest time to test and code the flows through the interfaces
+| The payment data of the purchases can intervene | slower payment transactions
+| An attacker can access and modify the data of our application | More time to choose a robust db for the application
+| It is complicated to add new functionalities to the application | Refactor and choose application design patterns well to facilitate the addition of new functionalities
+| Waiting times for application processes are very long | Increased work to design a code as efficient as possible
+| It is complicated to test the functionalities of the application | Increased work to design tests that test all the functionalities of the application
+|===

docs/12_glossary.adoc

@@ -43,4 +43,12 @@ Potentially more columns in case you need translations.
 | BootStrap                     | Bootstrap is a free and open source front end development framework for the creation of websites and web apps
 | TypeScript                    | TypeScript is a programming language developed and maintained by Microsoft
 | Visual Studio Code            | Visual Studio Code is a lightweight but powerful source code editor which runs on your desktop and is available for Windows, macOS and Linux
+|Cloudinary                     |Cloudinary is an api that transform images and videos to load faster with no visual degradation, automatically generate image and video variants, and deliver high quality responsive experiences to increase conversions.
+|OpenStreetMap                  |OpenStreetMap is a collaborative project to create free and editable maps.
+| U.1                           | Identificator for Usability
+| P.1                           | Identificator for Privacity
+| S.1                           | Identificator for Security
+| M.1                           | Identificator for Modifiability
+| E.1                           | Identificator for Efficiency
+| T.1                           | Identificator for Testability
 |===