Architectural Design Document Sensus Digital

July 6, 2017 Valedictorian Architectural Design Document Version 1.0.0

Abstract

This document describes the architectural design of the SensUs Digital Platform. The architecture described by this document satisﬁes the requirements speciﬁed 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 deﬁnitions ...... 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 Splitting main 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 Design method ...... 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 Shared modules between web applications ...... 29 4.2.5 File structure ...... 30

Valedictorian | Architectural Design Document 3 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 traceability matrix 40 7.1 SR to modules ...... 40 7.2 Components to SR ...... 44 7.2.1 Server application modules ...... 44 7.2.2 Main user application modules ...... 44 7.2.3 Dashboard application modules ...... 45 7.2.4 Shared modules ...... 45

Valedictorian | Architectural Design Document 4 July 6, 2017

DOCUMENT STATUS SHEET

GENERAL

Document title: Architectural Design Document v1.0.0 Identiﬁcation: ADD/1.0.0 Authors: B.A.M. van Geffen, N. de Kroon Document status: Final 1.0.0

DOCUMENT HISTORY

Version Date Author(s) Reason 0.0.1 16-5-2017 B.A.M. van Geffen Document layout N. de Kroon

0.0.2 23-5-2017 B.A.M. van Geffen Sections 1 to 6 drafted N. de Kroon

0.0.3 28-5-2017 B.A.M. van Geffen All sections drafted, feedback N. Zan- N. de Kroon none

0.1.0 28-5-2017 B.A.M. van Geffen First version N. de Kroon

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

Valedictorian | Architectural Design Document 5 July 6, 2017

DOCUMENT CHANGE RECORDS

Section Reason 1.0.0 Incorporated ﬁnal (minor) feedback

Valedictorian | Architectural Design Document 6 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 separate 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 satisﬁed by each component. Finally, the context and overview of the system are provided, along with an estimation of the feasability and resource requirements.

1.2 SCOPE

Valedictorian is a group of computer science students working on behalf of the Eindhoven Uni- 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 a web application which acts as a platform to further engage interested 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 experience 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, including concurrent events. Finally, the website provides online viewers with the ability to engage with participating teams. This is provided through asking questions to team members, submit- ting videos and pictures of the event (and/or teams speciﬁcally), and voting for teams. Overall, the SensUs Digital Platform adds another dimension of engagement to anyone interested in following the contest.

1.3 LIST OF DEFINITIONS

Backend Data Access Layer (runs in server environment)

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

Valedictorian | Architectural Design Document 7 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 Mechanism for ﬁltering HTTP requests entering or leaving the (backend) application.

MariaDB Open-source database management system.

Laravel Open-source PHP web framework for developing MVC web application.

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 always measured in milliseconds un- less stated otherwise.

1.4 LIST OF ACRONYMS

ADD Architectural Design Document

API Application Programming Interface

CSS Cascading Style Sheets

DBMS Database Management System

DOM Document Object Model

HTML HyperText Markup Language

MVC Model-View-Controller

REST Representational State Transfer

SRD Software Requirement Document

TU/e Eindhoven University of Technology

URD User Requirement Document

Valedictorian | Architectural Design Document 8 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 SensUs Digital Platform and their interfaces and external ﬁles. Section 4 describes the system design, its decomposition into components, their relationships (such as dependencies), and design methods. 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 development and production, and discusses feasibility. Section 7 is a requirement traceability matrix, which describes how software requirements - as set out in the SRD [2] - are met by our architectural design.

1.6 LIST OF REFERENCES

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

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

[3] Facebook. The ofﬁcial React website, https://facebook.github.io/react/ (accessed on 2017- 6-27).

[4] The jQuery Foundation. The ofﬁcial jQuery website, https://jquery.com/ (accessed on 2017-6-27).

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

[6] Facebook Inc. The ofﬁcial Flux website, https://facebook.github.io/ﬂux/ (accessed on 2017-6-27).

[7] Dan Abramov. The ofﬁcial Redux website, http://redux.js.org/ (accessed on 2017-6-27).

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

