architecturaldesigndocumentdash-it architecturaldesigndocument documentchangerecord version date...

Architectural Design Document2IPE0 SOFTWARE/WEB ENGINEERING PROJECTDASH-IT

A.S. Brouwers0934189

M.M. Kenbeek0816268

A.R. Lifmann0939291

W.D. de Vries1009509

D. Lawlor García0914832

J.J. Traas0848222

T. Honcoop0896709

P.G.R.M.J. Gerards0963833

Quartile 1 – Group 2DateOctober 30, 2018Version1.1ManagersD. BronsM.M.R. SchalkenSupervisorN. ZannoneCustomerC.G. Giraldo García

AbstractThis document presents the architectural design of the online dashboardDASH-IT. The archi-tectural design decisions in this document satisfy the requirements in the respective Soft-ware Requirements Document [1] and User Requirements Document [2]. This documentcomplies with ESA standards [3].

DASH-IT Architectural Design Document

Contents1 Introduction 51.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 Definitions and Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.3.2 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4 List of References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.5 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 SystemOverview 82.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Context and Basic Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3 Design Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.3.1 Separation of Front-End and Back-End . . . . . . . . . . . . . . . . . . . 92.3.2 Front-End Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.3 Node PackageManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.4 Front-End Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.5 CoreUI Admin Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.6 Plotly.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.7 Back-End Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.8 Back-End Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.3.9 Continuous Integration andDeployment . . . . . . . . . . . . . . . . . . 12

3 SystemContext 133.1 Coursera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 SystemDesign 144.1 DesignMethod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.2 Decomposition Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.2.1 Front-End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144.2.2 Back-End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164.2.3 File Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 Component Description 226 Feasibility and Resource Estimates 236.1 Resource Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236.2 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6.2.1 Measuring Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.2.2 Test Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.2.3 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246.2.4 Measured Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

1


6.2.5 Page Ready for User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256.2.6 Evaluation of Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

7 Requirements TraceabilityMatrix 287.1 Software Requirements toModules . . . . . . . . . . . . . . . . . . . . . . . . . 287.2 Components to Software Requirements . . . . . . . . . . . . . . . . . . . . . . . 34

7.2.1 Front-End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347.2.2 Back-End . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347.2.3 Coursera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2


Document Status SheetGeneralDocument title: Architectural Design DocumentDocument identifier: DASH-IT.ADD/1.1Authors: A.S. Brouwers 0934189

M.M. Kenbeek 0816268A.R. Lifmann 0939291W.D. de Vries 1009509D. Lawlor García 0914832J.J. Traas 0848222T. Honcoop 0896709P.G.R.M.J. Gerards 0963833

Document status: Final version

Document HistoryVersion Date Authors Reason0.1 17-10-2018 All First draft.0.2 22-10-2018 All Feedback from supervisor.0.3 24-10-2018 Anne Brouwers

Cornee TraasWouter de Vries

Feedback from supervisor.

1.0 25-10-2018 Wouter de Vries Feedback from supervisor.1.1 24-10-2018 Anne Brouwers

Peter GerardsMissing requirements.

3


Document Change RecordVersion Date Section Reason0.1 04-09-2018 All Document setup.0.1 10-10-2018 Chapter 2 Added the system overview.0.1 10-11-2018 Chapter 4 Added decomposition descriptions.0.1 11-10-2018 Chapter 3 Added the system context.0.1 12-10-2018 Chapter 6.1 Added resource requirements in Section 6.1.0.1 15-10-2018 Chapter 6.2 Added the performance test in Section 6.2.0.2 18-10-2018 Chapter 7 Other sections were almost finalized.0.2 18-10-2018 Chapter 2, 3, 4 Added introductory texts and clarified de-

scriptions.0.2 19-10-2018 Chapter 4 Added directory trees.0.3 22-10-2018 Chapter 7 Addedmissing requirements.0.3 23-10-2018 Chapter 6 Added the specifications of the test systems

used.0.3 23-10-2018 Chapter 3 Removed Section 3.2 because it was unneces-

sary.1.0 25-10-2018 Chapter 7 Changed spacing in tables to be consistent.1.1 30-10-2018 Chapter 7 Addedmissing requirements.

4


Chapter 1Introduction1.1 PurposeTheArchitecturalDesignDocument (ADD) serves topresent a thoroughviewof the softwarearchitecture present in theDASH-IT analytics tool. Each software component is hereby intro-duced individually, and each component’s description includes its dependencies, interfaces,relation to other external interfaces, as well as its relation to the SRD’s software require-ments.

1.2 ScopeDASH-IT is a project developed by a group of Computer Science students working to createa web-based dashboard that displays statistics of the online learning platformCoursera. Theproject aims to bring a functional, effective solution that involves a versatile model of smartconsiderations, involving the efficient gathering andprocessing of data to acquire the desiredoutcomes. This is done as specified by the customer representatives.DASH-IT aims to tailor-make a dashboard that has the proper functions that are required torealize the proposed solution of the project. The purpose of the dashboard is to ensure thatthe user gets an overview of all processes and their patterns and/or anomalies in their learn-ing environment, which in our case is Coursera. The displaying of this information is to bearranged in a way such that the proper knowledge can be attained intuitively by the user.Using existing technology and research in education and statistics, the people participatingin the project integrate this knowledge in a coherent framework. The approach ofDASH-IT isto integrate efficient use of statistics and learner involvement in the educational system. Ad-ditionally, the reduction of inefficient learning and/or teachingwill contribute to an improvedservice.The suitability of the resulting system will be validated by the customer for whom it is in-tended. The customer is allowed and encouraged to participate in both the development andvalidation of the product in every stage from start tofinish. Customermeetingswherein bothparties explore possibilities happen so that the understanding of what the customer wantsfor the product may improve. In a later stage they may validate the suitability of the finalproduct and its features [4].

5


1.3 Definitions and Abbreviations1.3.1 DefinitionsAngularJS (or Angular) A JavaScript framework for building dynamic web applications.Node.Js A JavaScript based server frameworkPipenv Pipenv runs Python programs in a separate environment.Plotly.js A graph library.Python A programming language.ReactJS (or React) A JavaScript library for building user interfaces.Vue.js (or Vue) A JavaScript framework for building user interfaces that is used

in this project.

1.3.2 AbbreviationsAPI Application Programming Interface.CSS Cascading Style Sheets.EIT European Institute of Innovation & Technology.ESA European Space Agency.HTML HyperTextMarkup Language.MOOC Massive OpenOnline Course.npm Node PackageManager.PDEng Professional Doctorate in Engineering.QDT Quality andDesign Team.SCSS Sassy Cascading Style Sheets.SEP Software Engineering Project.SRD Software Requirements Document.TU/e Eindhoven University of Technology.DOM Document ObjectModel.XSS Cross Side Scripting.URD User Requirements Document.

