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

Describes the relevant requirements and the driving forces that software architects and development team must consider. These include

  • underlying business goals, essential features and functional requirements for the system

  • quality goals for the architecture

  • relevant stakeholders and their expectations

  • LoMap is a decentralized web application where citizens will be able to check personalized maps filled with their city’s places and shops.

  • Our goal is to provide Brussels' citizens the most useful and secure application to keep and share their favourites places such as restaurants, shops, monuments and more.

  • We have also the objective of creating a general software solution for every city around the world that could need our app.

1.1. Requirements Overview

Contents

Short description of the functional requirements, driving forces, extract (or abstract) of requirements. Link to (hopefully existing) requirements documents (with version number and information where to find it).

Motivation

From the point of view of the end users a system is created or modified to improve support of a business activity and/or improve the quality.

Form

Short textual description, probably in tabular use-case format. If requirements documents exist this overview should refer to these documents.

Keep these excerpts as short as possible. Balance readability of this document with potential redundancy w.r.t to requirements documents.

Table 1. High level requirements
Name Description

Adding places on different tabs

Users can add different kinds of places (shops, restaurants, monuments, landscapes…​)

Map visualization

Users can see places on a map

Reviews

Users can add punctuations, comments, photos and more to added places

Privacy

A user can customize the way of sharing information with other users

Decentralized information

Each user has a unique pod for its personal information

Social interaction

A user can see other user’s places and reviews

App options available

There are filters for categories, friends and more
Table 2. Extra requirements
Name Description

User roles

There will be roles: citizien, clothing shop, restaurant, bar…​

1.2. Quality Goals

Contents

The top three (max five) quality goals for the architecture whose fulfillment is of highest importance to the major stakeholders. We really mean quality goals for the architecture. Don’t confuse them with project goals. They are not necessarily identical.

Motivation

You should know the quality goals of your most important stakeholders, since they will influence fundamental architectural decisions. Make sure to be very concrete about these qualities, avoid buzzwords. If you as an architect do not know how the quality of your work will be judged …

Form

A table with quality goals and concrete scenarios, ordered by priorities

Name Description

Privacy

User information will be on its personal pod (information will be decentralized)

Integrity

The app will check that the stored data is valid and ensures that the information lasts

Usability

All users will use the app without any problem. The app will be intuitive and easy to use

Accesibility

The app can be used with any device (mobile, laptop, tablet or pc)

Security

Real-time-location is only available if the user enables it. LoMap will store the minimum required info of the user

1.3. Stakeholders

Contents

Explicit overview of stakeholders of the system, i.e. all person, roles or organizations that

  • should know the architecture

  • have to be convinced of the architecture

  • have to work with the architecture or with code

  • need the documentation of the architecture for their work

  • have to come up with decisions about the system or its development

Motivation

You should know all parties involved in development of the system or affected by the system. Otherwise, you may get nasty surprises later in the development process. These stakeholders determine the extent and the level of detail of your work and its results.

Form

Table with role names, person names, and their expectations with respect to the architecture and its documentation.

Role/Name Contact Expectations

Inrupt

info@inrupt.com

Make decentralized SOLID based technologies more visible for the public through this app

Eduardo Blanco Bielsa

uo285176@uniovi.es

Build a secure and decentralized app, hone teamwork and try to get the scolarship offered by SOLID team

Jonathan Arias Busto

uo283586@uniovi.es

Learn new skills and learn how to work as a team on big projects

Fernando José González Sierra

uo277938@uniovi.es

Learn new frontend skills and build a nice app

Chen Xin Pan Wang

uo276967@uniovi.es

Learn some new technologies and work in a good team

Cristian Augusto

augustocristian@uniovi.es

A full functional and decentralized app

Irene Cid

cidirene@uniovi.es

A full functional and decentralized app

2. Architecture Constraints

Contents