[9] Bootstrap Core Team. The ofﬁcial Bootstrap website, http://getbootstrap.com/ (accessed on 2017-6-27).

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

[11] Jeremy Thomas. The ofﬁcial Bulma website, http://bulma.io/ (accessed on 2017-6-27).

Valedictorian | Architectural Design Document 9 July 6, 2017

[12] Materialize. The ofﬁcial Materialize website, http://materializecss.com/ (accessed on 2017-6-27).

[13] Taylor Otwell. The ofﬁcial Laravel website, https://laravel.com/ (accessed on 2016-6-27).

[14] MariaDB Foundation. The ofﬁcial MariaDB website, https://mariadb.org/ (accessed on 2017-6-27).

[15] Oracle Foundation. The ofﬁcial MySQL website, https://mariadb.org/ (accessed on 2017- 6-27).

[16] The PostgreSQL Global Development Group. The ofﬁcial PostgreSQL website, https://www.postgresql.org/ (accessed on 2017-6-27).

[17] IETF OAuth WG. 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- ﬁg.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 ofﬁcial Laravel website, https://laravel.com/docs/5.4/eloquent (accessed on 2016-6-27).).

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

[25] DigitalOcean Inc. The ofﬁcial DigitalOcean website, https://www.digitalocean.com/ (accessed on 2017-6-27).

[26] Locust. The ofﬁcial Locust website, http://locust.io/

Valedictorian | Architectural Design Document 10 July 6, 2017

2 SYSTEM OVERVIEW

The system is a web application that provides a platform for users to interact with the SensUs event remotely. A high level description of the SensUs Digital Platform can be found in the User Requirements Document (URD) [1]. Furthermore, a more in-depth background of the SensUs Digital Platform and the environment in which the system will 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

The SensUs Digital Platform is conceived by the SensUs organization. After organizing a highly successful ﬁrst 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 the Netherlands to physically be at the event. SensUs saw the need for a platform that enablesusers to remotely participate in theevent. Users canuse the SensUs Digital Platform to view and upload videos and pictures, ask questions and receive answers from the participating 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 organization a platform to organize different aspects of the competition, e.g. recording match results through a match data management system.

2.2 CONTEXT AND BASIC DESIGN

The SensUs Digital Platform consists of three major elements. There are two single-page web applications: a main user application which offers user interfaces to all public parts of the Sen- sUs Digital Platform, and a dashboard application that is reserved for team members and administrators that offers user interfaces to manage the content and conﬁguration of 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, they send requests to the server application through a REST API that then independently handles the requests and returns the requested data.

The web 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.

Valedictorian | Architectural Design Document 11 July 6, 2017

FIGURE 1: SYSTEM OVERVIEW DIAGRAM.

2.3 DESIGN DECISIONS

In this section we will discuss and justify the signiﬁcant design decisions made when choosing the technologies and architecture used in the SensUs Digital Platform.

2.3.1 SPLITTING MAIN USER APPLICATION AND DASHBOARD

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 team member privileges. Thereby, by splitting the web applications, we limit the access to our administration code to users that are at least somewhat vetted.

Another advantage is that it enforces a clear separation between main user code and administration code. This improves cohesion and thus the structure of the project. Furthermore, because the web application is split, a normal user would never have to load the SensUs Digital Platform administration code, thereby we improve the speed of the initial load of the web application. A disadvantage is that splitting the web 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.

Valedictorian | Architectural Design Document 12 July 6, 2017

2.3.2 MODEL-VIEW-CONTROLLER PATTERN

The Model-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 application. It divides the design into three components:

• Model: Deﬁnes the structure of the data which the application depends on.

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

• Controller: Receives signals from the views and transmits commands to the model to update the model’s state. Furthermore, sends commands to its associated views to change the view’s presentation of the model.

FIGURE 2: MODEL-VIEW-CONTROLLER DIAGRAM.

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 updates the model according to the action performed. When the model changes, it notiﬁes the controller. The controller then again updates its associated views according to the new model. A graphical representation of these principles is show in Figure 2.