6


1.4 List of References[1] DASH-IT, Software requirements document, Eindhoven University of Technology, 2018.[2] DASH-IT,User requirements document, Eindhoven University of Technology, 2018.[3] E. B. for Software Standardisation andControl, ESA software engineering standards. 1991.[4] A. Craddock, K. Richards, D. Tudor, B. Roberts, and J. Godwin, The DSDM Agile Project

Framework for Scrum. 2012.[5] M. Butusov. (2018). Reactjs vs angular5 vs vue.js - what to choose in 2018? [Online].

Available: https://blog.techmagic.co/reactjs-vs-angular5-vs-vue-js-what-to-choose-in-2018/.

[6] P. Tasker. (2018).Vuevs react: 2018edition, [Online].Available:https://deliciousbrains.com/react-vs-vue-2018/ (visited on 08/21/2018).

1.5 OverviewThis document consists of seven chapters, the first being the current introduction. In Chap-ter 2 we present the system overview, part of which are the design decisions their motiva-tions. In Chapter 3 we describe the system context: other systems that DASH-IT interactswith. Chapter 4 corresponds to the system design, the design method and the decomposi-tion description. Chapter 5 is omitted, and Chapter 6 is a study on feasibility and resourceestimates. Finally, Chapter 7 consists of the requirements traceability matrix.

7

https://blog.techmagic.co/reactjs-vs-angular5-vs-vue-js-what-to-choose-in-2018/

https://blog.techmagic.co/reactjs-vs-angular5-vs-vue-js-what-to-choose-in-2018/

https://deliciousbrains.com/react-vs-vue-2018/

https://deliciousbrains.com/react-vs-vue-2018/


Chapter 2SystemOverviewIn this chapter we describe decisions we made concerning the design of the product, as wellas technologieswe used to develop it. Before that, we introduce the background and contextof the product, and a basic description of its design.

2.1 BackgroundCoursera is anonline learningplatformthatoffers courses, specializations, anddegrees. Cours-era works with universities and other organizations to offer online courses, specializations,and degrees in a variety of subjects, such as engineering, biology, mathematics and computerscience. Said courses are ever improvingwith time as the assigned employees are taskedwithfinding bottlenecks, choke points and other patterns and anomalies in the processes involvedin learning and teaching. When identified these anomalies and patterns can then be viewedas opportunities for improving courses, should theybedeemed interesting for suchpurposes.To this end, team DASH-IT has been endowed with the task of building a dashboard that dis-plays the analytics of the online learning platform. In more specific terms, the aim of thisdashboard is to ensure that the users are provided with an overview of the processes theywish to have displayed. In order to meet the expectations set for the dashboard, there is anintent to ensure a certain degree of convenience in working with the dashboard. This mani-fests itself in paying attention to user friendliness among other things. It is important to takeinto consideration that, while the staff that is expected to do maintenance on the system inthe future can be expected to have a sufficient level of expertise on thematter, the userswhoare mainly teachers may not. With that in mind, it is to be expected that the dashboard isconsidered usable to a plausible degree by the latter.

2.2 Context and Basic DesignTheDASH-IT dashboard is intended to be hosted on a server that can be accessed by users viaa web page. The web page is expected to load on a local browser. The client side (front-end)of the website is written in JavaScript, andwe developed it using the Vue.js framework.The server side of thewebsite is written in Python, andwe choseDjango as our developmentframework. We use the node package manager to manage our dependencies, and Travis CIto support continuous integration and deployment. We elaborate andmotivate each of thesedecisions in the following section.

8


2.3 Design DecisionsIn this section we describe and justify the design decisions made regarding the technologiesused in our product and its development, alongwith possible alternativeswe could have cho-sen.

2.3.1 Separation of Front-End and Back-EndThe software architecture of our web application consists of the front-end and back-end ofthewebsite. The front-end refers to thepart of the code that runson theclient-side (browser),and the back-end is the part that runs on the server. We use different languages (JavaScriptversus Python) and frameworks (Vue.js versus Django) on both ends of the system. Havingthis modularity is an advantage; we allow both ends of the system to be decoupled. Thisensures a clear separation between front- and back-end, and a clear definition and imple-mentation of the communication between the two. It also is an advantage since it allows foradditional front-end clients such as mobile or desktop apps to be added later on in a feasibleway. Frameworks which do not differentiate between front-end and back-end such as PHPrequire a significant amount of work to allow such additional clients, while with our methodit is implicit.

2.3.2 Front-End LanguageWe chose JavaScript as our front-end language since it is the only language that can be na-tively run in web browsers. Along with HTML and CSS it is the foundation of front-end webdevelopment, and all widely-used front-end frameworks exist to support it.An alternative would have been to use Python for the front-end, as our client voiced prefer-ence for it. Although theoretically possible, this practice is strongly discouraged in the webdevelopment world, and it would have made our goal nearly unreachable in the time we had.We presented our reasoning, and the client eventually agreed.

2.3.3 Node PackageManagerThe node package manager (npm) is the default package manager for Node.js, and the mostpopular one. Its repository contains over 600,000 different packages, and it manages over amillionpackagedownloadsperday. Weusenpmtoeasilymanageourproject’s dependencies,limitingmanual work.We can easily install our project’s dependencies using the command line client, with the sim-ple npm install command. When doing so, npm finds the needed packages, fetches them fromtheir repository, installs and configures all dependencies in the package.json project file, andwe do not need to add them to the Git repository.Wheneverwe need to run thewebsite on our development server, we can simply run the npmrun serve command to do so. We made the design decision to choose npm over other Node.jspackagemanagers. Two reasonable alternatives are presented here:

• Yarn is the "other" alternative to npm (there are more, but far less popular). It initiallyhad some advantages over npm, but recent npm updates have reduced the advantagesof using Yarn.

9


• Bower is a comparable package to npm or Yarn but it is becoming less and less relevantover time. While it is being maintained, the Bower website itself recommends users tonot use it.