Any requirement that constrains software architects in their freedom of design and implementation decisions or decision about the development process. These constraints sometimes go beyond individual systems and are valid for whole organizations and companies.

Motivation

Architects should know exactly where they are free in their design decisions and where they must adhere to constraints. Constraints must always be dealt with; they may be negotiable, though.

Form

Simple tables of constraints with explanations. If needed you can subdivide them into technical constraints, organizational and political constraints and conventions (e.g. programming or versioning guidelines, documentation or naming conventions)

2.1. Technical constraints

Name Description

React

We will use React framework to develop the frontend of the application.

JavaScript

It will be used on the frontend but also on the backend to work with SOLID pods.

Bootstrap

We will use Bootstrap to make a responsive interface.

SOLID

We will use SOLID to store users information using PODs, giving this data more privacy. This is a requirement.

GitHub

We will use GitHub to update the changes of the source code.

Docker + Netlify

We will deploy our application using Netlify.

2.2. Convention

Name Description

Language

We will work with English as our main language. All commits, pull request, issues, code documentation, etc will be written in English.

Code documentation

All the code should have its documentation.

Project documentation

We will use Arc42 template to write the documentation.

2.3. Organizational constraints

Name Description

Meetings

We will assemble every week on the laboraty class to decide the following steps to develop the application. If necessary, extra meetings will be made.

Time

This large project can lead to time issues as we need to learn a lot of new technologies. Also we have more subjects to attend to.

3. System Scope and Context

Contents

System scope and context - as the name suggests - delimits your system (i.e. your scope) from all its communication partners (neighboring systems and users, i.e. the context of your system). It thereby specifies the external interfaces.

If necessary, differentiate the business context (domain specific inputs and outputs) from the technical context (channels, protocols, hardware).

Motivation

The domain interfaces and technical interfaces to communication partners are among your system’s most critical aspects. Make sure that you completely understand them.

Form

Various options:

  • Context diagrams

  • Lists of communication partners and their interfaces.

3.1. Business Context

Contents

Specification of all communication partners (users, IT-systems, …​) with explanations of domain specific inputs and outputs or interfaces. Optionally you can add domain specific formats or communication protocols.

Motivation

All stakeholders should understand which data are exchanged with the environment of the system.

Form

All kinds of diagrams that show the system as a black box and specify the domain interfaces to communication partners.

Alternatively (or additionally) you can use a table. The title of the table is the name of your system, the three columns contain the name of the communication partner, the inputs, and the outputs.

LOmap BUsiness

Entity

Description

User

Interacts with the application front-end and sends requests to the backend.

POD

Stores user’s private information. In case the user is not registered it creates a new POD.

System

It is responsible for making the application work.

API

We are using OpenStreet Maps to visualize the locations.

3.2. Technical Context

Contents

Technical interfaces (channels and transmission media) linking your system to its environment. In addition a mapping of domain specific input/output to the channels, i.e. an explanation with I/O uses which channel.

Motivation

Many stakeholders make architectural decision based on the technical interfaces between the system and its context. Especially infrastructure or hardware designers decide these technical interfaces.

Form

E.g. UML deployment diagram describing channels to neighboring systems, together with a mapping table showing the relationships between channels and input/output.

Technical

Technology

Description

REACT

We use it to develop the frontend of the application

SOLID

We use SOLID PODs to store users information

JavaScript

Principal language for our code application

CSS

Language to set different styles and positions to our components.

Docker

Used for the system deployment

Netlify

Used for the system deployment

Bootstrap

Simplifies the use of CSS and HTML, using the HTLM5 standards.

We use OpenStreet Maps as the main API for the project to visualize the maps.

4. Solution Strategy

Contents

A short summary and explanation of the fundamental decisions and solution strategies, that shape the system’s architecture. These include

  • technology decisions

  • decisions about the top-level decomposition of the system, e.g. usage of an architectural pattern or design pattern

  • decisions on how to achieve key quality goals

  • relevant organizational decisions, e.g. selecting a development process or delegating certain tasks to third parties.

