valedictorian architecturaldesigndocument · july6,2017 valedictorian architecturaldesigndocument...

July 6, 2017

Valedictorian

Architectural Design DocumentVersion 1.0.0

Project team

J.M.A. Boender | 0978526

R. Coonen | 0902230

R.A.T. van Dijk | 0864724

H.R. Galioulline | 0927184

B.A.M. van Geffen | 0892070

A.A.W.M. de Kroon | 0905382

R.Morel | 0905326

W.M.W.R. Verlaek | 0908937

C.C.Weibel | 0883114

Project managers

J. Ubbink

R.Wouters

Project supervisor

dr. N. Zannone

Customer

prof.dr.ir. M.W.J. Prins

W.W.C.C. Brekelmans

SensUs Digital

July 6, 2017

Abstract

This document describes the architectural design of the SensUs Digital Platform. The ar-

chitecture described by this document satisfies the requirements specified in the User Re-

quirements Document [1] and in the Software Requirement Document [2]. This document

furthermore complies with the ESA software standard.

Valedictorian | Architectural Design Document 2

July 6, 2017

Contents

1 Introduction 7

1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3 List of definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4 List of acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.5 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

1.6 List of References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2 System overview 11

2.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Context and basic design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.3 Design decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.1 Splittingmain user application and dashboard . . . . . . . . . . . . . . . . 12

2.3.2 Model-view-controller pattern . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3.3 Client-server style . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3.4 React . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3.5 Redux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.6 Semantic UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.7 Laravel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.8 MariaDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 System context 18

3.1 YouTube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.1 Core Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1.2 Requesting Parts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 Google OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.1 Implementation (Google) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3 Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4 System design 22

4.1 Designmethod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2 Decomposition description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2.1 Server application decomposition . . . . . . . . . . . . . . . . . . . . . . . 22

4.2.2 Main user web application decomposition . . . . . . . . . . . . . . . . . . 26

4.2.3 Dashboard web application decomposition . . . . . . . . . . . . . . . . . . 28

4.2.4 Sharedmodules betweenweb applications . . . . . . . . . . . . . . . . . . 29

4.2.5 File structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30


July 6, 2017

4.2.6 Database design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5 Component Description 34

6 Feasibility and resource estimates 35

6.1 Resource requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.2 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6.2.1 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

7 Requirements traceabilitymatrix 40

7.1 SR tomodules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

7.2 Components to SR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7.2.1 Server applicationmodules . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7.2.2 Main user applicationmodules . . . . . . . . . . . . . . . . . . . . . . . . . 44

7.2.3 Dashboard applicationmodules . . . . . . . . . . . . . . . . . . . . . . . . 45

7.2.4 Sharedmodules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45


July 6, 2017

DOCUMENT STATUS SHEET

GENERAL

Document title: Architectural Design Document v1.0.0

Identification: ADD/1.0.0

Authors: B.A.M. van Geffen, N. de Kroon

Document status: Final 1.0.0

DOCUMENTHISTORY

Version Date Author(s) Reason

0.0.1 16-5-2017 B.A.M. van Geffen

N. de Kroon

Document layout

0.0.2 23-5-2017 B.A.M. van Geffen

N. de Kroon

Sections 1 to 6 drafted

0.0.3 28-5-2017 B.A.M. van Geffen

N. de Kroon

All sections drafted, feedback N. Zan-

none

0.1.0 28-5-2017 B.A.M. van Geffen

N. de Kroon

First version

1.0.0 5-7-2017 B.A.M. van Geffen Final version


July 6, 2017

DOCUMENTCHANGERECORDS

Section Reason

1.0.0 Incorporated final (minor) feedback


July 6, 2017

1 INTRODUCTION

1.1 PURPOSE

The Architectural Design Document (ADD) provides a comprehensive architectural overview

of the SensUs Digital Platform. The document describes the software decomposed in sepa-

rate components to depict different aspects of the system. For every component its interface

is given, as well as its dependencies and relation to other (external) interfaces. Moreover, we

describe which software requirements (as described in the SRD) are satisfied by each compo-

nent. Finally, the context and overviewof the systemare provided, alongwith an estimation of

the feasability and resource requirements.

1.2 SCOPE

Valedictorian is a groupof computer science studentsworking onbehalf of theEindhovenUni-

versity of Technology (TU/e) for the SensUs Organization. SensUs is an organization that or-

ganizes an annual student competition between different universities and colleges across the

globe to develop and demonstrate the design and effectiveness of various biosensors. The de-

veloped software system is aweb applicationwhich acts as a platform to further engage inter-

ested parties (both attendees and online viewers) in the contest (a physical event).

The main purpose of the SensUs Digital Platform is to provide online viewers with an expe-

rience as close as reasonably possible to actually attending the event in person. This is real-

ized by having live video streams of the event, along with (on-demand) videos that showcase

highlights of past live video streams. Moreover, information about the competition is provided

on the website. This gives online viewers access to the same amount of information and en-

tertainment of the event as attendees. Furthermore, the platform provides both viewers and

attendees with additional information regarding activities, participating teams, the contests’

awards and judges. Moreover, attendees can use it to catch up with missed activities, includ-

ing concurrent events. Finally, the website provides online viewers with the ability to engage

with participating teams. This is provided through asking questions to teammembers, submit-

ting videos and pictures of the event (and/or teams specifically), and voting for teams. Overall,

the SensUs Digital Platform adds another dimension of engagement to anyone interested in

following the contest.

1.3 LISTOFDEFINITIONS

Backend Data Access Layer (runs in server environment)

Frontend Presentational Layer (runs in web application/client environment)


July 6, 2017

HTTP Requests A request message following the HTTP protocol from the client to the

server.

JavaScript Client side scripting language used to provide interactive views on our

platform.

Middleware MechanismforfilteringHTTPrequestsenteringor leaving the (backend)

application.

MariaDB Open-source databasemanagement system.

Laravel Open-sourcePHPweb framework for developingMVCwebapplication.

OAuth Open standard to grant systems authentication information by other

websites.

PHP Server side scripting language used to provide dynamic content on our

platform.

React Open-source JavaScript library for building user interfaces.

Redis Open-source in-memory data store used for caching.

Redux Open-source JavaScript library for managing application state.

Response Time The time between sending a web request and receiving a response. In

this document the response time is alwaysmeasured inmilliseconds un-

less stated otherwise.

1.4 LISTOFACRONYMS

ADD Architectural Design Document

API Application Programming Interface

CSS Cascading Style Sheets

DBMS DatabaseManagement System

DOM Document ObjectModel

HTML HyperTextMarkup Language

MVC Model-View-Controller

REST Representational State Transfer

SRD Software Requirement Document

TU/e Eindhoven University of Technology

URD User Requirement Document


July 6, 2017

RT Response Time

1.5 OVERVIEW

The remainder of this document is composed of sections that detail the architectural design

of the SensUs Digital Platform. Section 2 provides an overview of the system, and describes

design choices, alternatives and rationale. Section 3 describes external relationships of the

SensUsDigital Platform and their interfaces and external files. Section 4 describes the system

design, its decomposition into components, their relationships (such as dependencies), andde-

signmethods. Section 5, which is omitted, would contain a description of the components. We

refer to the Detailed Design Document instead, for those interested in the descriptions. Sec-

tion 6 describes estimates for computer resources used by the SensUs Digital Platform in de-

velopment and production, and discusses feasibility. Section 7 is a requirement traceability