2.3.4 Front-End FrameworkWe chose Vue.js as the framework for the front-end of the site because of its great archi-tecture, broad adoption among companies and the large ecosystem of additional librariesdeveloped for it. Vue is open source, but is supported by many companies using it for theirwebsites. This means that a lot of thought has gone into making Vue fast to run, and easy todevelop for. This also means that security auditors working for these companies can quicklyeliminate any security issues foundwithin Vue, or the libraries written for it.Vue has features such as hot-reload, where any changes to the source files are compiled andupdated in the browser, without needing any manual reloading of the website. This helpsenormously in giving quick feedback when developing new features, as they are instantly in-tegrated in the website without the website losing state, for example. Vue also has easy-to-addextensions for keeping the state of thewebsite, VueX. Thismeanswedonot have towritethis ourselves, eliminating a lot of bug-hunting.There are other frameworks for front-end development which are also widely used, and al-ternatives to Vue. Themain ones are:

• ReactJS is the most popular JavaScript library for building user interfaces. It is so com-prehensive that it is used as a framework in many projects. React is much bigger thanVue in terms of users (about 80 times bigger [5]), and so its ecosystem is richer. Mostpeople use the JSX JavaScript syntax extension when using ReactJS. Just like Vue, Re-act utilizes a virtual DOM. In React, everything is JavaScript, and any HTML or CSS hasto go within it, whereas Vue components are divided into three parts (each with onelanguage).

• AngularJS is another popular JavaScript front-end framework. It is open source, andmaintained by Google. In AngularJS, the script is written inside HTML, whereas Vuedivides each language in its own part of the component. Angular is more of a completesolution thanVueorReact: it containsmore functionality from the start, and it providespreferences on how to structure the web application.

The reason we chose Vue.js instead of React is because the growth of Vue compared to Re-act. While React has more users, the number of projects using Vue is growing faster. TheJavaScript ecosystem can change quickly, as existing solutions need to keep supporting theold way of doing things. Because of this better solutions compared to existing ones are al-ways being developed. We chose Vue as experts agree that it is a worthy contender for beingthemost popular framework [6].

2.3.5 CoreUI Admin TemplateAs a Vue template we use CoreUI, this is an admin template based on Bootstrap. It providesmany different useful features such as ready-to-use components, layout options (like a grid)and navigation options like for instance a breadcrumb or navigation menu. While providingmuch functionality it remains fully customizable. We have used this template as a startingpoint, while adding, removing and changing things as required. It gave us away to quickly getup and running, while not limiting us to any design choice we could not easily change.

10


2.3.6 Plotly.jsNext to theCoreUI admin templateweusea library calledPlotly.js. This libraryprovides func-tionality to easily drawmany different charts and graphs. To fullymake use of the capabilitiespresent in Vue.js, we made our own components for the graph. In this way, we can easilytranslate the data we get from the back-end into good-looking, uniform graphs. This libraryprovides its graphswith interactive functionalities out-of-the box, so actions such as zoomingin and out, or exporting the graph to PNG are already implemented.

2.3.7 Back-End LanguageFor our back-end, Python is used as a programming language. Python is a widely-used pro-gramming language for a range of applications, including back-end development. Python isa powerful, expressive language that focuses on readability, and has a large, varied ecosys-tem of open-source packages. There are several popular back-end frameworks available forPython, such as Flask andDjango.The most popular alternative for back-end development is PHP. While PHP has historicallyhad a lot of traction, it is often criticized for its inconsistent APIs in the standard library, itsoften surprising behaviour and its poor security design.Our customer expressed a preference for Python, and our teamhas former experience, soweopted for using Python over PHP.

2.3.8 Back-End FrameworkWe picked Django as our back-end framework. Django is a powerful, "batteries-included"web framework that provides a wide range of features out-of-the-box. Its Object-RelationalMapper allows toeasily interfacewith thedatabasesweuse. Djangoprovides several security-by-default features, such as parametrized queries to protect against SQL injection, and auto-matic protection against CSRF and XSS.Two commonly-used back-end framework alternatives to Django are:

• Flask is considered a Python microframework, since it relies on third-party libraries toprovide most of the functionality. Flask is often used with SQLAlchemy to interfacewith a relational database, or with MongoDB. It is a valid alternative, but one we werenot familiar with, and it requires a lot of know-how to collect third-party packages forany features we require.

• For PHP developers, Laravel is the most popular back-end framework. It follows theMVC (model-view-controller) architectural pattern. We chose not to use this becauseof the aforementioned disadvantages of PHP.

We use Pipenv as our package manager. Built as an extension on pip, Pipenv automaticallycreates avirtual environment to separate theproject’s dependencies fromsystem-widePythonpackages and other projects’ dependencies. It allows to separate development dependenciesfrom production dependencies, and provides a locking mechanism to lock dependencies tospecific versions, and allow for a stable, repeatable build.As a testing framework we use pytest. Tests in pytest are written as simple functions, usingthe built-in assert statements. It provides a powerful fixture feature that allows to inject de-pendencies into the unit tests.

11


2.3.9 Continuous Integration andDeploymentEarly on in the projectwe set up both continuous integration and deployment to speed up thedevelopment process. We use Travis CI to run all the configured unit tests before deploying.This is used for both the front-end and back-end. The front-end runs the Jest test cases af-ter which it deploys to GitHub pages. The front-end deployment only happens from a stablebranch to ensure there is always a stable version on GitHub pages.The back-end runs the pytest test cases to confirm the build works. The back-end needs anapplication server to run, so Github pages is not an option. Instead we deploy on a VirtualPrivate Server provided by the TU/e. Travis CI does not have direct access to this server, soweuse a pull-based architecture. Every 5minutes, the server checks the Travis API for the latestsuccessful build. If a new build is found, an Ansible playbook is ran to automatically update tothe latest version. It keeps one previous build around to make it easier to roll back in case oferrors.An added benefit of continuous deployment is that the client can always take a look at thelatest state of the project.

12


Chapter 3SystemContextIn this chapter we describe the external systems the tool interacts with, and the interfaces ituses to do so.

3.1 CourseraData is delivered to us by the client in a zip file, containing the data in the form of CSV files.These files can be loaded into a SQL database with help of the included load.sql file. This filecontains the SQL commands to import the CSV files, but the database schema has to be setup beforehand. For that we use a setup_unique_tables.sql, which creates the necessary tablesfor load.sql to do its work. This file waswritten by our client, and adapted by us. After this hascompleted successfully the materialized views need to be created. These present the datain the tables in a way such that we can more easily work with them. These are created bycustomDjangomigrations, and only have to be run oncewhen setting up the database. Thesematerialized views also have the advantage of maintaining their data while the underlyingtables are being updated.A separate script loads the Clickstream events table. Clickstream is the way Coursera keepstrack of what the users are doing on their site. It records when users start watching videos, itsends a heartbeat for every 5 seconds of watched video, and records when users have eitherfinished watching the video or have prematurely stopped. This data is used for many of theanalytics in the video details page. The data fits into one table, as each row contains the userdata, the type of activity that has taken place, and the actual data concerning that activity.That data is in the form of a JSON array, located in the "value" key. Postgres can directly useand filter JSON data in SQL queries. To update the data, a new zip file is provided, and thescript is run again. While this can be easily automated, for now it is a manual process, andoutside of our scope to work on.