Motivation

These decisions form the cornerstones for your architecture. They are the basis for many other detailed decisions or implementation rules.

Form

Keep the explanation of these key decisions short.

Motivate what you have decided and why you decided that way, based upon your problem statement, the quality goals and key constraints. Refer to details in the following sections.

We have chosen to use the next technologies on the app:

  • React: is a Javascript library focused on developing user interfaces so we decided to use it because of its big documentation and easy learning. It is also a solid base for creating apps with Javascript.

  • SOLID: is an acronym that refers to five good and essential principles for the design of a software architecture (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation and Dependency Inversion). With this principles the user knows that all his "sensitive data" is safe and decentralized. We use it because it is required on the project.

  • Javascript: is an interpreted programming language based on prototypes, imperative and dynamic. We will use it on both frontend and backend.

  • CSS: is a graphic programming language oriented to define the repesentation of a document. We will use it as part of the frontend of the app.

  • Docker: is a software platform that allows to create, try and implement new apps easily and fast. We will use it for the fast deployment of our web application.

  • Netlify: is a cloud server provider which we will use to deploy our app. It is also free (for our specific case) and it’s one of the fastest options for deploying the app.

  • Github: is a version management system where all the code will be stored, structured and modified.

  • Bootstrap: is a framework that provides a collection of tools to simplify the use of html and css in the application.

4.1. Why this technologies?

  • React, CSS and Javascript were chosen to reach a good level of usability and accesibility.

  • Github was chosen for version control and organization and communication between the team.

  • Bootstrap was chosen because the facilities it provides and to have a nice, clean and responsive view to the web app.

  • Netlify was chosen because of its deployment, which it’s very easy and it automaticaly builds when updating the app.

5. Building Block View

Content

The building block view shows the static decomposition of the system into building blocks (modules, components, subsystems, classes, interfaces, packages, libraries, frameworks, layers, partitions, tiers, functions, macros, operations, datas structures, …​) as well as their dependencies (relationships, associations, …​)

This view is mandatory for every architecture documentation. In analogy to a house this is the floor plan.

Motivation

Maintain an overview of your source code by making its structure understandable through abstraction.

This allows you to communicate with your stakeholder on an abstract level without disclosing implementation details.

Form

The building block view is a hierarchical collection of black boxes and white boxes (see figure below) and their descriptions.

Hierarchy of building blocks

Level 1 is the white box description of the overall system together with black box descriptions of all contained building blocks.

Level 2 zooms into some building blocks of level 1. Thus it contains the white box description of selected building blocks of level 1, together with black box descriptions of their internal building blocks.

Level 3 zooms into selected building blocks of level 2, and so on.

5.1. Whitebox Overall System - Level 1

Here you describe the decomposition of the overall system using the following white box template. It contains

  • an overview diagram

  • a motivation for the decomposition

  • black box descriptions of the contained building blocks. For these we offer you alternatives:

    • use one table for a short and pragmatic overview of all contained building blocks and their interfaces

    • use a list of black box descriptions of the building blocks according to the black box template (see below). Depending on your choice of tool this list could be sub-chapters (in text files), sub-pages (in a Wiki) or nested elements (in a modeling tool).

  • (optional:) important interfaces, that are not explained in the black box templates of a building block, but are very important for understanding the white box. Since there are so many ways to specify interfaces why do not provide a specific template for them. In the worst case you have to specify and describe syntax, semantics, protocols, error handling, restrictions, versions, qualities, necessary compatibilities and many things more. In the best case you will get away with examples or simple signatures.

Here, the app is represented as a whitebox. Inside of it we can see the component-based architecture in black boxes:

Here you describe <black box 1> according the the following black box template:

  • Purpose/Responsibility

  • Interface(s), when they are not extracted as separate paragraphs. This interfaces may include qualities and performance characteristics.

  • (Optional) Quality-/Performance characteristics of the black box, e.g.availability, run time behavior, …​.

  • (Optional) directory/file location

  • (Optional) Fulfilled requirements (if you need traceability to requirements).

  • (Optional) Open issues/problems/risks