matrix, which describes how software requirements - as set out in the SRD [2] - aremet by our

architectural design.

1.6 LISTOF REFERENCES

[1] Valedictorian (2017) User Requirements Document version 1.0.0

[2] Valedictorian (2017) Software Requirements Document version 1.0.0

[3] Facebook.TheofficialReactwebsite, https://facebook.github.io/react/ (accessedon2017-

6-27).

[4] The jQuery Foundation. The official jQuery website, https://jquery.com/ (accessed on

2017-6-27).

[5] Evan You. The official Vue.js website, https://vuejs.org/ (accessed on 2017-6-27).

[6] Facebook Inc. The official Flux website, https://facebook.github.io/flux/ (accessed on

2017-6-27).

[7] Dan Abramov. The official Reduxwebsite, http://redux.js.org/ (accessed on 2017-6-27).

[8] Semantic Organization. The official Semantic UI website, https://semantic-ui.com/

[9] Bootstrap Core Team. The official Bootstrap website, http://getbootstrap.com/ (accessed

on 2017-6-27).

[10] Yahoo! Inc. The official Pure.css website, https://purecss.io/ (accessed on 2017-6-27).

[11] Jeremy Thomas. The official Bulmawebsite, http://bulma.io/ (accessed on 2017-6-27).


July 6, 2017

[12] Materialize. The official Materialize website, http://materializecss.com/ (accessed on

2017-6-27).

[13] TaylorOtwell. The official Laravel website, https://laravel.com/ (accessed on 2016-6-27).

[14] MariaDB Foundation. The official MariaDB website, https://mariadb.org/ (accessed on

2017-6-27).

[15] Oracle Foundation. The officialMySQLwebsite, https://mariadb.org/ (accessed on2017-

6-27).

[16] The PostgreSQL Global Development Group. The official PostgreSQL website,

https://www.postgresql.org/ (accessed on 2017-6-27).

[17] IETF OAuthWG. OAuth 2.0 Framework - RFC 6749, https://tools.ietf.org/html/rfc6749

(accessed on 2017-6-13)

[18] Google. Using OAuth 2.0 for Web Server Applications,

https://developers.google.com/identity/protocols/OAuth2WebServer (accessed on

2017-6-13)

[19] Google. YouTube API, https://developers.google.com/youtube/v3/docs/videos (accessed

on 2017-6-20).

[20] PHP Framework Interop Group. Coding Style Guide (PSR-2), http://www.php-

fig.org/psr/psr-2/ (accessed on 2017-6-20).

[21] Airbnb. Javascript Style Guide, https://github.com/airbnb/javascript (accessed on 2017-

6-20).

[22] Airbnb. React/JSX Style Guide, https://github.com/airbnb/javascript/tree/master/react

(accessed on 2017-6-20).

[23] Taylor Otwell. The official Laravel website, https://laravel.com/docs/5.4/eloquent (ac-

cessed on 2016-6-27).).

[24] RedisLabs. The official Redis website, https://redis.io/ (accessed on 2016-6-27).

[25] DigitalOcean Inc. The official DigitalOcean website, https://www.digitalocean.com/ (ac-

cessed on 2017-6-27).

[26] Locust. The official Locust website, http://locust.io/


July 6, 2017

2 SYSTEMOVERVIEW

The system is a web application that provides a platform for users to interact with the SensUs

event remotely. Ahigh leveldescriptionof theSensUsDigitalPlatformcanbe found in theUser

Requirements Document (URD) [1]. Furthermore, a more in-depth background of the SensUs

Digital Platform and the environment inwhich the systemwill operate is described in Sections

2.3 and 2.4 of the Software Requirements Document (SRD) [2] and Section 2.5 of the URD [1].

2.1 BACKGROUND

TheSensUsDigital Platform is conceivedby theSensUsorganization. After organizing ahighly

successful first edition of the SensUs competition in 2016, SensUs noticed an unmet demand.

Since teams from all over the world compete, many of their friends and family are not able to

travel to theNetherlands tophysically be at theevent. SensUs saw theneed for aplatform that

enablesusers toremotelyparticipate in theevent. UserscanusetheSensUsDigitalPlatformto

viewandupload videos andpictures, ask questions and receive answers from theparticipating

teams and SensUs organization, and view graphs that represent the different teams progress

throughout the competition. Finally, the SensUs Digital Platform would offer the SensUs or-

ganization a platform to organize different aspects of the competition, e.g. recording match

results through amatch datamanagement system.

2.2 CONTEXTANDBASICDESIGN

The SensUsDigital Platform consists of threemajor elements. There are two single-page web

applications: amain user applicationwhich offers user interfaces to all public parts of the Sen-

sUs Digital Platform, and a dashboard application that is reserved for teammembers and ad-

ministrators that offers user interfaces tomanage the content and configurationof the SensUs

Digital Platform. Both the main user application and the dashboard application connect to a

third application: the server application that stores the data relevant to the web applications

in a database. In order for the two web applications to retrieve and alter the data relevant to

them, theysendrequests to theserverapplication throughaRESTAPI that then independently

handles the requests and returns the requested data.

Theweb applications feature video and picture content that is hosted on external services

like YouTube and Imgur. The SensUs Digital Platform server stores links and content id’s that

identify the content to be displayed, which is then requested by the web applications and em-

bedded into its views. The basic overview of the systems main elements can be found in Fig-

ure 1.


July 6, 2017

FIGURE 1: SYSTEMOVERVIEWDIAGRAM.

2.3 DESIGNDECISIONS

In this section we will discuss and justify the significant design decisions made when choosing

the technologies and architecture used in the SensUs Digital Platform.

2.3.1 SPLITTINGMAINUSERAPPLICATIONANDDASHBOARD

The web applications are split into a main user application and a dashboard application. This

offers a number of advantages. Firstly, it offers some security advantages. By splitting the

applications, the code and logic concerning the administration of the SensUs Digital Platform

(the dashboard application) is not visible to regular users accessing the site. More concretely,

by splitting the SensUs Digital Platform in two applications, we ensure that we only send this

code to users that at least have teammember privileges. Thereby, by splitting theweb applica-

tions,we limit theaccess toouradministrationcode tousers that areat least somewhatvetted.

Another advantage is that it enforces a clear separation between main user code and ad-

ministration code. This improves cohesion and thus the structure of the project. Furthermore,

because theweb application is split, a normal userwould never have to load the SensUsDigital

Platformadministrationcode, therebywe improvethespeedof the initial loadof thewebappli-

cation. A disadvantage is that splitting theweb application entices code duplication. However,

through letting the dashboard application depend on essential parts of the code base of the

main user application this can be minimized, although it requires additional code to properly

manage this process that would not be needed otherwise.


July 6, 2017

2.3.2 MODEL-VIEW-CONTROLLER PATTERN

TheModel-View-Controller (MVC)model design pattern is central to the architectural design

of the SensUs Digital Platform, and is used in both the web applications and the server appli-

cation. It divides the design into three components:

• Model: Defines the structure of the data which the application depends on.

• View: The output representation of the information contained in themodel.

• Controller: Receives signals from theviewsand transmits commands to themodel toup-

date themodel’s state. Furthermore, sends commands to its associated views to change

the view’s presentation of themodel.

FIGURE 2:MODEL-VIEW-CONTROLLERDIAGRAM.

Applying the MVC pattern enforces a clear separation between data, presentation, and