13


Chapter 4SystemDesignThis chapter includesdetaileddescriptionsof the systemdesignused inourproduct. It specif-ically covers the decomposition of the system, the design method and the file structure foreach repository that we use.

4.1 DesignMethodThe project is decomposed into a front-end interface, a back-end log-in server, and one ormore learning-platform-specific analytics servers. We chose to decompose the project inthis way to ensure a decent decoupling of parts. Decomposing a project into front-end andback-end is commonpractice inweb-development, butwealso chose todecompose theback-end. The back-end decomposition includes user authorization and authentication function-alities, while also organizing user roles and course access. The other part of the back-endis the Coursera decomposition, which deals with all data gathered from Coursera. In princi-ple, when another platform is added to the application, a new component will be added forit, within this decomposition. We take care to ensure that all parts communicate seamlessly,and that all parts integrate into one coherent system.

4.2 Decomposition DescriptionAt the highest level, the software can be divided into the front-end, back-end and Coursera-specific components. In the following sections, the further decomposition of these compo-nents and the dependency relations that apply will be elaborated on.

4.2.1 Front-EndThe front-end includes themain user dashboard, as well as a separate view throughwhich anadministrator can manage user accounts. The components in this decomposition will largelycorrespond to the Vue components that make up the front-end.

14


Login

Settings

Navigation

Contact

Course view

Assignment view

Admin view

Home

Video view

Quiz view

Default Container

Page

Dependency on

Subclass of

Pages

Password reset view

Course comparison view

Figure 4.1: The decomposition and component dependencies of the front-end.

• Default container: Themain component of the user view of theweb application; this isa container which will at all times display the navigationmenu and one of the pages.

• Navigation: This component is responsible for rendering the header and sidebar navi-gation that is present in all other views in the user part of the front-end. This navigationmenuwill also contain the data filtering options.

• Page: The ’Page’ component represents the general concept of a pageof thedashboard:all components in the ’Pages’ section are subclasses of this page.

• Home: This component renders the first view users see upon logging in, namely theoverview of basic statistics of the courses they have available and general information.

• Course view: This component renders the page containing the graphs that representthe analytics belonging to a single course.

• Video view: This component renders the page containing the graphs that representanalytics belonging to a specific video.

• Assignment view: This component renders the page containing the graphs that repre-sent analytics belonging to the course the user has selected.

• Quiz view: This component renders the page containing the graphs that represent theanalytics belonging to the quiz the user has selected.

• Course comparison view: This component renders the page on which the analytics oftwo courses can be compared.

15


• Settings: This component renders the user settings view.• Contact: This component renders the contact page andmanages the contact form.• Login: This componentprovides the login interfaceandhandles the corresponding form.• Admin view: This component provides the admin view, where the admin has the abilityto view andmanage user accounts.

• Password reset view: This component provides a view that allows users to set a newpassword. This will be possible to set the password of a new account or if the user hasreset his password.

4.2.2 Back-EndTheback-end is responsible for providing the analytic data to the front-end, aswell as provid-ing user authorization functionality. For extensibility, functions specific to Coursera and it’sdatabase structure are in a separate ‘Coursera’ module, while platform-independent func-tionality is in the ‘Back-end’ module.

16


Coursera models

Coursera serializers

Coursera views

Coursera database

Coursera

User model

User serializer

User view

User table

Authentication

Coursera router

Back-end router

Course model

Course serializer

Course view

Course table

Back-end database

Back-end

Dependencyon

Figure 4.2: The decomposition and component dependencies of the back-end.

Back-end• Back-enddatabase: This component represents the database thatwill contain theUserand Course tables.

• Course table: The database table containing the courses that can be related to users intheUser table.

• Course model: The course model is a class describing the structure of the Course table.Themodel provides the viewswith the data from the database.

• Course serializer: The course serializer specifies to the views how the data retrieved

17


from the coursemodels should be formatted.• Course view: The course view handles requests for course data. The view uses thecorrespondingmodel object to retrieve andfilter thedata, andpasses it to the serializerto convert the relational model of the database into python objects, which the viewthen converts into JSON.

• User table: The database table containing the user accounts for the dashboard.• User model: The User model describes the structure of the User table. The model pro-vides the views and the serializer with data from the database.

• User serializer: The user serializer specifies to the views how the data retrieved fromthe user models should be formatted.

• User view: The user view handles requests for user data and returns viewsets contain-ing the requested data. The data is retrieved from the user model, and the serializer isused to determine how the data should be formatted.

• Back-end router: The back-end router routes API requests to the right user or courseview based on the URL.

• Authentication: The authentication module handles user log-in: it checks the enteredusername and password against the user database and (given the username and pass-word belong to an account) provides the user with a token.

Coursera• Coursera database: The database containing all data fromCoursera on which the ana-lytics are based. In practice, this is a snapshot of Coursera’s own database that is pro-vided to us by the client.

• Courseramodels: TheCourseramodels are classesdescribing the structureof theCours-era database. They provide the viewswith the data from the database.

• Coursera serializers: The Coursera serializers specify to the views how the data re-trieved from the Courseramodels should be formatted.

• Coursera views: The Coursera views handle requests for the Coursera analytic dataand return viewsets containing this data. The data is retrieved from the Courseramod-els, and the Coursera serializers are used to determine how this data should be format-ted.

• Coursera router: The Coursera router routes API requests to the right Coursera viewbased on the URL.

4.2.3 File StructureIn the next pages, we show the file structure of our project. Since the project is divided inthree repositories, we show each directory individually. We have not included every singlefile, since some folders contain a large number of files that are very similar to each other innature. In those cases, we describe the content in the folder without displaying all files con-tainedwithin it.

18


1. Front-end directory tree, with all relevant files and folders included:/

coverage...............Contains HTML website and tools for test coverage reportsnode_modules.......................Contains all npm packages used by the projectpublic.........................Contains all public files (images and index.html file)

img.........................................Folder containing all imported imagessrc...............................................Contains all source code (.vue files)

assets.......................Contains the assets imported into the componentsscss............................Contains all global SCSS used by components

components.................................Contains small reusable componentscontainers....................Container files (basic layout of the website page)router..............................................Contains the index router file