The MVC pattern is used in the SensUs Digital Platform server application. The view component of the pattern is then represented by the two web applications. The two web applications also on its own implement the MVC pattern, although they use a slightly modiﬁed 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 ﬁt for the SensUs Digital 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

Valedictorian | Architectural Design Document 13 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 instances. However, since the SensUs Digital Platform does not need distributed data processing the advantages are moot. Peer-to-peer furthermore increases the difﬁculty of achieving data integrity and managing the data over the network. Therefore, this style is not a good ﬁt for the SensUs Digital Platform.

2.3.4 REACT

React [3] is a library that represents the view component of the MVC architecture of both web applications. It allows developers to declaratively describe the graphical presentation of a view 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 efﬁciently: when the model changes, a new virtual DOM is built just using JavaScript. It then changes the current actual DOM displayed in browser to equal the new virtual DOM while attempting to minimize the amount of costly DOM manipulations. This results in fast and responsive web applications. There are many alternatives to React, two of which are listed below.

• RegularHTMLandjQuery: Theclassicwaytomakewebsitesistouseamulti-pageHTML and CSS website and adding dynamic behavior by using JavaScript, often helped by using jQuery [4]. There are good reasons why this style is getting out of fashion for complex websites: because of the imperative nature of altering the DOM in this manner, it is much 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 reuse and modularity.

• 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 muchmore resemblestraditionalweb developmentwith added featurescompared to the 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 is more popular than Vue and has 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 allow much of the web-application code to be reused for an eventual mobile app.

Valedictorian | Architectural Design Document 14 July 6, 2017

2.3.5 REDUX

A problem that arises when using React is how to share data among different components. Tra- ditionally, this would give rise to a MVC pattern. However, in practice it is found that the MVC pattern is not able to handle the high level of complexity introduced by larger web applications. An illustration of this can be seen in Figure 3.

FIGURE 3: MODEL-VIEW-CONTROLLER IN PRACTICE.

The problem is that in traditional web application MVC, each component has its own associated 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 putting more constraints on the ﬂow of information through a web application. Redux [7] is the most popular implementation of this architecture, 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: REDUX ARCHITECTURE.

Valedictorian | Architectural Design Document 15 July 6, 2017

The core feature of Flux is unidirectional data ﬂow. 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 ﬂow in our web applications.

2.3.6 SEMANTIC UI

Semantic UI [8] is a development framework for designing web applications. The reason to use such a framework is simple: it makes it much easier and faster to create modern user interfaces for the SensUs Digital 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 combination 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 considered were either too minimalist (such as Pure CSS [10] and Bulma [11]) or had a less user friendly syntax for new developers (such as Bootstrap and Materialize [12]).

2.3.7 LARAVEL

Laravel [13] is an open-source PHP framework which supports development of web applications with the MVC architecture. In particular, Laravel provides tools that makes development quicker such as different ways to model 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 registered code that we do not use, and additionally that due to the abstraction we may not be able to use all features that a speciﬁc provider offers. As a concrete example, the database facade provided by Laravel is designed to work with most popular database management systems, as such we may not be able to (conveniently) use features that the speciﬁc DBMS we 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, ﬁnding expe- rienced developers is easier, and more importantly there are many resources available online. Moreover, there is an active community of developers which minimizes bugs and other quality problems in the framework, and often contribute to quicker development of new features.

The reason to use PHP (and Laravel), in comparison to other web development frameworks

Valedictorian | Architectural Design Document 16 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 to build a web server application. Moreover, within our group we had two people who had experience with Laravel speciﬁcally, and more had experience with PHP.Furthermore, a reason to use Laravel compared to other 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 speciﬁc DBMS, has security measures implemented and offers alternative ways to build a query (for example). In the end, using Laravel allowed us to develop rapidly, and, equally important, provides a more elegant transition when the codebase is picked up by other developers.

2.3.8 MARIADB

