Arquisoft · uo282492 · May 4, 2023 · May 3, 2023 · May 3, 2023 · May 3, 2023
diff --git a/.github/workflows/lomap_es4a.yml b/.github/workflows/lomap_es4a.yml
@@ -13,6 +13,9 @@ on:
       - master
       - develop
 
+env:
+  REACT_APP_GOOGLE_KEY: ${{ secrets.REACT_APP_GOOGLE_KEY }}
+
 jobs:
   unit-tests:
     runs-on: ubuntu-latest
@@ -34,8 +37,8 @@ jobs:
     needs: [unit-tests]
     runs-on: ubuntu-latest
     steps:
-    - uses: actions/checkout@v2
-    - uses: actions/setup-node@v2
+    - uses: actions/checkout@v3
+    - uses: actions/setup-node@v3
       with:
         node-version: 18
     - run: npm --prefix webapp install

diff --git a/README.md b/README.md
diff --git a/docs/01_introduction_and_goals.adoc b/docs/01_introduction_and_goals.adoc
@@ -3,7 +3,7 @@
 
 === Requirements Overview
 
-The LoMap system is a software solution that allows the citizens of a city to share places of interest as well as allow businesses to share their locations to potential clients. These places are part of a map, and the users can give feedback about them to other users.
+The LoMap system is a software solution that allows the citizens of a city to share places of interest with other users. These places are part of a map, and the users can give feedback about them to other users.
 
 The LoMap system must accomplish the following requirements:
 
@@ -24,7 +24,7 @@ The LoMap system must accomplish the following requirements:
 |Quality Goal|Description
 | Usability | Non technical users must be able to use the app easily. Aesthetics must be familiar and understandable to them.
 | Privacy | Users can control the data that is shared with the app thanks to SOLID principles and the use of pods.
