ViaDe ES3C

The main requirement is to provide a system to store and display routes. The system will be based on a decentralized architecture where data storage is done locally for each user. An overview of the high-level requirements is shown below:

Quality attributes qualify functionality of the application. This table contains the main features Viade looks for.

The following table shows the people interested in the application.

This section shows a representation of the communication partners and stakeholders of our system, offering a more easy to understand graphical view of the business, and later explain more indepth in the technical context.

For this applicacion we are using a couple of technologies, like SOLID, REACT, etc…​ the main idea is building an applicacion working with the technologies we mentioned earlier capable of working with SOLID and allowing SOLID users to save their routes and sharing them with friends in a safe way, the base part of the applicacion is gonna be done using REACT, while the communication is done using SOLID and its pods.

Level 1

At a first place, there are two main modules, Viade and Solid Server. All Viade’s components communicate with Solid Sever.

Contained building blocks

Level 2

In this level there is the main view, In this level you will find all the containers which the user will interact.

Contained building blocks

Level 3

This is the lowest level. It provides us the necessary logic to communicate with user’s pod.

Contained building blocks

Users must log in with their credentials in order to access the application and upload their data.

Once logged in correctly, the user has 2 main options: to create a new route or to view his saved routes.

To create a new route, the user must access the corresponding view of the application where a map is shown on which he must draw his route using points. Once drawn, the user must enter a name, a description, and if desired, photos and/or videos to save along with his route.

In the application, there is a view that shows all the routes that the user has saved so far. For each route you can see: name, author, description, the points of the route on the map and you can also share the route with your friends.

You can also create a route through a geojson or gpx file. The user enters the name and description of the route, he can also upload multimedia. Once you press the save button, you will be redirected to my routes, where the new route will appear.

This part of the application allows you to view the list of the user’s friends in session. It is also possible to add and remove friends. After these two actions, the page where the friends are seen will be reloaded, allowing us to see the update of the list of our friends.

You can adding new friends to our list entering their webid and pressing the add button.

If you want to delete a friend from the list, it is also possible by clicking on the delete button.

Our application allow us to share a route with some friends. When you visualize the routes, each route has a button where you can select the friends who you want to share the route with.

We can see the routes that users shared with us by clicking on the shared routes option in the navigation menu. The procedure is the same as loading my routes.

When a route is shared with that friend, this friend receives a notification that follows this procedure:

Although it was not requested we made some functionalities that are detailed below:

Our domain diagram has three entities: one of them is the route that has a series of points and multimedia files. We also have the Point class that has the attributes longitude and latitude and the Multimedia class that counts on giving us information about the author, the date, the name, the url and the path they belong to since they are saved from that way in the pod the path will have a reference to the media files. Next, we can see this domain model

Although we said that we would analyze this section more carefully later, we do not believe that we have used any specific design pattern.

Something we are sure about is the arquitecture of our project. We are going to work with two arquitectural patterns: n layers pattern and MVC pattern. These patterns will allow us to develop a maintainable and scalable application. On the one hand, we want to use 3-layers pattern. This pattern will allow to separate the presentation of the application, business where we have the logic and the persistence which in our case we will store the information of each user in its pod. Regarding the n-layer pattern, we could say that in some cases it was difficult to separate the business layer from persistence, since in some cases it did not require excessive complexity to obtain the data, for example in the case of friends. In this case, we use some React components that allow showing friends in the interface, but in the case of Routes it is much more complicated and it is necessary to obtain and parse those routes from the pod and then use a manager as an intermediate class as a service. that allows us to list those routes in the front. In other cases, such as adding or removing friends, we do use an intermediate class that allows us to remove and add them, but in this case we do not make a difference between the service layer and the persistence layer.

In addition, we are using React js to develop viade that also have its patterns. Content-container pattern is one of the React´s pattern and it consist on divide the component into two components: one component is responsible for obtaining the information - the container - and another component shows the information that is passed through its properties - the content.

We have to develop this application using React js and architecture SOLID. Moreover, we want to use Bootstrap library to simplify the design of the frontend. The app must meet the requirements so we are testing with diferent tools but we have not decided yet. In the end, as I said before, we did not use the Boostrap library since we wanted to make a design and a style of our own for our Viade application.

Today, the development of secure applications is one of the most important points. Therefore, our app is based on SOLID architecture so each user will identified itself with a WebId and it will deal with it personal data. When we are offered the option of sharing routes to maintain both the security and the right of our clients, what we do is give permissions to that route so that the friend can see the route instead of copying the route to his pod since this would imply less security and less privacy since the application would have more permissions than necessary

We try to carry out a usable application design. This is reduced to following the principles of web usability, maintaining constant navigation and not forcing users to learn new ways for navigation in the different parts of the application. We also try not to abuse the animation as this could tire your eyes and become overwhelming. In addition to find out if it is also usable we resorted to the completion of a questionnaire that we sent to different people to test the app and tell us what their opinion was.

We try to create a modular interface, that is, that each part of the application is a unique component that can have 0 or more within it and that each one takes care of its own functionality, which will allow our application be more maintainable and adaptable to change.

we wanted to create an app that could be viewed and worked with on different devices from computers to mobiles following the adaptive web design

We believe that viade is interoperable with other applications since we follow the specification determined in viadeSpec. Although it may not be interoperable with all applications, we believe that with a part of them it will be.

To test the accessibility of our application, we decided to contact people who may have problems viewing it due to some type of disability.

There are some aspects of our application that could be improved: