LOMAP ES1B1

Note	This version of the template contains some help and explanations. It is used for familiarization with arc42 and the understanding of the concepts. For documentation of your own system you use better the plain version.

1. Introduction and Goals

The software development company HappySw has been hired by the Council of Brussels to develop a software system called LoMap. This system will allow citizens to have personalized maps of places and local businesses in their city. The places that can be mapped include shops, bars, restaurants, sights, and cultural attractions, among others. Users will have full control over their personalized maps and the shared information will be stored in a personal pod according to the SOLID project.

HappySw’s goal is to develop a generic software solution that can be deployed and used in other cities. The initial focus of the project is on the user, allowing them to create their own personal map of the places they live. The next step could be to allow places such as shops, restaurants, etc. to create their own digital spaces.

The software development project aims to create a system that meets the underlying business goals, essential features, and functional requirements. The architecture of the system must also meet specific quality goals, which are of utmost importance to the major stakeholders (especially the Happy Software project management). The relevant stakeholders and their expectations must also be considered during the development process.

As the software architects and developers of the LoMap aplication we must take into account the following issues:

Business Goals: On request of Brussels' Council, LoMap has to provide citizens with personalized maps about local places and business. Regarding to the enterprise’s expectations, the software solution should aim to be general enough to be adapted to other future projects.
Essential Features and Functional Requirements
Quality Goals for the Architecture
Relevant Stakeholders and Expectations: The stakeholders in the LoMap project include the Council of Brussels, HappySw, and the citizens of the city who will be using the software system. The Council of Brussels expects a software solution that will provide citizens with personalized maps about places and local businesses in their city. HappySw is expected to develop a generic software solution that can be deployed and used in other cities in the future. The citizens are expected to have an easy-to-use and responsive software solution that respects their privacy and allows them to create personalized maps about places and local businesses.

1.1. Requirements Overview

We expect the future users of the application to use it as a simpler and more friendly version of other mapps such as Google mapps, for example. Additionally, it will offer solid references of what can be expected from the city (as a general overview) and the sites that the users may introduce, post, comment, advise, etc…

The LoMap system must allow users to add locations in different categories such as shops, bars, restaurants, sights, monuments, etc.
It should also enable users to show the locations on a map window and add review scores, comments, pictures, etc. about the added places.
The system must allow users to manage the information accessible by other users.
The LoMap system must prioritize the aesthetics and usability by non-technical people.
Quality of technical documentation
Code quality and tests code coverage.
The system should also have a continuous integration and continuous delivery strategy and must be interoperable between the data stored by different applications.

1.2. Quality Architecture Goals

The information about a place should be stored in each user’s personal pod.
Security and respect for user privacy.
Responsiveness of the application.
Adaptability of the application.
Originality of the solution.

1.3. Stakeholders

Table 1. Stakeholders
Role/Name	Contact	Expectations
Brussels Council	Fatima Abid	Keep the power in the next elections
Happy Software	Jose Emilio Labra Gayo	Earning a lot of money and getting a polivalent software solution
Developement Team	Gihub repository	Winning the SOLID tournament

Brussels Council: The final solution is bound to be evaluated in terms of the popular satisfaction with the product.
Happy Software: It is neccessary that the solution keep the bosses satisfyed in every aspect of the project. Documentation will be a determinant factor as long as other techincal oriented people will certainly evaluate the work performed. It is particularly important that the architecture satisfyes their requirements.
Developement team: Must discuss and come up with ideas and solutions related to the architecture, design, system… Of course deep knowledge about the entire software is mandatory.

2. Architecture Constraints

2.1. 1. Technical constraints

Constraint	Explanation
SOLID	In order to protect the privacy of our customers, it is necessary to follow the SOLID principles.
Github	Git is used for managing version control and the repository is hosted on Github. Additionally, Github provides tools for communication and project organization.
Continuous Integration System	We will employ Docker to deploy the application and have a virtual machine allocated in Azure for this purpose.

Constraint

Explanation

SOLID

In order to protect the privacy of our customers, it is necessary to follow the SOLID principles.

Github

Git is used for managing version control and the repository is hosted on Github. Additionally, Github provides tools for communication and project organization.

Continuous Integration System

We will employ Docker to deploy the application and have a virtual machine allocated in Azure for this purpose.

2.2. 2. Organisational constraints