MariaDB [14] (sometimes incorrectly referred to as MySQL) is an open-source relational database management system (RDBMS). The reason to use MariaDB over MySQL [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 implemented anything speciﬁc for MariaDB, and switching to, for example, PostgreSQL [16] is as simple as changing a single conﬁguration line.

Valedictorian | Architectural Design Document 17 July 6, 2017

3 SYSTEM CONTEXT

This section describes the environment in which the SensUs Digital Platform will operate. The external interfaces that the SensUs Digital Platform uses are detailed explicitly. In particular we describe how YouTube’s and Google OAuth’s external interfaces are used to retrieve information necessary for our services.

3.1 YOUTUBE

The Youtube Data API (v3) [19] is used to retrieve information about uploaded content (videos and streams) on the SensUs Digital Platform. The data retrieval is done by making API calls to the Google server, and the Google server responds with the requested information in JSON format.

3.1.1 CORE REQUEST

This section describes the bare request, meaning without any optional data requested, and response to the YouTube API. The request is a GET request, and contains the key (our YouTube API key) and id (the video ID) ﬁelds. 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 YOUTUBE API RESPONSE OBJECT

Property Description

kind string Identiﬁes the type of API resource of the response.

etag string The entity tag of the resource; used to identify a speciﬁc 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. integer resultsPerPage The number of results included in the response.

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

Valedictorian | Architectural Design Document 18 July 6, 2017

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

TABLE 4: THE VIDEO RESOURCE OBJECT

Property Description

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 REQUESTING PARTS

The core request yields a video resource with little data on the video resource. By providing the parts ﬁeld 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 resource will 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 GOOGLE OAUTH

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 workﬂow 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)

The OAuth 2.0 open standard, as described in RFC 6749 [17], is followed by 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 workﬂow (also see Fig-

Valedictorian | Architectural Design Document 19 July 6, 2017

TABLE 5

Property Description

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

snippet.publishedAt datetime The date and time that the video was published on YouTube.

snippet.channelId string Identiﬁes the YouTube channel to which the video was 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 Identiﬁer of the YouTube category associated with the video.

snippet. string liveBroadcastContent 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. unsigned long commentCount 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).

Valedictorian | Architectural Design Document 20 July 6, 2017

2. The Web Server handles the OAuth 2.0 response, which - when authentication was successful - contains the state (from the request) and an authorization code.

3. The Web Server exchanges the authentication code for access tokens. The corresponding request to the Google authorization server contains - next to the received authorization code - the Client ID and a Client secret. Note that unlike in step 1, this call is made directly from the Web Server to Google’s server.

4. The Web Server handles the OAuth 2.0 response, which contains access tokens. Authen- tication is completed.

5. The access tokens are used for all following API calls to Google, for example for retrieving some proﬁle information.

FIGURE 5: GOOGLE OAUTH 2.0 WEB APPLICATION 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 example hosted on popular services such as Imgur) and will simply be rendered in a HTML image element. Note that no content (including images) will be publicly visible before an authorized administrator approves the content.

Valedictorian | Architectural Design Document 21 July 6, 2017

4 SYSTEM DESIGN

This chapter contains details about the system design of the SensUs Digital Platform . The design method, component decomposition, ﬁle structure, and database design will be covered in this chapter.

4.1 DESIGN METHOD

The system is decomposed in the main user web application, dashboard web application and the server application. These three applications are designed to be as separate from each other as possible, with the exception of some code reuse in the dashboard and main user web applications. 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 applications are written in JavaScript with React and follow the Airbnb JavaScript Style Guide [21] and Airbnb React/JSX Style Guide [22].

4.2 DECOMPOSITION DESCRIPTION