user interaction. The user interacts with the view which is some representation of the model.

When the user performs an action, a signal is sent to the controller. The controller then up-

dates the model according to the action performed. When the model changes, it notifies the

controller. The controller then again updates its associated views according to the newmodel.

A graphical representation of these principles is show in Figure 2.

TheMVC pattern is used in the SensUs Digital Platform server application. The view com-

ponent of the pattern is then represented by the two web applications. The two web applica-

tions also on its own implement theMVCpattern, although theyuse a slightlymodified version

of it (Flux) as explained in the Redux section.

2.3.3 CLIENT-SERVER STYLE

Since the requirements of the application imply multiple clients using the software sharing a

single source of truth, the client-server architecture is a perfect fit for the SensUsDigital Plat-

form. The main user web application and the dashboard application together form the client

side (also referred to as front-end). They communicate through remote procedure calls with


July 6, 2017

the server application. An alternative architectural style would be peer-to-peer. With this

style, every client acts as both a client and a server. The advantage is that the application

is decentralized and is thereby more robust. It also spreads the workload over multiple in-

stances. However, since theSensUsDigitalPlatformdoesnotneeddistributeddataprocessing

the advantages are moot. Peer-to-peer furthermore increases the difficulty of achieving data

integrity andmanaging the data over the network. Therefore, this style is not a good fit for the

SensUs Digital Platform.

2.3.4 REACT

React [3] is a library that represents the view component of theMVCarchitecture of bothweb

applications. It allowsdevelopers todeclarativelydescribe thegraphicalpresentationofaview

depending on some model representing state. When the model changes, React automatically

updates relevant presentational elements in order to represent the new state of the model.

It does this very efficiently: when the model changes, a new virtual DOM is built just using

JavaScript. It then changes the current actual DOMdisplayed in browser to equal the new vir-

tualDOMwhile attempting tominimize theamountof costlyDOMmanipulations. This results

in fast and responsivewebapplications. Therearemanyalternatives toReact, twoofwhichare

listed below.

• RegularHTMLand jQuery: Theclassicwaytomakewebsites is touseamulti-pageHTML

and CSS website and adding dynamic behavior by using JavaScript, often helped by us-

ing jQuery [4]. There are good reasonswhy this style is getting out of fashion for complex

websites: becauseof the imperativenatureof altering theDOMin thismanner, it ismuch

harder to keep track of the current state of the website. Furthermore, it does not offer

the componentization features other modern frameworks have that help with code re-

use andmodularity.

• Vue: Another popular front-end library and a direct competitor to React is Vue [5]. It is

lighter weight than React, and slightly faster. It also allows the use of templates, which

muchmoreresembles traditionalwebdevelopmentwithaddedfeaturescomparedtothe

component structure of React.

We chose for React because of the large scale of our web application: the component nature

of React allows a very clear structure for large projects, is more easily testable and promotes

code reuse. It also ismorepopular thanVueandhas a very healthy ecosystem. Another reason

for our choice is that our client showed interest in expanding the SensUs Digital Platform to

also include an app in the future. React, through React-Native, would easily allowmuch of the

web-application code to be reused for an eventual mobile app.


July 6, 2017

2.3.5 REDUX

Aproblemthat ariseswhenusingReact is howto sharedata amongdifferent components. Tra-

ditionally, this would give rise to aMVCpattern. However, in practice it is found that theMVC

pattern is not able tohandle thehigh level of complexity introducedby largerwebapplications.

An illustration of this can be seen in Figure 3.

FIGURE 3:MODEL-VIEW-CONTROLLER IN PRACTICE.

The problem is that in traditional web applicationMVC, each component has its own asso-

ciated model. Furthermore, many views might depend on a certain model and models might

have interdependencies. As indicated in Figure 3, as the web application scales complexity

soon becomes very high as the interdependencies between controllers, models, and views be-

come very hard to track. The Flux architecture [6] is a solution to this proposed by Facebook

in 2014, and it attempts to solve these issues by puttingmore constraints on the flow of infor-

mation through aweb application. Redux [7] is themost popular implementation of this archi-

tecture, and we decided to use this in our web applications in order to manage the complexity

of shared data. An overview of the redux pattern can be seen in Figure 4.

FIGURE 4: REDUXARCHITECTURE.


July 6, 2017

The core feature of Flux is unidirectional data flow. A view never directly changes state,

it has to dispatch an action which indirectly triggers the change of state through the reducer.

The reducer is a simple pure function which takes the current state and an action and returns

the new state. The Redux state acts as a single source of truth for shared data. Use of Redux

greatly improves the structure and predictability of data flow in our web applications.

2.3.6 SEMANTICUI

SemanticUI [8] is a development framework for designingweb applications. The reason to use

such a framework is simple: it makes it much easier and faster to create modern user inter-

faces for the SensUsDigital Platform. The big advantage of Semantic UI is that the syntax this

framework uses is much more like natural language than other popular CSS frameworks such

as Bootstrap [9]. Other than that, Semantic UI by default looks more modern and is very user

friendly (for the developers) by default. The components provided by Semantic UI, in combi-

nation with the friendly syntax and experience in our team are the main reason we selected

Semantic UI over other popular design-related frameworks. In particular, other frameworks

we consideredwere either toominimalist (such as Pure CSS [10] and Bulma [11]) or had a less

user friendly syntax for new developers (such as Bootstrap andMaterialize [12]).

2.3.7 LARAVEL

Laravel [13] is an open-source PHP framework which supports development of web applica-

tionswith theMVCarchitecture. In particular, Laravel provides tools thatmakes development

quicker such as different ways tomodel and access relational databases, routing requests and

implementing authentication. Finally, Laravel provides contracts and facades that abstract

from implementation details. This allows us to easily swap providers for caching, database

management and authentication. A large downside is that there is overhead from the regis-

tered code that we do not use, and additionally that due to the abstractionwemay not be able

to use all features that a specific provider offers. As a concrete example, the database facade

provided by Laravel is designed to work withmost popular databasemanagement systems, as

suchwemay not be able to (conveniently) use features that the specific DBMSwe use offers.

Another reason to use Laravel is its popularity compared to other PHP Frameworks. Since

it is likely that the product will be continuously worked on by different developers, selecting a

well-known and well-documented framework has many advantages. First of all, finding expe-

rienced developers is easier, andmore importantly there aremany resources available online.

Moreover, there is an active community of developerswhichminimizes bugs and other quality

problems in the framework, and often contribute to quicker development of new features.

The reason tousePHP (andLaravel), in comparison to otherwebdevelopment frameworks


July 6, 2017

again comes down to popularity. PHP has an enormous user base and has had so for decades.

The result is a tested, reliable and secure platform tobuild aweb server application. Moreover,

within our group we had two people who had experience with Laravel specifically, and more

hadexperiencewithPHP.Furthermore, a reason touseLaravel compared toother frameworks

is the amount of functionality implemented at an abstract level. Accessing a Database can be

done “out-of-the-box” and is not dependent on a specific DBMS, has security measures imple-

mented and offers alternative ways to build a query (for example). In the end, using Laravel

allowed us to develop rapidly, and, equally important, provides amore elegant transitionwhen

the codebase is picked up by other developers.

2.3.8 MARIADB

MariaDB [14] (sometimes incorrectly referred to asMySQL) is an open-source relational data-

basemanagement system (RDBMS). The reason to useMariaDBoverMySQL [15] itself is that

