Arquisoft · lumialfe · Apr 4, 2022 · Apr 4, 2022 · Apr 4, 2022
diff --git a/docs/03_system_scope_and_context.adoc b/docs/03_system_scope_and_context.adoc
@@ -10,15 +10,15 @@ Here we define how the different components of DeDe interact with each other, as
 @startuml
 Actor User
 database POD
-component CorreosAPI
+component ShippingAPI
 node DeDe {
   database MongoDB
 }
 User --> DeDe : Input
 User --> POD : Creates and manages
 DeDe -u-> User : Returns view / data
 DeDe -l-> POD : Requests / updates information
-DeDe -r-> CorreosAPI : Places order on checkout
+DeDe -r-> ShippingAPI : Places order on checkout
 POD --> DeDe : Returns information
 @enduml
 ....
@@ -31,7 +31,7 @@ POD --> DeDe : Returns information
 |DeDe|The application will receive requests to fulfill from the user, as well as data from both the POD and the MongoDB when required.|The web app will send responses to the user and requests for information to both the POD and Mongo Database. For solicitations to the POD, a login in Solid must be filled by the user. It's integral to the architecture that the data from the POD and the one from MongoDB are handled separately as to not divulge any personal information.
 |Solid POD|The user will create the POD to manage his personal information in the app. The application itself, will request for the necessary sensitive data and should always ask for authentication from the user.|The POD will only send personal information to the application, after the appropiate login in Solid.
 |MongoDB|The database will accept requests from the application for any information stored (that is, the one we consider not to be personal or sensitive, like the set of products available).|The database will communicate with the application as a response. It will return information that is supposed to be known as public.
-|Correos API|The API will accept requests from the application, avoiding interaction with the user as serving to mediate between him and the delivery is the main purpose of the application.|From the API, a response will ideally be given to DeDe when the order has been completed, although this behaviour can be considered optional as making the order is the end goal.
+|Shipping API|The API will accept requests from the application, avoiding interaction with the user as serving to mediate between him and the delivery is the main purpose of the application.|From the API, a response will ideally be given to DeDe when the order has been completed, although this behaviour can be considered optional as making the order is the end goal.
 |===
 
 

diff --git a/docs/04_solution_strategy.adoc b/docs/04_solution_strategy.adoc
@@ -7,7 +7,7 @@ We have chosen to use the following technologies:
 
 * *MongoDB:* One of the most potent non-relational databases, which fits the decentralised data model of DeDe. We will use it to store the information that is general to the application so as to not fill the PODs with unnecessary and redundant information.
 * *JSON:* Exporting the information of the purchases for communication with API will be done with JSON, a flexible and powerful format of handling data that can also be converted easily to many others (such as n3 or turtle).
-* *Correos API:* We will communicate with it to inform the deliverers of the chosen products. It's the single most important external service in our application.
+* *Shipping API:* We will communicate with it to inform the deliverers of the chosen products and receive an estimate shipping price to show the user. It's the single most important external service in our application.
 * *Mongoose:* We will employ the Mongoose library as the frame to communicate with the internal Mongo database. It is easily accesible with Node JS
 * *Material UI:* A library for web development that contains many predefined components. It will serve to ease work on HTML and CSS by providing default stylization and easy ways of handling customization from TypeScript. It is also highly compatible with React.
 

diff --git a/docs/06_runtime_view.adoc b/docs/06_runtime_view.adoc
@@ -59,8 +59,32 @@ WebApp --> User: notifies finalization of ordering
 ----
 
 
