Viade es2b

1. Introduction and Goals

Viade 2b is an app for the management and display of routes, whith social functions such as sharing with friends or group of them. Is developed over React and follows the SOLID specification and is a client-side app.

1.1. Requirements Overview

System requirements

System will use a descentralized architecture, being the data independent from the system.
System will let users to share info to other users, using a friendly-style. In addition, users can have a group of that "friends" for share instantly routes with them.
System will let users set a privacy for their routes, making them public or private.
Systems will show users the routes of their friends if that routes are public.
System will let registred users download their routes in their own devices.
Same way, registered users can display their routes on a map.
System will recognize routes files from other app or devices which follow the GPX standard.

1.2. Quality Goals

System objectives are as follows, from most important to less:

Priority	Objective	Detail
1	Usability	System will be intuitive for all kind of users, needing a short time for them to get acquainted with it.
2	Simple UI	The interface of the app should be clean and simple to make things easier for the users.
3	Performance	The system must be effective and fast, with short loading times for the users.
4	Security	System shall be secure. Privacy of data will be a central part of the development following SOLID specification.
5	Testability	Tests must be carried out to verify the correct operation of the system.

Priority

Objective

Detail

Usability

System will be intuitive for all kind of users, needing a short time for them to get acquainted with it.

Simple UI

The interface of the app should be clean and simple to make things easier for the users.

Performance

The system must be effective and fast, with short loading times for the users.

Security

System shall be secure. Privacy of data will be a central part of the development following SOLID specification.

Testability

Tests must be carried out to verify the correct operation of the system.

1.3. Stakeholders

The table below contains information about the potential users of the application.

Role/Name	Contact	Expectations
Basic users	New users to use the app. The app should be build in a way that they are familiar with and with explanations when necessary.	They will expect the app to be simple and intuitive. They may expect explanations about PODs for those users how don’t know how it works.
Experienced users	Users who know about PODs and their usage.	They will expect the app to be simple and efficient. The POD management should be similar to other SOLID apps' usage.
App Developers	People in charge of the develop of the app, so they should understand all the components of the app and the technologies used.	They are expected to develop a secure, simple and usable application.
SOLID Developers	People in charge of defining the SOLID standards. Therefore, they will have a great impact in the design and way of work of the application.	They will mark some constrains to the project but they will also help with the documenatation and guidelines of the SOLID standard.
SOLID Community	People following the project and helping others throught forums and social platforms. In some cases they’re also SOLID developers	They help people new to the SOLID world through asvices and, in case of they are also developers, with libraries and technical suggestions.
Inrupt	Company founded by Tim Berners Lee supporting the development of SOLID related projects and providing POD host.	They provide libraries and project skeletons to make things easier for app developers..

Role/Name

Contact

Expectations

Basic users

New users to use the app. The app should be build in a way that they are familiar with and with explanations when necessary.

They will expect the app to be simple and intuitive. They may expect explanations about PODs for those users how don’t know how it works.

Experienced users

Users who know about PODs and their usage.

They will expect the app to be simple and efficient. The POD management should be similar to other SOLID apps' usage.

App Developers

People in charge of the develop of the app, so they should understand all the components of the app and the technologies used.

They are expected to develop a secure, simple and usable application.

SOLID Developers

People in charge of defining the SOLID standards. Therefore, they will have a great impact in the design and way of work of the application.

They will mark some constrains to the project but they will also help with the documenatation and guidelines of the SOLID standard.

SOLID Community

People following the project and helping others throught forums and social platforms. In some cases they’re also SOLID developers

They help people new to the SOLID world through asvices and, in case of they are also developers, with libraries and technical suggestions.

Inrupt

Company founded by Tim Berners Lee supporting the development of SOLID related projects and providing POD host.

They provide libraries and project skeletons to make things easier for app developers..

2. Architecture Constraints

Introduction

There are some constraints in the development of our application. These constraints are technical, organitazional and conventional. The following tables detail these constraints.