-| Efficiency | There must be a medium point between privacy and efficiency (all the information may not be stored inside the pods due to decreases in performance.
+| Efficiency | There must be a medium point between privacy and efficiency (all the information may not be stored inside the pods due to decreases in performance).
 | Testability | The application should be able to go through different test and complete them successfully.
 |===
 

diff --git a/docs/02_architecture_constraints.adoc b/docs/02_architecture_constraints.adoc
@@ -5,8 +5,8 @@
 [options="header",cols="1,2"]
 |===
 |Constrains | Description
-| Arc42 | It will be the base template followed by the documentation.
-| Git & GitHub | A version control management has to be used so that the software can be versioned and all developers have access to the project. GitHub is a tool that has to be used so the professors can evaluate the project.
+| Arc42 | It will be the base template followed for the documentation.
+| Git & GitHub | A version control management system has to be used so that the software can be versioned and all developers have access to the project. GitHub is a tool that has to be used so the professors can evaluate the project.
 |===
 === Technology conventions
 [options="header",cols="1,2"]

diff --git a/docs/03_system_scope_and_context.adoc b/docs/03_system_scope_and_context.adoc
@@ -6,7 +6,7 @@
 :imagesdir: images/
 image::03_system_scope_context_business.png[business system scope and context diagram]
 
-The main components that the LoMap system interacts with are: Database, Maps API, POD.
+The main components that the LoMap system interacts with are: Maps API, POD.
 
 The final user has a POD and uses the LoMap system to save and share maps. The LoMap system can also access the user's POD to store information.
 
@@ -15,4 +15,4 @@ The final user has a POD and uses the LoMap system to save and share maps. The L
 :imagesdir: images/
 image::03_system_scope_context_technical.png[technical system scope and context diagram]
 
-The components of the application use certain technologies and communicate with eachother using different channels. The LoMap application will be programmed mostly using TypeScript and the React and Node JS Express frameworks. The Pod will be a SOLID POD. The connections that happen between LoMap and the user's device follow the http protocol and the connection between the user's device and the SOLID PODs follow the https protocol, so the information is secure. LoMap will use a Google Maps API, and the connections will use http.
+The components of the application use certain technologies and communicate with eachother using different channels. The LoMap application will be programmed mostly using TypeScript and the React framework. The Pod will be a SOLID POD. The connections that happen between LoMap and the user's device follow the https protocol and the connection between the user's device and the SOLID PODs follow the https protocol, so the information is secure. LoMap will use a Google Maps API, and the connections will use http.
diff --git a/docs/04_solution_strategy.adoc b/docs/04_solution_strategy.adoc
@@ -16,15 +16,15 @@ Some members of the team will use Github IDEs such as Github Destopk, Github Kra
 
 === How are the quality goals going to be reached?
 .Usability:
-Our interfaces will be intuitive and easy to use for anyone.
+Our interfaces will be intuitive and easy to use for anyone thanks to using the React framework.
 
 .Privacy:
 The essential information will be stored in SOLID PODs providing a strong privacy.
 
 .Eficiency:
-The performance will be smooth, by using the SOLID PODs correctly.
+The performance will be smooth, by using the SOLID PODs correctly and not using a REST API.
 
 .Testability:
-The team will test the app manually and automatically 
+The team will test the app manually and automatically with automated jest tests. 
 
 ***
diff --git a/docs/05_building_block_view.adoc b/docs/05_building_block_view.adoc
@@ -39,14 +39,14 @@ folder api as "Maps' API"
 folder pod as "User's pod"
 package LoMap {
     component frontend
-    component backend
+    component solidapi
 
-    frontend <-> backend
+    frontend <-> solidapi
 }
 
-backend -up-> api: API request
+frontend -up-> api: API request
 User -up-> frontend: interacts with
-backend<-right-> pod: obtains data
+solidapi<-right-> pod: obtains data
 ----
 
 Motivation::
@@ -58,24 +58,6 @@ Contained Building Blocks::
 |===
 | **Black boxes** | **Description**
 | Frontend | Application user's interface.
-| Backend | It is in charge of administrate the application logic.
+| Solidapi | It contains all the functionality related with pod's management.
 |===
 
-
-
-=== Level 3
-
-==== White Box <_building block x.1_>
-
-_<white box template>_
-
-
-==== White Box <_building block x.2_>
-
-_<white box template>_
-
-
-
-==== White Box <_building block y.1_>
-
-_<white box template>_
diff --git a/docs/07_deployment_view.adoc b/docs/07_deployment_view.adoc
@@ -4,15 +4,15 @@
 
 === Development Diagram
 
-While in development, the LoMap system will be run in the developer's computer. The system will be deployed in the developer's computer using Docker images which contain the necesary programs to run the application as a standalone application. Prometheus and Grafana will monitor and give information about the restapi. As it is shown in the diagram, the SOLID PODs, as well as the Maps API, are not part of the LoMap system.
-While the application is being developed, the MongoDB database will be allocated in the developer's computer. This will not be the case when the application is deployed.
+While in development, the LoMap system will be run in the developer's computer. The system will be deployed in the developer's computer using a Docker image which contains the necesary programs to run the application as a standalone application. As it is shown in the diagram, the SOLID PODs, as well as the Maps API, are not part of the LoMap system.
+While the application is being developed, there is a Docker image that runs the webapp. This will not be the case when the application is deployed.
 
 :imagesdir: images/
 image::07_deployment_view_development.png[deployment view diagram in development]
 
 === Deployment Diagram
 
-While in deployment run in a Server. The users will connect to this server to access the application for the most part in the user's device, whether it is a smartphone or a personal computer. The system will be deployed using Docker images. The webapp is the part of the system that the users will interact with. The restapi will be in charge of integrating all the other parts of the system and using external components such as SOLID PODs and a Maps API.
+While in deployment the application will run in GitHub pages on another repository. The users will connect to GitHub pages to access the application, for the most part through the user's device. The webapp is the part of the system that the users will interact with.
 
 :imagesdir: images/
 image::07_deployment_view_deployment.png[deployment view diagram in deployment]

diff --git a/docs/08_concepts.adoc b/docs/08_concepts.adoc
@@ -1,61 +1,16 @@
 [[section-concepts]]
 == Cross-cutting Concepts
 
-
-[role="arc42help"]
-****
-.Content
-This section describes overall, principal regulations and solution ideas that are
-relevant in multiple parts (= cross-cutting) of your system.
-Such concepts are often related to multiple building blocks.
-They can include many topics, such as
-
-* domain models
-* architecture patterns or design patterns
-* rules for using specific technology
-* principal, often technical decisions of overall decisions
-* implementation rules
-
-.Motivation
-Concepts form the basis for _conceptual integrity_ (consistency, homogeneity)
-of the architecture. Thus, they are an important contribution to achieve inner qualities of your system.
-
-Some of these concepts cannot be assigned to individual building blocks
-(e.g. security or safety). This is the place in the template that we provided for a
-cohesive specification of such concepts.
-
-.Form
-The form can be varied:
-
-* concept papers with any kind of structure
-* cross-cutting model excerpts or scenarios using notations of the architecture views
-* sample implementations, especially for technical concepts
-* reference to typical usage of standard frameworks (e.g. using Hibernate for object/relational mapping)
-
-.Structure
-A potential (but not mandatory) structure for this section could be:
-
-* Domain concepts
-* User Experience concepts (UX)
-* Safety and security concepts
-* Architecture and design patterns
-* "Under-the-hood"
-* development concepts
-* operational concepts
-
-Note: it might be difficult to assign individual concepts to one specific topic
-on this list.
-****
 === Domain Concept
 
 :imagesdir: images/
 image::08_concepts.png[Domain concept]
 
 User: This represents a client of the application. They can add other users as Friends, and they have a map to mark their favourite places too. We get their information through the POD.
 
-Map: This represents the users map of the app. Contains the markers made by the user.
+Map: This represents the users' map. It contains the markers made by the user.
 
-Mark: This class represents the Marker made by the user with his name, user score, a Location and a list of all times comments.
+Mark: This class represents the Marker that represents the location of a place.
 
 Comment: This represents a comment made in a marked location by a certain user with all his information including the posting time and rate of the user.
 

diff --git a/docs/09_design_decisions.adoc b/docs/09_design_decisions.adoc
@@ -1,35 +1,11 @@
 [[section-design-decisions]]
 == Design Decisions
 
-
-[role="arc42help"]
-****
-.Contents
-Important, expensive, large scale or risky architecture decisions including rationals.
-With "decisions" we mean selecting one alternative based on given criteria.
-
-Please use your judgement to decide whether an architectural decision should be documented
-here in this central section or whether you better document it locally
-(e.g. within the white box template of one building block).
-
-Avoid redundancy. Refer to section 4, where you already captured the most important decisions of your architecture.
-
-.Motivation
-Stakeholders of your system should be able to comprehend and retrace your decisions.
-
-.Form
-Various options:
-
-* List or table, ordered by importance and consequences or:
-* more detailed in form of separate sections per decision
-* ADR (architecture decision record) for every important decision
-****
-
 .Desing Decisions ordered by priority (from most to least important)
 [options="header",cols="1,2,2"]
 |===
 |Desing Decision|Advantages|Disadvantages
 | TypeScript | Versatile language to program web applications. | Neither of us has experience with its use.
 | React | Very used javascript library. Easy to learn and use. Reusable components. | We have never worked with a library like this.
-| Node.js | Allows javascript use in the backend. High-performance for Real-time Applications. Easy Scalability. Easy to learn. | We only know PHP as server-side language.
+| Not using REST API | Less latency. Easier to develop. Lighter application. | Higher coupling in the application. Lack of backend
 |===
diff --git a/docs/10_quality_scenarios.adoc b/docs/10_quality_scenarios.adoc
@@ -1,72 +1,35 @@
 [[section-quality-scenarios]]
 == Quality Requirements
 
-
-[role="arc42help"]
-****
-
-.Content
-This section contains all quality requirements as quality tree with scenarios. The most important ones have already been described in section 1.2. (quality goals)
-
-Here you can also capture quality requirements with lesser priority,
-which will not create high risks when they are not fully achieved.
-
-.Motivation
-Since quality requirements will have a lot of influence on architectural
-decisions you should know for every stakeholder what is really important to them,
-concrete and measurable.
-****
-
 === Quality Tree
+:imagesdir: images/
+image::QualityTree.png[]
+=== Quality Scenarios
 
-[role="arc42help"]
-****
-.Content
-The quality tree (as defined in ATAM – Architecture Tradeoff Analysis Method) with quality/evaluation scenarios as leafs.
-
-.Motivation
-The tree structure with priorities provides an overview for a sometimes large number of quality requirements.
+[options="header",cols="1,3,3"]
+|===
+|Quality requirement | Quality scenario | Priority
+| Usability | Our app has to be easy to use for every kind of user, even for a non-experienced one. The views must be clear and intuitive, and the user has to be able to browse fluently through the entire application. In addition, the required mechanisms to ease the users use of the app must be implemented. | High
+| Privacy | Giving the users the control of the information saved and shared, we guarantee that there won't be personal leaks. This is a result of the use of pods and a very cared system of terms and privacy options. | Medium-high
+| Efficiency | The conection and browsing speed must be fast enough to keep the users' attention and to not bore them, giving a fluent experience through the app. | Medium-high
+| Testability | The application should be able to go through different test and complete them successfully. Besides, the app has to be prepared for all kind of logical uses by the user | Medium-low
+|===
 
-.Form
-The quality tree is a high-level overview of the quality goals and requirements:
+Some of these quality attributes have been checked with the following load tests:
 
-* tree-like refinement of the term "quality". Use "quality" or "usefulness" as a root
-* a mind map with quality categories as main branches
+* 4 load peaks of 100 users, each 40 seconds:
 
-In any case the tree should include links to the scenarios of the following section.
-****
 :imagesdir: images/
-image::QualityTree.png[]
-=== Quality Scenarios
-
-[role="arc42help"]
-****
-.Contents
-Concretization of (sometimes vague or implicit) quality requirements using (quality) scenarios.
+image::loadTest_4_peaks.png[]
 
-These scenarios describe what should happen when a stimulus arrives at the system.
+* 1 user per second, through 3 minutes:
 
-For architects, two kinds of scenarios are important:
+image::loadTest_1_user_per_second.png[]
 
-* Usage scenarios (also called application scenarios or use case scenarios) describe the system’s runtime reaction to a certain stimulus. This also includes scenarios that describe the system’s efficiency or performance. Example: The system reacts to a user’s request within one second.
-* Change scenarios describe a modification of the system or of its immediate environment. Example: Additional functionality is implemented or requirements for a quality attribute change.
+* 3 series of 1, 5 and 10 users per second during 60 seconds, each other:
 
-.Motivation
-Scenarios make quality requirements concrete and allow to
-more easily measure or decide whether they are fulfilled.
+image::loadTest_3_series.png[]
 
-Especially when you want to assess your architecture using methods like
-ATAM you need to describe your quality goals (from section 1.2)
-more precisely down to a level of scenarios that can be discussed and evaluated.
+* normal app use (20 users for 30 seconds):
 
-.Form
-Tabular or free form text.
-****
-[options="header",cols="1,3,3"]
-|===
-|Quality requirement | Quality scenario | Priority
-| Usability | Our app have to be easy to use for every kind of user, even for a non-experienced one. The views must be clear and intuitive, and the user has to be able to browse fluently through the entire application. In addition, must be implemented the recquired mechanisms to ease the users use of the app. | High
-| Privacy | Giving the users the control of the information saved and shared, we guarantee that there wouldn't be personal leaks. This is a result of the use of pods and a very cared system of terms and privacy options. | Medium-high
-| Efficiency | The conection and browsing speed must be faster enaugh to keep users attention and don't bore them, giving a fluent experience through the app. We are looking a balance with the privacy in terms of storeage of the personal user's information | Medium-high
-| Testability | The application should be able to go through different test and complete them successfully. Besides, the app has to be prepared for all kind of logical uses by the user | Medium-low
-|===
+image::loadTest_normal_app_use.png[]
diff --git a/docs/11_technical_risks.adoc b/docs/11_technical_risks.adoc
@@ -1,20 +1,6 @@
 [[section-technical-risks]]
 == Risks and Technical Debts
 
-[role="arc42help"]
-****
-.Contents
-A list of identified technical risks or technical debts, ordered by priority
-
-.Motivation
-“Risk management is project management for grown-ups” (Tim Lister, Atlantic Systems Guild.) 
-
-This should be your motto for systematic detection and evaluation of risks and technical debts in the architecture, which will be needed by management stakeholders (e.g. project managers, product owners) as part of the overall risk analysis and measurement planning.
-
-.Form
-List of risks and/or technical debts, probably including suggested measures to minimize, mitigate or avoid risks or reduce technical debts.
-****
-
 === Risks
 
 ==== Organizational Risks
@@ -26,4 +12,9 @@ List of risks and/or technical debts, probably including suggested measures to m
 ==== Technological Risks
 
 * If the team does not properly understand the technologies used, the system may not satisfy the quality goals.
-* If the data stored centrally contains too much information, the user privacy will not be respected. On the other hand, if all the data is stored in user PODs, the system will be too slow, so a certain balance must be found.
+
+==== Technical Debt
+
+* There is no REST API, which means there is no backend. This is something that may hinder future development. Not having a REST API also means that the application will not be able to be used through requests to the REST API.
+* There is no database, this means that there is no possibility to store useful information centrally. This might be useful for future growth of the application.
+* The code could be better organized, currently a change may require to update various files. In the future the application may need to be refactored to lower its coupling.