Merge pull request #107 from Arquisoft/develop

Finalizada la versión 1.0.0

docs/01_introduction_and_goals.adoc

@@ -43,5 +43,5 @@ It is also proposed that this application could be extrapolated to other cities,
 | Customer. Brussels City Hall | https://www.brussels.be/city-hall | Promoter of the initiative. Obtain software that meets the requirements within the term and cost stipulated in the contract.
 | Administrators |   | After the deployment of the software in production, they monitor and resolve possible incidents.
 | POD provider | https://solidproject.org/users/get-a-pod | Allow data storage in a secure and decentralized way. Allow users to control which people and applications can access their data.
-| Map provider|  Pending select | It provides the base cartography in which users add places of interest to obtain personalized maps.
+| Map provider|  Mapbox | It provides the base cartography in which users add places of interest to obtain personalized maps.
 |===

docs/02_architecture_constraints.adoc

@@ -12,6 +12,9 @@ The technologies that are going to be used to develop this project are:
 | GitHub                  | Employed for version control and for team coordination, with tools such as issues and branches.
 | Interactive Map         | A means of implementing an interactive map must be included.
 | Docker                  | The web application will run on docker.
+| React                   | We are goinf to use React for the front-end
+| Typescript              | The language of the application will be typescript
+| Node.js                 | For the communication of the application we are going to use Node.js
 |===
 
 === Organizational constraints
@@ -20,9 +23,11 @@ The technologies that are going to be used to develop this project are:
 |===
 | *Constraint* | *Explanation*
 | Teamwork         | The project must be developed working as a team. 
+| Members          | The team must have a maximum of 4 members.
 | Time             | The application must be finished and delivered within a given timeframe.
 | Git              | The use of Git must be mandatory in order to keep a good workflow.
 | New Technologies | Most of the technologies employed in this proyect have never been used by any of us.
+| Meetings         | To develop the application we need to do frequent meetings
 |===
 
 === Conventions
@@ -33,4 +38,4 @@ The technologies that are going to be used to develop this project are:
 | Language   | The application, both the documentation and the code, will be entirely developed in english.
 | TypeScript | As we are using the TypeScript programming language, it's naming conventions must be followed.
 | Arc42      | The documentation will be written following the arc42 architecture.
-|===
+|===

docs/03_system_scope_and_context.adoc

@@ -2,7 +2,7 @@
 == System Scope and Context
 
 === Business Context
-
+:imagesdir: images/
 image:3.1BusinessContextdiagram.png["Business Context diagram"]
 
 Users:: Citizens creating custom maps about local places and businesses in the city.

docs/04_solution_strategy.adoc.bak