The decomposition of the SensUs Digital Platform into separate components is based on the requirements in the URD [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 ﬁle structure of the project and 4.2.4 describes the database design.

4.2.1 SERVER APPLICATION DECOMPOSITION

The server application is responsible for maintaining and retrieving data in the database. As such, the server application consists mainly of the Model and Controller aspect of the application as a whole. The back-end is written to be RESTful and modular, which results in interoper- ability between computer systems and web applications. First, we decompose the the server application in the major constructs provided by Laravel which we extent and on which we 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 all HTTP requests that enter the application. The kernel applies “bootstrapping” to register core features such logging, exception handlers and middleware 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. The most important step is loading the service providers of our application.

Valedictorian | Architectural Design Document 22 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 to as “bootstrapped”) include components related to queuing, databases, caching, validation, 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 applying middleware spe- ciﬁc to that request (for example authorization middleware is often applied to a single route), and then ﬁnally passing the request to the right controller.

4.2.1.4 Middleware

Middleware are used to process, ﬁlter, 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 requests. More commonly, middleware is applied to a group of routes; for example for authentication, encrypting cookies and preventing banned users from accessing the site.

4.2.1.5 Controller

A controller is a grouping (class) of related request handling logic. In short, a Controller consists of one or more handlers for incoming requests, and are responsible for outputting changes to the models and/or views.

4.2.1.6 Models

Each database table has a corresponding model, which are used by Laravel’s Object-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 controller logic). In our case, Laravel’s views are only used to render the web applications.

Valedictorian | Architectural Design Document 23 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, which are stored byindividual voteentries in the database. Using the cache we store the counts per team instead of individual votes to avoid recomputing.

4.2.1.9 Modules

The “modules” of the server application are deﬁned 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 ﬁll 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: The DataSetting module is used to configure Live (Sensor Data) results. The model consists of a key (string) value (boolean) pair to enable or disable settings. The result is a flexible way to configure settings related to live results (for example to hide/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: AsubclassofLinksthatholdthelivestreams. TheyaremanagedbyLiveStream- Controller, and are only seeded in development environments.

• Measurement: The sensor data measurements are represented by the Measurement model. They are managed 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, however, it will create mostly empty measurements rows which can be edited in the dashboard application.

Valedictorian | Architectural Design Document 24 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 environments.

• Question: The Question module consists of a Model for the questions for the Q&A functionality, and the QuestionController for the logic.

• Tag: The tag module is used to tag teams to submitted media. Besides the tag model, there is a migration for the join table to manage the many-to-many relationship between tags and media. Tagsare 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 updated with the TeamCon- troller.

• User: The user module manages user accounts, and is used for authentication and authorization. Users are managed by the AuthController, which creates, updates and incorpo- rates user management (for administrators only) for manually changing user details such as associated team and user role.

• Video: A subclass of Link that holds submitted videos. Videos are managed by the Video- Controller (which extends the MediaController) and are only seeded in development environments.

• 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 dashboard 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, we mark such modules with a double border. Clearly, almost every module is used by the Routes module. This makes sense, as the Routes module deﬁnes all possible endpoints of our server application. Note that the Middleware block contains all default Laravel middleware.

Valedictorian | Architectural Design Document 25 July 6, 2017

Another important module is the Link module, which is used by all media, questions, media and livestreams. DataSetting is not directly used by any other modules (except for Routes), as it used for conﬁguration on the front-end. Finally, the Views module is not included in the diagram as it consist of only two trivial methods to return views. Note that Views (like most other modules) is used by the Routes module.

FIGURE 6: BACK-END DEPENDENCY SCHEMA.

4.2.2 MAIN USER WEB APPLICATION DECOMPOSITION

The main user web application is decomposed in the following modules:

• 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 content 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. informationaboutthejudgesoftheevent.

• Explore: This module is responsible for rendering a view that shows all the dynamic media which is currently public.

Valedictorian | Architectural Design Document 26 July 6, 2017

• Home: This module is responsible for rendering a view that displays the home page of the main 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: This module is responsible for rendering a view that displays the approved questions 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 competition).

• Voting: Thismoduleisresponsibleforrenderingaviewthatallowsuserstovoteonteams, 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 these modules can be found in Figure 7. As can be seen, the dependencies of the main user web application follow a clear pattern. The App module is always active, and it renders one of the other modules. The other modules have no interdependencies, and may only depend on shared code contained in Common or Shared. Note that Common is used exclusively by the Main User Application, while Shared is used by both web applications.