MariaDB is open and has a more vibrant community. Furthermore, MariaDB is the de facto

RDBMS and is supported by many platforms. An important reason to choose for the default

RDBMS is that by using Laravel we are product-agnostic. In other words, we have not imple-

mented anything specific for MariaDB, and switching to, for example, PostgreSQL [16] is as

simple as changing a single configuration line.


July 6, 2017

3 SYSTEMCONTEXT

This section describes the environment inwhich the SensUsDigital Platformwill operate. The

external interfaces that the SensUs Digital Platform uses are detailed explicitly. In particular

we describe howYouTube’s andGoogleOAuth’s external interfaces are used to retrieve infor-

mation necessary for our services.

3.1 YOUTUBE

TheYoutubeDataAPI (v3) [19] is used to retrieve information about uploaded content (videos

and streams) on the SensUs Digital Platform. The data retrieval is done bymaking API calls to

the Google server, and the Google server responds with the requested information in JSON

format.

3.1.1 COREREQUEST

This section describes the bare request, meaningwithout any optional data requested, and re-

sponse to the YouTube API. The request is a GET request, and contains the key (our YouTube

API key) and id (the video ID) fields. The YouTube API returns a JSON formatted object with

information on the video (a ‘video resource’).

The response has the format shown in Table 3

TABLE 3: THE YOUTUBEAPI RESPONSEOBJECT

Property Description

kind string

Identifies the type of API resource of the response.

etag string

The entity tag of the resource; used to identify a specific version of an

API resource.

pageInfo object

Provides page information of the result.

pageInfo.totalResults integer

The total number of results available (in our case always 1).

pageInfo.

resultsPerPage

integer

The number of results included in the response.

items array

List of (requested) video objects (in our case a single resource).


July 6, 2017

The Video Resource in a response to a “bare” request has the format shown in Table 4.

TABLE 4: THEVIDEORESOURCEOBJECT


id string

The value that YouTube uses to identify the video.

kind string

