Merge branch 'documentation' into documentation-1.1-sara

docs/01_introduction_and_goals.adoc

@@ -1,6 +1,6 @@
 [[section-introduction-and-goals]]
 == Introduction and Goals
-
+This is a mock to test how to deploy the documentation.
 [role="arc42help"]
 ****
 Describes the relevant requirements and the driving forces that software architects and development team must consider. These include
@@ -9,7 +9,11 @@ Describes the relevant requirements and the driving forces that software archite
 * quality goals for the architecture
 * relevant stakeholders and their expectations
 ****
-LoMap intends to be an easy-to-use tool for people to create, customize, and share personal maps filling them with the places they live
+LoMap intends to be an easy-to-use tool for people to create, customize, and share personal maps filling them with the places they live.
+
+This map application allows the user to create multiple different maps that are empty.
+
+The user then will create locations or photos for the places they want and add them to any of their own maps. You can add friends or groups and share these location with them so that they show on their maps for them to comment or give a score
 
 === Requirements Overview
 
@@ -32,18 +36,17 @@ If requirements documents exist this overview should refer to these documents.
 Keep these excerpts as short as possible. Balance readability of this document with potential redundancy w.r.t to requirements documents.
 ****
 
-* Users must be able to create different maps
-** One user could have more than one map
-* Users must be able to add locations to their own maps
-** The locations could be of different types, initially shops, bars, restaurants, sight and monuments.
-* Users must be able to add reviews to locations.
-** Scores, comments and pictures could be added to a location.
-* Locations could be shared with other users.
-** Locations can be shared with a friend or a group of friends.
-* User's data will be extracted and stored into SOLID PODS.
-** Users' locations information will also be stored in the user' POD.
-* Locations will be printed in a map.
-** The map should have filters. Initially category, friends, and different types of locations.
+* Users must be able to create different maps. One user could have more than one map
+
+* Users must be able to add locations to their own maps. Initially shops, bars, restaurants, sight and monuments.
+
+* Users must be able to add reviews to locations. Scores, comments and pictures could be added to a location.
+
+* Locations could be shared with other users, a friend or a group of friends.
+
+* User's data will be extracted and stored into SOLID PODS. Users' locations information will also be stored in the user' POD.
+
+* Locations will be printed in a map. It will have filters. Initially category, friends, and different types of locations.
 
 
 
@@ -64,11 +67,10 @@ A table with quality goals and concrete scenarios, ordered by priorities
 [options="header",cols="1,2,2"]
 |===
 |Priority|Description|Expectations
-|1|Delivery time|Project must be delivered the first week of May. 
-|2|Privacy|Users' data will only be accessed when permissions have been granted.
-|3|Decentralization|Users' data will be accessed and stored using Solid PODS.
-|4|Usability|The application must be intuitive so a novice user should be able to navigate in less than 10 minutes.
-|5|Accesibility|The web application will comply with WCAG 2.0 at level AAA.
+|1|Privacy|Users' data will only be accessed when permissions have been granted.
+|2|Decentralization|Users' data will be accessed and stored using Solid PODS.
+|3|Usability|The application must be intuitive so a novice user should be able to navigate in less than 10 minutes.
+|4|Accesibility|The web application will comply with WCAG 2.0 at level AAA.
 |===
 
 === Stakeholders
@@ -97,11 +99,11 @@ Table with role names, person names, and their expectations with respect to the
 |===
 |Role/Name|Contact|Description|Expectations
 |Developers|Mario Pérez Fernández ([email protected]) +
- Ivan Vega Gracía ([email protected]) + 
- Silvia Suárez Prendes ([email protected]) +
- Sara María Ramírez Pérez ([email protected]) + 
- Elías Llera García-Riaño ([email protected]) + 
- Andrés Álvarez Murillo ([email protected])|Group of students in charge of developing the project.|Deliver a fucntional version that meets the specified requirements.
+Ivan Vega Gracía ([email protected]) +
+Silvia Suárez Prendes ([email protected]) +
+Sara María Ramírez Pérez ([email protected]) +
+Elías Llera García-Riaño ([email protected]) +
+Andrés Álvarez Murillo ([email protected])|Group of students in charge of developing the project.|Deliver a fucntional version that meets the specified requirements.
 |Teachers|Pablo González González ([email protected]) +
 José Emilio Labra Gayo ([email protected]) |Professors of the course in charge of supervising and guide the development team.| Evaluate the final delivery and help through the process.
 |Users| |Final users of LoMap. |Use the application, and they should be satisfied by it.

docs/03_system_scope_and_context.adoc

@@ -26,6 +26,6 @@ image:3-Context/TechnicalView.png["Technical context diagram"]
 
 The frontend of the application is made with React, Redux and has a Map API wich provides the application with visual maps. The frontend will communicate with the Solid POD by means of a library that is not determined yet.
 
-The Map will be used to search for an API and it will make HTTP requests. It will also communicate with the backend of the application using a technology that is not determined yet.
+The Map will be used to search for an API and it will make HTTPS requests. It will also communicate with the backend of the application using a technology that is not determined yet.
 
 The user will access the frontend of the application by using different devices such as a PC or a smartphone. 

docs/04_solution_strategy.adoc

@@ -38,8 +38,9 @@ This are the technologies that we have decided to use, some of them may vary in
 === Design decisions:
 The general design of our project has two main parts, connected using a facade:
 
- * Webapp (frontend): with views and connections to the SOLID PODs and to the RestAPI facade
- * RestAPI (backend): controls the acess to the database and works as a microservice
+ * Webapp (frontend): It has different views, it connects to the SOLID PODs to acess user's data in an secure way, and it communicates with the backend using a facade
+ * RestAPI (backend): controls the acess to the database and communicates with the frontend using the facade
+
 
 
 === Quality decisions

docs/07_deployment_view.adoc

@@ -106,7 +106,7 @@ The "WebApp" block corresponds to the Static Provider Container, which provision
 [plantuml, target=deployment-node-diagram, format=png]
 ....
 frame Docker {
-    frame nodeCont as  "node:10-alpine" {
+    frame nodeCont as  "node" {
         node RestApi {
 
         }