index.html.................Router file, manages all links within the websiteshared.............................................Contains Bootstrap sizing filesviews....................................Directory containing all page (.vue) files

admin....................Contains .vue files for admin home and admin panelcharts..........Has the chart class file, which is extended for specific graphspages.................vue files for login, forgot password, 404 and more pagesplatforms................................................Platform directories

coursera..........................................Coursera platform pagesAssignments.vue...........................Assignment overview pageCourseDetails.vue...............................Course Details pageCourses.vue.....................................Course overview pageLessons.vue....................................Lessons overview pageQuizDetails.vue....................................Quiz details pageQuizzes.vue....................................Quizzes overview pageVideoDetail.vue.................................Video overview pageVideos.vue..........................................Video details page

sidebars............................................Contains the sidebar filesBottombarNav.vue..................Bottom half of sidebar, fixed contentTopbarNav.vue........Top half of sidebar, content dinamically generated

Contact.vue..........................Contact page, independent of platformSettings.vue...................................................Settings page

App.vue...........................................First component to be createdmain.js..............................................Creates the first componentstore.js.................Manages login and logout actions, and stores the state

tests...................................................................Test directorye2e.............................................End-to-end tests (auto generated)unit............................................................Unit test directory

admin.............................................Tests for admin componentscomponents..................................Unit tests for small componentsmain.................................Main unit tests for Coursera componentspages........................Unit tests for pages components (login, 404 etc.)sidebars...................................Unit tests for sidebar components

.env.local...........................................................Root folder file

.eslintrc.js........................................................Root folder file

.travis.yml.............Declaration file for the Travis continuous integration tool

.babel.config.js............................Configuration file for Babel compiler

.jest.config.js...................................Configuration file for test suite

.package.json............................................Dependency declarations

19


2. Back-end directory tree:/

courses..........................................Courses application within Django__init__.py....................Declares that the current directory is a moduleadmin.py...Administrator display settings within Django, used for developmentapps.py................................Configuration for the courses Django appmigrations............Contains all migrations, which create materialized views

0001_initial.py.............................................................0002_auto_20180918_1154.py..............................................__init__.py.................Declares that the current directory is a module

models.py...........Contains representations of database tables within Pythonrouters.py......Generates URL patterns to route to the views within views.pyserializers.py...................Converts model instances into simple objectsviews.py.....Converts serialized instances into JSON strings for each end-point

eit_dashboard..................................Serves as the main Django project__init__.py....................Declares that the current directory is a modulesettings.py...........Sets the main application, settings and all dependenciesurls.py............Routes the URLs to the right apps and views within Djangowsgi.py.........Used by the server to communicate with the Django framework

manage.py.......................Runs the Django main function and command linetests...............................................................Contains all tests

__init__.py....................Declares that the current directory is a moduleconftest.py...................Configuration file for tests, contains sample datacourses......................................................Courses test module

__init__.py.................Declares that the current directory is a modulefactories.py........Generates mock data in the database, to later test on.test_models.py................Tests all models within the courses directorytest_serializers.py.....Tests the serializers within the courses directorytest_views.py.............................Tests for all views in courses app

users............................................................User test module__init__.py.................Declares that the current directory is a modulefactories.py.........Generates mock data in the database, to later test ontest_models.py...................................Tests all modules for userstest_serializers.py...........................Tests all serializers in userstest_urls.py............................Test for the urls.py file within userstest_views.py........................Tests for the views.py file within users

users..............................Contains all files needed for displaying user data__init__.py....................Declares that the current directory is a moduleadmin.py...Administrator display settings within Django, used for developmentapps.py..................................Configuration for the users Django appmigrations..............................................Migrations for user datamodels.py.........................................User database representationsrouters.py.............Gets the API request URL and points to the right classserializers.py...................Converts model instances into simple objectstemplates........................................................................

registration.................................................................urls.py............Routes the URLs to the right apps and views within Djangoviews.py....................Converts the serialized instances into JSON strings

20


3. Coursera database directory tree:/

auth............................................................Authorization module__init__.py....................Declares that the current directory is a modulebackends.py..............Sends request to login server, which returns user infomiddleware.py..................................Adds user object to the requestusers.py..........................................................................

coursera........................................Coursera application within Django__init__.py....................Declares that the current directory is a moduleapps.py..............................Configuration for the authorization modulemigrations.......................................................................

__init__.py.................Declares that the current directory is a modulemodels...............Contains representations of database tables within Python

__init__.py.................Declares that the current directory is a moduleactivities.py......................All represenatations activity data tablesassessments.py.......................................All assessment modelsclickstream.py...........................Models for clickstream video datacourse_structure.py........Course-structure related data representationscourses.py.................................Course data table representationsdiscussion.py....................................Models for discussion datafeedback.py........................................Models for feedback datagrades.py..........................Models for all student grade related datasessions.py..............Representation of sessions(cohort) database tablesusers.py..............................Representation of all user-related data

routers.py......Generates URL patterns to route to the views within views.pyserializers.py...................Converts model instances into simple objectsviews.py...........Convert serialized model instances into JSON string objects

coursera_ dashboard..........................Serves as the main Django project__init__.py....................Declares that the current directory is a moduledb_router.py.....Used to prevent write operations into the Coursera databasesettings.py...........Sets the main application, settings and all dependenciesurls.py............Routes the URLs to the right apps and views within Djangowsgi.py.........Used by the server to communicate with the Django framework

manage.py.......................Runs the Django main function and command linetests...................................................Directory containing all tests

__init__.py....................Declares that the current directory is a moduleauth...........................Tests for the authorisation module within Django

__init__.py.................Declares that the current directory is a moduletest_backend.py..................................Tests the backend moduletest_middleware.py.......................Tests for the middleware module

conftest.py...................Configuration file for tests, contains sample datacoursera.......................Tests for the coursera application within Django

__init__.py.................Declares that the current directory is a moduletest_models.py...........................................Tests the modulestest_serializers.py...................Serializer tests within coursera apptest_views.py......................Tests for the views within coursera app

test_db_router.py.......................................Database router tests

21


Chapter 5Component DescriptionThis chapter has been omitted.

22


Chapter 6Feasibility and Resource Estimates6.1 Resource RequirementsDevelopmentmachineminimum requirements:CPU Any capable of running the operating systems belowOperating System Any supported by the node and python ecosystem; including but

not limited toWindows,MacOS, Linux, and the BSDsMemory Minimum 1GB. Recommended at least 8GB.Disk Space 3 GB for the code and dependencies plus 5 GB for the test

databaseNetwork None needed for local testingBrowser Any browser withmore than 1%market share as of the publishing