Constraint	Explanation
Testing	Various scenarios will be considered to verify the correct behavior of the application. Multiple techniques will be employed to test the application and achieve the highest possible level of coverage.
Meetings	As only one of us can come to the lab, the meetings will be telematic. Information on these meetings can be found here.
Team size	The team consists of only two people. If one of us were to leave, the other would be in a very difficult situation.
Due dates	We have to meet the deadlines for handing in the project. These coincide with the deadlines for the evaluation of the subject.

Constraint

Explanation

Testing

Various scenarios will be considered to verify the correct behavior of the application. Multiple techniques will be employed to test the application and achieve the highest possible level of coverage.

Meetings

As only one of us can come to the lab, the meetings will be telematic. Information on these meetings can be found here.

Team size

The team consists of only two people. If one of us were to leave, the other would be in a very difficult situation.

Due dates

We have to meet the deadlines for handing in the project. These coincide with the deadlines for the evaluation of the subject.

2.3. 3. Conventions

Constraint	Explanation
SOLID	The application must follow the SOLID specification.
Language	The application should be designed so that any English-speaking person can interact with it and perform any task successfully.
Clean code	The code that makes up the application must be written in a clean and efficient way to facilitate understanding and maintainability.
Accessibility	The application should be designed for ease of navigation, ensuring that users with any disability can use it without difficulty.
Documentation	The documentation should be written according to the Arc42 method, which emphasizes clarity, simplicity, and effectiveness.
Programming language conventions	It is important to respect the coding conventions of the programming languages we use.

Constraint

Explanation

SOLID

The application must follow the SOLID specification.

Language

The application should be designed so that any English-speaking person can interact with it and perform any task successfully.

Clean code

The code that makes up the application must be written in a clean and efficient way to facilitate understanding and maintainability.

Accessibility

The application should be designed for ease of navigation, ensuring that users with any disability can use it without difficulty.

Documentation

The documentation should be written according to the Arc42 method, which emphasizes clarity, simplicity, and effectiveness.

Programming language conventions

It is important to respect the coding conventions of the programming languages we use.

3. System Scope and Context

3.1. Business Context

Entity	Input	Output
User	The user interacts with the application through a device, experiencing the frontend and sending requests to the backend.	The user will create his pod, in which his information will be stored and will operate the application to create locations.
User POD	Receives requests to modify or obtain personal information and locations created by the user.	Stores and/or returns the information requested by the user.
MongoDB	The database receives requests to create or obtain locations not stored in the POD for performance reasons.	Stores and/or returns the information requested by the user.
LoMap System	The user interacts with this system by sending requests through the interface.	It processes incoming requests, manages the database to ensure consistency, and then displays the requested information to the user via the interface.

Entity

Input

Output

User

The user interacts with the application through a device, experiencing the frontend and sending requests to the backend.

The user will create his pod, in which his information will be stored and will operate the application to create locations.

User POD

Receives requests to modify or obtain personal information and locations created by the user.

Stores and/or returns the information requested by the user.

MongoDB

The database receives requests to create or obtain locations not stored in the POD for performance reasons.

Stores and/or returns the information requested by the user.

LoMap System

The user interacts with this system by sending requests through the interface.

It processes incoming requests, manages the database to ensure consistency, and then displays the requested information to the user via the interface.

3.2. Technical Context

According to the SOLID project, shared information will be stored in each user’s POD. In addition, we will implement the application using TypeScript together with React for Front-end development. Finally; we will make use of MongoDB, a NoSQL database system; and an endpoint using NodeJS with Express.

Technical interface	Description
React	JavaScript library used for Front-end development.
NodeJS	Server environment used for the endpoint.
MongoDB	The database.
TypeScript	The programming language used for development.
SOLID PODs	The data management unit utilized for storing private and sensitive information adheres to the principles of the SOLID architecture.
SOLID specification	The project’s data management structure is defined by an architecture that decentralizes data and securely stores it on PODs.

Technical interface

Description

React

JavaScript library used for Front-end development.

NodeJS

Server environment used for the endpoint.

MongoDB

The database.

TypeScript

The programming language used for development.

SOLID PODs

The data management unit utilized for storing private and sensitive information adheres to the principles of the SOLID architecture.

SOLID specification

The project’s data management structure is defined by an architecture that decentralizes data and securely stores it on PODs.

4. Solution Strategy

4.1. Technology decisions

We are using the following technologies for the development of the application:

Solid. Specification that lets people store their data securely in decentralized data stores called Pods. This was a constraint.
React. A open-source JavaScript library for building user interfaces. We use it since it is easy to lern, its high performance and the high demand of this technology.
MongoDB. A document oriented NoSQL database, popular for agile development. It has advanced queries compared to other NoSQL databases and the developer team has some previous experience with it.
MongoDB Atlas. A fully-managed cloud database that handles all the complexity of deploying and managing deployments on the cloud. The starter plan is free and it is possible to scale horizontally and vertically the database as needed.

4.2. Decisions about the top-level decomposition of the system

We are starting this project from the public template Arquisoft/lomap_0

4.3. Decisions on how to achieve key quality goals

Quality goal

Approach

Security and Privacy

SOLID pods will be used to store the user data securely in a decentralized way.

Responsiveness

React will be used for achieving a responsiveness web application. A database will be used with non-personal data to improve performance.

Maintanability

The code will be clean, avoiding bad smells.

4.4. Relevant organizational decisions

Documentation written in English.
Kanban borad in GitHub.

5. Building block view

5.1. Level 1

Motivation: LoMap is a software system where the citizens can have personalized maps about places and local businesses in their city. The user’s PODs securely hold all of their data.
Contained Building Blocks

Name	Description
User	Who uses the application.
LoMap system	Information from the Pods will be extracted through it.
Pod service	Responsible for accessing each user’s personal POD.

Name

Description

User

Who uses the application.

LoMap system

Information from the Pods will be extracted through it.

Pod service

Responsible for accessing each user’s personal POD.

5.2. Level 2

Motivation: It shows the broad outline of the internal structure of the application: by interacting with the user interface, the client will be able to communicate with the data access layer.
Contained Building Blocks

Name	Description
User Interface	Through it, the user will be able to perform any task in the system.
Data access layer	Layer providing simplified access to data stored in persistent storage.
MongoDB	Responsible for storing information that is not to be stored in the PODs.

Name

Description

User Interface

Through it, the user will be able to perform any task in the system.

Data access layer

Layer providing simplified access to data stored in persistent storage.

MongoDB

Responsible for storing information that is not to be stored in the PODs.

5.3. Level 3

Motivation: Detailed system operation. Concentrated on the building blocks of both User Interface and Data Access.
Contained Building Blocks

Name	Description
Views	Parts of the application where the user will interact with the system.
Sign up	Allows the user to create an account. This process happens only once per user.
Sign in	Allows the user to log in with their account, if they have already created one.
Log out	Allows the user to log out.
Home	Initial tab of the application. Displays a welcome message.
Map	Tab that displays a map and allows to manage the user’s locations.
My ubications	Tab showing a short description of the locations created by the user.
My friends	Tab for managing the user’s friends.

Name

Description

Views

Parts of the application where the user will interact with the system.

Sign up

Allows the user to create an account. This process happens only once per user.

Sign in

Allows the user to log in with their account, if they have already created one.

Log out

Allows the user to log out.

Home

Initial tab of the application. Displays a welcome message.

Map

Tab that displays a map and allows to manage the user’s locations.

My ubications

Tab showing a short description of the locations created by the user.

My friends

Tab for managing the user’s friends.

6. Runtime View

6.1. Unidentified user

Data flow with an unidentified user

6.2. Login

Unidentified user that logs in.

6.3. Changes in a location

When an identified user performs a change to a location (deletion, review submit…)

7. Deployment View

7.1. Infrastructure Level 1

Infrastructure Level 1

7.1.1. Motivation:

During the development and testing phases, each student will run the runtime environment on their own machine. However, once the system is ready for production, it will be deployed on Azure in a Dockerised environment. It is important that we understand Docker as the infrastructure on which our system will be deployed.

7.1.2. Quality and/or performance features:

The performance of the deployment build relies on both the user’s internet connection and the Azure servers used for the app’s deployment, which are beyond our control. However, we can optimize the application’s performance by using certain coding techniques. Our primary concerns in achieving the best and most secure user experience will be privacy and security.

7.1.3. Mapping of building blocks to infrastructure:

Element	Description
WebApp	The front-end of our application. It will be displayed on the user’s device through the execution of a web browser.
REST API	Part of our application’s back-end. It will be hosted on the Azure server.
MongoDB	The chosen database, in which all information that is not stored in the pods for privacy and/or performance reasons will be stored.
Pod provider	Supplier of the pods to be used.
Google Maps API	API used to display a map and user-created locations.

Element

Description

WebApp

The front-end of our application. It will be displayed on the user’s device through the execution of a web browser.

REST API

Part of our application’s back-end. It will be hosted on the Azure server.

MongoDB