Table 1. Technical Constraints
Constraint	Explanation
Decentralized architecture	The project architecture will be descentralized, which means user data is separated from the application and users are the one who control the flow of information.In order to achieve that,we will use SOLID specifications.
React	The project interface will be develop with React. This library will desing and update effectively the proper components when the data changed. It’s mandatory to have some knowdledge at HTML5, CSS3 and JavaScript for using React.
JavaScript	JavaScript will be used to develop this project as it is the base language of React.
Node.js	Node is used for making server side applicattions with Javascript. We’ll be using it to generate our app.
Travis	Travis is a continuous integration platform that automatically tests and builds code changes on every push.
Codevoc	Codecov provides highly integrated tools to group, merge, archive, and compare coverage reports.
Codacy	Codacy automatically identifies issues through static code review analysis. It’s used for detecting duplicate code, security issues, code coverage and code complexity in every commit and pull request.
Compatibility and adaptability	This project can be used at any major web browser (Mozilla Firefox, Google Chrome, Opera, Safari…) and Operating Systems in order to fullfill maximum market coverage.
SOLID PODs (data storage)	For the storage and management of the user data we will use the SOLID PODs, as it is required by the assignment and the SOLID specification.There won’t be any database in this project.

Table 2. Organitazional and political constraints
Constraint	Explanation
Git	Git is a control version system. It will allow us to lead a colaborative development and simplify the sharing and reviewing of it.
GitHub	Our project will be managed using GitHub, a configuration management system that will facilitate us working together.
Continuous delivery	The project will have several deliveries throughout its development to be review by teachers.
Team	This project will be developed by a random development group, with the difficulties of adaptation that this implies.
Project budget	This project will be developed by students without a source of income available to improve its development. For that reason only free development tools were used.
Meetings	We must keep track of every meeting at the poject’s wiki to ensure everyone can follow up our workflow.
License	This is an Open Source project published under de MIT License. All the contents included in the project should be Open Source published under the MIT license.

Table 3. Conventions
Constraint	Explanation
arc42	As a template for documentation, we must use arc42 in order to make it clean and useful for future readers.
AsciiDoctor	Our project will be using AsciiDoctor to convert AsciiDoc documentation into HTML5 content.
Language	This project needs to be internationalized in order to make it accesible to the Inrupt community.For that reason this project will be entirely developed in English

3. System Scope and Context

The scope of our project, Viade, is to create an app where users can save their routes in order to see them later without this information going through an external server. To accomplish that, we are going to base our app on Solid and, more specifically, in the use of PODs which will work as an internal private server, so each user will have his own POD and no one but that user will have access to the information stored there.

With Viade, users will be able to upload their routes to a Solid POD, including name, description and images, as well as the privacity of the route (public or private). Once the user has any routes, he will be able to display the track associated to that route in a map and see all the information about that route. They will also be able to edit, download and delete their routes, as well as share them with friends or groups of friends.

Viade will also let users create groups containing some of their friends, which could be used to group them and share routes with all the members of an specific group, instead of doing it one by one.

As the app is based on Solid, and more specifically on the concept of Solid PODs, every user should need a POD where the routes, groups and other important information used will be stored. Connection to the internet is mandatory too, as the POD cannot be accessed without it.

3.1. Business and Technical Context

As our technical and business diagrams in our app are pretty similar, we decided to put them together into a single diagram which represents both of them.

Entity	Context
User	It represents every potential user of our app, which will interact with it to perform the different options offered by Viade
Viade	It’s our app, the center of the system. All the information and processes related with the routes will go through it
SOLID Pod	There is one for each user and it’s where they will keep all their routes and other information like friends, groups, etc..
Routes	GPX format files (which could be extended to KML or GeoJSON in a future) that users upload in order to see them later or share them with their friends
Leaflet	Viade uses a map to display the tracks contained in each route’s gpx file. This map is provided by Leaflet, which takes that file and parses it into the map, showing the different points contained in it and the track itself

Entity

Context

User

It represents every potential user of our app, which will interact with it to perform the different options offered by Viade

Viade