FIGURE 7: MAIN USER APPLICATION DEPENDENCY 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. Speciﬁcally, each module

Valedictorian | Architectural Design Document 27 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 components, 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 displaying 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 representational concerns is essential is achieving maintainability in a react application.

4.2.3 DASHBOARD WEB APPLICATION DECOMPOSITION

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 following modules:

• Dashboard: This is the main module of the dashboard application. It renders the menu banner on the top of the website. Furthermore, it acts as a router and displays as its main content the view currently selected as route.

• Biosensordata: This module is responsible for rendering a view that displays the data currently entered about the event, as well as allowing administrators to manage this data.

• Event: This module 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 isresponsible forrendering aview thatallows users tomanage theques- tions and answers section of the SensUs Digital Platform.

• Team: This module is responsible for rendering a view that allows administrators to manage the team portion of the SensUs Digital Platform, e.g. altering the team descriptions.

• User: This module is responsible for rendering a view that allows administrators to manage 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.

Valedictorian | Architectural Design Document 28 July 6, 2017

A dependency diagram for these modules can be found in Figure 8. As can be seen, similarly to the main user application, the dependencies of the dashboard application follow a clear pattern. 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 contained in Common or Shared.

FIGURE 8: DASHBOARD APPLICATION DEPENDENCY SCHEMA.

4.2.4 SHARED MODULES BETWEEN WEB APPLICATIONS

Besides the modules speciﬁc for the two applications, there are also shared modules that contains code that is shared between the two applications. This code is contained in a single folder onthesamelevelasthetwowebapplications. Thefollowingmodulesareincludedintheshared 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, deﬁnition of some types etc.

A dependency diagram for these modules 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 and Menu).

Valedictorian | Architectural Design Document 29 July 6, 2017

FIGURE 9: SHARED MODULES DEPENDENCY SCHEMA.

4.2.5 FILE STRUCTURE