The chosen database, in which all information that is not stored in the pods for privacy and/or performance reasons will be stored.

Pod provider

Supplier of the pods to be used.

Google Maps API

API used to display a map and user-created locations.

8. Cross-cutting Concepts

8.1. Domain

Location: The application revolves around the concept of locations, which can be shops, restaurants, sights, museums, etc. Users can add personalized locations to their map. Users can also create reviews for locations created by other users. These reviews may include scores, comments or pictures.
- Public location: A location that will be visible for every user in the application. Logged-in users will be able to create reviews for those locations. Stored in the application DB.
- Shared location: A location that will be visible and reviewable by the solid friends of the user that created it. Stored in the user pod.
- Private location: A location that will be visible only to the creator. Stored in the user pod.
Personalized maps: The application allows users to have their own personalized map, with the locations they create. They can also see the map with the public locations and a map with their friend’s locations.

8.2. Domain model

8.3. User Experience

Map filters: The ability for users to filter the map by category, friends, and other criteria, which helps them find the places they are interested in more easily.

8.4. Safety and security

Privacy: The application must ensure the privacy of its users. The information about a place stored by each user should not be centralized and should be stored in each user’s pod. No data from the user is stored in the database. Only public locations are stored in the DB. Security is a quality goal for the architecture, and the system must respect the privacy of the users.
Access control: The system must have appropriate access controls in place to ensure that only authorized users can access and modify personal and shared data.
Secure data storage: The system must ensure that data stored in user pods and other centralized data stores is secure and protected from unauthorized access.

8.5. Interoperability

The solution must be designed in a way that allows for interoperabilitybetween the data stored by different applications. We have followed theproposed specification with a few changes (two extra fields for thelocations) for implementing the different visibility options that ourapplications offers.

9. Design Decisions

9.1. Accepted decisions

Architecture decision	Pros	Cons	Architecture decision record
React.js	This library is flexible, has Facebook’s and Community support, great performance and is easy to test. Intended to make Front-end development simpler.	None of us has used this library before.	ADR #1
TypeScript	While JavaScript is dynamically-typed, TypeScript is a statically-typed superset of JavaScript, which means it offers strict static typing as an option but will allow dynamic typing, as well.	None of us has used this language before.	ADR #2
MongoDB	A TypeScript-compatible NoSQL database that is simple to utilize and incorporate.	MongoDB uses multi-document ACID transactions. This is one of the major limitations with MongoDB as it may lead to corruption of data.	ADR #3
Node.js	We will use it in SDI. Active and vibrant community, with lots of code shared via GitHub, etc.	None of us has worked with this environment before.	ADR #4
Express.js	Minimal and flexible Node.js web application framework used for designing and building our web application quickly and easily.	None of us has worked with this environment before.	ADR #5

Architecture decision

Pros

Cons

Architecture decision record

React.js

This library is flexible, has Facebook’s and Community support, great performance and is easy to test. Intended to make Front-end development simpler.

None of us has used this library before.

ADR #1

TypeScript

While JavaScript is dynamically-typed, TypeScript is a statically-typed superset of JavaScript, which means it offers strict static typing as an option but will allow dynamic typing, as well.

None of us has used this language before.

ADR #2

MongoDB

A TypeScript-compatible NoSQL database that is simple to utilize and incorporate.

MongoDB uses multi-document ACID transactions. This is one of the major limitations with MongoDB as it may lead to corruption of data.

ADR #3

Node.js

We will use it in SDI. Active and vibrant community, with lots of code shared via GitHub, etc.

None of us has worked with this environment before.

ADR #4

Express.js

Minimal and flexible Node.js web application framework used for designing and building our web application quickly and easily.

None of us has worked with this environment before.

ADR #5

9.2. Deprecated decisions

None to date.

10. Quality requirements

10.1. Quality tree

Quality tree

10.2. Quality scenarios