It’s our app, the center of the system. All the information and processes related with the routes will go through it

SOLID Pod

There is one for each user and it’s where they will keep all their routes and other information like friends, groups, etc..

Routes

GPX format files (which could be extended to KML or GeoJSON in a future) that users upload in order to see them later or share them with their friends

Leaflet

Viade uses a map to display the tracks contained in each route’s gpx file. This map is provided by Leaflet, which takes that file and parses it into the map, showing the different points contained in it and the track itself

4. Solution Strategy

We’ve decided to use Github because of his easy-way for control versions. In adittion, users can do pull request from branches and have a history of team actions.

Also we’ve decided to use React plus SOLID for working with descentralized data, being a prerequisit of this project. SOLID works well with different programming languages and allows us to have a range of possibilities in this early phases of the project.

Regarding React, it’s a JavaScript library (developed by Facebook) that makes easy the creation of interactive and reusable components in focus to user’s interfaces. Rdflib.js will be use in this project, because it makes us easier working with SOLID.

For archieve our quality goals, like the possibility that our application can load files generated by other similar aplications, we have decided to use .GPX files. This kind of files are used by most of well-known apps so this decision will make our system compatible with their files.

In adittion, we have used a sort of libraries:

Library name	Explanation
Solid-React-Components	This library is used in order to create components wich read info from POD directly, like users' name or friends. Plus, it makes easier for us to discover a user’s mailboxes, as well as allowing us to send and receive notifications instantly.
Material UI	This library is being used in a clear amount of visual components, like "option buttons" for every route (delete, edit, download). Sadly, we have discovered this library too late and we couldn’t apply it to all project.
Styled Components	This library was being replaced by the previous one. Used for visual components too, it provides a simple but effective visual solution in order to create style sheets.
React-leaflet	This library was used because it allows us to use leaflet components as React components.
Leaflet-gpx	This plugin allows us to process and work with GPX files and add them to React component wich has leaflet map.
React-testing-library	This library was used in order to test React components in a more effective way.
Jest-cucumber & jest-puppeteer	This library was used in order to test our application using Cucumber tool.
Solid-File-Client	This library is a JavaScript library with high-level methods to create, read, and manage files and folders. The methods may be used in browser scripts or in nodejs shell scripts
Solid-Auth-Client	This library is a browser library that allows our apps to securely log in to Solid data pods and read and write data from them.

Library name

Explanation

Solid-React-Components

This library is used in order to create components wich read info from POD directly, like users' name or friends. Plus, it makes easier for us to discover a user’s mailboxes, as well as allowing us to send and receive notifications instantly.

Material UI

This library is being used in a clear amount of visual components, like "option buttons" for every route (delete, edit, download). Sadly, we have discovered this library too late and we couldn’t apply it to all project.

Styled Components

This library was being replaced by the previous one. Used for visual components too, it provides a simple but effective visual solution in order to create style sheets.

React-leaflet

This library was used because it allows us to use leaflet components as React components.

Leaflet-gpx

This plugin allows us to process and work with GPX files and add them to React component wich has leaflet map.

React-testing-library

This library was used in order to test React components in a more effective way.

Jest-cucumber & jest-puppeteer

This library was used in order to test our application using Cucumber tool.

Solid-File-Client

This library is a JavaScript library with high-level methods to create, read, and manage files and folders. The methods may be used in browser scripts or in nodejs shell scripts

Solid-Auth-Client

This library is a browser library that allows our apps to securely log in to Solid data pods and read and write data from them.

Finally, about organizational schema, we have decided that all of us will get involved in all the project, either working directly in the assigned code or checking another’s one.

5. Building Block View

This block shows the decomposition of the system into building blocks and their respective dependencies.

5.1. Whitebox Overall System

Contained Building Blocks

Name	Responsibility
User	Interacts with the application
Viade	It’s the application. Contains all the functionality about route displaying, friends, groups…
POD	One for each user. Provides all the routes and other information like friends, etc…
Leaflet	This is the API we use to show the routes in the map