The project has a nested and complex file structure. Tobe specific, the server application is the root of the project. The main user and dashboard applications are sub-folders of the server application project. First we 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 with mock modules 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 customer middleware [Models]...... Contains the Model 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 NPM packages (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

Valedictorian | Architectural Design Document 30 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 the main user and dashboard applications [charts]...... Module containing shared chart components [login]...... Module containing shared login component [menu]...... Module containing shared menu component [upload]...... Module containing shared upload component [util]...... Module containing some shared functions and components [dashboard]...... Directory containing dashboard application [biosensordata] ...... Contains the Biosensordata module code [common] ...... Contains code shared between dashboard application modules [dashboard] ...... Contains the code for the Dashboard module [event] ...... Contains the code for the Event module [qa] ...... Contains the code for the QA module [team] ...... Contains the code for the Team module [user] ...... Contains the code for the User module dashboard.jsx ...... The entry file of the dashboard web application [main] ...... Directory containing the main user application [about]...... Contains the code for the About module [app] ...... Contains the code for the App module [common]...... Contains code shared between main application modules [explore]...... Contains code for the Explore module [home]...... Contains code for the Home module [liveresults]...... Contains code for the Liveresults module [qa]...... Contains code for the QA module [teams]...... Contains code for the Teams module [voting]...... Contains code for the Voting module app.jsx...... The entry file of the main user web application

4.2.6 DATABASE DESIGN

The database is implemented using a traditional relational database model. Our database design 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.

Valedictorian | Architectural Design Document 31 July 6, 2017

• users: Contains information about each user.

• measurements: Contains the measurement 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 by OAuth 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.

A detailed database diagram specifying the table columns and the foreign keys between the tables is shown in Figure 10.

Valedictorian | Architectural Design Document 32 July 6, 2017

FIGURE 10: DATABASE SCHEMA. Valedictorian | Architectural Design Document 33 July 6, 2017

5 COMPONENT DESCRIPTION

This section is omitted.

Valedictorian | Architectural Design Document 34 July 6, 2017

6 FEASIBILITY AND RESOURCE ESTIMATES

This section describes an estimation of required computer resources to use and run the SensUs Digital Platform. A distinction is made between using the SensUs Digital Platform (i.e. running the web applications), hosting the SensUs Digital Platform (i.e. running the server application) and development of the SensUs Digital Platform.

6.1 RESOURCE REQUIREMENTS

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

TABLE 6: WEB APPLICATION REQUIREMENTS

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 performance profilers of browsers, we found that the web application uses up to 200 MB when interacting with multiple pages in a short time interval. Note that in practice it will likely use less MB when little RAM is available. Nevertheless, we decided to recommend 500 MB to ensure 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 of Google Chrome, Mozilla Firefox and Mi- crosoft Edge (which states 1.0 GHz). Moreover, this CPU requirement should be sufficient for the front-end logic of the SensUs Digital 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 for mobile users depends on the browser and operating system used; in particular the RAM usage might be considerably lower.

Valedictorian | Architectural Design Document 35 July 6, 2017

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

TABLE 7: SERVER APPLICATION REQUIREMENTS

CPU ≥ Two-core 2.0 GHz x86 or equivalent

RAM ≥ 4 GB of available RAM

Storage ≥ 8 GB 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 retrieved using Composer and/or NPM. Laravel 5.4, Laravel Socialite v3.0, Predis v1.1, Doctrine DBAL v2.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 trafﬁc (in number of requests per second), as detailed in Section 6.2.1. Note that the server requirements are in-line with available hosting services (e.g. DigitalOcean [25]), and correspond to a low- to mid-end modern computer. Since the platform will be visited almost exclusively in a 48-hour period, we recommend a more minimalistic server outside of that period.

Valedictorian | Architectural Design Document 36 July 6, 2017

The requirements for developing on (and hosting a local version of) the SensUs Digital Platform are shown in Table 8.

TABLE 8: DEVELOPMENT REQUIREMENTS

CPU ≥ 2.0 GHz x86 or equivalent

RAM ≥ 1 GB of available RAM

Storage ≥ 5 GB of available space

Software 1 All software requirements for the server application. Additionally, an editor for the code ﬁles - 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 conﬁg 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 two minutes) 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 single livestream for extended time periods. Under the hardware requirements speciﬁed in the above subsection, we can expect the following performance metrics:

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

• When new content (questions, answers, and media) is approved, that content will be publicly visible within 30 seconds.

• When biosensor data is added or updated, all (relevant) viewers will receive the updated biosensor data within 30 seconds.

• When a vote is cast or updated, all (relevant) viewers will be able to see the updated vote counter within 30 seconds.

Valedictorian | Architectural Design Document 37 July 6, 2017

6.2.1 EVALUATION

In order to support the recommended system requirements of the server application, we have performed stress-tests on two available machines that we have labeled Digital Ocean Server and Development Machine. Their speciﬁcations are listed in Table 9.

TABLE 9: TEST SYSTEMS’ SPECIFICATIONS

Resource DigitalOcean Server Development Machine

CPU 1 Core @2GHz 4 (Physical) Cores @2.4GHz

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 performed with the web load testing framework Locust [26]. A single test has been performed by simulating a 10000 users each selecting a random API endpoint, uniformly distributed. Furthermore, the time between selections is also uniformly distributed between 90s and 210s. TABLE 10: STRESS-TEST DIGITAL OCEAN 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-TEST DEVELOPMENT 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 easily met on both machines. Furthermore, the average response time is orders

Valedictorian | Architectural Design Document 38 July 6, 2017 of magnitude smaller than 3 seconds, while the maximum 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- ﬁcations and results between the two machines also gives an indication of how well the application scales. Similarly, it shows that the minimum requirements as listed above for the server application are indeed capable of fulﬁlling the performance requirements.

Valedictorian | Architectural Design Document 39 July 6, 2017