-=== ... 
- * In further versions more runtime views will be added... #TBD
+=== User logs in
+ * To log in, the user must access the login page, where they must choose a solid pod provider to authenticate with. Once authentication is complete, the provider will grant the web app the information requested. Thanks to this information, the user orders stored in the database will be retrieved. All this data will be shown to the user by means of the user page.
+
+[plantuml,"Runtimeview 3",png]
+----
+@startuml 07_RuntimeView_login
+actor User
+participant WebApp
+participant restapi as "Dede Server"
+participant Provider as "Pod Provider"
+database POD as "User's POD"
+database DB as "DeDe database"
+
+User -> WebApp: Selects provider
+WebApp -> Provider: Asks for login
+Provider -> POD: Searches for login information
+POD -> Provider: Returns login information
+Provider -> WebApp: Returns login information
+WebApp -> restapi: Asks for user orders
+restapi -> DB: Asks for user orders
+DB -> restapi: Returns user orders
+restapi -> WebApp: Returns user orders
+WebApp -> User: Shows user profile page
+
+@enduml
+----
 
 
 

diff --git a/docs/07_deployment_view.adoc b/docs/07_deployment_view.adoc
@@ -30,13 +30,13 @@ node DBserver {
 
 actor User
 
-cloud CorreosAPI
+cloud ShippingAPI
 
 DeDe -u-> MongoDB : CRUD
-DeDe -d-> Pod : getUserAddress
+DeDe -d-> SOLID_POD : getUserAddress
 DeDe -l-> WebApp : serve
-DeDe -r-> CorreosAPI : calculateRoute
-Pod <-l- User
+DeDe -r-> ShippingAPI : calculateRoute
+SOLID_POD <-l- User
 WebApp <-d- User
 
 @enduml
@@ -60,5 +60,5 @@ Mapping of Building Blocks to Infrastructure::
     |WebApp | This is the user end of the application. It will be rendered by a web browser, which will be executed over the users personal computer or smart device, like phones, tablets...
     |Pod | These are the users Pods, where their address will be stored. They will be served by the SOLID project, and hosted in a server of the user's election.
     |MongoDB | This is the DataBase, which will be stored on a server as well. Like the application per se, the nature of this server is still to be determined.
-    |CorreosAPI | This API will be used to calculate routes and costs of delivery. It will be hosted by a third party in a server of their choosing.
+    |ShippingApi | This API will be used to calculate routes and costs of delivery. It will be hosted by a third party in a server of their choosing.
 |===
diff --git a/docs/09_design_decisions.adoc b/docs/09_design_decisions.adoc
@@ -4,15 +4,21 @@
 
 === Web Application
 We decided to create a Web application supported by the latest versions of the main market browsers (Chrome, Firefox, Edge...). This online version of DeDe could be ported
-to a portable device app easily with REACT Native, a JavaScript framework for writing real, natively rendering mobile applications for iOS and Android.
+to a mobile device app easily with REACT Native, a JavaScript framework for writing real, natively rendering mobile applications for iOS and Android.
+
+Because we are choosing to develop a web app from the beggining, we must take careful consideration into making components mobile friendly. This should not be done, it would prove a struggle to adapt in the future.
 
 
 === Database
 We chose MongoDB as our Database Management System because its flexible schema allows us 
 to rapidly model the domain and change it with the evolution of the app without any problems.
 MongoDB stores data in form of JSON so the conversion and interaction between typescript and the database are flawless.
-Another point in favor is its performance and scalability although in a small application like ours is not strictly necessary.
+Another point in favor is its performance and scalability although in a small application like ours is not strictly necessary. We also chose MongoDB because it gives us a free database in the cloud for developing purposes.
+
+By discarding the use of an SQL database, we are also losing the opportunity to wotk with an schema, and thus, all data validation responsibility falls in the hands of the developers, that is, us. This may prove trying at times, but it is also good to learn new technologies.
 
 
 === Material UI
 Material UI is a free React-compatible library directed at easy creation of responsive components. It contains many default styles for typography, forms, buttons, navigation, and other interface components. It will allow us to create a good frontend with less effort.
+
+We descarded the use of Bootstrap because we felt that Material was more attuned to what we were trying to do with this reactive app. By doing so, we made a lot of design decision fall in the developers hands, making it more customizable but also more diffcult and time consuming to create.