Whitebox Overall System

5.1.1. Black Box descriptions of Overall System

Name

Responsability

Utils

Stores/gets data from personal pods, images…​ Gives information to the component.

Store

Stores/gets the context of the user to the correct functionality of the component.

Components

Is the final view of the application and interacts with the final user, self managed.

5.2. Building block view - Level 2

Here you can specify the inner structure of (some) building blocks from level 1 as white boxes.

You have to decide which building blocks of your system are important enough to justify such a detailed description. Please prefer relevance over completeness. Specify important, surprising, risky, complex or volatile building blocks. Leave out normal, simple, boring or standardized parts of your system

building block view

6. Runtime View

Contents

The runtime view describes concrete behavior and interactions of the system’s building blocks in form of scenarios from the following areas:

  • important use cases or features: how do building blocks execute them?

  • interactions at critical external interfaces: how do building blocks cooperate with users and neighboring systems?

  • operation and administration: launch, start-up, stop

  • error and exception scenarios

Remark: The main criterion for the choice of possible scenarios (sequences, workflows) is their architectural relevance. It is not important to describe a large number of scenarios. You should rather document a representative selection.

Motivation

You should understand how (instances of) building blocks of your system perform their job and communicate at runtime. You will mainly capture scenarios in your documentation to communicate your architecture to stakeholders that are less willing or able to read and understand the static models (building block view, deployment view).

Form

There are many notations for describing scenarios, e.g.

  • numbered list of steps (in natural language)

  • activity diagrams or flow charts

  • sequence diagrams

  • BPMN or EPCs (event process chains)

  • state machines

  • …​

6.1. Register User

register diagram

6.2. User Login Pod

login diagram

6.3. Visualize map

Map diagram

6.4. Friends list

Friends list diagram

6.5. Add places to map

Add places diagram

6.6. Reviews

Reviews diagram

6.7. Filter map

filter map diagram

7. Deployment View

Content

The deployment view describes:

  1. the technical infrastructure used to execute your system, with infrastructure elements like geographical locations, environments, computers, processors, channels and net topologies as well as other infrastructure elements and

  2. the mapping of (software) building blocks to that infrastructure elements.

Often systems are executed in different environments, e.g. development environment, test environment, production environment. In such cases you should document all relevant environments.

Especially document the deployment view when your software is executed as distributed system with more then one computer, processor, server or container or when you design and construct your own hardware processors and chips.

From a software perspective it is sufficient to capture those elements of the infrastructure that are needed to show the deployment of your building blocks. Hardware architects can go beyond that and describe the infrastructure to any level of detail they need to capture.

Motivation

Software does not run without hardware. This underlying infrastructure can and will influence your system and/or some cross-cutting concepts. Therefore, you need to know the infrastructure.

Form

Maybe the highest level deployment diagram is already contained in section 3.2. as technical context with your own infrastructure as ONE black box. In this section you will zoom into this black box using additional deployment diagrams:

  • UML offers deployment diagrams to express that view. Use it, probably with nested diagrams, when your infrastructure is more complex.

  • When your (hardware) stakeholders prefer other kinds of diagrams rather than the deployment diagram, let them use any kind that is able to show nodes and channels of the infrastructure.

7.1. Infrastructure Level 1

Describe (usually in a combination of diagrams, tables, and text):

  • the distribution of your system to multiple locations, environments, computers, processors, .. as well as the physical connections between them

  • important justification or motivation for this deployment structure

  • Quality and/or performance features of the infrastructure

  • the mapping of software artifacts to elements of the infrastructure

For multiple environments or alternative deployments please copy that section of arc42 for all relevant environments.

Motivation

This diagram helps us to visualise which components we will use and their dependencies.