@@ -0,0 +1,56 @@
+[[section-solution-strategy]]
+== Solution Strategy
+
+Tecnologias
+
+Backend
+
+* NodeJS: es un entorno de tiempo de ejecuci�n de JavaScript que se utiliza para crear aplicaciones escalables del lado del servidor y de red a trav�s de servidores privados virtuales.
+
+Frontend
+
+* React: es una biblioteca JavaScript de c�digo abierto dise�ada para crear interfaces de usuario con el objetivo de facilitar el desarrollo de aplicaciones en una sola pagina.
+* TypeScript: es un lenguaje de programaci�n de c�digo abierto pensado para ejecutar grandes proyectos y que permite trabajar de manera estructurada.
+
+Base de datos
+
+* MongoDb: se utilizara para la creaci�n de la base de datos.
+
+Utilizaremos POD para los usuarios.
+
+Objetivos
+
+* Privacidad: Utilizaremos PODs para que cada usuario tenga mas seguridad y no sean tan vulnerables.
+
+Decisiones organizativas
+
+Issues
+
+Cada miembro del equipo crear� issues cada vez que vaya a realizar una tarea y asignar� que miembros van a realizarla.
+
+Comunicaci�n
+
+La comunicaci�n del equipo se realizar� a trav�s de discord y mediante Whatsapp. Tambi�n mediante las issues se realizara el reparto de tareas.
+
+
+
+[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.
+****

docs/05_building_block_view.adoc

@@ -5,7 +5,7 @@
 === Whitebox Overall System: Level 1
 
 :imagesdir: images/
-image::building_block_view_1.png[]
+image::doc05b.JPG[]
 
 Motivation::
 
@@ -45,13 +45,12 @@ Here's a list of each of the application's building blocks:
 
 View::
 
- * Home page
- * Register
  * Log in
- * Create map
- * Add place
- * Add opinion
- * Explore place
+ * Map
+ * Account
+ * Friends
+ * About
+ * Category
 
 Model::
 
@@ -62,8 +61,4 @@ Model::
 
 Controller::
 
- * MapController
- * PlaceController
- * OpinionController
- * UserController
- * AccessController
+ * LocationController

docs/06_runtime_view.adoc

@@ -12,18 +12,9 @@ entity Application as "Application"
 database Server as "Server"
 database Pod as "User POD"
 User -> Application: User enters credentials
-User -> Application: User attempts to log in
-Application -> Server: Log in petition sent
-Server -> Pod: Log in petition sent
-Pod -> Server: Log in result returned
-Server -> Application: Log in result returned
+Application -> Pod: Log in petition sent
+Pod -> Application: Log in result returned
 Application -> Application: Log in result evaluation
-Application -> Server: Personal info petition sent
-Server -> Pod: Personal info petition sent
-Pod -> Server: Personal info petition result returned
-Server -> Application: Personal info petition result returned
-Application -> User: Correct log in
-Application -> User: Personal info is shown
 ----  
 
 === Adding a location
@@ -36,12 +27,31 @@ actor User as "User"
 entity Application as "Application"
 database Server as "Server"
 database Pod as "User POD"
-User -> Application: Select a location
+User -> Application: Select a location 
+Application-> User: Show a point in that place
+User -> Application: Clic on add a review
+Application -> User: Show a form
+User -> Application: Complete the form
 Application -> Server: Add location petition sent
-Server -> Pod: Store location data
+Server -> Pod: Store location and review data
 Application -> User: Show info: "The location has been added succesfully"
 ---- 
 
+=== See a reviews of a place in the map
+[plantuml,"Create a review in the map diagram",png] 
+---- 
+actor User as "User"
+entity Application as "Application"
+database Server as "Server"
+database Pod as "User POD"
+User -> Application: Select a location 
+Application -> Server: Ask for the place
+Application -> Pod: search for the reviews of that place
+Server -> Application: Return the place
+Pod-> Application: Return the reviews of that place
+Application -> User: Show the place with the review
+----
+
 === Map filtering
 
 User's can visualize maps by filtering them by category, friends, etc.
@@ -58,4 +68,4 @@ Application -> Server: Get map information
 Server -> Application: Return map information
 Application -> Application: Filter map with parameters
 Application -> User: Filtered map is shown
----- 
+---- 

docs/07_deployment_view.adoc

@@ -1,8 +1,8 @@
 [[section-deployment-view]]
 
 == Deployment View
-
-image:7.1Deploydiagram.png["Deploy diagram"]
+:imagesdir: images/
+image:Doc07.JPG["Deploy diagram"]
 
 Motivation::
 
@@ -24,4 +24,14 @@ Deployment in the cloud has advantages over an on-premises solution (software de
 * Security. Cloud platforms have hundreds of engineers dedicated exclusively to security.
 
 Mapping of Building Blocks to Infrastructure::
-To do
+Deployment
+To deploy the project we have two options, deploy it locally or through a web hosting service.
+
+
+|===
+| Type of hosting        | Characteristics
+| Local | You can throw the app with a local server in  your own computer.
+| Web service    | Used to host the application on a remote server, Servicio que sirve para alojar la aplicación en un servidor remoto, there are a lot of services to host, being able to make the application accessible to other people. 
+
+|===
+We have to decide how to build the infraestructure with dockers.

docs/08_concepts.adoc

@@ -2,7 +2,7 @@
 == Cross-cutting Concepts
 
 === Domain model
-
+:imagesdir: images/
 image:08.1DomainModel.png["Domain model"]
 
 [options="header",cols="1,4"]
@@ -14,3 +14,18 @@ image:08.1DomainModel.png["Domain model"]
 | Place   | Represents the physical location on the map of an element of interest to the user: a monument, a restaurant, etc. The same place can appear on different maps associated with the same user or with different users.
 | Opinion | Information linked to a place generated and managed by the user: photos, comments, score, etc.
 |===
+
+=== User requirements
+The application is easy to use, it is not necessary to have previous knowledge, but as is logical, if the user is already familiar with the use of maps and social media is better. 
+The only requirement is that the user need a POD account to use the application, but its not too difficult
+
+
+=== Security
+The application is secure because we use the SOLID principles, that means that every user data will be stored in his POD, so the information will be saved externally.
+
+=== Operative Concepts
+The basic operations that we can do in this application are:
+* User authentication: Refers to identifying oneself in the application as a registered user through their POD.
+* Put a mark on the map: The user will be able to place a point on the map by clicking on it, and a form for that point will appear.
+* Saving a location with data in the POD: when filling out the form and clicking on submit, that information is saved in the user's POD.
+* Filter by categories: A function that allows the user to see specific types of locations more precisely.

docs/09_design_decisions.adoc

@@ -6,6 +6,13 @@ Regarding the design decisions made by the team, we have the following:
 
 * *Use of Node.js for the development, execution, and deployment of the back-end of the project*: We made this decision for similar reasons as the choice of React - it is a widely used technology with high support and is ideal for running JavaScript code quickly and easily.
 
-* *We start with the idea of using MongoDB to better adapt to what a web application requires, with a variety of data to manage*: For this, a non-relational database like MongoDB will help us have greater flexibility for storing data, since we will be storing a wide variety of data types.
+* *We are going to use MongoDB to better adapt to what a web application requires, with a variety of data to manage*: For this, a non-relational database like MongoDB will help us have greater flexibility for storing data, since we will be storing a wide variety of data types.
+
+* Use of typeScript for the language of the code, This language has great advantages in the short and long term.
+
+* For the deployment, it has not been decided how it will be done yet, as we have not discussed that yet.
+
+* To perform tests, we are going to use Puppeteer and Cucumber
+
+* We will use arc42 for documentation, which is a well-established standard.
 
-We have many more decisions to make regarding the implementation and functionality of the application, but these decisions will be made later, and we will update this section to reference all those decisions made throughout the development of the project.

docs/11_technical_risks.adoc

@@ -6,4 +6,6 @@ Regarding the risks and technical debt that may hinder the implementation of the
 * The *lack of knowledge of users about the technologies we will use to carry out the project* (React, Node.js, MongoDB or other non-relational databases), and the way to make them all work together correctly to provide the best possible user experience.
 * The complete *unfamiliarity with the operation of SOLID and how to integrate it* into an application that will have to handle decentralized data and provided by a third-party application.
 * Having *to work as a team*, especially because we do not know each other.
-* *Time*, since we have to finish the project at a given deadline.
+* *Time*, since we have to finish the project at a given deadline.
+* *MongoDB*, most of the team members are not familiar with MongoDB
+* When working in a group and merging code, it is possible that if two people work on the same part, some parts of the code may not be easily understood by other team members. Communication is needed so that everyone understands the parts.