Name

Responsibility

User

Interacts with the application

Viade

It’s the application. Contains all the functionality about route displaying, friends, groups…

POD

One for each user. Provides all the routes and other information like friends, etc…

Leaflet

This is the API we use to show the routes in the map

5.2. Level 2

The whitebox shown at this level is the application: Viade

Those clasified as blackboxes will be further explained in the Level 3 part. Those clasified as components don’t need further decomposition, as they are already small and don’t have enough complexity. We have shown the user, the POD and Leaflet as we consider them necessary to explain this level.

Contained Building Blocks

Name	Responsibility
Components	The parts of each container. They provide different functionalities like showing the routes or the access to our friends list
Containers	They represent all the different views and pages that compose our application. They are what the user interacts with
Route	This is used to store all the information related to the route: the route itself, the images, the name, the privacy…
POD Manager	Interacts with the POD, receiving the files requested by the containers and sending them

Name

Responsibility

Components

The parts of each container. They provide different functionalities like showing the routes or the access to our friends list

Containers

They represent all the different views and pages that compose our application. They are what the user interacts with

Route

This is used to store all the information related to the route: the route itself, the images, the name, the privacy…

POD Manager

Interacts with the POD, receiving the files requested by the containers and sending them

5.3. Level 3

At this level we have two whiteboxes: Components and Containers

5.3.1. Components

Here we can see two important things:

The map is the component that interacts directly with Leaflet (the API that provides the map).
All the components of this whitebox are used by the components of container whitebox. The relation with the containers implies also that the components receive all the necessary information to work from them.

There are more components, but the ones shown here are the most relevant.

Contained Building Blocks

Name	Responsibility
NavBar	The top bar of the application. We have two: one for the users not logged in and another for the ones that are currently logged in. It provides different functionalities like the view with the routes or the one with the list of friends
Footer	The bottom part of every view. It displays our organization and the version of the application
Spinner	This component displays all the images that a route has
RouteList	It shows all the different routes that a user has in his POD
FormEditRoute	From this form, we can edit our routes
Map	Shows the selected route drawn in the world map

Name

Responsibility

NavBar

The top bar of the application. We have two: one for the users not logged in and another for the ones that are currently logged in. It provides different functionalities like the view with the routes or the one with the list of friends

Footer

The bottom part of every view. It displays our organization and the version of the application

Spinner

This component displays all the images that a route has

RouteList

It shows all the different routes that a user has in his POD

FormEditRoute

From this form, we can edit our routes

Map

Shows the selected route drawn in the world map

5.3.2. Containers

The discontinuous arrow shows the navegation of our aplication; the movement between containers that the user can do. The continuous ones show interaction between components; they imply a flow of information.

Contained Building Blocks

Name	Responsibility
Home	The default view. It is shown when the user is logged in. You can find things like the map or the images here
Login	The default view when a user accesses the application without logging in. Here you can log yourself in or access to the register view
Profile	It shows the user that is currently in the application
Register	When accessed, it allows the user to register in a SOLID provider
Friends	This view shows our SOLID friends and also the groups we are in. We can create or delete groups

Name

Responsibility

Home

The default view. It is shown when the user is logged in. You can find things like the map or the images here

The default view when a user accesses the application without logging in. Here you can log yourself in or access to the register view

Profile

It shows the user that is currently in the application

When accessed, it allows the user to register in a SOLID provider

Friends

This view shows our SOLID friends and also the groups we are in. We can create or delete groups

6. Runtime View

Here we include some diagrams representing different actions that can be done with our application.

6.1. Store routes & groups

6.2. Share routes

7. Deployment View

Our application is a client side application which relies on SOLID specifications for the management of the user personal data. The fact os being a client-side application has repercussions in the performance of the app. But because the nature of the app, which doesn’t do many calculations or resource demanding actions it shouldn’t be a problem.

We are deploying the app in GitHub Pages, so we depend on this service in terms of avaibility and stability.