date of the software; and their last two versions, excluding Inter-net Explorer versions below 10

Other Software Node≥ 8.0.0, npm≥ 4.0.0, Python≥ 3.6, Pipenv≥ 2018.7.1Client machine requirements:CPU Any capable of running the operating systems belowOperating System Any capable of running the browsers belowMemory At least 300MB free.Disk Space ~1MB for storing cookies and local storageNetwork At least 200 kb/s for responsive usageBrowser Any browser withmore than 1%market share as of the publishing

date of the software; and their last two versions, excluding Inter-net Explorer versions below 10

Other Software None

23


Server machine requirements:CPU Any capable of running the operating systems belowOperating System Any supported by the python ecosystem; including but not limited

toWindows,MacOS, Linux, and the BSDsMemory Minimum 1GB. We recommend an amount of RAM large enough

to fit the entire database into memory. At the moment 16GBshould suffice.

Disk Space 1 GB for the software plus at least 20 GB for the full databaseNetwork At least 200 kb/s per simultaneous userBrowser NoneOther Software Python≥ 3.6, Pipenv≥ 2018.7.1

6.2 Performance6.2.1 Measuring PerformanceThe website is required to give visual feedback within 2 seconds. This requirement is testedin this performance section. Testing is done bymeasuring the time it takes for certain eventsto happenwhile loading a page. There are two different ways of loading a page and thereforethe tests were done twice to measure the loading times of both ways. The website can beloaded in different ways because of the way it has been constructed. It is a single page ap-plication, which means that while navigating the website the user’s current page will only berewritten instead of loading an entirely new page. For this reason, measurements have beensplit up in reloading entirely newpages and rewriting the current page. For reloading entirelynew pages, the cache of Google Chrome had been disabled to closely resemble the real-lifesituation of a user using the website for the first time on their computer.

6.2.2 Test SetupThe tests were performedwhile thewebsite was hosted onGitHub pages. The browser usedis Google Chrome version 69. The machine used is running on macOS version 10.14, andhas a 2,9 GHz CPU with 2 cores and 8 GB of RAM. The network connection with the serverwas measured at 150 Mbps. Both the log-in and the Coursera server were hosted on thesame virtual machine. The machine has two cores of an Intel(R) Xeon(R) CPU E5-2690 v4 @2.60GHz, and 4GB of RAM.

6.2.3 ToolsVarious tools have been used to do the measurements. Google Chrome extensions such asPage Speed Monitor, First Paint, PageSpeed Insights Pro and Page Load Time were used.However, these extensions could not detect the transitions on the single page applicationand generally only measured the time it took for the page to be fully loaded. The GoogleChrome performance profiler provides a more detailed overview of what exactly happenswhen a page is loaded. By using the profiler, loading times of several events were measuredmaking clearwhy some pageswere loading slowly and others fast. The profiler only provideda graph, so the points in time had to be selected manually and they therefore can slightly dif-fer from the true value. All measurements have also only been done once because of time

24


constraints. The results only give an indication of the performance and do not represent av-erages.

6.2.4 Measured EventsIn total, measurements of 8 events were included in the performance tests. The profiler gavemore detailed information on full reloads than on page rewrites, which is why only 5 eventscould bemeasured for page rewrites. All the events will be explained below.

• DOMContentLoaded: The HTML file is completely loaded and parsed, while other filessuch as stylesheets and pictures are not necessarily loaded yet.

• Fully loaded: All resources of the page are loaded.• First meaningful paint: The first content that is displayed on the screen which also ismeaningful to the user.

• Last paint: The last content that had to be put onto the screen tomake the visual aspectof the page complete.

• Start animation: The fade-in animation of the page has started.• End animation: The fade-in animation of the page has ended.• Start loading: The page has started showing the loading screen.• End loading: The page is done showing the loading screen.

The differences between the events are important to understand. If the event DOMContent-Loaded is fired, it does not necessarily mean that something has been painted on the page. Itcan be fired without the user noticing this. The same holds for Fully loaded, which means thatall necessary resources have been loaded and therefore does not say anything about visualfeedback. However, the other 6 events do say something about visual feedback.Tomake sure only the time it takes for the page to load ismeasured, the eventsMouseUp andMouseDown have been used. The measurements were started from the point in time whenthe MouseUp event fired. This is when the user releases his click, which is when a new pageactually starts to load. The event is preceded by aMouseDown event, which has no effect onthe website. By excluding theMouseDown event, reaction times of the user using his mouseare eliminated from themeasurements.

6.2.5 Page Ready for UserFor a page to be considered as completely ready for the user, one has to look at one of thefollowing three events: Last paint, End animationor End loading. It depends on the type of pageto knowatwhich one of these events should be looked. Somepages havemany statistics on itand therefore have to load additional information from the server. If this takes long enough,a loading screen is presented to the user. However, the fade-in animation does not wait forthe loading to be done and could in some cases already be finished before the loading hasfinished. Therefore, a page is only completely ready for the userwhen both the End animationand End loading events have fired. This means that the final loading timewill be the longest ofthe two events. If there is no animation or loading event, only the Last paint event marks thepoint in timewhen the page is ready for the user.However, for the visual feedback requirement to hold it is not needed to have a page thatis completely ready for the user. There should only be visual feedback, to let the user knowthere is something happening. This is considered to be the First meaningful paint event. It is

25


the first point in time that the user actually sees anything meaningful related to the page hewants to see. As this was not possible to measure for page rewrites, the event Last paintwillbe used to denote the point in time the page gives visual feedback to the user.

6.2.6 Evaluation of ResultsIn the tables below, the times it took for events to fire while loading certain pages are showninmilliseconds. The following table shows the results of themeasurementsof full page reloadswith a disabled cache.Page DOMCon-

tentLoadedFullyloaded

First mean-ingful paint

Lastpaint

Start an-imation

End an-imation

Startloading

Endloading

