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 system, DeDe, is this year’s project for the course Software Architecture of the University of Oviedo. The development team, that is, the team EN1B is composed by the following students:

  • Alonso Ferreiro, Luis Miguel.

  • Álvarez Díaz, Daniel.

  • Cuesta Martínez, Miguel.

  • González Méndez, Jesús.

  • López Hernández, Sebastián.

And, of course, by the teacher:

  • Labra Gayo, Jose Emilio.

  • González, Pablo.

DeDe is an online retail system that preserves the privacy of the customers following the SOLID principles. This means that our Decentralized Delivery app will not store user data per se, but will acess, when permission is granted, the information located inside the user’s SOLID pod. This information will be used by our app to know the user’s address for delivery purposes.

1.1. Requirements Overview

The main point of creating DeDe is to develop a delivery application similar to those that already exist, but which does not store user data in the app’s database. Instead, user hosted SOLID pods will be used.

Functional Requirements

  • The system must emulate an online shopping system where end-users can select and order products to buy.

  • Once a user selects the products to buy:

    • The system will access the users address by requesting permision to access their POD.

    • The system will calculate the estimated delivery cost by calculating the distance from the reailer to the obtained user address.

  • The system will show the user the the final price of the products to buy.

  • Once an order has been placed, the system will simulate that the product has been bought and that it can proceed with the delivery.

  • The system will allow the users to visualize the orders done.

1.2. Quality Goals

Quality goal Scenario Priority


Privacy is our top priority when it comes to creating DeDe. This is due to the fact that all delivery systems nowadays store user information in their own databases, making it vulnerable to breaches or attacks. Meanwhile, DeDe will only access user information by means on their own hosted SOLID PODS, making it impossible to acces personal information through our app.



As DeDe is meant to be an app for everyone to use, usability is our second top priority. We want for everyone to be able to use this app without few previous knowledge, so we will put a lot of effort in making good usable user interfaces.



As in most applications nowadyas, security is a very important topic. That’s the reason we made it our top 3 priority. Even though no personal user data will be stored in our servers, we will still need to keep track of other data, like orders made. We also will be managing prices and money. These are the reasons we are planning to make our app very secure.


1.3. Stakeholders

Role/Name Contact Expectations

Development Team

These are the students of group EN1B. Their information can be found at the bottom of the README file.

They will be the ones in charge of documenting, developing and testing the application, among others.