Quality and/or Performance Features

High performance as we operate directly.

Mapping of Building Blocks to Infrastructure

arc42

7.2. Infrastructure Level 2

Here you can include the internal structure of (some) infrastructure elements from level 1.

Please copy the structure from level 1 for each selected element.

Motivation

This diagram allow us to have a more exhaustive vision about how the deployment on every deployment service using Docker and also the deployment on Netlify.

Quality and/or Performance Features

We are going to use Netlify to deploy the application, working as a remote server. We will use Docker to in case it’s wanted to deploy on other services.

Mapping of Building Blocks to Infrastructure

arc42

8. Cross-cutting Concepts

Content

This section describes overall, principal regulations and solution ideas that are relevant in multiple parts (= cross-cutting) of your system. Such concepts are often related to multiple building blocks. They can include many different topics, such as

  • domain models

  • architecture patterns or design patterns

  • rules for using specific technology

  • principal, often technical decisions of overall decisions

  • implementation rules

Motivation

Concepts form the basis for conceptual integrity (consistency, homogeneity) of the architecture. Thus, they are an important contribution to achieve inner qualities of your system.

Some of these concepts cannot be assigned to individual building blocks (e.g. security or safety). This is the place in the template that we provided for a cohesive specification of such concepts.

Form

The form can be varied:

  • concept papers with any kind of structure

  • cross-cutting model excerpts or scenarios using notations of the architecture views

  • sample implementations, especially for technical concepts

  • reference to typical usage of standard frameworks (e.g. using Hibernate for object/relational mapping)

Structure

A potential (but not mandatory) structure for this section could be:

  • Domain concepts

  • User Experience concepts (UX)

  • Safety and security concepts

  • Architecture and design patterns

  • "Under-the-hood"

  • development concepts

  • operational concepts

Note: it might be difficult to assign individual concepts to one specific topic on this list.

Possible topics for crosscutting concepts

8.1. Domain model

Name

Description

POD

User information.

User

User who uses the application. Can be friend with other users.

Comment

A comment made by a user related to a place.

Score

A score submitted by a user related to a place.

Photo

A photo upload by a user related to a place.

Place

A location in the map that is static over time.
modeloDominio

8.2. User Interface

Prototype version:

ux1.0 Main

9. Design Decisions

Contents

Important, expensive, large scale or risky architecture decisions including rationals. With "decisions" we mean selecting one alternative based on given criteria.

Please use your judgement to decide whether an architectural decision should be documented here in this central section or whether you better document it locally (e.g. within the white box template of one building block).

Avoid redundancy. Refer to section 4, where you already captured the most important decisions of your architecture.

Motivation

Stakeholders of your system should be able to comprehend and retrace your decisions.

Form

Various options:

  • List or table, ordered by importance and consequences or:

  • more detailed in form of separate sections per decision

  • ADR (architecture decision record) for every important decision

Decision

Details

Advantages

Disadvantages

Architecture

We will use component-based architecture (CBA) as the architecture design.

We will have a very well structured code separarated by components.

The separation in components makes the application complicated.

OpenStreetMaps API

We will use the API to create the map.

It’s free, not like the Google Maps API.

It’s the first time using it, we’ll have to adapt.

Netlify

We use them to deploy the application.

It’s free and it provides a very fast deployment.

The general cloud computing issues as backup protection.

CSS+Bootstrap

We use it to add a nice look to the application.

It’s a well known stylesheet languaje for the team, responsive.

Different browsers work different, we have to take care of it.

10. Quality Requirements

Content

This section contains all quality requirements as quality tree with scenarios. The most important ones have already been described in section 1.2. (quality goals)

Here you can also capture quality requirements with lesser priority, which will not create high risks when they are not fully achieved.

Motivation

Since quality requirements will have a lot of influence on architectural decisions you should know for every stakeholder what is really important to them, concrete and measurable.

10.1. Quality Tree

Content

