Merge pull request #145 from Arquisoft/develop

Segundo prototipo de la aplicación

.gitignore

@@ -29,3 +29,4 @@ yarn-error.log*
 #documentation build does not go into master
 docs/build
 
+restapi/.env

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/05_building_block_view.adoc

@@ -5,36 +5,10 @@
 
 The building block view shows the static decomposition of the system into building blocks as well as their dependencies. It allows us to understand the system as a whole.
 
-////
-  *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.
-////
-
 === Whitebox Overall System
 ****
 
 
-////
-  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::Diagram_ASW_Whitebox_Overall_System.png[Whitebox Overall System Diagram]
@@ -67,70 +41,19 @@ image::Diagram_ASW_Level1.png[Level 1 Diagram]
 
 ****
 
-////
-  === Level 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
-  ****
-
-  ==== White Box _<building block 1>_
-
-  [role="arc42help"]
-  ****
-  ...describes the internal structure of _building block 1_.
-  ****
-
-  _<white box template>_
-
-  ==== White Box _<building block 2>_
-
-
-  _<white box template>_
-
-  ...
-
-  ==== White Box _<building block m>_
-
-
-  _<white box template>_
-
-
-
-  === Level 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.
-  ****
-
-
-  ==== White Box <_building block x.1_>
-
-  [role="arc42help"]
-  ****
-  Specifies the internal structure of _building block x.1_.
-  ****
-
-
-  _<white box template>_
-
-
-  ==== White Box <_building block x.2_>
-
-  _<white box template>_
-
+=== Level 2
+****
+image::Diagram_ASW_Level2.png[Level 2 Diagram]
 
 
-  ==== White Box <_building block y.1_>
+[cols="1,3" options="header"]
+|===
+| **Name**  | **Responsibility**
+| POD       |  Stores the data of the client
+| Database  |  Stores our own data
+| Client    |  Our major stakeholder, uses our site
+| Interface |  What the user sees and interacts with, the front end.
+| API       |  The server of the interface, processes the information and deals with the database and the PODs
+|===
 
-  _<white box template>_
-////
+****

docs/06_runtime_view.adoc

@@ -1,45 +1,12 @@
 [[section-runtime-view]]
 == Runtime View
+=== Add Product to Shopping Cart
 
-
-
-////
-.Contents
-The runtime view describes concrete behavior and interactions of the system’s building blocks in form of scenarios from the following areas:
-
-* important use cases or features: how do building blocks execute them?
-* interactions at critical external interfaces: how do building blocks cooperate with users and neighboring systems?
-* operation and administration: launch, start-up, stop
-* error and exception scenarios
-
-Remark: The main criterion for the choice of possible scenarios (sequences, workflows) is their *architectural relevance*. It is *not* important to describe a large number of scenarios. You should rather document a representative selection.
-
-.Motivation
-You should understand how (instances of) building blocks of your system perform their job and communicate at runtime.
-You will mainly capture scenarios in your documentation to communicate your architecture to stakeholders that are less willing or able to read and understand the static models (building block view, deployment view).
-
-
-.Form
-There are many notations for describing scenarios, e.g.
-
-* numbered list of steps (in natural language)
-* activity diagrams or flow charts
-* sequence diagrams
-* BPMN or EPCs (event process chains)
-* state machines
-* ...
-
-
-////
-
-=== Log In
+=== Log In / Register
 
 
 image:Diagram_ASW_Runtime_LoginRegister.png["Hierarchy of building blocks"]
-////
- * _<insert description of the notable aspects of the interactions between the
-building block instances depicted in this diagram.>_
-////
+
 The the runtime interactions inside the system to log or register are the following:
 
  - First the client enters the webpage.
@@ -49,40 +16,89 @@ The the runtime interactions inside the system to log or register are the follow
  - We look into our database to see if user exists, if exists brings back his data, if dont we store them.
  - Now the user is logged in and it goes back to the home page.
 
-////
-It is possible to use a sequence diagram:
-
-image:
-[plantuml,"Sequence diagram",png]
-----
-actor Alice
-actor Bob
-database Pod as "Bob's Pod"
-Alice -> Bob: Authentication Request
-Bob --> Alice: Authentication Response
-Alice  --> Pod: Store route
-Alice -> Bob: Another authentication Request
-Alice <-- Bob: another authentication Response
-----
-////
 === 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
+----
 
-=== <Runtime Scenario n>
-////
+
+=== View User Orders
+
+=== Filter Catalog 
+image:Diagram_ASW_Runtime_FilterCatalog.png["Hierarchy of building blocks"]
+The the runtime interactions inside the system purchase any item in our store are the following:
+
+ - First the client enters the webpage.
+ - Then types the desired words to search for.
+ - Clicks search.
+ - 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>_