These are the teachers. In particular, Jose Emilio Labra Gayo ( and Pablo González (

They will provide functional requirements as well as constraints.


This group will be composed by the development team, the teachers, students, and other.

They will be the final users of the application. Due to our scope, no real user will interact with our app, so these users will server as test dummies for our system.

SOLID Project

Solid is a specification that lets people store their data securely in decentralized data storages called Pods. (

The application will use the PODS, developed by the SOLID Project.


Inrupt is a company that helped craft Solid-based solutions in verticals such as healthcare, finance, telecommunications, government and media. (

Inrupt is one of the two companies that organize the SOLID challenge in which our app will be competing.


Empathy is a company that specializes in Commerce Search and Discovery platforms.

Empathy is the other compnay that organizes the SOLID challenge in which our app will be competing.

2. Project Constraints

In this section the different constraints that are present in the project are described.

2.1. Technical constraints

Constraint Details


The project will have to be compatible with the SOLID technology, as the only way of retrieving information will be the different user pods provided by the before mentioned technology.

React & Node

React must be the framework used to develop the project, that also implies the usage of Node.


Typescript will be the language in which the project is implemented, which is a superset of Javascript that adds static types and class based objects.

2.2. Organizational constraints

Constraint Details


The project must be implemented before the last lab session of the subject, on April the 5th 2022.

Developer team

The team is formed by 5 students of the ASW course.


It must be tested to make sure a certain quality degree is met. The testing process will include unit tests, acceptance tests and load tests.


The development monetary costs will be zero, as all members of the developing team are students of the course.

2.3. Convention constraints

Constraint Details


The documentation for the project will be done using the Arc42 templates, and it will use Asciidoctor for publishing purposes.

Version control

Git version control system will be used in the project through Github. The repository employed was initialized and provided by the teachers of the subject.

3. System Scope and Context

Here we define how the different components of DeDe interact with each other, as well as the technologies the application depends on.

3.1. Business Context

Communication Partner Input Output


The user will receive a response from the application (generally a solicited view) via the device the web is being consulted on.

The user will continuously provide input to the application. He is also the one responsible of creating and managing sensitive information in the Solid POD.


The application will receive requests to fulfill from the user, as well as data from both the POD and the MongoDB when required.

The web app will send responses to the user and requests for information to both the POD and Mongo Database. For solicitations to the POD, a login in Solid must be filled by the user. It’s integral to the architecture that the data from the POD and the one from MongoDB are handled separately as to not divulge any personal information.

Solid POD

The user will create the POD to manage his personal information in the app. The application itself, will request for the necessary sensitive data and should always ask for authentication from the user.

The POD will only send personal information to the application, after the appropiate login in Solid.


The database will accept requests from the application for any information stored (that is, the one we consider not to be personal or sensitive, like the set of products available).

The database will communicate with the application as a response. It will return information that is supposed to be known as public.

Shipping API

The API will accept requests from the application, avoiding interaction with the user as serving to mediate between him and the delivery is the main purpose of the application.

From the API, a response will ideally be given to DeDe when the order has been completed, although this behaviour can be considered optional as making the order is the end goal.

3.2. Technical Context

DeDe is a decentralized system that follows the architecture of the Solid Project. This means that users are the ones that own and manage the access to their sensitive information, and not the application itself. To handle this, each user will be the owner of a Solid POD (Personal Online Data Store) from which the required information is extracted if needed.

Although the personal data is handled by the PODs, DeDe will also store general information within MongoDB. The application is written in TypeScript, employing the React framework in combination with Material UI for a more polished appearance.

We identify the following technical interfaces:

Technical interface Description

Solid Project

Defines the handling of data, which will in turn determine the general structure of the project.


Personal Online Data Store, it contains sensitive information related to the user so that the provider (DeDe) has no direct access to it without given permission.


The web development language that will be employed to write our application.


Widespread framework in JavaScript and TypeScript that focuses on handling the views of the application and save time invested on interfaces.

4. Solution Strategy

4.1. Technology decisions

We have chosen to use the following technologies:

  • MongoDB: One of the most potent non-relational databases, which fits the decentralised data model of DeDe. We will use it to store the information that is general to the application so as to not fill the PODs with unnecessary and redundant information.

  • JSON: Exporting the information of the purchases for communication with API will be done with JSON, a flexible and powerful format of handling data that can also be converted easily to many others (such as n3 or turtle).

  • Shipping API: We will communicate with it to inform the deliverers of the chosen products and receive an estimate shipping price to show the user. It’s the single most important external service in our application.

  • Mongoose: We will employ the Mongoose library as the frame to communicate with the internal Mongo database. It is easily accesible with Node JS

  • Material UI: A library for web development that contains many predefined components. It will serve to ease work on HTML and CSS by providing default stylization and easy ways of handling customization from TypeScript. It is also highly compatible with React.

4.2. Decisions on top-level decomposition

ON development, the project will match MVC (Model-View-Controller). The separation of responsibilities in layers provides both easier especialization of each member during the development and a better way of treating the data model so that POD and MongoDB information does not intersect.

4.3. Decisions on quality goals

The primary concern, privacy, is already solved through the usage of the PODs (assuming of course the correct implementation of the access to them). The whole structure of the application is centered around preserving the integrity of the user’s data, so it’s not hard to affirm DeDe will have a high privacy value. Usability is also a major concern and so the application will be built as responsive and accesible as possible. The decentralization of data will also have positive consequences on the security of DeDe, and server-side validation will be provided to check for the legitimity of the user’s operations.

4.4. Organizational decisions

Apart from the periodic Tuesday reunion during the laboratories, a second one has been scheduled every Thursday at 18:00. Thanks to Microsoft Teams, it will be easy to get together and check the progress multiple times during the week. A WhatsApp group has also been created for a more swift communication on the kind of matters that must be resolved quickly or are too unimportant for the reunions.

The use of pull requests is our standard to solicit aproval from the team to add a new feature or improvement to the develop branch. This will also guarantee the quality of the code through the peer review process.

5. Building Block View

5.1. Level 1 - Overall System


5.2. Level 2 - DeDe Structure


6. Runtime View

6.1. User browses DeDe WebApp

  • When a user enters DeDe’s WebApp (s)he can browse through it. Several items are displayed organized following some policy, such as category (type of item). Such item will display an image and price.

User browses DeDe

6.2. User makes an order

  • For the purpose of making an order, the user should select some item(s). The cumulative price of the items in the order will be shown. (Users should be notified that delivery costs are not included yet). When the user decides to proceed with the ordering, a registration is made. The system gets the delivery address from the user’s own POD. The price is calculated using an API and taking into account the distance from the distribution center to that address. If the user decides to finish with the ordering, the registration is made and the order is done.

Runtimeview 2

6.3. User logs in

  • To log in, the user must access the login page, where they must choose a solid pod provider to authenticate with. Once authentication is complete, the provider will grant the web app the information requested. Thanks to this information, the user orders stored in the database will be retrieved. All this data will be shown to the user by means of the user page.

Runtimeview 3

7. Deployment View

7.1. Infrastructure Level 1


Our software would be nothing without a hardware to run it on and, of course, it will affect greatly the way our application behaves and performs under several different situations. Our goal is to have a correct understanding of the infraestructure over wich our system will be deployed.

Quality and/or Performance Features

As we have stated before, privacy and security will be our main concerns. Having a good infraestructure and servers backing up our app, will be a crucial part for us to achieve this goals. Performance is also a thing to look after, but DeDe being a Web App, this will depend mostly on the server in which it runs, as well ass the users own internet connection.

Mapping of Building Blocks to Infrastructure

Building Block

Mapping to Infraestructure


This is the brains of our shop, It’s job is to retrieve the products, save the orders, store de reviews…​ etc . It will run inside a docker container, which will be automatically deployed in an Azure server.The server will count with 1 cpu and 2GB of RAM, in a real world, a more powerfull server should be use, but for this example is more than enought.


This is the user end of the application. It will be rendered by a web browser, which will be executed over the users personal computer or smart device, like phones, tablets…​


These are the users Pods, where their address will be stored. They will be served by the SOLID project, and hosted in a server of the user’s election.


This is the DataBase, which will be stored on a server as well. It’s has been deployed in an Oracle server.


This API will be used to calculate routes and costs of delivery. As there are no free APIs for this kind of demostration, we are using our own api simulating the prices.

7.2. Process of chossing a provider

As we are students, we searched for the cheapest provider to run our application. The first one we tried, Oracle, has a free tier for students which includes 2 virtual machines with 1 cpu and 1 GB of RAM without time limt. We deployed our database there and had no issues with performance, but when we tried to deploy our application, the server struggled to run everything smoothly so we looked for an alternative. We found that Microsoft Azures has also a student program which gives us 100$ credit for its services, so we used it to rent a vm with 1 cpu and 2GB of RAM. We kept the database in the oracle server and use the azure one to deploy our application.

To use other Solid providers, it is necesary to have the web encrypted with https because connections from https to http are not allowed for security reasons. To have HTTPS on our web, we used Caddy to configure a proxy server, and registered a free domain name with freenom. Caddy is in charge to serve the content in localhost:3000 to the requests coming from encrypting it first using a SSL certificate from The same thing is done for to serve the api.

With this setup, we have now a complete infrastructure for our application.

7.3. Continuous Integration

Both the WebApp and the RestApi are automatically deployed using GitHub Actions. Every time a new realese is made, a script, located in .github/workflows/asw2122.yml, will be executed. This script first runs the tests, and if they all pass succesfully, the docker images will be build and publish to GitHub Packages. Finally, the scripts connect through SSH to the server and deploys the application using Docker-Compose. As tokens, server IPs and other information must be private, we are using GitHub Secrets to store it.

8. Cross-cutting Concepts

8.1. Domain model

  • User, will use the unique id of the user’s pod, which will provide us the different addresses that the user has available. As well as the role assigned to the user.

We will store store the user in our non-relational database, provided by mongoDB.

8.2. Design patterns

The MVC pattern is the one that will be used to start coding our project, as it is one of the best ways for accessing the SOLID pods using REACT.

Routes for accessing every action will exist, and a model defining the database schema will be defined.

8.3. Security

Protocol HTTPS will be used to ensure the user’s secure access, and validation constraints will be present to avoid undesired access.

SOLID pods also provide a mean of security, as each user is the only owner of his/her private information stored in a decentralised way.

8.4. Technical decisions

An independent login was used to access the administrator page, we considered this decision a mean of improving security on that specific feature, as there will be only one administrator and we don’t want to depend on external providers for performing any of its responsabilities.

8.5. Internationalization

The project will be a multi-language application since the beginning of the design, to save expensive future costs in implementing this functionality.

Unfortunately, due to time constraints, the interationalization of the app could not be implemented. DedEx remains a single language application for the moment, written entirely en English.

8.6. Notifications

A notification system will be implemented, in which a user gets a notification that provides relevant information to keep track of the product, such as whether that product has arrived or not.

On the same trend as with internazionalization, time would not let us implement this optional feature. Both these things are now pending to create in next sprints.

9. Design Decisions

9.1. Web Application

We decided to create a Web application supported by the latest versions of the main market browsers (Chrome, Firefox, Edge…​). This online version of DeDe could be ported to a mobile device app easily with REACT Native, a JavaScript framework for writing real, natively rendering mobile applications for iOS and Android.

Because we are choosing to develop a web app from the beggining, we must take careful consideration into making components mobile friendly. This should not be done, it would prove a struggle to adapt in the future.

9.2. Database

We chose MongoDB as our Database Management System because its flexible schema allows us to rapidly model the domain and change it with the evolution of the app without any problems. MongoDB stores data in form of JSON so the conversion and interaction between typescript and the database are flawless. Another point in favor is its performance and scalability although in a small application like ours is not strictly necessary. We also chose MongoDB because it gives us a free database in the cloud for developing purposes.

By discarding the use of an SQL database, we are also losing the opportunity to wotk with an schema, and thus, all data validation responsibility falls in the hands of the developers, that is, us. This may prove trying at times, but it is also good to learn new technologies.

9.3. Material UI

Material UI is a free React-compatible library directed at easy creation of responsive components. It contains many default styles for typography, forms, buttons, navigation, and other interface components. It will allow us to create a good frontend with less effort.

We descarded the use of Bootstrap because we felt that Material was more attuned to what we were trying to do with this reactive app. By doing so, we made a lot of design decision fall in the developers hands, making it more customizable but also more diffcult and time consuming to create.

10. Quality Requirements

The most important Quality Requirements have already been described in section 1.2. (Quality Goals). Nevertheless, we will see them again next to each corresponding quality scenario and mapped in the Quality Tree.

10.1. Quality Tree

QA tree

10.2. Quality Scenarios

Quality attribute QA scenario Priority


DeDe must not keep private information of its users, just the bare minimum, using mainly each user’s SOLID POD for the necessary things.



Every type of user should be able to make use of DeDe. It should be easy to work with, intuitive, and as accesible as possible. DeDe should also be adaptable to the main platforms used now a days (PC and portable devices).



DeDe should take into account the triple A concept: Authentication, Authorization, Accounting. Special care with the contents shown to each user. Data must never be given to any third party.



The system should be robust enough so that the most common errors won’t make it collapse for extended periods of time. That is, every type of possible exception should be properly handled. As it is a product for a retail company, we must ensure good behaviour and service to its final clients.



The system should work as supposed to with response times under 0.5 - 1 seconds on most of its operations. Any user should be able to make their own purchases with no major problems and without having noticeable delays on response times.


11. Risks and Technical Debts

11.1. Risks

Risk Explanation


The development team, that is, us, must comply with the deadlines imposed by the course.


Software requiring a subscription as well as servers or DBMSs are no go to the developers.

11.2. Technical Debts

Technical debt Explanation

Lack of knowledge of REACT

It will be the first time any member of the team uses REACT framework, so some time must be spent learning it, slowing down the development.


Even though we have some experience with JavaScript, we have never used Typescript, hence there will be a period of adaptation.


MongoDB has a non relational scheme, which means that data validation and integrity must be taken into account solely by the developpers.

12. Glossary

Term Definition


Decentralized Delivery, the name of our app.


An integrated suite of cloud database and data services to accelerate and simplify how you build with data.

Quality attribute

Architecture characteristic. Non-functional requirement.

Quality scenario

Describes a stimulus of the system and a measurable response to the stimulus. i.e: 20 concurrent users and response time of less than 1s.


Solid is a specification that lets people store their data securely in decentralized data stores called Pods. Pods are like secure personal web servers for data. When data is stored in someone’s Pod, they control which people and applications can access it.

13. Testing

Different testing methods were used to check the correct functioning and implementation of the project.

13.1. Unitary Tests

We made use of Jest and React testing library. We tried to take into account several tips and good-practises for testing by Kent C Dodds, creator of the react testing library. He has several blogs and videos for teaching React in action.

Unitary testing had difficulty in the sense that there should not be any dependencies and if they do, they must be mocked for the test.

We needed to verify that isolated parts of DeDe worked as expected and in some cases it got really hard.

The general strategy used was, in some cases, to put a data-testid in the components we wanted to fetch, or query them by text criteria.

When the component relied on asynchronous API calls, we mocked their implementation and used functions like waitFor() or waitForElementToBeRemoved(), in order to wait for the end of execution of those functions.

In other cases we had to wrap elements inside others such as MemoryRouter or ReactNotifications before rendering them with the goal of mounting them properly.

In the end, we have 40 test distributed in 19 suites. We tested the following scenarios:

  • OrderAdminCard component

    1. Check that it is rendered properly with a product.

  • AdminLogin component

    1. Check that it is rendered properly.

    2. Check that when signing-in it calls the API as expected.

  • OrderAdminDetails component

    1. Check that it is rendered properly.

  • CartItem component

    1. Check that it is rendered correctly.

    2. Check that quantity can be modified.

  • ShoppingCart component

    1. Check that it is rendered correctly when cart is empty.

    2. Check that it is rendered correctly when it has some products.

    3. Check that it can have its products deleted calling the corresponding API function.

  • CheckoutItem component

    1. Check that it is rendered correctly with a product.

  • Checkout component

    1. Check that it is rendered correctly with multiple products.

    2. Check that is rendered with the proper information and does not let user go to shipping if the cart is empty.

  • Main Products component

    1. Filter is rendered properly.

    2. When listing products, the proper function is called and correct products are rendered.

    3. When listing products, using filter by color works as expected calling the proper function with corresponding parameters.

    4. When listing products, using filter by brand works as expected.

    5. When listing products, using filter by rating works a expected.

  • Product Card component

    1. Check that is rendered correctly

    2. Check that it handles adding

  • Product Page component

    1. Check that it is rendered correctly when the product with given ID exists and it has reviews.

    2. Check that it is rendered correctly when the product with given ID does not exist.

    3. Check that it is rendered correctly when it has no reviews.

  • Review view component

    1. Check that it is rendered correctly

  • Fragments components (NavBar, Footer, AboutUs, DeveloperCards)

    1. Check that it is rendered correctly. (One test per fragment)

  • Address Form

    1. Check alert is shown when an address field is missing

13.2. Integration Tests

We used Jest and Cucumber to perform integration testing in our app. Thanks to cucumber, we could design integration tests following the famous syntax "Given, When, Then". This allowed for better understandability of the code as well as easier debugging.

We divided the 8 tests in 5 different suites, who aggregate similar tests. For each on of them, these were the features tested:

  • Add Address:

Feature: Adding/Changing DedEx Address

Scenario: Adding an address

  • Given A loged in user

  • When They change their address in their profile

  • Then It appears on the shipping page

  • Add to Cart:

Feature: Adding items to the cart

Scenario: Adding one item

  • Given A user

  • When They add an item to the cart and navigate to the cart

  • Then They can see the item

Scenario: Adding an item from product details view

  • Given A user

  • When They add an item to the cart from the details view of the product and navigate to the cart

  • Then They can see the item

  • Buy item:

Feature: Buying products

Scenario: Buying a product

  • Given A user with an item in his cart

  • When They buy it

  • Then The order appears in their profile

  • Product Visualization:

Feature: Visualizing products

Scenario: Main Products view

  • Given An user

  • When They enter the application

  • Then Several Prodcut cards must be shown

Scenario: Product detail view

  • Given An user

  • When They enter the application and click on a product card

  • Then The details view of the selected product must be shown

  • SOLID Login:

Feature: Registering or logging in a new user

Scenario: The user is not registered in the site

  • Given An unregistered user

  • When They press the profile button and log in with their preferred SOLID provider

  • Then Their name should be shown

Scenario: The user is registered in the site

  • Given A registered user

  • When They press the profile button and log in with their preferred SOLID provider

  • Then Their name and orders, if any, should be shown

The result of running these test is as follows:


13.3. Load Tests

Gatling tool was used to perform load tests to the application. Using its recorder functionality we were able to capture a fixed number of requests and reproduce their functionality for every user that was simulated by the program.

Those requests included the use of filters, adding products to the cart, modifying their quantities and perform checkout functionality.

The recorder tool acts as a man-in-the-middle to capture the traffic and requests made, we had to modify the proxy configuration in our browsers for the tool to do the before-mentioned actions properly, losing internet connection meanwhile.

This internet loss made it impossible for us to load test the SOLID login and, as a consequence, the order creation.

An Open Model for user injection was the one used because you control the arrival rate of users, and the concurrent number of users in our web is not capped. We used this injection setup.


An approximate number of 18k requests were made during the test in which 10% of those had a response time between 800ms and 1200ms, and just 1% had a response time above the latter.


During the test there was a peak of 196 concurrent users.


Observing the percentile response time chart generated we can know where in the execution of the recording the requests consume more time and its different distributions. The requests that consume more time in this test would be filter usage, and quantity modification in the shopping cart.


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

© We acknowledge that this document uses material from the arc 42 architecture template, Created by Dr. Peter Hruschka & Dr. Gernot Starke.