For the data, we relie entirely in the user’s POD, so if the user’s POD has some problem who falls out of our control, the app can fail. This is a constraint due of the use of the Solid specification, a constraint that make sense for a project like this one, where the users are who control their own data.

We are developing this application using Google Chrome, so is the recommended web browser, but it should work in almost every modern browser due to the use of widely-used standards.

7.1. Infrastructure

In the diagram above we can see the three main systems involved in the use and deploy of the aplication.

These systems are:

User’s PC: The system that hosts the app, more specifically, the web browser running on that PC. Will provide all the neccesary resources, including network resources to allow connection to GitHub Pages.
GitHub Pages: Host app and keeps it available for the user.
Solid POD: The Soild POD holding all the user data.

8. Cross-cutting Concepts

In this section we are going to explain the ideas, concepts and regulations on which we base our system.

8.1. Domain Concepts

Route: GPX file containing the user’s routes, which can be stored and consulted by that user.
Pod: this is the repository, which follows the SOLID specification. This is where all the routes and other information such as friends are stored.
Client: this is the app that will run in the user’s browser. It provides a friendly, intuitive interface and all the app’s functionality, but it won’t store the data (we use the POD for that)

8.2. User experience

This is one of the most important parts in our application. Users need an intuitive, friendly, easy to understand interface in order to feel confident using the app and not getting overwhelmed by confusing, cryptic options.

To achieve that, we are going to divide our app in two simple parts: the first one includes the functionality needed to upload and store a route file from the user’s device, as well as editing, downloading, sharing, deleting and displaying those routes in the map; and the second one allows the user to see all his friends and groups of friends. He will also be able to create new groups. This division helps the most unexperienced users to understand the functioning of the app in a simple way.

8.3. Safety and security concepts

By using the PODs, we make sure that all the user’s data are decentralized and only stored in that user’s POD, avoiding multiple security problems which could cause some difficulties in case of using a centralized system. With this storage system, users become the owners of their data, instead of letting third party companies collect all of it and use it for their own purposes.

8.4. Architecture and design patterns

We base our app on the MVC architectural pattern, which consists on separating the data and business logic of the app from the visual representation and the communication channels.

8.5. "Under-the-hood"

Session handling: we manage the session by using the SOLID session itself, which can be accessed using the SOLID credentials. Users can login with two different providers, Inrupt and Solid Community.
Persistence: as the data is stored in PODs, we don’t need to use any other kind of databases or storages to save all the user’s information. However, we use a self-made library to perform all the operations related with saving and retrieving information from the users POD.
Error handling: the main error on this app will occur in case of not having a good and stable internet connection, which could lead to lag or malfunctioning of the app. That’s why we recommend using a good internet connection if possible, since it will improve user experience and response times.

8.6. Development concepts

Building: we use the Node.js package manager, npm, to build the app by using different plugins or tools in order to accomplish the goals we want to reach and to provide the desired functionality.
Testing: this is a key part in our app, and we put a lot of our efforts on ensuring that the app works the way it has to. For accomplishing this, we use several frameworks such as Cucumber.js, Jest and Gatling, as well as React’s own testing library.

8.7. Operational concepts

Disaster recovery: the user’s data are stored in his own POD, which is independent from the app, so they won’t be at risk if something wrong happens with the app. As for the app itself, it depends on GitHub, so if GitHub is down, the app will be too until the problem is solved. However, the app can also be deployed using Docker, as explained in the repository readme.
High availability: once a new version of the app is finished, it is available for the user as soon as the changes included in the development branch are merged with the master branch, which is the branch from where the app is deployed.
Administration: as we are a team, we divide the administration of the project equally between all the team members, as well as we might help others with the problems they have.

8.8. Scheme prototypes

We have made some prototypes of our application. This point is not included in the arc42 standard, but we consider this as something helpfull to understand the design process we followed.

9. Design Decisions

Brief description of all the decisions we took in order to develop the app.

Note	All our decisions can be found at GitHub wiki