The quality tree (as defined in ATAM – Architecture Tradeoff Analysis Method) with quality/evaluation scenarios as leafs.

Motivation

The tree structure with priorities provides an overview for a sometimes large number of quality requirements.

Form

The quality tree is a high-level overview of the quality goals and requirements:

  • tree-like refinement of the term "quality". Use "quality" or "usefulness" as a root

  • a mind map with quality categories as main branches

In any case the tree should include links to the scenarios of the following section.

Quality Tree

10.2. Quality Scenarios

Contents

Concretization of (sometimes vague or implicit) quality requirements using (quality) scenarios.

These scenarios describe what should happen when a stimulus arrives at the system.

For architects, two kinds of scenarios are important:

  • Usage scenarios (also called application scenarios or use case scenarios) describe the system’s runtime reaction to a certain stimulus. This also includes scenarios that describe the system’s efficiency or performance. Example: The system reacts to a user’s request within one second.

  • Change scenarios describe a modification of the system or of its immediate environment. Example: Additional functionality is implemented or requirements for a quality attribute change.

Motivation

Scenarios make quality requirements concrete and allow to more easily measure or decide whether they are fulfilled.

Especially when you want to assess your architecture using methods like ATAM you need to describe your quality goals (from section 1.2) more precisely down to a level of scenarios that can be discussed and evaluated.

Form

Tabular or free form text.

Quality

Scenario

User Priority (App success)

Developer Priority (Difficulty to achieve)

Privacy

A user who wants to access their friend list. Because we are using SOLID, this information will be stored in its personal POD, only the user can access to this info.

HIGH

MEDIUM

Integrity

When an update releases, the information stored will still be there and valid.

LOW

HIGH

Usability

A user want to add a new point on the map. There will be an easy way to do it that is intuitive to users

HIGH

LOW

Accesibility

A user who want to access with their phone. The application will adapt so they can use it on multiple platforms

HIGH

MEDIUM

Security

If a user wants to make a point on the map with their current location, a message will be shown to ask for permision to use their location.

HIGH

HIGH

11. Risks and Technical Debts

Contents

A list of identified technical risks or technical debts, ordered by priority

Motivation

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

This should be your motto for systematic detection and evaluation of risks and technical debts in the architecture, which will be needed by management stakeholders (e.g. project managers, product owners) as part of the overall risk analysis and measurement planning.

Form

List of risks and/or technical debts, probably including suggested measures to minimize, mitigate or avoid risks or reduce technical debts.

11.1. Risks

This is a list of identified technical risks, ordered by priority (1 is the highest priority).

  1. Not knowing some of the technologies that we decided to use in this application. Such as SOLID (and PODs), REACT, AWS, OpenStreet Maps API or Docker. Some of us haven’t worked with web applications either.

    • In order to avoid this risk or minimize its damage, we will have to learn how to use this technologies, having to spend some time to do it.

  2. Due to having other projects and exams from other subjects, we will have limited time to work on this project that can lead to errors for rushing the project.

    • In order to avoid this risk or minimize its damage, we will have to plan well how we are going to do this project.

  3. A member of the group could leave it or drop the subject, having to work the same with less members.

    • In order to avoid this risk or minimize its damage, we will have to quickly restructure the assignments to each member so the project can continue. We must avoid the bus factor.

  4. Some of the members of the group didn’t know each other before the project, this could lead to misunderstandings because we are not close enough to voice our concerns or ideas.

    • In order to avoid this risk or minimize its damage, we will have to be open to the other team members, always consider their ideas and help each other if someone doesn’t understand something.

11.2. Technical Debt

This is a list of identified technical debts, ordered by priority (1 is the highest priority).

12. Glossary

Contents

The most important domain and technical terms that your stakeholders use when discussing the system.

You can also see the glossary as source for translations if you work in multi-language teams.

Motivation

You should clearly define your terms, so that all stakeholders

  • have an identical understanding of these terms

  • do not use synonyms and homonyms

