diff --git a/docs/01_introduction_and_goals.adoc b/docs/01_introduction_and_goals.adoc index f60659e..5ec7499 100644 --- a/docs/01_introduction_and_goals.adoc +++ b/docs/01_introduction_and_goals.adoc @@ -37,7 +37,8 @@ Users can: Diego Villanueva Berros | Develop a software we can be proud of while learning new technologies as SOLID +| HappySw | HappySw | An application that fulfils the contract agreed with the Council of Brussels | Teachers | Teachers | Make sure the students follow the guidelines and progress correctly -| Council of Brussels | Council of Brussels | Have an application developed that satisfies the contract +| Council of Brussels | Council of Brussels | Have an application developed that meets their needs | Users | Whoever uses the application | A functional and easy to use application |=== diff --git a/docs/02_architecture_constraints.adoc b/docs/02_architecture_constraints.adoc index 1c2b717..ae19178 100644 --- a/docs/02_architecture_constraints.adoc +++ b/docs/02_architecture_constraints.adoc @@ -9,7 +9,6 @@ These constraints are the base of the architecture process, and are the roots of |=== |Constraint|Description | Solid | _Provided by the stakeholders. A way of building decentralized social apps, it gives every user a choice about where data is stored, helping the privacy of each user._ -| Facilitate user navigavility | _The app is developed using react, a javascript library used to make the interaction of the user easier, as it helps in the building of the user interface of the web app._ -| Flexibility | _The map which is the base of the app is generated using the Google Maps API, for the possibility of working in any place around the world._ -| Quality | _The application is developed around some quality requirements, later described in section 10._ +| Github | _The development team was given a starting draft of a project in GitHub as a public repository. From then on, all the work related with this project will be tracked and uploaded in this repository._ +| Time | _The application is developed in a semester during a course, that means time is limited._ |=== \ No newline at end of file diff --git a/docs/03_system_scope_and_context.adoc b/docs/03_system_scope_and_context.adoc index c134f27..605bcf0 100644 --- a/docs/03_system_scope_and_context.adoc +++ b/docs/03_system_scope_and_context.adoc @@ -3,46 +3,25 @@ Lomap is a web application whose objective is to have markers and routes saved in a map where the user has total control of their data. They can also add and share this information with other "friends" sharing the platform. In order to achieve the control of their data SOLID technologies are used all along the project. A user will be able to post an dplace markers, they will also have the capability of viewing the ones of their online "friends". -=== Business context There is clearly 5 different actors regarding business context, however one is the SOLID pod of both admin and user actor. Which is "integrated" in them making it be a "subsystem". As a result we obtain the following use case scenario. -image::https://github.com/Arquisoft/lomap_en2b/blob/9e56d610c9f52f65fc04b36dca862d33b27296e1/docs/images/UseCaseASW.drawio.png[] +image::BusinessContext.png[Business Context Diagram] From that we can say that the main actors have this speciofications: [cols = "1,2"] |=== -|*User name* -|*Description and functionality* - -|*Guest* -|It is the type of user that haven't been identified so only the view for logging in will be displayed. - |*User* -|This type of user is the "average" user as it has an account and it is allowed to create routes or markers, following people and viewing different maps. - -|*Admin* -|It is a super user which can make changes on other users, this is done with the objective of moderating the behaviour to avoid unwanted problems. - -|*Central System* -|This will be a database in charge of containing the minimal data to make the web application to work and for it not to be heavily slowed down by the decentralized approach. -|=== +|This type of user is the "average" user as it has an account and it is allowed to create routes or markers, following people and viewing different maps. They connect to the webapp using the pod provider -=== Technical Context -The webapp follows the SOLID decentralized architecture. It is important to have a system to connect the pods with eachother using a central system. This is done using the API which is also the responsible for the usage of the website. +|*Pod Provider* +|A pod provider using SOLID architecture where all the sensitive data of the users will be stored. -image::https://github.com/Arquisoft/lomap_en2b/blob/c9dc0d1415008f61e8da3a6a08a3bdc78109940e/docs/images/Captura%20de%20pantalla%202023-02-20%20164603.jpg[] +|*lomap* +|The web service itself. Here the user is able to access and modify their maps same as looking the other's. -[cols = "1,2"] -|=== -|*Inrupt* -|Inrupt is a provider of pods, It could happen that it was another provider of SOLID architecture. What's important is that the user has a pod able to connect to the API. - -|*API* -|This API is in charge on making all the connections and logic so everything works as it should. This is done with TypeScript. - -|*Database* -|For the moment the technology decided for the main database hasn't been decided, so this will be updated later. +|*database* +|This will be a database in charge of containing the minimal data to make the web application to work and for it not to be heavily slowed down by the decentralized approach. -|*Website* -|The frontend of the website to show the information is using the React framework for typescript. +|*leaflet* +|Leaflet API is an api using openmaps which is simple and easy to develop in it to create personalizzed maps. |=== diff --git a/docs/04_solution_strategy.adoc b/docs/04_solution_strategy.adoc index 58ebcd5..9fbeeae 100644 --- a/docs/04_solution_strategy.adoc +++ b/docs/04_solution_strategy.adoc @@ -5,21 +5,21 @@ In this section we are explaining the main decisions we took in the development of the project. Up until now, we have made some decisions about the project, those decisions can be organized in different categories: -.*Technology decisions* -*React: JS framework that helps with the user interface of the web application. -*Map API: Used to plot the map in the application in order to allow the user to do every possible action. +. *Technology decisions:* +* React: JS framework that helps with the user interface of the web application. +* Map API: Used to plot the map in the application in order to allow the user to do every possible action. -.*Decisions on top-level decomposition* -*MVC: We are using the MVC (Model-View-Controller) pattern in order to organize the code in a clean and obvious way. -*Editor: We are all using Visual Studio Code to work on this project, it is the editor we are used to program in and it has some features that made us work using it. -*Github: The project is on a public repository as given by the professors of the subject. We are all able to work using it, and the main features of it are the pull requests in order to upload code. +. *Decisions on top-level decomposition:* +* MVC: We are using the MVC (Model-View-Controller) pattern in order to organize the code in a clean and obvious way. +* Editor: We are all using Visual Studio Code to work on this project, it is the editor we are used to program in and it has some features that made us work using it. +* Github: The project is on a public repository as given by the professors of the subject. We are all able to work using it, and the main features of it are the pull requests in order to upload code. -.*Decisions on quality goals* -*Usability: Our map application is quite easy to use for everyone, we are focusing on the ease of the user interaction and comprehension. -*Security: It is the main point of our application, as we are using solid, we are maintaining the privacy of every user who logs into LoMap. -*Response times: As much as possible, we are trying to minimize response times of the application in order to be more user friendly. +. *Decisions on quality goals:* +* Usability: Our map application is quite easy to use for everyone, we are focusing on the ease of the user interaction and comprehension. +* Security: It is the main point of our application, as we are using solid, we are maintaining the privacy of every user who logs into LoMap. +* Response times: As much as possible, we are trying to minimize response times of the application in order to be more user friendly. -*Organizational decisions* +*Organizational decisions:* During the development of this project, everyone is the group is in constant contact with the rest of the members of the team, mainly in the weekly meeting which takes part during lab classes throughout the semester. In addition to that, we used a whatsapp group in order to consult with each other little things that could emerge during the week. Related with the project, our main way of working with the code was through pull requests. Each one of the members did some work, in his newly created branch and when he ended his work, he committed the changes and requested a pull request in GitHub, where another person in the group should revise the changes and aprove that pull request in order to merge the changes to the main branch. In order to do advances in the development we are using the issues in Github as well, in that way we make sure that we do everything we consider necessary. diff --git a/docs/05_building_block_view.adoc b/docs/05_building_block_view.adoc index 985e0d9..f4e22b1 100644 --- a/docs/05_building_block_view.adoc +++ b/docs/05_building_block_view.adoc @@ -9,7 +9,7 @@ Motivation:: This diagram is motivated by the need of having a clear separation of the composition of the application. -[plantuml,"Deployment diagram",png] +[plantuml,"BuildingBlockView", png] ---- @startuml @@ -109,7 +109,7 @@ No issues, problems or risks are known. Currently, the only layer we have somewhat structured is the persistance layer. -[plantuml,"Deployment diagram",png] +[plantuml,png, id = "PersistenceLayer"] ---- @startuml diff --git a/docs/06_runtime_view.adoc b/docs/06_runtime_view.adoc index bd27207..a33c743 100644 --- a/docs/06_runtime_view.adoc +++ b/docs/06_runtime_view.adoc @@ -7,7 +7,7 @@ These situations where chosen as they show the impact of our architectural decis === Accessing the application This diagram shows the communication between the user, the app and the pod when the user logs in. -[plantuml,"Sequence diagram",png] +[plantuml,"SequenceDiagramLogging",png] ---- @startuml header Runtime View @@ -28,7 +28,7 @@ LoMap --> Diego: Main page logged in === Adding landmark to the map This diagram show the communication between the user, the app and the pod when the user adds a landmark. -[plantuml,"Sequence diagram",png] +[plantuml,"SequenceDiagramAddLandmark",png] ---- @startuml header Runtime View @@ -46,7 +46,7 @@ LoMap -> Pod: Store the coordinates === Seeing friends' added landmarks This diagram show the communication between the user, the app and the pods when the user wants to see their friends' landmarks. -[plantuml,"Sequence diagram",png] +[plantuml,"SequenceDiagramFriendsLandmark",png] ---- @startuml header Runtime View diff --git a/docs/07_deployment_view.adoc b/docs/07_deployment_view.adoc index e76e0a1..8cda4db 100644 --- a/docs/07_deployment_view.adoc +++ b/docs/07_deployment_view.adoc @@ -7,10 +7,9 @@ Given that we currently do not know much about hosting the application, at this moment we will follow a simple approach that will likely change in the future. -[plantuml,"Deployment diagram",png] +[plantuml,"Deployment diagram",png, id = "DeployDiagramView"] ---- @startuml - header Deployment view title Deployment view @@ -23,17 +22,12 @@ agent Pod2 agent Pod3 agent PodN -Pod1 ---> "LoMap Platform" -Pod1 <--- "LoMap Platform" -Pod2 ---> "LoMap Platform" -Pod2 <--- "LoMap Platform" -Pod3 ---> "LoMap Platform" -Pod3 <--- "LoMap Platform" -PodN ---> "LoMap Platform" -PodN <--- "LoMap Platform" - -"Database server" -> "LoMap Platform" -"Database server" <- "LoMap Platform" +Pod1 <--> "LoMap Platform" +"LoMap Platform" <--> Pod2 +PodN <--> "LoMap Platform" +"LoMap Platform" <-> "Pod3" + +"Database server" <-> "LoMap Platform" @enduml ---- diff --git a/docs/09_design_decisions.adoc b/docs/09_design_decisions.adoc index 514b477..5ef23a4 100644 --- a/docs/09_design_decisions.adoc +++ b/docs/09_design_decisions.adoc @@ -4,6 +4,7 @@ [options="header",cols="1,4"] |=== |Decision|Why? -| Inrupt | As a constraint in the project, we said we needed to use solid pods, and inrupt is the way we are going to include it in our project. Essentially it provides a way to deal with Solid pods. +| React | Taken as a recomendation by some teachers. In addition, one of the members of the group has already worked with it in the past. It allows us to build a good user interface for the application. | Leaflet | It is the provider we are going to use for obtaining the necessary features around the map. We studied some other different options, such as Mapbox o Google Maps API, but we needed the Api to be completely free. +| Inrupt | As a constraint in the project, we said we needed to use solid pods, and inrupt is the way we are going to include it in our project. Essentially it provides a way to deal with Solid pods. |=== \ No newline at end of file diff --git a/docs/11_technical_risks.adoc b/docs/11_technical_risks.adoc index 94b44f5..c119b3f 100644 --- a/docs/11_technical_risks.adoc +++ b/docs/11_technical_risks.adoc @@ -1,10 +1,6 @@ [[section-technical-risks]] == Risks and Technical Debts - -[role="arc42help"] - - As it stands now, we have identified some important risks before starting coding the project. |=== diff --git a/docs/images/BusinessContext.png b/docs/images/BusinessContext.png new file mode 100644 index 0000000..94d6236 Binary files /dev/null and b/docs/images/BusinessContext.png differ