Date	Participants	Our decisions	Description	Pros	Cons
03/02/2020	Whole Team	IDE	We are all using Visual Studio Code as it’s a very versatile IDE with numerous extensions which would make our work easier.	Easy to use. Some of us use this IDE on a daily basis so we can teach the other members where to find X option.	Some of the members never used this IDE before.
10/02/2020	Whole Team	Control System	We will be using Git as a control system and GitHub as source code manager to keep track of different app versions. We decided to create one main develop branch and subbranches per person. The main branch should only be updated before deliveries.	It’s a great way to keep a backup of the code. It also allows us to work on the project at the same time without risk of overwriting the work.	We are still not used to working with git and we do not know how to use all the commands yet.
10/02/2020	Whole Team	Project’s language	We will be using English as our main language for developing this project (commits, doc…) as we think this is the best option for persuing and international project.	Internationalization.	It’s not our main language so we may experience some trouble redacting our texts.
10/02/2020	Whole Team	Design Architecture	As Solid is a W3C endorsed linked data personal data store (PODS) that puts control into the hands of the user, we’ll be using P2P (Peer to peer) design architecture. Also, we will be following MVC (model view controller) architectual pattern.	Already known code distribution.
17/02/2020	Whole Team	Code revision	Each pull request should be checked by at least 2 team members in order to avoid bugs.	It improves code quality.	It takes time to check every line of code.
24/02/2020	Whole Team	Fixing issues	We decided to open an issue for every task we needed to solve.	It’s a great way to keep track of our tasks.	We might forgot to open a new issue if the task itself is simple and can be solved quickly.
09/03/2020	Whole Team	Meetings	We decided to meet at least 2 times (maybe 3) a week to talk about our weekly work.	We ensure everyone is doing their work.	Finding valid schedules could be tough.
16/03/2020	Whole Team	Front End	We decided to use Material UI with React to be able to integrate a responsive design easily.	Simpler to create a fancy interface.	First time using it.
23/03/2020	Whole Team	Testing	We decided to use Jest/Pupeteer/Cucumber for testing our app.	It ensures a proper functionality.	We are not used to work with those type of tests.
23/03/2020	Whole Team	Map	We decided to use GPX as it’s the standart most routing apps use.	Our app could load routes from other apps.	Our app would not support any other map format.
30/03/2020	Whole Team	Template	We decided to use Inrupt’s generator to make an app template	Easy to start out project.	The template is kind of complex and it has a lot of frameworks included that we might not end up using.
14/04/2020	Whole Team	Template	We decided to use Inrupt’s generator to make an app template	Easy to start out project.	The template is kind of complex and it has a lot of frameworks included that we might not end up using.
29/04/2020	Whole Team	Material UI	We decided to swap to Material UI as it’s components are well known by users worldwide.	Good looking and adaptable components	Lack of time to implement it everywhere.

Date

Participants

Our decisions

Description

Pros

Cons

03/02/2020

Whole Team

IDE

We are all using Visual Studio Code as it’s a very versatile IDE with numerous extensions which would make our work easier.

Easy to use. Some of us use this IDE on a daily basis so we can teach the other members where to find X option.

Some of the members never used this IDE before.

10/02/2020

Whole Team

Control System

We will be using Git as a control system and GitHub as source code manager to keep track of different app versions. We decided to create one main develop branch and subbranches per person. The main branch should only be updated before deliveries.

It’s a great way to keep a backup of the code. It also allows us to work on the project at the same time without risk of overwriting the work.

We are still not used to working with git and we do not know how to use all the commands yet.

10/02/2020

Whole Team

Project’s language

We will be using English as our main language for developing this project (commits, doc…) as we think this is the best option for persuing and international project.

Internationalization.

It’s not our main language so we may experience some trouble redacting our texts.

10/02/2020

Whole Team

Design Architecture

As Solid is a W3C endorsed linked data personal data store (PODS) that puts control into the hands of the user, we’ll be using P2P (Peer to peer) design architecture. Also, we will be following MVC (model view controller) architectual pattern.

Already known code distribution.

17/02/2020

Whole Team

Code revision