Log-in 976 1075 1037 1075 - - - -Home 1380 1798 1663 1830 1691 2645 - -Coursera 1625 2070 1911 2104 1982 2898 - -Course 1566 1917 1803 1970 1893 2815 1893 2856Videos 1720 2275 1996 2297 2057 3053 2057 2297Quizzes 1584 1989 1836 2018 1861 2821 - -Settings 1111 1645 1396 1682 1400 2362 - -Contact 897 1258 1124 1308 1152 2109 - -Generally, first the DOMContentLoaded event is fired, then First meaningful paint after whichStart animation is fired, followed by the Fully loaded event, Last paint event and ending withEnd animation. As has been discussed, only the First meaningful paint event is required to beunder 2 seconds. As can be seen in the table, for each page the visual feedback is below2 sec-onds and therefore thewebsite satisfies the requirementwith full page reloads. However, forsome pages the time is very close to 2 seconds, which means that it could very well go abovethe limit as these measurements only give an indication and are no averages. Nevertheless,full page reloads are not the main method of navigating the website and will only be used inrare circumstances. The main method of navigating, page rewrites, is actually the one thatshould always give visual feedback within 2 seconds.Differences in loading time can be explained by the type of content on the pages. Whereasthe Log-in page is fully loaded within 100ms of loading the DOM content, the Home pageneeds over 400ms. The browser needs this extra time for rendering the page. In Chromeit could be seen that the browser starts rendering the page at 1150ms. Almost all the extratime the Home page needs is used for rendering. This can be explained by the fact that theHome page has many more graphics and the page is shown by a fade-in animation. This an-imation already starts before the page is fully loaded, and therefore rendering time is usedfor this before the page being fully loaded. The result is that firing the Fully loaded event isdelayed, whichmeans the website can feel slower because of the animation.The following table shows the results of themeasurementsof apage rewrite for certainpages.Page Last paint Start animation End animation Start loading End loadingLog-in 41 - - - -Home 392 392 1376 - -Coursera 98 98 1062 - -Course 65 65 1022 65 946Videos 94 94 1070 94 460Quizzes 72 72 1033 - -Settings 68 68 1049 - -Contact 50 50 1042 - -

26


These page transitions are considerably faster than the full page reloads. Each page is com-pletely painted for the user within 100ms. The only exception is the Home page, which wasmeasured by logging in from the Log-in page. In this measurement, the processing time oflogging in was also included, which will not be there if the user navigates to this page fromany other page than the Log-in page. The Course page still needs almost a second to load alladditional statistics, which is the same as found during the full page reload test. The reasonfor this is that the way of loading these statistics does not change between the types of pagereloads, which results in having to see the loading page for one second nonetheless.As the page rewrite is used as main method of navigating the website, the requirement ofgiving visual feedback within 2 seconds has been satisfied.

27


Chapter 7Requirements TraceabilityMatrixThis chapter includes traceability matrices between the modules from the decompositiondone in this document and the software requirements present in the [1].A couple notes to better understand the information present in this chapter:

• Most requirements do not map to elements in every component (column of the tracematrix). This is normal, for example, the first requirement (SRF1.1) refers to the factthatusershaveane-mail address associated to them. This only concerns theusermodelof the user database, and has no relation to the front-end or Coursera components, asseen in thematrix.

• Whereas the Courseramodules have names like "Coursera Views" or "Coursera Serial-izers", we have dropped the firstword in the tracematrix (third column) to avoid redun-dancy.

• All requirements that link to the back-end include an API call that passes through theback-end router. Therefore all these requirements are related to the back-end router.This is not explicitly mentioned in the following matrix due to redundancy. The samecase holds with the Coursera router.

• For the back-end and Courera components, the modules are very dependent on eachother in a layered way (see 4.2.2). For example, a requirement that is linked to theCoursera serializer (where the analytics are computed) is by dependency also linkedto themodels and theCoursera database (the analytics are computedwith informationfrom the database). We chose to link each requirement to the top-most layer possi-ble (except the back-end router), making the connection to lower layers implicit. If wehad included every relation, the trace matrices would lose clarity and readability. Thisdecision explains why some modules in Section 7.2 are not explicitly linked to any re-quirements.

7.1 Software Requirements toModulesSRF Front-endmodules Back-endmodules CourseramodulesSRF1.1 User modelSRF1.2 User modelSRF1.3 User model

28


SRF Front-endmodules Back-endmodules CourseramodulesSRF1.4 Login AuthenticationSRF1.5 Password reset view User tableSRF1.6 Settings view User tableSRF1.7 Login User viewSRF1.8 User modelSRF1.9 User tableSRF1.10 User tableSRF1.11 Course tableSRF1.12 Admin view Back-end databaseSRF1.13 Admin view Back-end databaseSRF1.14 Admin view Back-end databaseSRF1.15 UsermodelSRF1.16 Back-end databaseSRF1.17 UsermodelSRF1.18 HomeSRF1.19 Page Back-end router ViewsSRF1.20 UsermodelSRF1.21 UsermodelSRF1.22 ModelsSRF1.23 Page ViewsSRF1.24 Not implementedSRF1.25 Not implementedSRF2.1 Coursemodel ModelsSRF2.2 Coursemodel ModelsSRF2.3 Course view, Views

NavigationSRF2.4 Course Comparison, Views

NavigationSRF2.5 Default Container, Serializers

NavigationSRF2.6 ModelsSRF2.7 ModelsSRF2.8 ModelsSRF2.9 ModelsSRF2.10 ModelsSRF2.11 ModelsSRF2.12 Models

29


SRF Front-endmodules Back-endmodules CourseramodulesSRF2.13 ModelsSRF3.1 SerializersSRF3.2 SerializersSRF3.3 SerializersSRF3.4 ViewsSRF3.5 ModelsSRF3.6 SerializersSRF3.7 SerializersSRF3.8 ModelsSRF3.9 SerializersSRF3.10 SerializersSRF3.11 SerializersSRF3.12 SerializersSRF3.13 SerializersSRF3.14 SerializersSRF3.15 Not implementedSRF3.16 Not implementedSRF3.17 Not implementedSRF3.18 Serializers

30


SRF Front-endmodules Back-endmodules CourseramodulesSRF3.19 Home, Course view, Back-end router Views

NavigationSRF3.20 Course view ModelsSRF3.21 Course view ModelsSRF3.22 Course view ModelsSRF3.23 Course view ModelsSRF3.24 Course view ModelsSRF3.25 ViewsSRF3.26 ModelsSRF3.27 ModelsSRF3.28 SerializersSRF3.29 SerializersSRF3.30 SerializersSRF3.31 Not implementedSRF3.32 SerializersSRF3.33 SerializersSRF3.34 SerializersSRF3.35 SerializersSRF3.36 SerializersSRF3.37 SerializersSRF3.38 SerializersSRF3.39 SerializersSRF3.40 Not implementedSRF3.41 Not implementedSRF3.42 Course view, Views

NavigationSRF3.43 ViewsSRF3.44 ModelsSRF3.45 ModelsSRF3.46 ModelsSRF3.47 ModelsSRF3.48 ModelsSRF3.49 SerializersSRF3.50 SerializersSRF3.51 SerializersSRF3.52 Video viewSRF3.53 Not implemented