7 REQUIREMENTS TRACEABILITY MATRIX

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 a mapping from the software requirements to the modules and vice versa. Note that not all software requirements are implemented. When the software requirement is implemented in one of the shared modules, we will denote that as shared:, where is re- placed by the name of the module in question.

7.1 SR TO MODULES

SR Server application mod- Main user application Dashboard application ules modules 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-10 Not implemented

SR-11 Authorization App Dashboard

SR-12 Not implemented

SR-13 Authorization App Dashboard

SR-14 User User

SR-15 Authorization App Dashboard

SR-16 User User

SR-17 Team Teams

Valedictorian | Architectural Design Document 40 July 6, 2017

SR-18 Team Teams

SR-19 Team Teams

SR-20 Team Teams

SR-21 Team Teams

SR-22 Not implemented

SR-23 Team Team

SR-24 Picture Teams

SR-25 Question Teams, QA

SR-26 Not implemented

SR-27 Team

SR-28 About

SR-29 Video Control, Shared:Upload

‘SR-30 Not implemented

SR-31 Not implemented

SR-32 Not implemented

SR-33 Not implemented

SR-34 Home

SR-35 Home

SR-36 Not implemented

SR-37 Not implemented

SR-38 Not implemented

SR-39 Not implemented

SR-40 Question Teams, QA

SR-41 Question Teams, QA

SR-42 Question Teams, QA

SR-43 Question Teams, QA

SR-44 Question Teams, QA

SR-45 Question Shared:Upload

Valedictorian | Architectural Design Document 41 July 6, 2017

SR-46 Question QA

SR-47 Answer QA

SR-48 Question QA

SR-49 Answer Teams, QA

SR-50 Answer Teams, QA

SR-51 Answer Teams, QA

SR-52 Answer QA

SR-53 Answer QA

SR-54 Not implemented

SR-55 Vote Event

SR-56 Not implemented

SR-57 Tag Explore, Teams, QA

SR-58 Livestream Home, Teams

SR-59 Livestream Home, Teams

SR-60 Not implemented

SR-61 Measurement Biosensordata

SR-62 Measurement Biosensordata

SR-63 Measurement Biosensordata

SR-64 Measurement Biosensordata

SR-65 Measurement Biosensordata

SR-66 Measurement Biosensordata

SR-67 Measurement Biosensordata

SR-68 Measurement Biosensordata

SR-69 Measurement Biosensordata

SR-70 Live-results, Biosensordata, Shared:Chart Shared:Chart

SR-71 DataSetting Teams, Live-results Biosensordata

SR-72 DataSetting Teams, Live-results, Biosensordata Shared:Chart

Valedictorian | Architectural Design Document 42 July 6, 2017

SR-73 Measurements Shared:Chart Shared:Chart

SR-74 Measurements Shared:Chart Shared:Chart

SR-75 Measurements Shared:Chart Shared:Chart

SR-76 Not implemented

SR-77 DataSetting Biosensordata

SR-78 Not implemented

SR-79 Video Explore, Teams

SR-80 Video Explore, Teams

SR-81 Video Explore, Teams

SR-82 Video Explore, Teams

SR-83 Video Shared:Upload Shared:Upload

SR-84 Video Control

SR-85 Video Control

SR-86 Not implemented

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

SR-95 Not implemented

SR-96 Not implemented

SR-97 Not implemented

SR-98 Not implemented

SR-99 Not implemented

SR-100 Not implemented

Valedictorian | Architectural Design Document 43 July 6, 2017

SR-101 Not implemented

SR-102 Not implemented

SR-103 Not implemented

SR-104 Not implemented

SR-105 Not implemented

7.2 COMPONENTS TO SR

7.2.1 SERVER APPLICATION MODULES

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 MAIN USER APPLICATION MODULES

Module SR

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

About SR-28

Valedictorian | Architectural Design Document 44 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 DASHBOARD APPLICATION MODULES

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 SHARED MODULES

Module SR

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

Menu SR-1, SR-8

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

Util

Valedictorian | Architectural Design Document 45