Each pull request should be checked by at least 2 team members in order to avoid bugs.

It improves code quality.

It takes time to check every line of code.

24/02/2020

Whole Team

Fixing issues

We decided to open an issue for every task we needed to solve.

It’s a great way to keep track of our tasks.

We might forgot to open a new issue if the task itself is simple and can be solved quickly.

09/03/2020

Whole Team

Meetings

We decided to meet at least 2 times (maybe 3) a week to talk about our weekly work.

We ensure everyone is doing their work.

Finding valid schedules could be tough.

16/03/2020

Whole Team

Front End

We decided to use Material UI with React to be able to integrate a responsive design easily.

Simpler to create a fancy interface.

First time using it.

23/03/2020

Whole Team

Testing

We decided to use Jest/Pupeteer/Cucumber for testing our app.

It ensures a proper functionality.

We are not used to work with those type of tests.

23/03/2020

Whole Team

Map

We decided to use GPX as it’s the standart most routing apps use.

Our app could load routes from other apps.

Our app would not support any other map format.

30/03/2020

Whole Team

Template

We decided to use Inrupt’s generator to make an app template

Easy to start out project.

The template is kind of complex and it has a lot of frameworks included that we might not end up using.

14/04/2020

Whole Team

Template

We decided to use Inrupt’s generator to make an app template

Easy to start out project.

The template is kind of complex and it has a lot of frameworks included that we might not end up using.

29/04/2020

Whole Team

Material UI

We decided to swap to Material UI as it’s components are well known by users worldwide.

Good looking and adaptable components

Lack of time to implement it everywhere.

10. Quality Requirements

This section explains the quality requirements of our application using a quality tree and quality scenarios. Quality goals are explained in section 1.2.

10.1. Quality Tree

10.2. Quality Scenarios

Quality Attributes	Scenarios	Priority
1.- Security	Require each user to identify in order to use the application and let them full control about their own data	High, High
2.1.- Suitability	The application meet the requirements for a successful performance.	Medium, High
2.2.- Capacity	The application can hold a maximum of 100 users at the same time.	High, High
3.- Efficiency	Short times for work and save/load data. This takes less than 10 seconds.	Medium, High
4.- Usability	Easy-to-learn and satisfy user requirements and motivations	High, High
5.- Maintainable	Easy to improve the code and makes changes to it	High, Low
6.- Testability	Should pass unit & integration test without any problems	Medium, Low

Quality Attributes

Scenarios

Priority

1.- Security

Require each user to identify in order to use the application and let them full control about their own data

High, High

2.1.- Suitability

The application meet the requirements for a successful performance.

Medium, High

2.2.- Capacity

The application can hold a maximum of 100 users at the same time.

High, High

3.- Efficiency

Short times for work and save/load data. This takes less than 10 seconds.

Medium, High

4.- Usability

Easy-to-learn and satisfy user requirements and motivations

High, High

5.- Maintainable

Easy to improve the code and makes changes to it

High, Low

6.- Testability

Should pass unit & integration test without any problems

Medium, Low

11. Risks and Technical Debts

List of risks and thechnical debts we might face throughout the developing of the project.

11.1. Risks

Risks	Measures to minimize risks
Solid is a totally new concept to us, so it might take us some time to get used to it.	List of useful SOLID resources attached to the project for quick usage.
JavaScript is not our main programming language. Eventhough we used it in the past, it’s still hard to us to adapt to it as we only know the basics.	Another list as the one mentioned above.
React is the JS UI (User Interface) library established to develop this app. It’s the first time we are using this library and it can lead to having some mistakes.	Implement Material UI to ease this aspect, and investigate about other available libraries that might help the developing process.
Libraries might be used during the development of the app. As we do not own the code we might experience some trouble with the understanding of their use.	Avoid using templates or libraries if we don’t fully understand them.
Documentation should be written in Engish to ease it’s internationallity. As it’s not our main language we take the risk to explain something wrongly or not as nicely as we intend.	Verify the English text is properly written and it’s a good representation of what we intend to tell.
Problems with git workflow	Use subbranches and only pull request to main once it’s been all tested at develop.
Problems with git workflow	Use subbranches and only pull request to main once it’s been all tested at develop.

