LOMAP ES3A

It is also possible to obtain more information through the following link, which contains a more specific description about the app itself.

The main objective of the application is the private treatment of user data. We will achieve this objective by using PODs to keep user data private and decentralized.

In SOLID architecture we can define a POD as a Personal Online Data Store. The user can have there any information he/she wants and can be hosted anywhere.

The application will be written in Typescript with React, Typescript being a language like JavaScript but with types and React a library to facilitate the creation of user interfaces.

We have taken the following organizational decisions:app-name:

For the login, the app shows the login view which asks the user for their Solid Identity Provider of choice.

Then the app does a login request to the REST API server, which redirects the user to the identity provider which handles the authentication.

Once the user successfully logs in, the identity provider gives the server the session information needed to interact with the user Pod, and the server sends the session ID to the web app, which can be used to identify the session in later REST API requests. Lastly, the web app shows the main view.

In this view he can do the CRUD operations:

Saved locations can later be viewed by the user and his friends through the web application.

The user can add a location to their map.

Locations added to the map later be removed by the user through the application.

Security is a very important concept in the context of a system. As we are managing information from users, it is important to ensure that the information is safe and that the system is not compromised. So, we decided to store in our system the minimum information necessary and obtain the other from the PODs. Also we decided to encrypt the users' passwords, if any.

Also, we added security in the back-end to prevent unauthorized requests to the RestAPI, as well as for preventing the execution of malicious code.

In order to ensure the correct functioning of the system, we decided to implement unit tests for most of the components and will also check the functionality of the whole app itself, so the user experience is at its best.

We have decided to create a branch for it, named testing, so when we need to do tests, we use that branch.

The maintainability of the application is an important section because it is necessary for the code to be easily modifiable in case in the future we are asked for new functionalities to implement.

To achieve this, we have implemented a number of practices and techniques throughout the application development lifecycle.

First of all, we have used a modular approach to the design of the application, dividing the functionality into small independent modules that are easy to maintain and update. Each module has been designed trying to make the code easily understandable and modifiable.

In addition, we have exported all the functions that PODs use so that when they are needed, they only have to be called

Finally, by using parameters in the elements that are rendered, we have allowed the reuse of those elements in different parts of the code.

Usability is a fundamental aspect of any application, since it determines the ease and efficiency with which users can interact with it. To ensure the usability of our application, we have followed a series of specific practices and techniques.

First of all, we have done extensive research on the needs and expectations of users, which has allowed us to design an intuitive and easy-to-use user interface.

In addition, we have used a user-centric approach at all times during the development of the application. We have designed the user interface with a focus on the user experience, which has allowed for easy and intuitive navigation. We have also incorporated user feedback and suggestions into each phase of development to improve usability.

In addition, we have carried out usability tests with real users to evaluate the ease of use of the application and improve it.

Lastly, we have used notifications to inform the user when they perform an action in our application.

We used Jest and Testing Library by React for testing our webapp, we followed the structure that we learned in our labs and Jest docs.

We created separate tests for each component, in order to test isolated parts and check if every aspect of our app worked, but we faced some problems in the process, as it ended up being almost impossible to check everything, mostly due to compatibility issues with libraries and problems with the react testing library itself (which is not suited to test the useState hook).

We reached a total coverage of 72.1% (at the momment of writing this document) with 106 tests in 25 suites, we had to mock the session and functions that interact with the PODs, but sometimes it wasn’t enought, due to the reasons we commented before.

We used Jest and Cucumber to perform integration testing in our app. Following cucumber gherkin language, we designed tests and User Stories with the structure: "Given, When, Then", which resulted in a lot of facilities when implementing them.

As GOMap! uses external technology, such as a Session Provider (Inrupt, SOLID Community, …​) or SOLID PODs, we had to test with some default values, written to test if this external techs worked propperly in our app context.

In the end we manage to have 2 e2e features, with 4 general tests:

Load testing is a process of testing the performance of a system by simulating a large number of users accessing the system. This tests are important to ensure the performance quality goal defined previously. In our case, to perform this test we used Gatling tool. This tool allows to record an action in the website and later simulate this actions but with a large number of users. Finally, we can see the results of the test and the average time of all the requests and a more complete report of the test.

In our case, we managed to achieve a load test of the app with a 3 users per second and a total duration of 15 seconds. The results obtained reflect that the average time of the requests was above 1200 ms. This is because our application makes multiple calls to the PODs, so the response time is less. The complete results can be seen in the following image in which we can see how 572 requests have been made, of which 65 took less than 800 ms, 46 took between 800 and 1200 ms, 396 took more than 1200 ms and 65 failed due to reasons of the connection with the PODs which is foreign to us.

To carry out the usability tests, the user will have to perform three medium-sized tasks so that the developers can check the performance of the app with users of all kinds.

The tasks are:

Once this is done, the user will have completed the 3 tasks and the test will have ended.

* Every time measurement is in seconds