Type of API resource (in this case “youtube#video”).

etag string

The entity tag of this resource.

3.1.2 REQUESTINGPARTS

The core request yields a video resource with little data on the video resource. By providing

the parts field in the request, the video resource in the response will be extended with nested

objects. We use the following parts: “snippet” (which contains basic details about the video,

e.g. name and description) and “statistics” (which contains statistics about the video such as

views and likes). These can be used in any combination, and the video resourcewill contain the

selected parts as keys in the JSON formatted object.

Specifying parts (such as “snippet”) will result in YouTube adding the objects to the Video Re-

source. The object formats are shown in Table 5 (some irrelevant properties are omitted)

3.2 GOOGLEOAUTH

The OAuth 2.0 standard is used to access authentication and authorization functionality of

Google API’s. Moreover, the external interface is used to allow users to authenticate with

Google Accounts on the SensUs Digital Platform. Note that OAuth 2.0 is widely adopted and

is supported by other authentication providers including GitHub, Twitter, Microsoft, Dropbox

and LinkedIn. As such it is relatively easy to extend the SensUs Digital Platform to support

other OAuth providers in the future. An abstract description of the workflow is explained

in this section. Note that detailed API request and response descriptions are omitted since

OAuth 2.0 is an open standard.

3.2.1 IMPLEMENTATION (GOOGLE)

TheOAuth2.0open standard, asdescribed inRFC6749 [17], is followedby the system. Specif-

ically, the OAuth 2.0 authentication for Web Server Applications is implemented according

to Google’s recommendation [18] (conform RFC 6749). The following workflow (also see Fig-


July 6, 2017

TABLE 5


snippet object

Contains basic details about the video (title, description, category, etc.).

snippet.publishedAt datetime

The date and time that the videowas published on YouTube.

snippet.channelId string

Identifies the YouTube channel to which the videowas uploaded.

snippet.title string

The video’s title.

snippet.description string

The video’s description.

snippet.channelTitle string

Channel title for the video’s associated channel.

snippet.tags array

List of keyword tags associated to the video.

snippet.categoryId string

Identifier of the YouTube category associated with the video.

snippet.

liveBroadcastContent

string

Indicates if the video is normal (“none”) or “upcoming”/ “live” stream.

statistics object

Contains statistics about the video.

statistics.viewCount unsigned long

The number times the video has been viewed.

statistics.likeCount unsigned long

The number of users that indicated they like the video.

statistics.

commentCount

unsigned long

The number of comments for the video.

ure 5) is adhered to:

1. Authentication starts by redirecting the client to the Google authorization server. Both

the required and recommended query string parameters are included, in particular the

Client ID, response URL and state (random string used for validation).


July 6, 2017

2. TheWeb Server handles the OAuth 2.0 response, which - when authentication was suc-

cessful - contains the state (from the request) and an authorization code.

3. TheWeb Server exchanges the authentication code for access tokens. The correspond-

ing request to theGoogle authorization server contains - next to the received authoriza-

tion code - the Client ID and a Client secret. Note that unlike in step 1, this call is made

directly from theWeb Server to Google’s server.

4. TheWebServer handles theOAuth2.0 response,which contains access tokens. Authen-

tication is completed.

5. Theaccess tokensareused for all followingAPI calls toGoogle, for example for retrieving

some profile information.

FIGURE 5: GOOGLEOAUTH2.0WEBAPPLICATION FLOW.

3.3 IMAGES

A simple system is in place to allow users to submit images. To avoid the costs and resources

required to host images on the SensUs Digital Platform server we decided to allow users to

submit externally uploaded pictures. In other words, any image URL can be submitted (for ex-

ample hosted on popular services such as Imgur) andwill simply be rendered in aHTML image

element. Note that no content (including images) will be publicly visible before an authorized

administrator approves the content.


July 6, 2017

4 SYSTEMDESIGN

This chapter contains details about the system design of the SensUsDigital Platform . The de-

signmethod, component decomposition, file structure, and database design will be covered in

this chapter.

4.1 DESIGNMETHOD

The system is decomposed in the main user web application, dashboard web application and

theserverapplication. These threeapplicationsaredesigned tobeas separate fromeachother

as possible, with the exception of some code reuse in the dashboard andmain user web appli-

cations.

The server application is written in PHP and follows the Coding Standard (in particular

Naming Convention) of the PSR-2 Coding Style Standard [20]. Both our (front-end) web ap-

plications are written in JavaScript with React and follow the Airbnb JavaScript Style Guide

[21] and Airbnb React/JSX Style Guide [22].

4.2 DECOMPOSITIONDESCRIPTION

The decomposition of the SensUs Digital Platform into separate components is based on the

requirements in theURD [1] and the SRD [2]. Subsection 4.2.1 lists all the components used in

the server application, 4.2.2 lists the components used in the main user web application, and

4.2.3 lists all components used in the dashboard web application. Subsections 4.2.3 describes

the file structure of the project and 4.2.4 describes the database design.

4.2.1 SERVERAPPLICATIONDECOMPOSITION

The server application is responsible for maintaining and retrieving data in the database. As

such, the server application consists mainly of theModel and Controller aspect of the applica-

tion as awhole. The back-end iswritten to beRESTful andmodular, which results in interoper-

ability between computer systems and web applications. First, we decompose the the server

application in themajor constructs provided by Laravelwhichwe extent and onwhichwe built

our application. In this decomposition, we follow the lifecycle of an incoming request.

4.2.1.1 Kernel

The (HTTP) kernel is the entry point of allHTTP requests that enter the application. Thekernel

applies “bootstrapping” to register core features such logging, exception handlers andmiddle-

ware that all requests must pass through. Essentially, the kernel receives a request, feeds this

request to a big black box; our application, and returns a HTTP response. Themost important

step is loading the service providers of our application.


July 6, 2017

4.2.1.2 Service Provider

The service providers are central to our Laravel application. They register all services that Lar-

avel offers, and any services we add ourselves. Components that are registered (sometimes

referred toas “bootstrapped”) include components related toqueuing, databases, caching, val-

idation, event listening and even routing.

4.2.1.3 Routing

After the kernel has bootstrapped the location, and all service providers have been applied, an

incoming request is sent to the router. The router is responsible for applyingmiddleware spe-

cific to that request (for example authorization middleware is often applied to a single route),

and then finally passing the request to the right controller.

4.2.1.4 Middleware

Middleware are used to process, filter, validate and augment incoming HTTP requests before

they are processed by the controllers. Some middleware is applied to all HTTP requests, for

example to check whether the application is down for maintenance or validate the size of re-

quests. More commonly, middleware is applied to a group of routes; for example for authenti-

cation, encrypting cookies and preventing banned users from accessing the site.

4.2.1.5 Controller

Acontroller isagrouping (class)of relatedrequesthandling logic. In short, aController consists

of one or more handlers for incoming requests, and are responsible for outputting changes to

themodels and/or views.

4.2.1.6 Models

Each database table has a correspondingmodel, which are used by Laravel’sObject-Relational

Mapping (ORM): Eloquent [23]. Eloquent uses models to build database queries and to insert

new records.

4.2.1.7 Views

Views contain the presentational logic (and are completely separate from the model and con-

troller logic). In our case, Laravel’s views are only used to render the web applications.


July 6, 2017

4.2.1.8 Cache

The cache provider (Redis [24] by default) is used to reduce the workload of the server when

handling requests. In particular, the cache is used to cache data that is commonly queried or

is particularly computationally heavy to retrieve. An example is the number of votes per team,

whicharestoredby individualvoteentries in thedatabase. Using thecachewestore thecounts

per team instead of individual votes to avoid recomputing.

4.2.1.9 Modules

The “modules” of the server application are defined in terms of models. In particular, we can

regard a module as a combination of a particular Model, Migration, Seeder and often a Con-

troller. Finally, some separate modules (such as middleware) are described. The modules we

implemented are:

• Answer: The Answer module consists of a Model for the answer part of a Q&A entry, a

CRUD (Create Read Update Delete) controller (AnswerController) to manage answers

and a migration and seeder to create and fill the database. Note that the seeder is only

used in development environment to create “test” answers.

• Authorization: Authorization is middleware that is used to protect routes with proper

authorization requirements.

• DataSetting: TheDataSettingmodule isusedtoconfigureLive (SensorData) results. The

model consists of a key (string) value (boolean) pair to enable or disable settings. The re-

sult is aflexibleway to configure settings related to live results (for example tohide/show

certain graphs). It is managed in the SensorDataController.

• Link: Links contain the underlying information of submitted content/media (Videos and

pictures). A link contains the shared properties of the media types, such as the location

andtypeofmedia. TheyarecreatedandmanagedbytheMediaControllerandLivestream-

Controller. The seeders are only used in development environments.

• Livestream: AsubclassofLinks thathold the livestreams. TheyaremanagedbyLiveStream-

Controller, and are only seeded in development environments.

• Measurement: The sensor data measurements are represented by the Measurement

model. They aremanaged by the SensorDataController and should be shown to the user

carefully. Some columns (such as the actual concentrations of data) are strictly private

until after the contest. Note that the seeders are ran in production environments, how-

ever, it will create mostly empty measurements rows which can be edited in the dash-

board application.


July 6, 2017

• Picture: A subclass of Link that holds submitted pictures. They are managed by the Pic-

tureController (a subclass of MediaController) and are only seeded in development en-

vironments.

• Question: TheQuestionmodule consists of aModel for the questions for theQ&A func-

tionality, and theQuestionController for the logic.

• Tag: The tag module is used to tag teams to submitted media. Besides the tag model,

there is amigration for the join table tomanage themany-to-many relationship between

tags andmedia. Tags are read-only and can be retrieved using the TagController. Associ-

ation of tags to media items is performed by the MediaController. The tags are created

(and can be updated) using the seeder.

• Team: The teams module is used to represent participating teams in the contest. Teams

are only added through a seeder, however, the teams can be updatedwith the TeamCon-

troller.

• User: Theusermodulemanages user accounts, and is used for authentication andautho-

rization. Users aremanaged by the AuthController, which creates, updates and incorpo-

rates usermanagement (for administrators only) formanually changing user details such

as associated team and user role.

• Video: A subclass of Link that holds submitted videos. Videos aremanagedby theVideo-

Controller (which extends theMediaController) and are only seeded in development en-

vironments.

• Views: The views module consists solely of the ViewsController. This controller’s sole

responsibility is to return the views containing the main web application and the dash-

board web application.

• Vote: The vote module is used for casting votes for teams. Votes are created, updated

and managed by the VoteController which uses caching to store vote counts. Votes are

not seeded.

• Routes: The routes define all available routes for either AJAX calls (prefixed with “api/”)

or regular web (HTTP) requests. In this module, middleware for specific routes can be

defined, and the endpoint (a method in a specific controller) is defined for each route.

A dependency diagram is shown in Figure 6. First of all, note that to improve understandabil-

ity of the diagram, we have left “Use” arrows from routes to most other modules implicit. In-

stead,wemark suchmoduleswith adouble border. Clearly, almost everymodule is usedby the

Routes module. This makes sense, as the Routes module defines all possible endpoints of our

server application. Note that the Middleware block contains all default Laravel middleware.


July 6, 2017

Another importantmodule is the Linkmodule, which is usedby allmedia, questions,media and

livestreams. DataSetting is not directly used by any other modules (except for Routes), as it

used for configuration on the front-end. Finally, the Views module is not included in the dia-

gram as it consist of only two trivialmethods to return views. Note that Views (likemost other

modules) is used by the Routes module.

FIGURE 6: BACK-ENDDEPENDENCY SCHEMA.

4.2.2 MAINUSERWEBAPPLICATIONDECOMPOSITION

Themain user web application is decomposed in the followingmodules:

• App: This is the main module of the user web application. It renders the menu banner

on the top of the website. Furthermore, it acts as a router and displays as its main con-

tent the view currently selected as route. It is also responsible for deciding which menu

options to display to a user given its authentication level.

• About: This module is responsible for rendering a view that has information about the

SensUsorganizationandtheSensUsevent, e.g. informationabout the judgesof theevent.

• Explore: This module is responsible for rendering a view that shows all the dynamicme-

dia which is currently public.


July 6, 2017

• Home: This module is responsible for rendering a view that displays the home page of

themain user web application.

• Live-results: This module is responsible for rendering a view that displays a live-results

page that displays charts relevant to the competition.

• QA:Thismodule is responsible for rendering aview that displays theapprovedquestions

and answers to SensUs and the competing teams.

• Teams: This module is responsible for rendering a view that displays information about

teams (e.g. team information and charts showing their progress through the competi-

tion).

• Voting: Thismodule is responsible for renderingaviewthatallowsusers tovoteonteams,

as well as displaying the total number of votes.

• Common: This module holds several utility views that are used throughout the rest of

the website, as well as the code for the Redux reducers and actions.

A dependency diagram for thesemodules can be found in Figure 7. As can be seen, the de-

pendencies of themain user web application follow a clear pattern. The Appmodule is always

active, and it rendersoneof theothermodules. Theothermoduleshaveno interdependencies,

and may only depend on shared code contained in Common or Shared. Note that Common is

used exclusively by theMain User Application, while Shared is used by both web applications.

FIGURE 7:MAINUSERAPPLICATIONDEPENDENCY SCHEMA.

It should be noted that each module that is responsible for rendering a view, including the

App component, is again subdivided into several smaller elements. Specifically, each module


July 6, 2017

has a container which holds the logic and state. The container is also connected to the Redux

store, takes a subset of the state that is relevant to its view, and is responsible for dispatch-

ing Redux actions. The container then renders one or more so called representational com-

ponents, which solely contain logic regarding what HTML and styles should be displayed, and

explicitly do not manage any data. The container passes relevant data necessary for display-

ing the representational components through function arguments, which in React are called

properties. If the representational component contains a UI element that might require logic

on activation, the container passes a callback function: the logic is explicitly handled by the

container and not the representational component. This separation of logical and representa-

tional concerns is essential is achievingmaintainability in a react application.

4.2.3 DASHBOARDWEBAPPLICATIONDECOMPOSITION

The modules in the dashboard web application are, as explained in Section 4.2.2, subdivided

in a container and representational components. The dashboard application is decomposed in

the followingmodules:

• Dashboard: This is the main module of the dashboard application. It renders the menu

banner on the top of thewebsite. Furthermore, it acts as a router and displays as itsmain

content the view currently selected as route.

• Biosensordata: This module is responsible for rendering a view that displays the data

currentlyenteredabout theevent, aswell asallowingadministrators tomanage thisdata.

• Event: Thismodule is responsible for rendering a view that allows you to select interest-

ing sub-views that can then be displayed in a full screen slide-show format.

• QA:Thismodule is responsible for renderingaviewthatallowsusers tomanagetheques-

tions and answers section of the SensUs Digital Platform.

• Team: Thismodule is responsible for rendering aview that allowsadministrators toman-

age the team portion of the SensUs Digital Platform, e.g. altering the team descriptions.

• User: Thismodule is responsible for rendering a view that allows administrators toman-

age the users of the website, e.g. by banning and changing the role of users.

• Control: This module is responsible for rendering a view that allows administrators to

control the media portion of the SensUs Digital Platform, e.g. by approving or deleting

videos and pictures.

• Common: This module holds several utility views that are used throughout the rest of

the website, as well as the code for the Redux reducers and actions.


July 6, 2017

Adependencydiagram for thesemodules canbe found inFigure8. As canbe seen, similarly

to themain user application, the dependencies of the dashboard application followa clear pat-

tern. The Dashboard module is always active, and it renders one of the other modules. The

other modules have no inter dependencies, and may only depend on some shared code con-

tained in Common or Shared.

FIGURE 8: DASHBOARDAPPLICATIONDEPENDENCY SCHEMA.

4.2.4 SHAREDMODULES BETWEENWEBAPPLICATIONS

Besides themodules specific for the two applications, there are also sharedmodules that con-

tains code that is sharedbetween the twoapplications. This code is contained in a single folder

onthesame levelas thetwowebapplications. Thefollowingmodulesare included in theshared

module:

• Charts: Components that render charts.

• Login: Components that render the login modal.

• Menu: Components that can render a generic menu.

• Upload: Components that render an upload UI to let users submit content to the server.

• Util: Set of utility functions. Includes things like shared Redux reducers, a full screen

component, definition of some types etc.

A dependency diagram for thesemodules can be found in Figure 9. As can be seen from the

diagram, there are no interdependencies between the modules, except that any module may

depend on the Util module (e.g. Charts, Login andMenu).


July 6, 2017

FIGURE 9: SHAREDMODULESDEPENDENCY SCHEMA.

4.2.5 FILE STRUCTURE

The project has a nested and complex file structure. To be specific, the server application is the

root of the project. Themain user anddashboard applications are sub-folders of the server ap-

plication project. Firstwe list the root file structure (containing the server application project).

The assets folder is printed in bold, to indicate that the content is shown separately, since this

folder contains the web applications. The root file structure is listed below:

[root]......................................................................Root folder[__mocks__].........................Folder withmockmodules for testing javascript[app] ...............................Contains the core code of the server application.

[Events] ...............Contains events, used to broadcast actions have occurred.[Exceptions] .............................Describes how exceptions are handled.[Globals].....................Contains Global data such as constants and Enums.[Http] ................Contains almost all logic related to handling HTTP requests

[Controllers]..............................Contains the backend Controllers[Middleware] .....Contains the default configurable and customermiddleware

[Models]..........................................Contains theModel definitions[Provider]................Contains the Service Providers, used for bootstrapping

[bootstrap]..........................Bootstraps Laravel and configures autoloading[config]....................Contains all configuration files for the server application[database]........................................Contains all Database related files

[factories] ...........Provide factories for easily generating instances of models[migrations].........Defines the database structure in a Version control like way[seeds]........................Seed the database (for testing and/or default data)

[node_modules]................All installed NPMpackages (front-end dependencies)[public]....................Public files of the web applications (compiled JS and CSS)[resources] ........................Contains the resources our site uses (images, JS)

[assets]..............................Contains the assets of the web applications[views].......................Contain the views that renders the web application

[routes]...............................................Contains all route definitions[storage] ...............Contains file based cache/sessions and other generated files[tests]......................Contains the automated tests for the server application[vendor]..................Contains our Composer dependencies (server application)

The subtree starting at the assets folder (in the resources folder) which contains both web


July 6, 2017

applications is is listed below:

[assets] .........................................Directory containing web applications[fonts]....................................................................Font files[images].................................................................Image files[sass].............................................................SASS styling files[semantic].........................................................Semantic UI files

[definitions]...........................................Default Semantic styles[site]....................................................Custom style overrides[themes]............................................................Style themes

[tests]..............................................................Front end tests[actions] ................................................Tests for Redux actions[reducers]..............................................Tests for Redux reducers

[js]........................................................Web application JS code[shared]..........Shared code between themain user and dashboard applications

[charts].........................Module containing shared chart components[login]............................Module containing shared login component[menu]............................Module containing sharedmenu component[upload].........................Module containing shared upload component[util]..............Module containing some shared functions and components

[dashboard]..........................Directory containing dashboard application[biosensordata] ...................Contains the Biosensordatamodule code[common] ......Contains code shared between dashboard applicationmodules[dashboard] ....................Contains the code for the Dashboardmodule[event] ..............................Contains the code for the Event module[qa] ....................................Contains the code for theQAmodule[team] ................................Contains the code for the Teammodule[user] ................................Contains the code for the User moduledashboard.jsx ................The entry file of the dashboard web application

[main] ............................Directory containing themain user application[about]...............................Contains the code for the Aboutmodule[app] ...................................Contains the code for the Appmodule[common].............Contains code shared betweenmain applicationmodules[explore]...............................Contains code for the Exploremodule[home]....................................Contains code for the Homemodule[liveresults].......................Contains code for the Liveresults module[qa].........................................Contains code for theQAmodule[teams]...................................Contains code for the Teamsmodule[voting].................................Contains code for the Votingmoduleapp.jsx.........................The entry file of themain user web application

4.2.6 DATABASEDESIGN

The database is implemented using a traditional relational database model. Our database de-

sign contains the following tables:

• teams: Contains information about each team.

• links: Contains links to external resources. For example for YouTube video’s, the con-

tentID of the video is stored. For external images, a direct link to the image is stored.


July 6, 2017

• users: Contains information about each user.

• measurements: Contains themeasurement data from the SensUs event. Used to display

charts etc.

• livestreams: Contains information regarding the livestreams shown on the main user

web application.

• answers: Contains information about answers given to questions.

• tags: Contains tags that can be associated with pictures and videos.

• pictures: Contains information about pictures uploaded to the SensUs Digital Platform.

• videos: Contains information about videos uploaded to the SensUs Digital Platform.

• social_logins: Contains user information provided byOAuth authentication provider.

• votes: Table linking users with their two team choices.

• questions: Contains information about questions asked on the SensUs Digital Platform.

• picture_tag: Pivot table linking pictures to their associated tags.

• tag_video: Pivot table linking videos to their associated tags.

• picture_team: Pivot table linking pictures to their associated teams.

• team_video: Pivot table linking videos to their associated teams.

Adetaileddatabasediagramspecifying the table columnsand the foreignkeysbetween the

tables is shown in Figure 10.


July 6, 2017

FIGURE 10: DATABASE SCHEMA.


July 6, 2017

5 COMPONENTDESCRIPTION

This section is omitted.


July 6, 2017

6 FEASIBILITYANDRESOURCE ESTIMATES

This sectiondescribesanestimationof requiredcomputer resources touseandrun theSensUs

Digital Platform. A distinction ismade between using the SensUsDigital Platform (i.e. running

theweb applications), hosting the SensUsDigital Platform (i.e. running the server application)

and development of the SensUs Digital Platform.

6.1 RESOURCEREQUIREMENTS

The requirements for running (i.e. using) the web applications are shown in Table 6.

TABLE 6:WEBAPPLICATIONREQUIREMENTS

CPU ≥ 1.3 GHz x86 or equivalent

RAM ≥ 1.0 GB available RAM

Software Google Chrome version 57 or later, or, Mozilla FireFox version 52 or

later.

The web application requirements are based on actual usage of the web applications. Using

performanceprofilers of browsers,we found that thewebapplicationusesup to200MBwhen

interacting with multiple pages in a short time interval. Note that in practice it will likely use

lessMBwhen little RAM is available. Nevertheless, we decided to recommend 500MB to en-

sure that the website works flawless when more content is loaded. The remaining 500 MB

is based on the Hardware Requirements of Mozilla Firefox. Note that other browsers may

require more or less RAM, for example Microsoft Edge states 1 GB as a requirement. The

CPU speed is based on the hardware requirements ofGoogle Chrome,Mozilla Firefox andMi-

crosoft Edge (which states 1.0 GHz). Moreover, this CPU requirement should be sufficient for

the front-end logic of the SensUsDigital Platform. The software requirements are recommen-

dations, intended to ensure that the browser is compatible with all front-end assets (including

JavaScript code). Finally, note that the resource requirements formobile users depends on the

browser and operating systemused; in particular the RAMusagemight be considerably lower.


July 6, 2017

The requirements for running (i.e. hosting) the server application are shown in Table 7.

TABLE 7: SERVERAPPLICATIONREQUIREMENTS

CPU ≥ Two-core 2.0 GHz x86 or equivalent

RAM ≥ 4GB of available RAM

Storage ≥ 8GB of available space

Operating System Ubuntu 16.04 or above.

Software1 PHP 7.0, NGINX v1.10.3, MariaDB 10.1.24, Composer V1.4.0 or later,

Node.js v8.1.2, NPM v5, Redis v3.2.8, Laravel Echo Server v1.2.0

Dependencies2 Non-exhaustive list of dependencies that can be automatically re-

trieved using Composer and/or NPM.

Laravel 5.4, Laravel Socialite v3.0, Predis v1.1, DoctrineDBALv2.5, Re-

act v15.6.1 (or later), Redux v3.6.0 (or later), Semantic UI v2.2, axios

v0.15.3 (or later), Papa Parse v4.3, Lodash v4.17.4 (or later), plotly.js

v1.26.1.

The server application requirements are based on simulations we performed with expected

traffic (in number of requests per second), as detailed in Section 6.2.1. Note that the server re-

quirements are in-linewith available hosting services (e.g. DigitalOcean [25]), and correspond

to a low- tomid-endmodern computer. Since the platformwill be visited almost exclusively in

a 48-hour period, we recommend amoreminimalistic server outside of that period.


July 6, 2017

Therequirements fordevelopingon (andhostinga local versionof) theSensUsDigitalPlatform

are shown in Table 8.

TABLE 8: DEVELOPMENTREQUIREMENTS

CPU ≥ 2.0 GHz x86 or equivalent

RAM ≥ 1GB of available RAM

Storage ≥ 5GB of available space

Software 1 All software requirements for the server application. Additionally, an

editor for the code files - we recommend PhpStorm.

Dependencies 2 All dependencies for the server application. Additionally:

PHPUnit v5.7 (or later), PHP_CodeSniffer v2.8.1 (or later), Mockery

v0.9, ESLint v3.19, ESLint Airbnb config v14.1 (or later), Babel for

Es2015 and React v6.24.1, Jest (and Babel for Jest) v20, Nock v9.

The development requirements are minimal and based on a low-end computer which will be

able to run the required software. However, note that a better machine is required for a good

development experience (for example, in order to fully utilize a feature-rich IDE such as Php-

Storm). A system similar to the server requirements is more realistic and is recommended.

6.2 PERFORMANCE

When evaluating estimated performance, we assume 10,000 concurrent users which gener-

ate 300,000 requests HTTP per hour (one request per user per twominutes) which is approx-

imately equal to 83 requests per second. Note that this model is based on the idea that the

number of requests per user will likely be infrequent, since many users will be watching a sin-

gle livestream for extended time periods.

Under thehardware requirements specified in theabove subsection,wecanexpect the follow-

ing performancemetrics:

• Content served by the SensUs Digital Platform shall load within 3 seconds.

• Whennewcontent (questions, answers, andmedia) is approved, that contentwill bepub-

licly visible within 30 seconds.

• When biosensor data is added or updated, all (relevant) viewerswill receive the updated

biosensor data within 30 seconds.

• When a vote is cast or updated, all (relevant) viewerswill be able to see the updated vote

counter within 30 seconds.


July 6, 2017

6.2.1 EVALUATION

In order to support the recommended system requirements of the server application, we have

performedstress-testson twoavailablemachines thatwehave labeledDigitalOceanServerand

DevelopmentMachine. Their specifications are listed in Table 9.

TABLE 9: TEST SYSTEMS’ SPECIFICATIONS

Resource DigitalOcean Server DevelopmentMachine

CPU 1 Core@2GHz 4 (Physical) [email protected]

Memory 512MB 8192MB

OS Ubuntu 16.04.2 Arch Linux (4-7-2017)

PHP Version 7.0 Version 7.1

Web-Server NGINX version/1.10.3 NGINX version/1.10.3

The tests have been performedwith theweb load testing framework Locust [26]. A single test

has been performed by simulating a 10000 users each selecting a random API endpoint, uni-

formly distributed. Furthermore, the timebetween selections is also uniformly distributed be-

tween 90s and 210s.

TABLE 10: STRESS-TESTDIGITALOCEAN SERVER

Method Name # requests Median RT (ms) Average RT (ms) Min RT (ms) Max RT (ms) Average Content Size (B) Requests/s

GET /api/questions 7302 19 20 11 696 34041 16.39

GET /api/sensordata 7275 13 14 6 1025 1530 16.33

GET /api/tags 7384 13 14 6 3017 281 16.58

GET /api/teams 7449 14 15 7 3012 16747 16.72

GET /api/videos 7479 28 34 14 3032 272 16.79

GET /api/votes/counts 7478 13 13 6 1010 104 16.79

None Total 44367 15 18 6 3032 8775 99.60

TABLE 11: STRESS-TESTDEVELOPMENT SYSTEM

Method Name # requests Median RT (ms) Average RT (ms) Min RT (ms) Max RT (ms) Average Content Size (B) Requests/s

GET /api/questions 17578 13 239 1 3312 33321 54.62

GET /api/sensordata 17409 13 240 1 3355 1518 54.10

GET /api/tags 17728 13 233 1 3357 281 55.09

GET /api/teams 17664 14 230 2 3336 16747 54.89

GET /api/videos 17645 81 316 39 3361 268 54.83

GET /api/votes/counts 17695 13 233 1 3340 104 54.98

None Total 105719 22 249 1 3361 8697 328.50

As can be seen from the results (Tables 10 and 11) the previously determined minimum of 83

requests/sec is easilymetonbothmachines. Furthermore, the average response time is orders


July 6, 2017

ofmagnitude smaller than 3 seconds, while themaximum response time is roughly around the

previously determined limit of 3 seconds. These fast response times ensure that any newly

approved or added data is almost instantly available on the website. The difference in speci-

fications and results between the twomachines also gives an indication of howwell the appli-

cation scales. Similarly, it shows that theminimum requirements as listed above for the server

application are indeed capable of fulfilling the performance requirements.


July 6, 2017

7 REQUIREMENTS TRACEABILITYMATRIX

This section describes the relation between the software requirements in the SRD [2] and the

modules of the decomposition described in Section 4 of this document. We present amapping

from the software requirements to the modules and vice versa. Note that not all software re-

quirements are implemented. When the software requirement is implemented in one of the

shared modules, we will denote that as shared:<module name>, where <module name> is re-

placed by the name of themodule in question.

7.1 SR TOMODULES

SR Server application mod-

ules

Main user application

modules

Dashboard application

modules

SR-1 User App, Shared:Login,

Shared:Menu

SR-2 Not implemented

SR-3 Authorization App Dashboard

SR-4 User

SR-5 User

SR-6 User

SR-7 User

SR-8 User App, Shared:Menu Dashboard,

Shared:Menu

SR-9 Vote Voting





SR-14 User User


SR-16 User User

SR-17 Team Teams


July 6, 2017

SR-18 Team Teams

SR-19 Team Teams

SR-20 Team Teams

SR-21 Team Teams


SR-23 Team Team

SR-24 Picture Teams

SR-25 Question Teams, QA


SR-27 Team

SR-28 About

SR-29 Video Control, Shared:Upload

‘SR-30 Not implemented




SR-34 Home

SR-35 Home










SR-45 Question Shared:Upload


July 6, 2017

SR-46 Question QA

SR-47 Answer QA

SR-48 Question QA

SR-49 Answer Teams, QA



SR-52 Answer QA

SR-53 Answer QA


SR-55 Vote Event


SR-57 Tag Explore, Teams, QA

SR-58 Livestream Home, Teams

SR-59 Livestream Home, Teams


SR-61 Measurement Biosensordata









SR-70 Live-results,

Shared:Chart

Biosensordata,

Shared:Chart

SR-71 DataSetting Teams, Live-results Biosensordata

SR-72 DataSetting Teams, Live-results,

Shared:Chart

Biosensordata


July 6, 2017

SR-73 Measurements Shared:Chart Shared:Chart




SR-77 DataSetting Biosensordata


SR-79 Video Explore, Teams




SR-83 Video Shared:Upload Shared:Upload

SR-84 Video Control

SR-85 Video Control


SR-87 Video Explore ControlPanel

SR-88 Picture Explore, Teams

SR-89 Picture Explore, Teams

SR-90 Picture Shared:Upload Shared:Upload

SR-91 Picture Control

SR-92 Picture Control

SR-93 Link Home, Explore, Teams

SR-94 Link Home, Explore, Teams








July 6, 2017






7.2 COMPONENTS TO SR

7.2.1 SERVERAPPLICATIONMODULES

Module SR

Answer SR-47, SR-49, SR-50, SR-51, SR-52, SR-53

DataSetting SR-71, SR-72, SR-77

Link SR-93, SR-94

Livestream SR-58, SR-59

Measurement SR-61, SR-62, SR-63, SR-64, SR-65, SR-66, SR-67, SR-68, SR-69, SR-73, SR-74,

SR-75

Picture SR-88, SR-89, SR-90, SR-91, SR-92

Question SR-40, SR-41, SR-42, SR-43, SR-44, SR-45, SR-46, SR-48

Tag SR-57

Team SR-17, SR-18, SR-19, SR-20, SR-21, SR-23, SR-24, SR-25, SR-27

User SR-4, SR-5, SR-6, SR-7, SR-8, SR-14, SR-16

Video SR-29, SR-79, SR-80, SR-81, SR-82, SR-83, SR-84, SR-85, SR-87

Vote SR-9

Authorization SR-3, SR-11, SR-13, SR-15

Routes

7.2.2 MAINUSERAPPLICATIONMODULES

Module SR

App SR-1, SR-3, SR-8, SR-11, SR-13, SR-15

About SR-28


July 6, 2017

Explore SR-57, SR-79, SR-80, SR-81, SR-82, SR-87, SR-88, SR-89, SR-93, SR-94

Home SR-34, SR-35, SR-58, SR-59, SR-93, SR-94

Live-results SR-70, SR-71, SR-72

QA SR-25, SR-40, SR-41, SR-42, SR-43, SR-44, SR-49, SR-50, SR-57, SR-51

Teams SR-17, SR-18, SR-19, SR-20, SR-21, SR-24, SR-25, SR-40, SR-41, SR-42, SR-43,

SR-44, SR-49, SR-50, SR-57, SR-58, SR-59, SR-51, SR-71, SR-72, SR-79, SR-80,

SR-81, SR-82, SR-88, SR-89, SR-93, SR-94

Voting SR-9

Common

7.2.3 DASHBOARDAPPLICATIONMODULES

Module SR

Dashboard SR-3, SR-8, SR-11, SR-13, SR-15

Biosensordata SR-61, SR-62, SR-63, SR-64, SR-65, SR-66, SR-67, SR-68, SR-69, SR-70, SR-71,

SR-72, SR-77

Event SR-55

QA SR-46, SR-47, SR-48, SR-52, SR-53

Team SR-23

User SR-14, SR-16

Control SR-29, SR-84, SR-85, SR-87, SR-91, SR-92

Common

7.2.4 SHAREDMODULES

Module SR

Charts SR-71, SR-72, SR-73, SR-74, SR-75

Login SR-1

Menu SR-1, SR-8

Upload SR-29, SR-45, SR-83, SR-90

Util


valedictorian architecturaldesigndocument · july6,2017 valedictorian architecturaldesigndocument...

Documents