Quality goal	Motivation	Usage scenarios	Change scenarios	Priority
Privacy	The application shall store only the necessary information in a decentralised manner.	Only information relating to locations shall be stored. The information provided in the registration form and during the checkout process is not stored, but rather obtained from the POD.	We have implemented a fully integrated login system with pod providers to avoid taking unnecessary information.	High
Usability	The user will not be able to create locations if the interface is not sufficiently clear and intuitive.	Anyone without prior knowledge of the application will be able to complete any task in a reasonable amount of time.	We have simplified the interface to avoid unintuitive processes and/or sections.	High
Security	Users will not trust our application if we do not store their data in a secure place.	The data must not be accessible to any third party.	As the privacy requirement is closely associated with security, we have made numerous adjustments to the application to ensure maximum protection.	High
Reliability	Errors in the application must be handled by the application itself, without crashing under any circumstances.	The user shall have no knowledge of such errors, except for those that must necessarily be communicated to the user.	A considerable amount of effort will be dedicated to error prevention, as it is closely tied to maintainability. When implementing a feature, there is much more involved than simply making it functional.	High
Maintainability	Our application will undergo many changes, so we need to develop it in a way that makes it easy to maintain in the future.	We aim to make as few errors per line of code as possible.	Investing greater effort in implementing a new feature can lead to significant rewards when modifications are made later on.	Medium
Freedom	We are developing the application on a greenfield basis. We intend to save unnecessary effort for those working on it in the future by including the code with plenty of documentation in a public repository.	The project must be available in its entirety in a public repository accessible by anyone at any time.	A repository that is accessible to the public and contains a record of every discussion, issue, or decision made.	Medium

Quality goal

Motivation

Usage scenarios

Change scenarios

Priority

Privacy

The application shall store only the necessary information in a decentralised manner.

Only information relating to locations shall be stored. The information provided in the registration form and during the checkout process is not stored, but rather obtained from the POD.

We have implemented a fully integrated login system with pod providers to avoid taking unnecessary information.

High

Usability

The user will not be able to create locations if the interface is not sufficiently clear and intuitive.

Anyone without prior knowledge of the application will be able to complete any task in a reasonable amount of time.

We have simplified the interface to avoid unintuitive processes and/or sections.

High

Security

Users will not trust our application if we do not store their data in a secure place.

The data must not be accessible to any third party.

As the privacy requirement is closely associated with security, we have made numerous adjustments to the application to ensure maximum protection.

High

Reliability

Errors in the application must be handled by the application itself, without crashing under any circumstances.

The user shall have no knowledge of such errors, except for those that must necessarily be communicated to the user.

A considerable amount of effort will be dedicated to error prevention, as it is closely tied to maintainability. When implementing a feature, there is much more involved than simply making it functional.

High

Maintainability

Our application will undergo many changes, so we need to develop it in a way that makes it easy to maintain in the future.

We aim to make as few errors per line of code as possible.

Investing greater effort in implementing a new feature can lead to significant rewards when modifications are made later on.

Medium

Freedom

We are developing the application on a greenfield basis. We intend to save unnecessary effort for those working on it in the future by including the code with plenty of documentation in a public repository.

The project must be available in its entirety in a public repository accessible by anyone at any time.

A repository that is accessible to the public and contains a record of every discussion, issue, or decision made.

Medium

11. Risks and Technical Debts

“Risk management is project management for grown-ups” (Tim Lister, Atlantic Systems Guild.)

(It will obviously be extended as we find new risks and generate others technical debts as we develop the application.)

Table 2. Risks
Priority	Problem description	Considerations
Medium	Huge dimension of the project	The quality and readability of the developement solutions are mandatory in order to keep order
Medium	Time availability of memebers of the developement team	Good organization and distribution of the project work along the semester
Medium	Experience	Regardless of our knowledge of the technologies used, this is the first time we have implemented a real-life project.
High	New technology	Most of the technologies of the project are new for us and we have little experience in web development.
Low	Working as a team	This is the first time that the two of us have worked as a team.
Medium	Coordination	We must coordinate properly to avoid problems like those that happened in the previous team.

Table 3. Technical Debts
Technical Debts	Considerations
Some small functional features	As a result of prioritizing other aspects, some interesting features have not been implemented, such as transforming a public location into a private one or vice versa, filtering locations by friend in a clean and straightforward way, etc.
Some small usability features	As a result of prioritizing other aspects, the app lacks the usual feedback of a profesional application. For example, confirmation dialogs when deleting, messages when an operation has been successfully completed, etc.
Testing	We have achieved a 70% of coverage, but we expected to be able to achieve at least 80%.
E2E Testing	We have not performed many e2e tests (5), since we can not log in the application in these tests and most of the features are only available for logged-in users.
Deployment	For using the solid login, we need to deploy the application with https. However, we can not use the restapi correctly using this protocol, so the deployed application is lacking the part related to the database.

12. Glossary