31


SRF Front-endmodules Back-endmodules CourseramodulesSRF3.54 Video view, Navigation ViewsSRF3.55 ViewsSRF3.56 ModelsSRF3.57 ModelsSRF3.58 ModelsSRF3.59 ModelsSRF3.60 Not implementedSRF3.61 SerializersSRF3.62 SerializersSRF3.63 SerializersSRF3.64 Not implementedSRF3.65 Not implementedSRF3.66 SerializersSRF3.67 SerializersSRF3.68 SerializersSRF3.69 Quiz view ViewsSRF3.70 Quiz view, Navigation ViewsSRF3.71 ViewsSRF3.72 SerializersSRF3.73 SerializersSRF3.74 SerializersSRF3.75 SerializersSRF3.76 SerializersSRF3.77 ModelsSRF3.78 ModelsSRF3.79 ModelsSRF3.80 Assignment View, Views

NavigationSRF4.1 PageSRF4.2 Page, NavigationSRF4.3 PageSRF4.4 PageSRF4.5 PageSRF4.6 PageSRF5.1 Default Container, Serializers


32


SRF Front-endmodules Back-endmodules CourseramodulesNavigation

SRF5.3 Default Container, SerializersNavigation

SRF5.4 Not implementedSRF5.5 Default Container, Serializers


NavigationSRF6.1 CoursemodelSRF6.2 CoursemodelSRF6.3 CoursemodelSRF6.4 CoursemodelSRF6.5 Course view Course tableSRF6.6 Course view Course tableSRF6.7 Course view Course tableSRF6.8 Not implementedSRF7.1 Not implementedSRF7.2 Not implementedSRF7.3 Not implementedSRF7.4 Not implementedSRF7.5 Not implementedSRF7.6 Not implementedSRF7.7 Not implementedSRF8.1 Not implementedSRF8.2SRF8.3 Course view SerializersSRF8.4 Course viewSRF8.5 Course view, Default

containerSerializers

SRF8.6 Video view, Navigation SerializersSRF8.7 Quiz view, Navigation SerializersSRF8.8 Quiz view, Navigation SerializersSRF8.9 Quiz view ModelsSRF8.10 Quiz view SerializersSRF8.11 Assignment view, Navi-

gationSerializers

SRF8.12 Assignment view, Navi-gation

SerializersSRF8.13 Not implemented

33


SRF Front-endmodules Back-endmodules CourseramodulesSRF8.14 Not implemented

7.2 Components to Software RequirementsThis section relates each module of each component of our system to the Software Require-ments it relates to. It is the inverse of the above requirements-to-modules matrix.

7.2.1 Front-EndFront-endmodules SRDefault Container SRF2.5, SRF5.1, SRF5.2, SRF5.3, SRF5.5, SRF5.6, SRF8.5Navigation SRF2.3, SRF2.4, SRF2.5, SRF3.19, SRF3.42, SRF3.54, SRF4.2,

SRF5.1, SRF5.2, SRF5.3, SRF5.5, SRF5.6, SRF8.6, SRF8.7, SRF8.8,SRF8.11, SRF8.12

Page SRF1.19, SRF1.23, SRF4.2, SRF4.3, SRF4.4, SRF4.5, SRF4.6Home SRF1.18, SRF3.19Course view SRF2.3, SRF3.19, SRF3.20, SRF3.21, SRF3.22, SRF3.23, SRF3.24,

SRF3.42, SRF6.5, SRF6.6, SRF6.7, SRF8.3, SRF8.4, SRF8.5Course comparison SRF2.4Video view SRF3.52, SRF3.54, SRF8.6Assignments view SRF3.80, SRF8.11, SRF8.12Quiz view SRF3.69, SRF3.70, SRF8.7, SRF8.8, SRF8.9, SRF8.10Settings SRF1.6Contact Does not relate to functionality present in the SRsLogin SRF1.4, SRF1.7Password reset view SRF1.5Admin view SRF1.12, SRF1.13, SRF1.14

7.2.2 Back-EndBack-endmodules SRBack-end database SRF1.12, SRF1.13, SRF1.14, SRF1.16, SRF1.19Course table SRF1.11, SRF6.5, SRF6.6, SRF6.7Coursemodel SRF6.1, SRF6.2, SRF6.3, SRF6.4Course serializer No requirement links directly to this layer of the back-endCourse view SRF2.1, SRF2.2User table SRF1.5, SRF1.6, SRF1.9, SRF1.10

34


Back-endmodules SRUsermodel SRF1.1, SRF1.2, SRF1.3, SRF1.8, SRF1.15, SRF1.17, SRF1.20,

SRF1.21User serializer No requirement links directly to this layer of the back-endUser view SRF1.7Back-end router SRF3.19Authentication SRF1.4

7.2.3 CourseraCourseramodules SRCoursera database All uses of the models, serializers and views use the information in this

moduleCourseramodels SRF1.22, SRF2.1, SRF2.2, SRF2.6, SRF2.7, SRF2.8, SRF2.9,

SRF2.10, SRF2.11, SRF2.12, SRF2.13, SRF3.5, SRF3.8, SRF3.20,SRF3.21, SRF3.22, SRF3.23, SRF3.24, SRF3.26, SRF3.27, SRF3.44,SRF3.45, SRF3.46, SRF3.47, SRF3.48, SRF3.56, SRF3.59, SRF3.77,SRF3.79

Coursera serializers SRF2.5, SRF3.1, SRF3.3, SRF3.6, SRF3.7, SRF3.9, SRF3.10,SRF3.11, SRF3.12, SRF3.13, SRF3.14, SRF3.18, SRF3.28, SRF3.29,SRF3.30, SRF3.32, SRF3.33, SRF3.34, SRF3.35, SRF3.36, SRF3.37,SRF3.38, SRF3.39, SRF3.49, SRF3.50, SRF3.51, SRF3.61, SRF3.62,SRF3.63, SRF3.66, SRF3.67, SRF3.68, SRF3.72, SRF3.73, SRF3.74,SRF3.75, SRF3.76, SRF5.1, SRF5.2, SRF5.3, SRF5.5, SRF5.6

Coursera views SRF1.19, SRF1.23, SRF2.3, SRF2.4, SRF3.4, SRF3.19, SRF3.25,SRF3.42, SRF3.43, SRF3.54, SRF3.55, SRF3.69, SRF3.70, SRF3.71,SRF3.80

Coursera router All uses of the models, serializers and views initially pass through thismodule

35

architecturaldesigndocumentdash-it architecturaldesigndocument documentchangerecord version date...

Documents