Risks

Measures to minimize risks

Solid is a totally new concept to us, so it might take us some time to get used to it.

List of useful SOLID resources attached to the project for quick usage.

JavaScript is not our main programming language. Eventhough we used it in the past, it’s still hard to us to adapt to it as we only know the basics.

Another list as the one mentioned above.

React is the JS UI (User Interface) library established to develop this app. It’s the first time we are using this library and it can lead to having some mistakes.

Implement Material UI to ease this aspect, and investigate about other available libraries that might help the developing process.

Libraries might be used during the development of the app. As we do not own the code we might experience some trouble with the understanding of their use.

Avoid using templates or libraries if we don’t fully understand them.

Documentation should be written in Engish to ease it’s internationallity. As it’s not our main language we take the risk to explain something wrongly or not as nicely as we intend.

Verify the English text is properly written and it’s a good representation of what we intend to tell.

Problems with git workflow

Use subbranches and only pull request to main once it’s been all tested at develop.

Problems with git workflow

Use subbranches and only pull request to main once it’s been all tested at develop.

11.2. Technical debts

Technical debt	Possible future solution
Security and condifentiality are a main concern at a decentralized app. Data should be encrypted in order to ensure these criteria and we are not experts at security just yet.	As it’s a complex task and we don’t know much about it yet, we’ll postpone it to a future version of the app.
Lack of time to complete the project, as we are pretty busy.	As this is an open source project, we can keep working on them once our assignment is done.
Undocumented code because of lack of time.	Do a basic singleline comment where necessary and explain main issues using GitHub issues and project documentation.
Code cleaning	Code might me refactored later on.
Performance	We improved our initial times but it could still be improved.
Interoperabillity	We should follow viadeSpec in order to load routes created by other teams.

Technical debt

Possible future solution

Security and condifentiality are a main concern at a decentralized app. Data should be encrypted in order to ensure these criteria and we are not experts at security just yet.

As it’s a complex task and we don’t know much about it yet, we’ll postpone it to a future version of the app.

Lack of time to complete the project, as we are pretty busy.

As this is an open source project, we can keep working on them once our assignment is done.

Undocumented code because of lack of time.

Do a basic singleline comment where necessary and explain main issues using GitHub issues and project documentation.

Code cleaning

Code might me refactored later on.

Performance

We improved our initial times but it could still be improved.

Interoperabillity

We should follow viadeSpec in order to load routes created by other teams.

12. Glossary

Term	Definition
SOLID	So cial Li nked D ata is a group of conventions and tools for building decentralized Web applications based on Linked Data principles.
Inrupt	The company that’s helping to fuel Solid’s success.
React	JavaScript library used to build user interfaces.
arc42	Documentation template used mainly in Europe. It’s divided into 12 sections that offer a simple and effective structure to document and communicate the project’s software system.
POD	P ersonal O nline D ata Stores, used to store data. The user owns the data stored here and gives permission to use it.
Git	Version control system used to keep track of different versions of the project and to improve teamwork.
Material UI	JavaScript framework that offers an Android look alike view.
MIT	Permissive free software license originating at the Massachusetts Institute of Technology

Term

Definition

SOLID

So cial Li nked D ata is a group of conventions and tools for building decentralized Web applications based on Linked Data principles.

Inrupt

The company that’s helping to fuel Solid’s success.

React

JavaScript library used to build user interfaces.

arc42

Documentation template used mainly in Europe. It’s divided into 12 sections that offer a simple and effective structure to document and communicate the project’s software system.

POD

P ersonal O nline D ata Stores, used to store data. The user owns the data stored here and gives permission to use it.

Git

Version control system used to keep track of different versions of the project and to improve teamwork.

Material UI

JavaScript framework that offers an Android look alike view.

MIT

Permissive free software license originating at the Massachusetts Institute of Technology

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