Term	Definition
TypeScript	Free and open source high-level programming language developed and maintained by Microsoft. It is a superset of JavaScript that adds static typing.
React	Free and open source JavaScript library for building interfaces, maintained by Meta.
Node.js	Cross-platform, open source server environment, a back-end JavaScript runtime environment.
Express.js	Free and open source back-end framework for developing web applications and APIs with Node.js
Solid	Specification that lets users store their data securely in Pods
Pods	Decentralized and secure data stores. The pod user controls who can access the data.
MongoDB	Open source document-oriented NoSQL database.
Docker	A set of platform as a service products that use OS-level virtualization to deliver software in containers.
CI, Continuous integration	The practice of automating the integration process of a software so it can be done several times a day and errors are found as soon as possible.
CD, Continuous deployment	Extension of the CI, where code changes to the application are released automatically into the production environment.
Jest	JavaScript testing framework built on top of Jasmine and maintained by Meta.
End-to-End testing, E2E	software testing methodology that verifies the working order of a software product in a start-to-finish process. End-to-end testing verifies that all components of a system can run under real-world scenarios.
Cucumber	Software tool that supports behavior-driven development. Central to the Cucumber BDD approach is its ordinary language parser called Gherkin.
Gatling	Gatling is an open-source load- and performance-testing framework based on Scala, Akka and Netty.

Term

Definition

TypeScript

Free and open source high-level programming language developed and maintained by Microsoft. It is a superset of JavaScript that adds static typing.

React

Free and open source JavaScript library for building interfaces, maintained by Meta.

Node.js

Cross-platform, open source server environment, a back-end JavaScript runtime environment.

Express.js

Free and open source back-end framework for developing web applications and APIs with Node.js

Solid

Specification that lets users store their data securely in Pods

Pods

Decentralized and secure data stores. The pod user controls who can access the data.

MongoDB

Open source document-oriented NoSQL database.

Docker

A set of platform as a service products that use OS-level virtualization to deliver software in containers.

CI, Continuous integration

The practice of automating the integration process of a software so it can be done several times a day and errors are found as soon as possible.

CD, Continuous deployment

Extension of the CI, where code changes to the application are released automatically into the production environment.

Jest

JavaScript testing framework built on top of Jasmine and maintained by Meta.

End-to-End testing, E2E

software testing methodology that verifies the working order of a software product in a start-to-finish process. End-to-end testing verifies that all components of a system can run under real-world scenarios.

Cucumber

Software tool that supports behavior-driven development. Central to the Cucumber BDD approach is its ordinary language parser called Gherkin.

Gatling

Gatling is an open-source load- and performance-testing framework based on Scala, Akka and Netty.

13. Testing

13.1. Unitary testing

For the creation of unit tests we have used the Jest libraries and, in the case of the components found in the webapp, the React Testing Library. In the webapp, the correct operation and rendering of each individual component is tested, the functions that call data from the pod or the database have been mockerized with functions that return prepared data.

We have achieved almost 70% of code coverage. Although a higher percentage would be optimal or required in a real environment, it is a good result considering that most of the application relies on a google map which makes it more difficult to test.

13.2. End-to-End testing

The Jest and Cucumber libraries have been used to create e2e tests. Cucumber allows the tests to be performed with the Given, When, Then user story syntax. Examples of acceptance test would be:

Feature: Login

Scenario: The user logs in

Given An user in the home page
When The user clicks on the login button
Then It opens the login dialog

Feature: Map view

Scenario: The user opens the filters

Given An user in the map page
When The user clicks on the filters button
Then It opens the filters dialog

Scenario: The user selects the public locations map

Given An user in the map page
When The user clicks on the combo box and selects public locations
Then The public locations are displayed

Feature: HomePage

Scenario: The user views the map page of the app

Given An user in the home page
When The user clicks on the map link in the navbar
Then The map page should be shown

Scenario: The user clicks on the Let’s get started button

Given An user in the home page
When The user clicks on the button
Then The map page should be shown

13.3. Static analysis

We have used SonarCloud in our project to enhance the maintainability of the project and reducing the code smells and security issues.

13.4. Load testing

We have used Gatling to perform some load testing. As there was not a number of users specified in the requirements, we first started with a rampUsersPerSec configuration. Starting with 2 users and scaling each second, we noticed that our application reached its limit with 10 simultaneous users.

We performed a stress test after that, with 20 simultaneous users with the atOnceUsers configuration.

About arc42

arc42, the Template for documentation of software and system architecture.

By Dr. Gernot Starke, Dr. Peter Hruschka and contributors.

Template Revision: 7.0 EN (based on asciidoc), January 2017