Form

A table with columns <Term> and <Definition>.

Potentially more columns in case you need translations.

Term Definition

API

Application Programming Interface. It’s a set of defined rules that enable different applications to communicate with each other. It acts as an intermediary layer.

Backend

Part of a computer application or a program’s code that allow it to operate and that cannot be accessed by a user

Decentrilized/centrilized Data

In a centralized network, all users are connected to a central server that stores complete network data and user information. On the contrary, a decentralized network has several peer-to-peer user groups wherein each group has its separate server that stores data and information relevant to only that particular group.

Deployment

Mechanism through which applications, modules, updates, and patches are delivered from developers to users

Framework

Tool that provides ready-made components or solutions that are customized in order to speed up development

Frontend

Part of computer programming that focuses on the coding and creation of elements and features that will then be seen by the user.

GitHub

Code hosting platform for version control and collaboration.

Component-based Architecture

Process of building software based on reusable components. Structure of components that contains other smaller components.

POD

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.

SOLID

SOLID is an acronym for the first five object-oriented design principleS. These principles establish practices that lend to developing software with considerations for maintaining and extending as the project grows.

Bootstrap

A multiplatform library, open source toolbox to design web applications.

Netlify

A remote cloud computing company that offers a development platform that provides: serverless backend services, build and deployment functionality for dynamic websites and web applications.

13. Test

In this section we are going to test the application. We will use the following technologies for testing:

Name Description

Sonarcloud

Checks the code coverage and quality for the application tests.

Cucumber

Technology used for behavior driven development (BDD) to write acceptance tests for the application.

Gatling

Technology used for load testing the application.

We are going to analyze the results of the Gatling tests in the following section.

13.1. Sonarcloud

Sonarcloud allows us to check the code coverage and quality of the application. The following image shows the results of the Sonarcloud tests:

sonarcloud test

We can see how we have a 80% of code coverage for the application. We can also see that the code quality is good, with 0 bugs and 0 security vulnerabilities. We can also see that the code duplication is 1.1% which seems to be a good value thinking that the application hasn’t been developed by a single person and a refactor of the code has never been done.

13.2. Gatling

After running the Gatling tests, we can analyze the results. After analyzing the results, we can see that the application at 100 active users and 50 requests per second has a response time of 0.8 seconds for a 40% of success rate. The following image shows the results of the Gatling tests:

test gatling

Maybe the success rate is not the best, but we can see that the response time is very good. We have to take into account that the application is running in a free instance of Netlify, so the performance is not the best. If we want to improve the performance, we can migrate the application to another cloud provider, like AWS, Azure or Google Cloud. We also need to take into account that the test have been run

when a lot of traffic has been generated to Inrupt POD provider. This can affect the results of the tests.

13.3. Usability

In this section we are going to have a look at the usability of the application. We have done a usability test with 5 users. The following table shows the results of the usability test:

Question Luis Carmen Paula Ana David Average

Is the application intuitive?

10

10

9

8

7

8.8

Is the application easy to use?

10

10

8

9

7

8.8

Is the application attractive?

8

9

10

10

9

9.2

Is the application fast?

7

6

7

8

8

7.2

Is the application accessible?

9

9

9

9

8

8.8

Is the application useful?

10

10

8

9

9

9.2

How would you rate the application?

9

10

10

10

10

9.8

We can see that overall the application has a good user rate. The users have rated the application with a 9.8 out of 10. The users have also rated the application as intuitive, easy to use, attractive, accessible and useful. The only thing that the users have not rated very well is the speed of the application. The found themselves waiting for the application to load some times.

The users have the following age: * Luis: 60 * Carmen: 55 * Paula: 19 * Ana: 66 * David: 22

We can see that the users are from different ages, so we can say that the application is suitable for all ages.

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, http://www.arc42.de. Created by Dr. Peter Hruschka & Dr. Gernot Starke.