FACULTY OF AUTOMATION AND COMPUTER SCIENCE 2017 ACTIVITY MANAGEMENT APPLICATION FOR STUDENTS AND TEACHERS BACHELOR’S THESIS Author: Róbert ISTÓK… [624467]

FACULTY OF AUTOMATION AND COMPUTER SCIENCE
2017
ACTIVITY MANAGEMENT APPLICATION FOR STUDENTS AND TEACHERS BACHELOR’S THESIS Author: Róbert ISTÓK Supervisor: Assist Prof. Eng. Iulia STEFAN

FACULTY OF AUTOMATION AND COMPUTER SCIENCE

DEAN Prof. Dr. Eng. Liviu MICLEA Approved, HEAD OF AUTOMATION DEPARTMENT Prof. Dr. Eng. Honoriu VĂLEAN Author: Róbert ISTÓK Activity Management Application for Students and Teachers 1. Theme statement: The central theme of the project is to showcase the benefits of using a centralized application for managing the activities of students and teachers of an educational institution. 2. Project’s content: Presentation page; Declaration of Authenticity; List of Figures; Table of Contents; Introduction; Bibliographic Study; Analysis, Design, Implementation and Testing; Conclusions; References 3. Place of documentation: Technical University of Cluj-Napoca 4. Theme issue date: 12 December 2016 5. Submission date: 11 July 2017 Author’s signature Supervisor’s signature

FACULTY OF AUTOMATION AND COMPUTER SCIENCE

Declarație pe proprie răspundere privind autenticitatea proiectului de diplomă Subsemnatul(a) Róbert ISTÓK , legitimat(ă) cu CI/BI seria KV nr. 282152, CNP [anonimizat] , autorul lucrării: Activity Management Application for Students And Teachers elaborată în vederea susținerii examenului de finalizare a studiilor de licență la Facultatea de Automatică și Calculatoare, specializarea Automatică și Informatică Aplicată (în limba engleză) din cadrul Universității Tehnice din Cluj-Napoca, sesiunea de vară a anului universitar 2016-2017, declar pe proprie răspundere, că această lucrare este rezultatul propriei activități intelectuale, pe baza cercetărilor mele și pe baza informațiilor obținute din surse care au fost citate, în textul lucrării, și în bibliografie. Declar, că această lucrare nu conține porțiuni plagiate, iar sursele bibliografice au fost folosite cu respectarea legislației române și a convențiilor internaționale privind drepturile de autor. Declar, de asemenea, că această lucrare nu a mai fost prezentată în fața unei alte comisii de examen de licență. In cazul constatării ulterioare a unor declarații false, voi suporta sancțiunile administrative, respectiv, anularea examenului de licență. Data Prenume NUME Róbert ISTÓK (semnătura)

Table of Contents
1 Table of Contents TABLE OF CONTENTS …………………………………………………………………………………………………….. 1 1 INTRODUCTION ……………………………………………………………………………………………………… 3 1.1 THE PURPOSE OF THE PROJECT ……………………………………………………………………………………… 3 1.2 DESCRIPTION OF THE PROBLEM …………………………………………………………………………………….. 3 1.3 REQUIREMENTS ……………………………………………………………………………………………………….. 3 1.3.1 Students ………………………………………………………………………………………………………. 4 1.3.2 Teachers ………………………………………………………………………………………………………. 4 1.4 OBJECTIVES …………………………………………………………………………………………………………….. 4 2 BIBLIOGRAPHIC STUDY ……………………………………………………………………………………………. 5 2.1 STATE OF THE ART …………………………………………………………………………………………………….. 5 2.1.1 Edmodo ……………………………………………………………………………………………………….. 5 2.1.2 Student portal for the Maastricht University …………………………………………………….. 5 2.1.3 Academicinfo for UBB ……………………………………………………………………………………. 5 2.1.4 Depinfo TUCN ………………………………………………………………………………………………. 6 2.1.5 Moodle ………………………………………………………………………………………………………… 6 2.1.6 FEEA App ……………………………………………………………………………………………………… 6 2.1.7 Social networks, Email, PDFs, Websites, and more ……………………………………………. 6 2.2 TECHNOLOGIES ………………………………………………………………………………………………………… 7 2.2.1 Backend ………………………………………………………………………………………………………. 7 2.2.2 Frontend ……………………………………………………………………………………………………. 10 2.2.3 Testing ………………………………………………………………………………………………………. 14 2.2.4 Deployment, hosting and package management …………………………………………….. 15 3 ANALYSIS, DESIGN, IMPLEMENTATION AND TESTING …………………………………………………. 16 3.1 PROBLEM ANALYSIS ………………………………………………………………………………………………… 16 3.2 USER STORIES ………………………………………………………………………………………………………… 16 3.3 STACK ANALYSIS …………………………………………………………………………………………………….. 17 3.3.1 Other possible choices …………………………………………………………………………………. 18 3.4 PROBLEM MODELLING ……………………………………………………………………………………………… 19 3.4.1 Use cases …………………………………………………………………………………………………… 20 3.5 DATABASE DESIGN ………………………………………………………………………………………………….. 23 3.6 ARCHITECTURE ………………………………………………………………………………………………………. 25 3.7 PROJECT STRUCTURE ……………………………………………………………………………………………….. 26 3.7.1 Server ………………………………………………………………………………………………………… 26 3.7.2 Client …………………………………………………………………………………………………………. 27 3.8 INSTALLATION GUIDE ……………………………………………………………………………………………….. 28 3.8.1 System requirements …………………………………………………………………………………… 29 3.8.2 Steps for cloning and starting the development environment ……………………………. 29 3.9 IMPLEMENTATION …………………………………………………………………………………………………… 30

Table of Contents
2 3.9.1 Database ……………………………………………………………………………………………………. 30 3.9.2 Server ………………………………………………………………………………………………………… 34 3.9.3 Client …………………………………………………………………………………………………………. 37 3.10 TESTING ………………………………………………………………………………………………………………. 52 3.10.1 Test Case 1, Login of a teacher ……………………………………………………………………… 52 3.10.2 Test Case 2, Sending a message ……………………………………………………………………. 54 3.10.3 Test Case 3, Responsive design ……………………………………………………………………… 55 4 CONCLUSIONS ……………………………………………………………………………………………………… 56 4.1 RESULTS OBTAINED …………………………………………………………………………………………………. 56 4.2 DEVELOPMENT DIRECTION ………………………………………………………………………………………… 57 5 REFERENCES ………………………………………………………………………………………………………… 58 6 LIST OF FIGURES …………………………………………………………………………………………………… 60

Introduction
3 1 Introduction 1.1 The purpose of the project The purpose of this project is to review the management tools used to establish the communication between students and teachers by different universities from all around the world, propose a new solution to the problem of using multiple tools and present how they could benefit from using a centralized online platform to deal with all the activity management problems. 1.2 Description of the problem The tools used to communicate, share information and solve the organizational questions at the majority of the universities from all around the world should be designed in such a way to make the process simple, fast and enjoyable. By implementing specific solutions, on one hand, professors could focus on the mission of sharing their knowledge. Students, on the other hand, would be able to focus on constant learning and improving, without being distracted by tools complexity. The respective tools should be optimized for time-efficiency, have all the necessary functionalities for a given university and they must be reliable, scalable and secure. They should have a simple, accessible and user-friendly interface to increase usability. However, the tools used by the majority of the universities in Romania are complex, confusing and time-consuming. By wasting hours, the current tools make hard for professors to focus on teaching and for students to get the most out of their university years. By these tools being complex and confusing, they lead to errors and misunderstandings in the system, which are hard to trace down. Digital communication between students and teachers is hard, due to reduced contact information from both sides. This also leads to headaches while making every kind of announcement outside the classes, often leading to the irrelevance of the information by the time it gets to the targeted parties. Using a centralized application having all the necessary information at one place, universities would be able to manage reducing the waste of time, improve student performance and reduce the stress level of professors. 1.3 Requirements The most critical requirement of the application is to solve the problem of information being stored at multiple places. The proposed solution is to develop a centralized web application where all the administration issues can be solved. The application should be used by all students and professors of a given university, otherwise its value is diminished. In order to convince them to use the application for all the teaching activities related

Introduction
4 problems, instead of the old tools, the application should remove the majority of current obstacles from their daily routines. In order to solve this critical requirement, the following requirements should be fulfilled: General: login system; forget password; have everything at one place without depending on other environments and tools; search for materials; brief overview about the upcoming week; spend as little time as possible with administration; simple user interface. Messages: contact teachers/students; view past conversations; filter conversations; mark important conversations. Settings: change personal information; change passwords. 1.3.1 Students Performance: view grades; view past year’s performance; track attendance Materials: have access to all the materials at one place (notes regarding the lecture’s procedure for finalizing it, pdfs); read articles recommended by teachers Notifications: get notified by teachers about changes in the schedule; get notified about updates on the lectures Social: get notified about career opportunities and interesting events 1.3.2 Teachers Performance: enter grades for students; track attendance; change grades/attendance Materials: manage all materials at one place; recommend articles to students; Notifications: send notifications about schedule changes to the students; Social: notify students about career opportunities and interesting events 1.4 Objectives To fulfill the requirements mentioned before, the objective of the project is to develop a web-application that consists of: • Improve and increase the communication amongst students and teachers by using a messaging system with a friendly interface. • Increase the chance of arriving of the information in time to the desired persons, with a push notification system. • Increase the focus of the professors and student by having attendance, grades, materials, messages, performance and posts all at one place. • Replacing Facebook groups from the tools used to manage university related stuff, Facebook being a huge distraction for students. • Make getting information about schedules intuitive by developing a dynamic schedule component. • Give the ability to users to have an overview about the latest happenings in a given course, by showing all the relevant posts on the homepage.

Bibliographic Study
5 2 Bibliographic Study 2.1 State of the art There are few similar applications used by educational centers all around the world. All of these applications have some features common with UTSocial, but they are not completely focused on the problems this application will solve. It is really interesting though, that approximately all universities worldwide use some kind of internal portals, mostly to manage their students’ grades, but there is no major commercial application incorporating high level educational institutions into one universal solution. This is understandable at some level, because managing a university is complex, as every institution has their own system configured to their own needs. The problem lies in the fact that these applications do not solve the activity management of the courses. Let's see what are the current solutions trying to solve this problem. 2.1.1 Edmodo Edmodo[1] is one of the best solution available right now on the market. It emphasizes teaching over paperwork, promising full control over the digital classroom of a teacher. Using the platform, professors can easily assign homework, schedule quizzes, track performance, upload materials etc. Scheduling quizzes online is a huge plus, it can help to reduce waste of paper dramatically. One of its awesome features is involving parents into the learning process. This encourages the moms and dads to take their part even more in the education of their children. They do not mention universities though, promoting the system only up to high-school. 2.1.2 Student portal for the Maastricht University This application[2] came the closest to UTSocial with its user-friendly interface and the similarity of its features. There are two major features missing from this application, which are present in UTSocial. One is the interactive schedule, where users can view and filter the schedule for whom they want. The other one is the newsfeed, where teachers can update their students of the current situation. 2.1.3 Academicinfo for UBB The platform[3] for the students, teachers and managers of the University of Babes Bolyai in Cluj-Napoca. Its main features consist of the online catalog, professor reviews, information about the university, learning plan and checking the current courses of a student. It has a basic design and it was written using the ASP.NET framework, with HTML, CSS and JavaScript on the frontend.

Bibliographic Study
6 2.1.4 Depinfo TUCN Depinfo[4] is the application used at the Technical University of Cluj-Napoca, which has only a few things common with UTSocial. It includes an online catalog for grades, and a review system of the teachers in terms of communicating between teachers and students. A huge advantage over UTSocial is the online paying system, which makes the life of the students much easier. That’s it regarding the functions which help reducing paperwork. At the core of its technology stays the ASP.NET framework, alongside HTML, CSS and JavaScript for the frontend. 2.1.5 Moodle Moodle[5] is a free and open source learning-management application written in PHP. It is used mainly for e-learning purposes in schools and universities from all around the world. There are more than a thousand plugins available to customize the application, which is great, because as it was mentioned before, every university is different. It is a software partially used by TUCN, the problem lies in the small number of teachers using it and the complexity of the configuration. 2.1.6 FEEA App This application[6] was developed by students from the West University of Timisoara. It is a mobile application designed for mobile phones using the Android system. As terms of features it has news, polls, information and the most important, up to date schedule right in the hand of the students. For generating the schedule, it uses a special algorithm, because entering all the data manually and keeping it up to date it's not the easiest thing. By being a platform specific application, it is the major downside of the application, it cannot be used by students who do not have an Android smartphone. 2.1.7 Social networks, Email, PDFs, Websites, and more The multitude of tools the majority of the universities use as a way to manage communication between students and teachers, to ease paperwork and share information. This does not seem like a centralized solution at all and it has its own problems. If a student wants to access online materials, she has to visit the webpage of the teacher. If a student wants to take a look at her attendance at a specific course, in the majority of the cases, she has to ask the teacher personally. If she wants to send a message to one of her colleagues or teachers, she needs to fire up her email or her social media account, find the person and hope that she got the right contact information. If she wants to check her schedule for Friday on the odd weeks, with her semigroup, she has to go through a huge Excel table and decode the information out there. What about a teacher? He even has a harder time maintaining tasks which should be simple. If he wants to check the attendance of a student, in the majority of the cases, he has to find that paper on which he noted the attendance for the lab which was 3 weeks ago. If he wants to contact a student about a great opportunity he just found out, he will struggle finding any contact information about the person. If he is late, because of the huge traffic jam he faced

Bibliographic Study
7 while commuting to work, his students may get annoyed and leave before he even gets there, he has no way to notify them about his problem. 2.2 Technologies JavaScript[22] has finally matured as a programming language. Long gone are the days, when it was only that weird language jQuery was written in. Being the only language which can speak with the web and the number of people with access to internet dramatically increasing, it quickly became the hottest language amongst developers. This means an increased complexity, which emerges mainly from the abundance of web frameworks and developer tools popping out every day. JavaScript is not only for the web though. With JavaScript frameworks like Electron[7], one can write performant desktop applications using only JavaScript, CSS and HTML. A great example for an application is the Atom text editor[9], developed by GitHub[8], which is one of the favorite text editor of web developers. With React Native[10] by Facebook or NativeScript[11] by Google, the development of native cross platform mobile applications is no longer a dream. With Cylon.js[12] code can be written in JavaScript even for robotics, physical computing and the Internet of Things. All this being said, now it is the best time to be a JavaScript developer, because one could consider the current trends as the “renaissance of JavaScript” with talented innovators. This is possible thanks to the great communities, meetups, conferences, the performant frameworks, useful libraries and the never-ending list of different solutions to a given problem. As someone who loves challenges, I choose to write the application using JavaScript on both the frontend and the backend. Having no prior experience with the JavaScript ecosystem, it was difficult absorbing so much information, choose the right tools and stay productive at the same time, but I had fun diving into the world of this language and I learned a lot. Here are the most important frameworks, libraries, tools and applications studied and used to develop UTSocial: 2.2.1 Backend 2.2.1.1 Node.JS “Node.js is a JavaScript runtime built on Chrome's V8 JavaScript engine. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient.”[14] Node.JS was chosen for the backend solution to reduce the complexity of the application, meaning that JavaScript is used not only on the frontend, but on the backend too. It also has great tools for using WebSockets for the real-time communication or for handling the interactions with the MongoDB database. Using Node.JS means that server side rendering of the React components could be used at later phases of the project. Server side rendering shines because it can solve the two major

Bibliographic Study
8 problems of the SPAs (Single Page Applications), serving a plain old HTML to search engine crawlers and slow initial loading time (they have to wait until all the JavaScript loads, before moving on). However, it increases the complexity of the applications, so it is better to also consider the advantages before rendering on the server. 2.2.1.2 Express.JS “Express is a minimal and flexible Node.js web application framework that provides a robust set of features for web and mobile applications.”[15] It abstracts out working with low-level Node.JS HTTP methods into a great framework, using it makes developing APIs faster, enjoyable and easier. All sort of middlewares can be plugged into it, which allow for better request monitoring and processing, error handling, security fixes etc. It also has an amazing routing system, which refers to figuring out how the application responds to a request at a specific endpoint. The server is built on top of this framework. 2.2.1.3 JWT JWT[16] stands for JSON Web Tokens and is an open, industry standard RFC 7519 method for transmitting information between two parties securely over the internet. It is an encrypted string storing information about a user. In UTSocial it is used for handling the sessions of the users’ and for authenticating the majority of the API calls. It uses a secret key for encoding and decoding the tokens sent to the server, assuring this way that unauthorized parties can not access the application. The secret key is stored as an environment variable on the Heroku server while in production or on the operating system while in development, so it is not exposed to threats from unauthorized outsiders. 2.2.1.4 Socket.IO Socket.IO is a JavaScript library, enabling “real-time bidirectional event-based communication”[17], built atop Engine.IO. It works everywhere, with a focus on performance and reliability. This library makes working with WebSockets a pleasure, by abstracting data transports into one simple and robust API. WebSockets are great, because they solve the problem of long-polling. Long polling means that an application makes a request every n seconds to the server, checking for new data. With WebSockets the client/server can listen to specific changes and poll the server only when there is new data available. This feature is a huge boost in the performance of complex web applications. At UTSocial, Socket.IO is used in order to make the real-time messaging, the notification system and the newsfeed possible. 2.2.1.5 PassportJS PassportJS[18] is a simple authentication middleware for Node.JS. It offers a wide range of options to authenticate users into the application and it helps in making private endpoints easy. It has more than 300 different strategies to choose from.

Bibliographic Study
9 At UTSocial, two strategies are used to authenticate students and teachers. The first is called LocalStrategy and is used to check the username and password fields of the users, before redirecting them to the protected content. The other one is called ExtractJwt and it is used to extract the data from a JWT token and validate its content. With the help of this strategy, the login on refresh and protected API routes are made possible. Other possible strategies are authentications based on social media accounts for example. In the case of UTSocial these strategies are not the the best options, as all users are registered by the administrators of the university. 2.2.1.6 MongoDB MongoDB[19] is a free and open source non relational (also called NoSQL) document database. MongoDB uses collections and documents, which are different from the terms used in relational databases. Collections are like tables and documents are like rows in relational databases. Document in the database is stored in a JSON like format with sets of key-value pairs.
Figure 2-1 Document representation in a MongoDB database The main advantage of using a NoSQL database like MongoDB over the more traditional relational databases is the ability to scale out easily, thanks to being a distributed databased at its core. This will remove the integration problems when UTSocial will be used by thousands of students and teachers daily and will need to scale automatically. 2.2.1.7 Mongoose Mongoose[20] is a Mongodb object modeling package for Node, which makes working with MongoDB more enjoyable. With the help of its schemas, MongoDB collections can be easily structured. These schemas are written as objects with key-value pairs. The type of their field can be defined, validated, make required, use default values, mark as unique etc. One can also define

Bibliographic Study
10 functions on these schemas, which can run before or after a change occurs in a collection. A function can also be attached to the schema, which is useful for example when one wants to get results based on the values in a collection. It also has a simpler and more developer friendly API to interact with the MongoDB database than the native mongo client. 2.2.2 Frontend 2.2.2.1 React React[21] is a JavaScript library developed by Facebook for building complex and efficient user interfaces. It uses a component base approach, with each component managing its own state, encouraging developers to write highly reusable components. Components make possible to split the UI into independent and reusable pieces. They are like JavaScript functions, accepting arbitrary inputs (called props) and return React elements describing what should appear on the screen[24]. A component can be as simple as a button to as complex as a dashboard view. This approach leads to one of the strengths of React, component composition. This means having the possibility to abstract out, as much as possible, the application into smaller components, then compose those small parts into more complex components. This approach has the advantage of having independent functional components, which given the same props, they produce the same output over and over again. Functional components are easy to test and in an ideal world, the majority of an application should consist of these types of components. React uses a concept named Virtual DOM, which is a copy of the DOM (Document Object Model) of the application. When a change in the application state is detected, the DOM is not manipulated directly, instead a new Virtual DOM representation is created. The new tree is then compared to the previous tree by a really smart and fast “diffing” algorithm and only the differences between the old tree and the new one are passed to the real DOM. This makes React really fast. The React team is currently working on the 16.0 version of React, called Fiber, which is a complete rewrite of the inner working of the library, with huge performance boosts.
Figure 2-2 React DOM update strategy

Bibliographic Study
11 When writing React applications the usage of an XML-like syntax extension to JavaScript, namely JSX, is recommended. This means writing HTML like code in JavaScript without learning any templates like it is required in Angular, Ember or Vue. This means that a developer should only be familiar with plain JavaScript and HTML in order to create React applications. The React API is also pretty small, so learning it takes only a few days. Styling React components can be done in a lot of ways. The solution provided by React out of the box is writing of the styles also in JS, which compile down to inline CSS styles. As opposed to Angular’s bidirectional data-flow, React has unidirectional data flow. This leads to better predictability of the application’s current state and the possibility of switching back and forth between different states. 2.2.2.2 Redux Redux[26] is the hottest JavaScript state management library inspired by the flux design pattern. Its main components are the store, the action creators and the reducers. The store is an object, where the whole state of the application is stored, it is the single source of truth of the application. The store is read-only, which means the developer can not mutate the state of the application. A change is made by dispatching an action creator, which updates the state of the applications and triggers a re-render. The store lives in the context of the application and is made available to the components by the connect higher order component from the react-redux module. Middlewares can be plugged into the store, resulting in every action going through them before arriving to the reducer. Action creators are in the majority of cases pure functions, which return an action type and a payload. When an action creator is called, it is dispatched to the reducers, which based on its type, updates the store. In the case of an API call, action creators can return other things than pure functions by using a middleware. Solutions used in this applications: redux-promise (allows to return a promise from the action creator), redux-thunk (a function can be returned from the action creator, which can be used to delay the dispatch of the action). Action creators are the layer between the application and the Redux store. The reducers are also pure function, which take in the previous state of the application and an action and return the new state based on the action passed to them. It must be emphasized, that one should never mutate the state, a new state must be always returned. This can be enforced by using immutable libraries like Immutable.js from Facebook or using a middleware which checks for immutability. Reducers can be composed together, leading to better code organization.

Bibliographic Study
12 Figure 2-3 Redux workflow Although Redux is not bound only to usage with React, React’s unidirectional data flow makes it the best fit. 2.2.2.3 Redux-form Redux-form[27] is a great module to connect the forms of the application to the Redux store to make smarter forms. It makes manipulating forms comfortable throughout the application, even from the outside of the component they are declared in and saving the forms state (if the page is reloaded for example) straightforward and easy. Dealing with custom field inputs, like a fancy dropdown, is less pain by using the provided Field component to connect them to the store. By each Field component being connected to the store, retrieving their values from other components is just a call to the state object of the application. This is all possible thanks to the provided reduxForm higher order component, which wraps a component having form related logic and provides functionality via props. 2.2.2.4 React-router React-router[28] is a routing library made for React. It’s component based build makes a perfect fit for the React ecosystem, it even allows responsive routing It consists of a bunch of navigational components, keeping the UI in sync with the URL. It supports the majority of the traditional routing necessities, like links, URL parameters, query parameters, not found URL matches, history etc. One can even supply additional props to the link component. This is useful in particular, when one wants to detect the location from where the user clicked on the link. 2.2.2.5 Styled-components Styled-components[29] allows the writing of real CSS in JavaScript, including animations, transitions, media queries, using the tagged template literal EcmaScript6 feature. Tagged template literals are basically “string literals allowing embedded expression” [39]. One can also use the power of JavaScript inside these tagged template literal function, which

Bibliographic Study
13 allows for example the usage of variables inside CSS. Any traditional HTML element or React component can be called with the styled function provided by the library. A styled component is basically a React component so it has its own lifecycle methods. This is mainly useful when passing a prop to a styled component, which will help in recalculating the style of the component based on the new prop. Styled-components stays at the heart of the look and feel of UTSocial. It made the component decoupling even more meaningful, because every component has its own style in the same file, without depending on some external CSS file. 2.2.2.6 Semantic UI React Semantic UI is an UI framework consisting of a bunch of predefined components. It is an useful library, because the developer does not have to reinvent the wheel and spend time with styling every time he wants a complex component. It includes components like dropdowns, forms, buttons, accordions, modals, menus and a lot more. It has a beautiful design, which can be customized by the developer. Semantic UI React[30] is the React version of the Semantic UI components. It has a much better developer experience, because instead of writing bunch of divs for a component, only a component with the afferent props needs to be written. Using styled-components, it is often needed to have a custom prop on a component. There is a conflict with custom props passed down to a Semantic UI component, they throw a warning, because that prop is not specified in the structure of the Semantic UI component. To address this, a wrapper div has to be used. The other problem arises when one wants to overwrite the style defined by the Semantic UI team, without deepening into the predefined styles. This involves using the !important CSS property pretty often. 2.2.2.7 BabelJS BabelJS[31] is a JavaScript compiler, used to compile next generation (ES6/ES7) code to ES5 code, which is supported by the majority of browsers. It is a crucial tool in React applications, if the JSX format wants to be used. Babel takes in the JSX code and transforms it with the help of ASTs (Abstract Syntax Tress), which then can be understood by browsers. 2.2.2.8 Webpack Webpack[32] is a module bundler of great importance used alongside modern JavaScript applications. It takes in a bunch of CSS, images, fonts, markups, JavaScript and bundles them together into a single bundle.js file, which is the only thing needed to be included in the HTML file served to the browser, the index.html file. It supports more advanced functionalities too, like bundle splitting, lazy loading (loading bundles as it is need), hot module replacement (updating of the React components without a page refresh). It has a lot of loaders which makes it extremely configurable. Webpack is not bounded to React only, it can be used also with Angular or Vue.

Bibliographic Study
14 2.2.2.9 Create-react-app Create-react-app is a handy npm module developed and maintained by Facebook. It allows the creation of React apps ready to production in a matter of minutes. It abstracts out all the build configuration needed to do before writing a single line of code. This means Webpack and Babel configured out of the box. A React application created with create-react-app can also be ejected, so the developer will have full control over the Webpack configuration of the project. After ejecting, features like hot-reloading (updating only the changed component while in developmnet) and server rendering can be set up, currently not supported with the standard setup. 2.2.2.10 Sketch Sketch[33] is an application used mainly be designers for creating wireframes, mockups, prototypes and designs. In creating UTSocial it was used to build the initial mockups/design of the application, in order to have an idea about the different components needed to be developed and how should they communicate with eachother. 2.2.3 Testing 2.2.3.1 ESLint “ESLint is a tool for identifying and reporting on patterns found in ECMAScript/JavaScript code”[34]. It is an essential tool in developing JavaScript applications, as it helps maintaining a consistent coding style, the usage of the JavaScript best practices and to catch bugs before runtime. It is highly customizable. In order to avoid wasting time with setting up from scratch the rules, the ESLint config from Airbnb was used, which incorporates all the coding standards.[35]. 2.2.3.2 Prettier[36] Prettier is a code formatter, which also has the role to maintain a consistent style across the whole application. It saves a lot of time, because it removes the cognitive load of paying attention to the format of the code. Prettier takes care automatically of the format, the developer can focus all their energy to the correctness of the code instead. Still being in the early development, it is not so highly customizable, but this will surely improve in the near future. 2.2.3.3 PropTypes It is well known that in JavaScript the types of the variables are not defined by the developer, they are defined by the compiler. This gives the developers a huge freedom, but it also makes the appearance of bugs related to types more frequent. Fortunately, there are solutions addressing this issue. The one used in UTSocial is the PropTypes library, which allows to define, as the name suggests, the types of the props passed down to a component. The typecheck is made at runtime, with a warning in the console, if the props don’t match. The warnings are shown only in development.

Bibliographic Study
15 2.2.3.4 Chrome DevTools Most of the time testing the application, the Chrome DevTools were open, as they have so many useful features. The most used was inspecting the elements and monitoring network requests. It also has a great performance checking feature and a JavaScript debugger. 2.2.3.5 Redux DevTools Redux DevTools is a browser extension, which allows visualizing the state of the application. It has a time travel functionality, which is great when debugging, because moving back and forth between the different state of the application is possible, which means catching bugs are simpler. Using the tools, it can also be verified if the action creators fired correctly. 2.2.3.6 React Devtools React Devtools is a browser extension, which allows the inspection of the React components, with the current state and props. 2.2.3.7 Sizzy Sizzy[37] is a handy application for testing the responsiveness of an application across various devices. One can open the application in eight different screen sizes at the same place. This makes comparing different screen sizes enjoyable. 2.2.4 Deployment, hosting and package management 2.2.4.1 Heroku “Heroku is a platform as a service (PaaS) that enables developers to build, run, and operate applications entirely in the cloud”[38]. It is the platform where UTSocial is stored. Deployments are easy and it is scalable. UTSocial is on the free plan though, which limits the scaling possibilities. 2.2.4.2 MongoLabs MongoLabs[40] is a DaaS(Database as a service) MongoDB hosting platform, where all the data for UTSocial stays. 2.2.4.3 GitHub GitHub[41] is a distributed version control system based on git, mainly used for storing codebases of projects. It is a crucial tool, as it makes tracking code possible. It is also a great place to store a backup of the codebase. With its branching feature, multiple developers can work on the same codebase at the same time. 2.2.4.4 Yarn Yarn is a fast, secure and reliable dependency manager. All the above mentioned packages (or modules) are open source projects, which are stored at the npm software registry. All this packages are added to the project using yarn.

Analysis, Design, Implementation and Testing
16 3 Analysis, Design, Implementation and Testing 3.1 Problem Analysis The problem consists in building a centralized management application for educational institutions, which is scalable, secure, fast and simple to use. The application would serve as the bridge between teachers and students of a university. It is a solution aiming to solve the problems with current information sharing systems used by the majority of universities. The main problem with the current information sharing systems is the multitude of the platforms teachers and students use to engage with each other, which leads to frustrations and confusions about where to find the needed information. This results in wasted time and increased cognitive load at both students and teachers. The problem is amplified in the case of students, when they want to navigate through all the available and always changing information, as every semester they have on average six new materials. Speaking from experience, this is not the easiest and most enjoyable part of the university life. Teachers are not in a better position neither, it is just a little bit manageable for them, as they mostly teach the same materials every year. But this does not mean, that the problem does not exist for them. They usually track attendances and not final grades on paper or in different files on the computer, have their materials at a website, which they have to maintain constantly, enter the final grade on the site of the faculty, communicate with students and colleagues through e-mail, Facebook, Slack etc. and they do not have the opportunity to send out notifications, in case something changes. All this being said, UTSocial is an application which aims to solve all the above mentioned problems at the same place, with a user-friendly and simple design and with even more features coming out in the future. 3.2 User stories According to Agilemodeling[45], “a user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it.”. They are mostly used in Agile software development teams. A typical user story looks like this: As a <type of user>, I want <some goal> so that <some reason>. The following table presents the most important user stories related to this application.

Analysis, Design, Implementation and Testing
17 Table 3. 1 User stories of the application As a/an I want to… so that… Everybody Have all the information at the same place I do not have to waste time searching for it Everybody Communicate with other teachers/students I can keep all my university related messages at one place Everybody Check my schedule easily I don’t forgot to attend classes Everybody Log in using my phone number, email or username I can choose to remember whichever I want Everybody Change my personal preferences I can configure my account to my needs Everybody Star important posts and conversations I can access them faster Student Have access to the course materials I can learn new things even at home Student Get notified about changes in the schedule immediately I can restructure my day Student Have access to my grades I can track my performance Student Know about attendances I can resolve my problems in time Student Get notified about information related to my courses I can act on up to date information all the time Teacher Update attendances fast I have more time left for teaching Teacher Add more than one grade to a given student I can evaluate the students better Teacher Notify my students about important changes 24/7 The information gets to them in time Teacher Update course materials 24/7 Students have access to new materials 3.3 Stack Analysis In order to build the application, the technologies for the backend and the frontend needed to be chosen carefully. In the process of choosing the stack, things like scalability (of the application and of the codebase), performance, ease of onboarding for new developers in later phases of the project, existing documentation and ease of testing have to be taken into consideration. The backend consists of three layers: a server to store and serve all the information, files and assets to the client, to handle network requests and to manage serving multiple clients at the same time; an application to manage authentication, security, database interaction and server setup processes like logging, routing etc.; a database to store all the information about the application. The frontend is the user interface of the application where the users interact with the server. As of 2017, there are tons of great frameworks and solutions to UI development. It was very hard to choose, especially if everything is new to the developer, like it was in this situation. When choosing a given solution to the problem, additionally to the before

Analysis, Design, Implementation and Testing
18 mentioned points, it should also be taken into consideration the community around the ecosystem, as most of them are open source projects. A huge plus if it is being used in production and it is maintained by a major company, like by Facebook in the case of React[23] or by Google in the case of Angular[43]. Waking up in a middle of a ghost GitHub repository after a few years of developing an application, is a situation which should be avoided by everybody. Taking into account everything and as the direction where the state of the art of web development is heading, JavaScript was chosen for both the backend and for the frontend. On the backend lies a JavaScript runtime called Node.JS built on Chrome’s V8 JavaScript engine, which has an event driven and non-blocking I/O model and a NoSQL database called MongoDB which is scalable and flexible at the same time. All this is being served by an Express server. The frontend is a SPA (single page application) and it consists of a bunch of composed React components bundled together by the module bundler Webpack. SPAs became popular a few years ago as the performance of the browsers dramatically increased, meaning faster rendering times on the client side. SPAs are great, because there is no need for constant interaction with the server, every time the user navigates to other pages, thanks to the fact that everything is being rendered on the client-side. They are also super responsive and reactive to changes, giving almost like a native application feeling, but with all the amazing features of the web. 3.3.1 Other possible choices On the backend, if JavaScript is a priority, there is not much to do, as currently only Node.JS is mature enough to build a trustable large scale application. There are a few other JavaScript frameworks available, but they are pretty unknown at the moment. A feasible option would be switching the Express Node.JS framework for either Koa or Hapi (backed by WalmartLabs), which provide mostly the same features as Express. At the moment of writing, they are not so popular than Express though. If JavaScript is not a priority, the backend can be written in almost any of the popular and older languages like Java (and other JVM languages like Clojure, Scala or Groovy), C#, PHP, Ruby, Python, Perl etc. A huge favorite from this list was Ruby, as it is still quite popular with its Rails framework. But learning another new language besides JavaScript was not an option which would worth the return on investment, because developing features had a higher priority for this project. Java and C# would have been the logical choice, as these languages already were in my arsenal, but as the popularity of these languages are decreasing (Stanford university recently changed their introductory courses from Java to JavaScript[42]) and JavaScript is still need to develop the frontend, they did not seem a profitable solution in the long run. On the database side another possible option would have been the usage of Relational Database Management Systems like Oracle, PostgreSQL, MySQL, SQLite or other NoSQL

Analysis, Design, Implementation and Testing
19 solutions like Firebase (backed by Google), Couchbase or RethinkDB. The choice has fallen on MongoDB as it is the highest ranking database amongst NoSQL databases, it integrates well with a JavaScript application, it is fast, scalable and it seems like the future of databases. On the frontend, the choice seemed even harder at the beginning of the research. It was hard to navigate through the jungle of JavaScript libraries and frameworks, especially with close to zero knowledge about the current state of the art of frontend development. There were countless of arguments in the favor of Angular, as the future of the frontend, but then Angular 2 came out and a lot of people were frustrated to relearn everything, as it is a whole different framework than Angular 1. The simplicity, reusability, component based thinking and the efficiency of React became interesting really fast. But there was this new kid, Vue, around town, slowly starting to gain popularity in the US, having the same principles as React. And there was the classic jQuery, which reshaped how developers think about web-development back in 2007. Or Ember. Or Backbone. The list could go on forever. What led to React though was the possibility of not having to learn much library specific code besides of vanilla JavaScript and a small API, the community is huge, it is maintained by Facebook, it is quite popular on the market and it is powerful in terms of efficiency. With the state management library Redux (which is literally around 100 lines of code only), it was quite an attractive option and it was probably the best choice. 3.4 Problem Modelling There needs to be at least three different account types: one for teachers, one for students and one for administrators. The difference between them has to be one regarding the access right of the users. Students would have reading rights regarding the courses they are participating in and the schedules of groups being in the same year, indifferent of language, writing and reading rights when they want to change some aspects of their personal preferences (e-mail address, phone number, username and password) and when they want to communicate with others. They would have the possibility though to send a message to every person in the university, who is in the database. Teachers would have writing and reading rights only in the courses where they are teaching in some kind of form, with the same possibility as students in changing their personal preferences and communicating with others. Regarding to the schedules, they can access the schedules of their colleagues. Administrators would be the ones managing the schedules, teachers, students and courses of the whole university. They would be able also to add temporarily available features to the the application, like reviewing teachers, signing up for dorm rooms or paying for exams.

Analysis, Design, Implementation and Testing
20 For having those three types of users, every user needs to have a type which would be used to identify the user trying to log in. This leads to having the possibility to include only the relevant component (Teacher, Student or Admin) to the bundled JS file, because there is no need for having all three of them at the same time, which results in faster initial loading time and a smaller bundled JS file. This comes in handy, when users access the site via slower network connections. As mobile devices are quite popular today, especially amongst the younger generation who is one of the main target of the application, and there are devices with various screen size and resolutions, the application should be responsive depending on the device it is being browsed. In order to increase user experience, a user should be able to log in with either his phone number, e-mail address or username. 3.4.1 Use cases An important use case will be described for each type of user, each followed by a diagram showing all the possible use cases for the given type. First, a major use case for teacher named Ionela is discussed. Suppose that it is the end of the semester, Ionela is teaching System Theory in the form of lectures to students being in third year, English section and the final exam is coming. In order to enter the exam, a student must have at least 7 attendances at the course and have a grade at each of the 14 labs with their average being greater than 5. In order to check for students who are eligible to enter the exam, Ionela navigates to UTSocial, logs in by entering her username, phone or email address and her password navigates to the courses tab and chooses the System Theory card where the language is English. Then she opens the attendance tab, selects the group, the type lecture and looks for students with lower than 7 attendances. After she finishes with all groups, she chooses the grades tab and checks the students who do not have all the grades or the average of them is less than 5. In the sad situation if she finds students who fit the mentioned description, she can write a new post to the course’s newsfeed and notify students about their situation. If she has even more time and she is a kind person, she can write a private message to each individual student and notify them directly with steps regarding the process of entering to the exam in their case.

Analysis, Design, Implementation and Testing
21 Figure 3-1 Use case diagram for a teacher A major use case for student named Paul, who as a normal student, starts studying four days before his next exam, which happens to be related to Systems Theory is described. After procrastinating for an hour, Paul finally closes Facebook and navigates to UTSocial, where he signs in using his credentials. As soon as he logs in, he is welcomed by two new notifications about his grades and a new message from her Systems Theory teacher, Ionela. He starts by checking the notifications about the grades, the first one being a new grade at the last exam, where he got a 10. He is super happy, but the happiness is over once he sees his last grade at the Systems Theory lab, with his average decreasing below 5, which means he cannot enter the upcoming exam. The message he gotten is related to the steps he needs to take in order to enter the exam. First he tries to negotiate the grade with his teacher through the messaging system, but with no luck. So he goes to the courses tab, finds the System Theory card and selects the materials section to start learning for the upcoming test, where if he gets above 5,

Analysis, Design, Implementation and Testing
22 he can enter the exam. The beauty of this is that Paul did not have to spend a lot of time trying to figure out his situation, finding Ionela’s contact information and the study materials, everything was done at the same place.
Figure 3-2 Use case diagram for a student Lastly let’s look at an administrator use case. At the moment the only thing he can do, is to add new schedule item. This is being done by logging in to the account, selecting the schedules tab, selecting the group whom he wants to add a schedule and finally clicking on the “add schedule” button. A popup will appear, where he can select the course, the type of the schedule, the teacher, the day, the time, the duration, the frequency and the location. After everything is selected, he clicks on the add new schedule button and the new item immediately appears on the table.

Analysis, Design, Implementation and Testing
23 Figure 3-3 Use case diagram for an admin 3.5 Database design In the first place, two major user types are needed, teacher and student. But some of their general characteristics (username, password, email, phone number) should live inside a users collection in order to access and modify more easily. If there would not be a separate users collection, at authentication for example both the Students and the Teachers collection had to be checked for a matching user. In order to link a user to a specific user type, his unique user id should be the same as the id of his user type. This way the collection can be populated with relevant data from the user type collection. In the case of the attendances, notifications and grades collections, one may ask why there is a need for separate collections with references instead of storing them in an embedded document in the respective user type collections? The answer lies in the number of items a user could have. Just for a semester a student could easily have over 300 attendances, which can add up fast. If storing past attendances is a priority, storing them in an embedded document is not a scalable solution. The same is valid also for the other two collections, maybe with a little less items to deal with. The only tradeoff with this approach is the increased complexity of the queries, which can lead to confusions, but in the long run it pays off. The rest of the collections are self explanatory, so they are going to be listed here only, before showcasing them on a diagram. They are the collections for conversations, posts, schedules, groups and courses.

Analysis, Design, Implementation and Testing
24 Figure 3-4 Database design MongoDB being a NoSQL database management system, the traditional modeling procedures do not apply and there are not so many tools to model these kind of databases. In order to create the database model, a sample model from the MongoDB official website was taken[50] and designed in Sketch from scratch. As in NoSQL type databases does not exists relationships similar to the ones in the Relational Database Management System, only references to other objects, the relationships on the figure above was drawn according to that. A line from a document to another means the existence of a reference in the document from where the line starts. A bidirectional line means a reference in both directions.

Analysis, Design, Implementation and Testing
25 3.6 Architecture The application is built using the client-server model, which is a distributed communication framework, where in the majority of the cases, the client and the server communicate with each other over a network. A good example for a client is a web browser. The server’s job is to provide the requested resources to the client.
Figure 3-5 Client-server model On the server side the order of actions is not so complicated. A request comes in to the router, which is redirected to the requested route, the token[2.2.1.3] from the header of the request is extracted, validated and if everything is alright, the corresponding action from the controller is called. The controller then sends back a response based on the status of the request. If the authentication of the request fails, further steps are not taken and an error with the status code of “401” is sent back to the client with the “Unauthorized” message. The majority of the routes are needed to be checked, in order to prevent unauthorized third parties to access the data. On the client side though, the order of actions is a little bit more complex. It is similar to the MVC(Model-View-Controller) architectural pattern. React being only the “V” in the MVC, a state management library is needed to take care of the “MC” part, which in this case is Redux[2.2.2.2]. It is tricky to make an analogy between a React with Redux architecture and the MVC pattern. The controllers are called actions, the models are the reducers and the components are the views. There is one more thing in the Redux vocabulary, the store, where all the state of the application is stored and it has no place in the MVC patern. One can think of the store as a “database on the frontend”, where all the state of the application is stored (in a key-value type JavaScript object), is available to every component via the connect higher order component and is immutable. While in the MVC pattern data can flow in a bidirectional manner, in a Redux application data can move only in one direction, which makes the application’s behavior more predictable and easier to debug. The flow in a Redux application is presented on the Figure 3-6.

Analysis, Design, Implementation and Testing
26 Figure 3-6 Redux data flow 3.7 Project Structure The project is structured inside a single repository. At the root of the repository are 2 folders, the client and the server, and some files which are responsible for the overall setup of the project. Inside the Procfile file is declared the command, required for Heroku, which is run by the application’s dynos. In our case the command is web: yarn start:prod, which simply changes inside the server directory and serves the build version of the server. Some other files are the .eslintignore (specifying the directories where running ESLint is not required), the .gitignore(specifying the directories which should not be tracked by git), .eslintrc.json (the configuration file for ESLint) and the package.json (specifying the engines to use for Heroku, dependencies and some scripts). 3.7.1 Server Inside the server folder lies all the backend logic for the application. It is separated into several folders and files, each having a specific role. Amongst the specified folder and files, here exists a package.json file too, having mostly the role to list the dependencies and scripts of the server. In the controllers folder are several files, each defining functions for the API endpoints. Each of these function have the role to specify how the backend reacts to a specify API endpoint calls, what changes needs to make in the database, what to send back to the client and how to handle the errors which arise in the case of bad requests. In the controllers folder are defined the Mongoose schemas for all the collections. A typical file specifies the attributes of a given model (including validations, required field, type of each field), specific functions to run before/after every operation (for example run a function before every save) and virtual fields (not stored in the database and can be used to compute values based on stored values).

Analysis, Design, Implementation and Testing
27 In the services folder two strategies for PassportJS are stored, one for logging in using the LocalStrategy and one for extracting the JWT token from the header, the ExtractJWT strategy. In the utils folder two utility function are stored, one for generating a JWT token and one for getting a clean user (without including the password). In the app.js file the setup for the server is done and in the server.js file the server is started and the WebSocket instance is created and exported. 3.7.2 Client The client folder has two folders, the semantic-ui.json (for configuring Semantic UI) and the package.json, containing all the dependencies and scripts for the client side. Inside the public folder there is a single index.html file, its body consists only of a div with the id root, where the bundled JavaScript file will be inserted. A more interesting folder though is the src, where all the logic of the frontend is placed. It has a structure, which is scalable as the codebase grows, as it is straightforward to navigate through. In the views folder the main endpoints and the related components are located. Here are defined components used only by a specific type of view, in the relevant folders. This means having the possibility to separate the authorized components from the rest of the application (not including all three in the bundled file at the same time) and loading only the type of the logged in user. The implementation of this will be discussed in the next section. In the Home component is defined the path accessible to everyone, before being logged in. Being a university management application, there is not much on the home screen, users can only log-in and reset their password. In the components folder, the common components are placed, they being the same to everybody, no matter of the type. The common components can be for example different form components (radio-button, checkbox, input fields, textareas, buttons etc.), icons, loaders, messages, settings, header, higher order components, form validations etc. The majority of these components are only presentational components, used as building blocks by the components from the views folder. But what are presentational components? They are pure functions, which given the same props, always return the same markup. They do not specify how the data is loaded, get their data via props, do not have dependencies on the rest of the app, are concerned only how things look and most of the time are written as functional components (exception is when they need state regarding to the UI, lifecycle hooks or performance optimizations). They are also called dumb components by some developers. If mentioning presentational components, one could not go further without talking about container components too. Those are the components concerned with how things work, not having any markup, they may call Flux actions, having state and provide the data

Analysis, Design, Implementation and Testing
28 and the behavior to the presentational components. By using the connect higher order component from the react-redux library, the needed parts from the Redux store and the needed action creators can be mapped as props to the component. They are often called smart components. By separating components like this, better code reusability is enforced, making it easy to change something in the UI, without touching the logic (great news for designers), reduces the length of a file and it makes understanding the application easier. This structure shined at this project, because different user types have different logic, but in the majority of the cases, the same UI. A component folder typically has three main parts: an index.js file containing the container component, a ComponentName.js file containing the presentational component and an elements folder containing the building blocks of the component, which can be anything from the tree types mentioned. Another important folder is the redux one, all the logic regarding to the state of the application is placed here. The ducks[44] pattern was used here, which is the brilliant idea of a guy called Erik Rasmussen. This pattern encourages to organize the reducers by features, each feature being a “duck” file. A duck contains all the action types, the action creators, the initial state, a reducer and the selectors. The default export must be the reducer function, while all the action creators must be exported too. This approach has the advantage of storing everything related to a feature in one file. Most of the tutorials online are made by having all the action related things (types and creators) in a folder, all the reducers in an another folder and all the selectors in another one. This is fine for a smaller application, but it becomes easily a headache when implementing a new feature, because every time all the folders need to be navigated. In the utils folder a lot of utility functions can be found, which can be used everywhere and they are not React related. The constants, different string, session, timestamp and date operations, style related functions and the theme is defined. In the assets folder are defined all the static assets like icons, images, CSS. The semantic folder is also placed here, where styles regarding to semantic-ui can be configured. 3.8 Installation guide In order to use the application no installation is required. One has to simply navigate to the address of the application[48] and provide the following credentials for accessing the protected content: Teacher: username: ionelarotaru18 and password: ionelarotaru18. Student: username: chiformircea69 and password: chiformircea69.

Analysis, Design, Implementation and Testing
29 In order to access the development environment, the following prerequisites have to be fulfilled and the steps described followed. 3.8.1 System requirements • Operating system: Unix based (macOS, Linux) or Windows • Node version 7.4.0 or higher and NPM version 4.0.5 or higher[46] • MongoDB installed and started[47] • A text editor (Atom is a good choice[9]) • Internet access 3.8.2 Steps for cloning and starting the development environment If the project is available on an USB or CD, the first step could be skipped. • Clone the project from GitHub by running the following command in the terminal or cloning using a desktop version of git: git clone https://github.com/robertistok/utsocial.git <destination folder> • Change into the directory where it was cloned (or copied) and run the following command in the terminal: npm install This will install all the required dependencies of the project. It takes quite a time to install everything, a good alternative for dependency management is yarn, which is faster[49]. • In order to start running the development environment, the next script has to be typed in the terminal, while in the root folder, which fires up the server for the backend the the server for the frontend. npm run start • To have access to the data, the connection to the database has to be made. A locally used database was used for development, migrated to MongoLabs in production. Recreating the local database would be difficult so instead is better to simply connect to the MongoLabs database. • The first step is to set the environment variable “MONGODB_URI” to: mongodb://heroku_g3v7z28p:2vrlf9dnki9skasi7c33eam14n@ds123662.mlab.com:23662/heroku_g3v7z28p • The second step involves opening a text editor and editing the app.js file from the server directory by replacing the argument of the function from the else branch to process.env.MONGODB_URI: Figure 3-7 MongoDB setup

Analysis, Design, Implementation and Testing
30 To make a production version of the application, ready to deployed one has to navigate to the root of the project and run the following command: npm run build The build versions for both the server and the client will be found in the respective directory in the build folder. It is recommended serving the build version in production, as it is an optimized code by being minified and uglifyed. 3.9 Implementation Over the past few months the application was built from scratch and now contains more than 15000 lines of code. It is a result of hundreds of hours of hard work, dedication and a strong desire to build a useful tool. The project was developed on a MacBook running macOS Sierra. Developing on a UNIX based system had the major advantage of having a powerful terminal built-in without any needed tweaks. JavaScript developers rely heavily on the terminal, because a lot of packages need to be installed constantly, a lot of the logging is done here, a bunch of scripts need to be run and also the deployment is made, in the majority of use cases, here. As a text editor Atom[9] was used, with a lot of useful add-ons like running ESLint[34] and prettier[36] at saving, autocomplete, GitHub integration etc. Tree different parts of the implementation worth mentioning and each of them will be presented in more details in the following chapters. The most work was done on the front-end part, resulting in a pretty complex codebase. 3.9.1 Database After having the document models presented at Figure 3-4, the equivalent mongoose schemas had to be created. The basic procedure for creating a schema is as follows: 1. Import the mongoose module. 2. Create a new mongoose.Schema object and setting up the the key-value pairs from Figure 3-4, adding some properties if needed (required fields, default value, custom validation, setting up the relevant references). 3. Create the model using the mongoose.model function, which takes in two parameters: the name of the collection and the recently created mongoose.Schema 4. Exporting the created model for using it in the future when data needs to be retrieved. The procedure is mostly the same for all the eleven models. There are though three procedures worth mentioning. With mongoose, one can add virtual properties to a model, which are additional fields, not stored in the database and can be custom getters or setters. This feature is useful when a value needs to be calculated based on the stored data. A common use case is getting the full name of somebody and this was one of the reasons of its usage. This can be done as in the Figure 3-8.

Analysis, Design, Implementation and Testing
31 Figure 3-8 Virtual field definition Virtual fields were defined in a similar manner for the others schemas too. An important notice here to always use the traditional function declaration to define a virtual type in order to achieve dynamic scoping for this. Another useful feature of mongoose is the ability to declare middleware functions (also called pre and post hooks) on the schemas, which will run during the execution of asynchronous functions. A great example for using middleware is in the user schema for creating strong and secure passwords.
Figure 3-9 Password encryption before save This function is run before every save event on the schema and its role is to encrypt the password if it is changed. This is done by generating a salt using the genSalt function from the bcrypt-nodejs[51] module, which will be used to hash the password. If there is no error, the generated salt and the password of the user is passed to the hash function from the same module. A hash will be returned from the function and the password of the user will be set to that hash. The password of a given user will look similar to the below presented string: $2a$10$tna5yNkCfgapxHyEkmDKFeNQVCMSW9gU5u/lg7EOnocXuNvm12R5S The last interesting part worth mentioning can be found again at the user schema. Custom function can be defined on a schema, available only when an instance of the schema

Analysis, Design, Implementation and Testing
32 is present. A function called comparePassword is defined on the user schema, used at authentication to compare the entered password with the password in the database. As the password being hashed, this procedure is done using the compare method of the bcrpyt-nodejs module, which takes in the two passwords and return the Boolean status of their matching. 3.9.1.1 Data generation To develop an application, there is a high need for data to be used in order to test the implemented functionalities. So to make the information familiar to work with and to model real world scenarios, existing data from the Technical University of Cluj-Napoca is used for the courses, schedules, students and groups. Different approaches to obtain the data were used for each one of them. The courses were entered by hand from the information available at the site of the faculty, as dealing with PDF parsing was not a priority at the moment. The respective courses are for the “Automation and Applied Informatics” English section of the “Faculty of Automation and Computer Science” for the 2016-2017 academic year. Entering the schedules was a longer procedure. Actually, the first feature of the application addressed this problem. It consists of a modal in the user interface of the admin panel, which appears after selecting the desired group and clicking the Add schedule button. This being only a tool to add new schedules, it is in the early stages of the development and it is not so sophisticated than the rest of the application. It does its job after all, the admins can add a new schedule easily. After the modal appears, the semigroup, course, type of the course, the teacher, the frequency, the start, the duration and the location can be entered. Upon hitting the Submit schedule button, the new schedule item gets submitted to the database and it appears instantly on the schedule table. In order to improve the user experience, the form is not reset on submit, this enables admins to enter faster similar schedule items, when only a few details need to be changed. If they want to start the process from scratch, they can hit the Clear button and the form will reset to the default values. Generating the students was probably the most interesting part. At first, the parsing of the lists from the current application of the university [52] was the chosen option. But sadly the parser library[53] was unable to deal with this, because of some access right errors it got when trying to parse the website. The next possible solution was downloading the excel files from the site and parsing them. This process was done on a laptop which had Ubuntu as its operating system, which led to a fortunate bug. Upon trying to download the excel files, Ubuntu’s Libre Office program parsed incorrectly the file and it resulted the exact same HTML structure as on the current application of the university. After deleting the unnecessary tags, the only thing left was the table with the list of all the students from a group, similar to the Figure 3-10 which was finally parseable.

Analysis, Design, Implementation and Testing
33 Figure 3-10 Sample of a student before parsing Each group had its own file, all containing tables like in the figure. The groups were separated into two files based on their language and the following algorithm was run on both of them, which resulted in two JSON files containing all the students of a section.
Figure 3-11 Parsing algorithm of students The algorithm maps over the file and for each group selects the content of the tr tag. The content is mapped, with each item being a student with its gender, name and identification number. This being a single string, it needs to be split by spaces. After the split is done, a new object can be pushed inside the respective container object (in this case autGroup). This is being done for each student. After the whole process is finished, the container object is saved into a JSON file. To generate a student, additional information need to be generated, like his email address, phone number, username, password, birth year and social security number. These are being done by mapping over the saved JSON files from the previous steps, for each item generating a student and saving them into another JSON, containing all the students by section. While generating the groups, the number of students from each section were divided by the number of required groups for each year and section. The number resulted upon division represented the number of students which were assigned to the group. This averages to 28 students for the English section and 27 students for the Romanian section. The course

Analysis, Design, Implementation and Testing
34 assignment for each group was being done by selecting the necessary courses from the courses collection. The rest of the data was generated mostly by random information or by using the functionalities of the application. 3.9.2 Server The starting point for the whole application lies in the app.js file. The Express server is generated and stored in the app variable, the necessary setups are configured and the connection to the database is made. The following six things are done here: 1. The “morgan” request logger middleware is plugged in from the “morgan” module. 2. Another two middlewares are passed from the “body-parser” module. This handy module parses the incoming request bodies and makes it available in the “req.body” object. These are the functions “json” for parsing the text as JSON and “urlencoded” for parsing the text as URL encoded data. 3. Next the path to the static files (files which will be served to browsers) are stored in the variable called “staticFiles” and plugged into the server 4. Making available the router to the API for handling the incoming requests 5. The connection to the database is made by the following piece of code: Figure 3-12 Connection to the database 6. The next step is to specify the port on which the server will run, either the one specified by the “PORT” environment variable or if that is not available, the default port 3001 is used. 7. The last step is exporting the “app” object. The object exported from the app.js file is imported in the server.js file, where the server is created and started. The connection to the socket.io server is made in the same file, by calling the socketIO function with the server as its argument. The tracking of the users connected to the socketIO server is made by adding them to the connectedUsers object upon connection and deleting them upon disconnection. From this file the socketIO server stored in the io variable and the connectedUsers object is exported in order to make available for other function to emit data to the connected sockets. Routes for the API are configured in the router.js file, where basically all the controllers are being imported from the controllers folder, the authentication methods are configured and the routes are set up. A sample route is presented on Figure 3-13, which is a route responsible for getting the conversations of a user.

Analysis, Design, Implementation and Testing
35 Figure 3-13 Sample route for getting the conversations of a user The router object is created by calling the Router function from the express module and storing the result in the router variable. In the figure above, a new route is configured where a GET request arrives. The first argument to the get function is the path to the request, the second argument is a method specifying the authentication process required to access the route (in this case it is the presence of a valid JWT token on the authorization header of the request) and the third argument is the function which will be executed when making a request to the specified path. The setup for all the routes is done in a similar way with some routes missing the need to be authenticated in order to access them (in the case of login for example). All the three files mentioned above, the package.json containing the dependencies of the server and the .babelrc specifying the rules for transforming ES6 code into ES5 are stored at the root of the server folder. 3.9.2.1 Controllers Here are defined all the controllers which are called upon hitting an endpoint specified in the router and they are responsible for manipulating the database. As seen on the following figure, controllers play a huge role at an application:
Figure 3-14 Place of the controllers in an application The controllers are grouped into eleven separate files based on the model they are interacting with, each model having its own controller file and each controller can access any model. For example, the Figure 3-15 represents the function called when a teacher wants to delete a post:

Analysis, Design, Implementation and Testing
36 Figure 3-15 Sample function from the posts controller file All the functions from the controllers follow a similar pattern, taking in the req (request objet), res (response object) and next (function for calling the next middleware) parameters and following the following steps: 1. The necessary parameters are extracted either from the “params” (in case there is information in the URL of the request) or from the “body” (in case of a POST request mainly) objects. 2. A modification to a document is made, which can be anything from the CRUD operations 3. If the modification is successful, the response is sent back to the client with the 200 status code, meaning the success. 4. If there is an error, the error thrown by the Promise is caught and handed to the next middleware. 3.9.2.2 Authentication The two Passport.js strategies, used for authenticating users, LocalStrategy and JwtStrategy, used for authentication are implemented in the services folder. The LocalStrategy is responsible for handling the initial login, when there is no available token. This is called after a user enters his credentials on the homepage and hits the Login button. The steps are as follows: 1. The User collection is checked for an existing user with either the received username, email or phone. 2. If there is no such user, the done function is called with the “Incorrect username” message and a false parameter indicating the unsuccessful login. 3. If there is a user, the received password is compared with the existing password from the database by calling the comparePassword method on the user. 4. If the passwords do not match, the done function is called with the “false” parameter indicating again the unsuccessful login. 5. If the passwords do match, the done function is called with the returned user object. If a valid user is returned by the LocalStrategy, the signIn function from the authentication controller is called, which generates a “clean user” (without the password)

Analysis, Design, Implementation and Testing
37 and sends to the client a JWT token which can be stored in the browser storage for further uses. The JwtStrategy is used for authenticating API calls and authenticating automatically the users if they refresh the page or come back to the application after they have closed the session (in case the “remember me” is checked at login). All this is being done by extracting a token from the authorization header of a request and checking its validity. 3.9.3 Client When a user navigates to the application, the flow of the events will be the one presented on the next flowchart diagram:
Figure 3-16 Event flow in the application The component diagrams of the application are presented below. All the below presented components can include other subcomponents too. The purpose of the following figures is to clarify how the application works and how it was developed. The important concepts which are general for the whole application will be discussed in the next section. 3.9.3.1 Starting Point of the Application As mentioned above, before a user is logged in, only the necessary components are included in the bundled file, this leads to faster loading time. The components available at this stage of the application are shown on Figure 3-17:

Analysis, Design, Implementation and Testing
38 Figure 3-17 Component diagram for the starting point of the application This is the main component diagram for the application, before the user is signed in. As one can see, everything starts at the Root component. Only a few things happen at the “Root” component, but they are crucial in the lifecycle of the application: 1. The state for the entire application is initialized (saved in the Redux store). 2. The CSS files are imported. 3. The user’s credentials are verified by searching for an existing JWT token (an encrypted string saved on the user’s machine). 4. The state saved inside the store object is made available to all the other components (by wrapping everything inside the Provider component and passing the store as a prop). 5. The predefined render method from the ReactDOM module renders the Root component into the DOM, to the div present inside the index.html. The next component is an important one too. The Router is defined here, with two initial paths, one for the “/” and one for the invalid paths. The component rendered when a given path is accesed differs based on the authentication status of the user. If he is logged in, the Authorized component is show, else the Home component. All this is being wrapped in a ThemeProvider component, responsible for passing the theme down to all the components. Inside the Authorized component, amongst other things, the connection to the socket.IO server is made by creating and exporting a new socket and the decision to which type of component to return is made. The decision making process is made during the componentDidMount lifecycle hook of the component (it runs after the component got mounted into the virtual DOM), by checking the type of the logged in user, importing the

Analysis, Design, Implementation and Testing
39 necessary components and updating the state to return the needed component. If a component needs some data, that can be pre-fetched at the then branch of the Promise responsible for the import:
Figure 3-18 Dynamic import of the components Inside the same method, the subscriptions of the recently created socket are made (what happens upon receiving a new message or notification for example). In the componentWillReceiveProps (it is called if the component is about to receive new props) lifecycle hook, if the user is logged in and is on the “/” path, he is redirected to the “home” path. In the componentWillUnMount (it is called when the component is un-mounted from the virtual DOM) lifecycle hook, the socket will be deleted from the connected sockets list. If the user is not authenticated, null is returned. If the user is authenticated, but its component has not finished loading yet, a beautiful spinner is displayed with a kind and informative message. Inside the Home component the definition of the routes for this specific part is found, each returning its own component.
Figure 3-19 Route definition for the Home component

Analysis, Design, Implementation and Testing
40 The Login component is mainly responsible for handling the login attempt of a user, displaying an error message if something went wrong. If the user forgot his password, he can easily reset it by clicking on the “Forgot password?” link. This moves the discussion to the next component, the ForgotPassword, being only a field where a user can enter his email address (its correctness is validated asynchronously, allowing him to submit, only if the email address exists) and make a request for resetting his password by hitting the “Reset password” button. If he got the email and he is not late (the link is valid only for 60 minutes), by clicking on the link sent in the email, the third component will appear, the ResetPassword. In the componentDidMount lifecycle hook, the token is extracted from the URL and its validity is checked. If the token is valid, the user can enter his new password and send it to the server. After the request is completed, a status message appears and if everything went right, he can login with his new password. 3.9.3.2 Teacher Component This is the component which will be served upon a teacher signs in successfully to the application. The component diagram containing the main components can be seen in the following figure:
Figure 3-20 Simplified component diagram for a Teacher component At the figure above one can observe the five main parts of the Teacher component. At each of those five components, the teacher can perform different actions After the teacher signs is, he is redirected to the “/home” route, where he can browse the newsfeed of the courses he is involved. The feed is fetched from the server, the request is being made after the component is mounted into the Virtual DOM. The PostList component is

Analysis, Design, Implementation and Testing
41 the same as in the case of the newsfeed of an individual course. Component reusability will be discussed in the upcoming chapters. Probably the most important route for a teacher is the “/courses” one. Navigating to this route, the teacher can choose to interact with the courses he is involved in, the courses being presented in the following way:
Figure 3-21 Course overview for teachers viewed on a desktop device Each card has an initial opacity of 0.8 and if they are hovered, the opacity will increase to 1, resulting in a nice effect. They are constructed the same way, by mapping through the course list, each one getting the title, year, semester, language, courseID as props and rendering the above presented cards. Every card is a link to a detailed section of the course where teachers can read and modify the data of a given course (attendance, grades, description, posts and materials). By clicking on a card, the teacher is redirected to the next page, which has an Accordion component like in the figure below. Each item can be toggled by clicking on them.
Figure 3-22 Course details accordion sample The posts for the selected course can be checked by clicking on the “Newsfeed”. One can make new posts by hitting the “New” button, fill the form and post it. He can choose the subject of the post by selecting from the “Related to” dropdown, can target specific groups, can make the post visible to other teachers too and write the content. Upon hitting the “Post” button, the information is sent to the server and if everything is alright, the post appears as

Analysis, Design, Implementation and Testing
42 the first element of the list below the form. If a given post is made by the logged in teacher, he can edit or delete it. Other possible post manipulations are marking as important and marking as unseen. The description is only a textbox showing a general description of the course, which can be edited by every involved teacher. The attendance of a group can be accessed by clicking on the “Attendance” and selecting the group and the type of the attendance. If everything is selected, the following table is rendered with all the students from the group and the dates when the respective class happens in a semester.
Figure 3-23 Attendance table By clicking on an attendance item, its status can be changed and the result is available in real time, thanks to React. It is important to remark that only the dates before the current date are marked as absent in case of no available presence, the future classes remain white. This is not observable at the figure above, because the picture was taken after the 29th of May. A problem with this table was the huge number of similar components available. For every group there is around 28 (StudentRow) * 14 (AttendanceItem) components. This meant initially the re-rendering of each component when an update occurred. This was caused by the way React behaves. If something is changed inside the main component (in this case the attendance list), all the components above will re-render. Luckily there is a way to solve this, by using the shouldComponentUpdate lifecycle hook of the components (being called before the re-render occurs), where one can specify when should the component update. Figure 3-24 shouldComponentUpdate for the AttendanceItem component

Analysis, Design, Implementation and Testing
43 On the Figure 3-24 it can be observed, that the function returns true, only if the current hasAttendance value is not equal to the next hasAttendance value, otherwise it returns false, meaning no update for the component. The same thing is done for the StudentRow component, the only difference being the comparison of the attendanceList length in the shouldComponentUpdate method. Using this method reduced the initial re-rendering of hundreds of items at each update, to only the update of the changed AttendanceItem. Grades can be accessed by clicking on “Grades” selecting a group. Removing, editing, adding of a grade can be made by any teacher involved in the course. All the possible features of this component is presented on the following figure.
Figure 3-25 Grades component for a teacher If a teacher wants to add more grades to a type, it is simply a click to the green “+” button, and a new column is added. The item having a green background represents a recently edited grade, the one with a gray background is the the grade being edited right now, respectively one having a red one represents an invalid grade (less than 1 and greater than 10). As seen from the above figure, if a grade is above 5, it has a green color and if is below 5 it has a red one. This could be useful to teachers when scanning for students with grade problems. In the “Materials” section, teachers can access and update the existing materials, and add new ones. At this stage of the application they can provide only links to existing sources with a description. By clicking on the “Schedules” link from the header, they are redirected to the “/schedules” route, where table of the teachers’ schedule is being shown, with the logged in teacher preselected. At the “/messages” route one can find all their past conversations, add new messages to existing conversations and start a new thread. At the “/preferences” route, teachers can

Analysis, Design, Implementation and Testing
44 change their login credentials; email, password, username and phone. As these are being common components, they will be discussed later. As the building components from both the Student and Teacher are similar, the separation of the presentational components from the container components, was a great idea. This enabled to reuse the same presentational component for each type, by switching only the container component they are wrapped in. 3.9.3.3 Student Component As it can be seen on the following figure, the component diagram of a Student is similar to the Teacher component. The only major difference in the structure is the appearance of the Grades component.
Figure 3-26 Simplified component diagram for a Student component Although the overall structure of a Student component is similar to a Teacher, the difference lies in the data plugged into each of the components and the access rights to the data. Students mostly have read-only rights, as letting them to manage their grades or attendances for example would not be a good idea. Selecting the “Courses” tab from the header results in getting cards similar to the ones presented at Figure 3-21. Only the courses being studied in a given semester are shown to the student. After clicking on a course, instead of getting the full attendance and grade list for their group, only the logged in student’s data is shown. Upon navigating to the “Schedules” tab, a table with the schedule of the signed in student’s group is show, with the possibility to check the schedule of other groups from the same year.

Analysis, Design, Implementation and Testing
45 The only new tab available for a student is the “Grades” one. Two dropdowns can be found, with one controlling the year of the displayed grades and the other filters the grades by semesters. This functionality is presented in the following figure:
Figure 3-27 Grades functionality The components found at the “Home”, “Messages” and “Preferences” tab are the same as for a Teacher. 3.9.3.4 Schedule Component The Schedule component, more exactly its Table was probably the hardest to implement. At first, the usage of a native table element was considered, but this approach represented a problem, as the number of elements can be changed based on two variables (semigroup and frequency). Another issue was how the component looked on smaller devices. So in order to solve this problem, a custom table was implemented based on flexbox. On the following figure, the presentational components and how they are nesting is shown:
Figure 3-28 Schedule component

Analysis, Design, Implementation and Testing
46 The Filter consists of three dropdowns, one for the entity whose schedule wants to be checked (group or teacher), one for filtering by semigroups and one for filtering by the frequency of the items (even weeks, odds or both). If a student is logged in the options in the first dropdown will reflect the groups from the same year and in the case of a teacher the values will be the name of their colleagues. This is done in the componentDidMount lifecycle method of the FilterContainer container component in both of the cases by dispatching the changeScheduleOf action creator, which sends a request to the server and populates the dropdown. The Table is composed of two main components. The InfoColumn is a simple presentational component, showing only the subject of each row, the only change is hiding it when the user is on a smaller device. Five Column components are present, one for each day of the week.
Figure 3-29 Table component The first two rows for each Column component only show information about the columns, based on the state of the dropdown. Starting from the forth row. Each column has at least one or at maximum four Week components, based on the state of the frequency filter. Each Week component has at its first row the number of the week (1 for odd, 2 for even), followed by seven ScheduleItem components. To construct a ScheduleItem, a check is needed while mapping over the schedulesList array. The result for the selected week, semigroup, day and hour is passed down to the ScheduleItem which renders something based on that value. If a schedule is present, the initials of the course are written in the box and colored based on the type of the item. If no schedule is found, the box remains empty.

Analysis, Design, Implementation and Testing
47 Figure 3-30 Column component 3.9.3.5 Messages Component The “Messages” component is responsible for handling the messaging in the application. As seen on the following figure, it consists of three major components: Inbox, Conversation and NewThread. The NewThread component is not shown on the figure, it is a form where users can start new thread, by entering the username, subject and the message.
Figure 3-31 Messages component

Analysis, Design, Implementation and Testing
48 It can be observed how the component is composed from the figure above. Two things are worth mentioning though. The first is the real-time behavior of the component, it gets the updates via WebSockets (making possible the instant appearance of new data). The Thread components inside the Inbox are generated by iterating over the existing conversations of the user, which is fetched after the component got mounted. If there is no conversations, a “No messages…” message is displayed. Figure 3-32 Generating the Thread components To reduce the number of renders, shouldComponentUpdate was used in a similar manner as described at Figure 3-24. 3.9.3.6 Preferences Two things can be done in the Preferences component: update password and change account details (email, username or phone). An interesting thing is the asynchronous validation of the fields, when changing account details. This includes a check on the server, if the entered credentials already exist and if the answer is positive, the form can not be submitted. This is done by handling a validation function to the form decorated with reduxForm. 3.9.3.7 Header Component The Header component is a universal one too. On the left, the MenuItems (links) are generated, while on the right different actions can be taken. By clicking on the bell or envelope icons, a dropdown will appear showing the notifications and the messages received by the user, clicking on the gears results in the redirection to the Preferences tab and selecting the last icon the user can sign out (the stored token will be deleted). Figure 3-33 Header component

Analysis, Design, Implementation and Testing
49 The dropdown for the Messages and Notifications components can be reused, as only the content changes. All the common logic is separated inside the DropDown component, getting as a crucial prop the Item component (message or notification) to be shown:
Figure 3-34 Rendering of the DropDown component When on a device with a width less than 768 pixels, the links are switched to a burger menu. This can be toggled by clicking the icon on the left side of the Header.
Figure 3-35 Header component on an iPhone 6

Analysis, Design, Implementation and Testing
50 3.9.3.8 Redux The store is a key-value JavaScript object, which is responsible for holding the whole state of the application. A part of it is presented on the figure below.
Figure 3-36 Redux store of the application In most of the cases the following steps are followed upon updating the Redux store. The case of a login attempt of a user is described: 1. When the user clicks on the “Login” button after entering his credentials, the loginUser action creator will be dispatched from the redux/account/auth.js file.
Figure 3-37 Action creator returning a thunk, responsible for authenticating users

Analysis, Design, Implementation and Testing
51 2. An action having only a type AUTH_USER is dispatched, updating the application with the loading state of the login attempt 3. A request is made to the “/api/auth/login” path, with the entered username and password in the body by calling the post function from the axios library (for making requests), which returns a Promise. 4. If the Promise gets resolved (successful login), the user is authenticated by dispatching the action with type AUTH_USER_SUCCESS and a payload containing the token and the user returned from the server is dispatched to the reducers 5. If the Promise is rejected (invalid password, server error), an action with type AUTH_USER_ERROR and a payload containing the error is dispatched to the reducers 6. The action arrives to the authReducer and the store is updated based on the type it receives
Figure 3-38 authReducer implementation 7. The components get updated and the user is signed in (in the case of a successful login) 3.9.3.9 Styling The styling of components was done using styled-components. This made possible styling each component separately, increasing the independence of a component. All the components have their style defined in the same file, where the component is defined. A styled div HTML element is presented on the figure below. It can be seen the possibility to use traditional CSS inside the tagged template literals, including media queries, pseudo selectors, transitions. On top of this, the usage of JavaScript is possible (the width of the component is set based on the truthness of the student prop passed to the component).

Analysis, Design, Implementation and Testing
52 Figure 3-39 Styled component example 3.10 Testing For testing of the application the Chrome DevTools, trial and error, usage of the console.log function and the terminal was used in the majority of the cases. Three test cases for three different aspects of the application will be described in the following sections. Similar solutions were used in order to test other parts of the application too. 3.10.1 Test Case 1, Login of a teacher 1. The username (ionelarotaru18) and the password (ionelarotaru18) is entered.
Figure 3-40 Before making a request

Analysis, Design, Implementation and Testing
53 2. After hitting the “Login” button, a request is sent to the server, checking the correctness of the credentials. If everything is correct, the Teacher component is loaded, showing a spinner while it loads.
Figure 3-41 Successful login 3. The teacher can browse the private content
Figure 3-42 Private content mounted

Analysis, Design, Implementation and Testing
54 3.10.2 Test Case 2, Sending a message Here the real-time behavior of the Messages and Notifications component is tested. Suppose that teacher Ionela wants to send a message to Mircea. 1. It can be seen on the following figure that neither of the participants have a recent conversation history and Ionela is about to send a new message to Mircea
Figure 3-43 Before sending the message 2. The request is sent to the server to store the message and after it is done successfully, the server emits an update to Mircea with the help of the socket
Figure 3-44 New message sent and arrived successfully

Analysis, Design, Implementation and Testing
55 3.10.3 Test Case 3, Responsive design With the help of the great tool Sizzy2.2.3.7, the responsive design was easy to test. On the following image, the responsiveness of the Messages and the Header component can be seen on the following devices: (iPhone4, iPhone5, iPhone6, iPhone7Plus, iPad Air):
Figure 3-45 Responsiveness of the Messages and Header components

Conclusions
56 4 Conclusions Managing a university is a complex responsibility especially if multiple different tools are used to solve the problem. By using a centralized web application to solve all the management related tasks, a huge cognitive load could be removed from the students and the teachers. Developing UTSocial from scratch was more than a full time job during the past few months. The presented application is the result of hundreds of hours of hard work, dozens of fixed bugs and some awesome features. 4.1 Results Obtained All the objectives of the application mentioned in the introduction were implemented and integrated successfully into UTSocial. The obtained results can be summarized as follows: • A responsive, user friendly and fast web application. • A newsfeed system where teachers can send announcements directly to the groups they are involved in. • A messaging system to solve the communication barriers between teachers and students. • Users can change their username, email, phone or password. • If the password of a user is forgotten, resetting it is straightforward and easy. • Students can see all their grades obtained during their studies at a single place, filtering by year and/or semester. • Students get notified each time they get a new grade or attendance. • Students have grades, attendances, news and materials at one place for each of the course they are enrolled. • Teachers can manage the attendances, grades, new and materials of the courses they are teaching at a single place. • Dynamic schedule component.

Conclusions
57 4.2 Development Direction As in the majority of software development projects, there is no such thing as “done” for an application. Always will be improvements, bug fixes and new features which should be implemented. UTSocial is not different neither. The focus was placed on the key features of the application, to solve several issues that teaching activities rise and the universities are facing. A lot of features are in plan for the next versions of the application: • A sophisticated administrator section for managing students, teachers, courses etc. • The possibility of adding temporary features to the application (for example enrolling into thesis defense, review of the teachers etc.). • A payment system for paying exams and university fees. • Writing automated tests for the whole application. • Making possible to upload files where it makes sense (materials, messages, newsfeed). • Personalized performance analysis for each student using machine learning and pattern recognition. • Developing an Android and iOS mobile application. • Making possible managing multiple universities. • Making secure and scalable enough in order to be used by universities in production.

References
58 5 References [1] https://www.edmodo.com/ (Last accessed: 14 April 2017) [2] http://newstudentportal.maastrichtuniversity.nl/ (Last accessed: 14 April 2017) [3] https://academicinfo.ubbcluj.ro/Info/ (Last accessed: 16 April 2017) [4] https://depinfo.utcluj.ro/ (Last accessed: 19 May 2017) [5] https://moodle.org/ (Last accessed: 14 April 2017) [6] https://play.google.com/store/apps/details?id=com.creative_minds.feaa_app (Last accessed: 14 April 2017) [7] https://electron.atom.io/ (Last accessed: 14 April 2017) [8] https://github.com/ (Last accessed: 24 June 2017) [9] https://atom.io/ (Last accessed: 14 April 2017) [10] https://facebook.github.io/react-native/ (Last accessed: 14 April 2017) [11] https://www.nativescript.org/ (Last accessed: 14 April 2017) [12] https://cylonjs.com/ (Last accessed: 14 April 2017) [13] E. Brown, Web Development with Node and Express: Leveraging the JavaScript Stack, O’Reilly Media, 2014 [14] https://nodejs.org (Last accessed: 07 June 2017) [15] https://expressjs.com (Last accessed: 02 June 2017) [16] https://jwt.io/ (Last accessed: 07 June 2017) [17] https://socket.io (Last accessed: 29 May 2017) [18] http://passportjs.org/ (Last accessed: 11 May 2017) [19] https://www.mongodb.com/ (Last accessed: 16 June 2017) [20] http://mongoosejs.com/ (Last accessed: 16 June 2017) [21] S. Stefanov, React: Up & Running: Building Web Applications, USA, O’Reilly Media, 2016 [22] V. Subramanian, Pro MERN Stack: Full Stack Web Development with Mongo, Express, React and Node, Apress, 2017 [23] https://facebook.github.io/react/ (Last accessed: 28 June 2017) [24] https://facebook.github.io/react/docs/components-and-props.html (Last accessed: 01 July 2017) [25] http://redux.js.org/ (Last accessed: 28 June 2017) [26] I. Gelman, B. Dinkevich, The Complete Redux Book, Lean Pub, 2017 [27] http://redux-form.com/6.8.0/ (Last accessed: 01 June 2017) [28] https://reacttraining.com/react-router/ (Last accessed: 01 June 2017) [29] https://www.styled-components.com/ (Last accessed: 01 June 2017) [30] https://react.semantic-ui.com/introduction (Last accessed: 11 June 2017) [31] https://babeljs.io/ (Last accessed: 22 May 2017) [32] https://webpack.js.org/ (Last accessed: 22 May 2017) [33] https://www.sketchapp.com/ (Last accessed: 22 May 2017) [34] https://github.com/eslint/eslint (Last accessed: 22 May 2017)

References
59 [35] https://www.npmjs.com/package/eslint-config-airbnb(Last accessed: 22 May 2017) [36] https://prettier.github.io/prettier/ (Last accessed: 22 May 2017) [37] http://sizzy.co/ (Last accessed: 29 June 2017) [38] https://heroku.com (Last accessed: 04 July 2017) [39] https://developer.mozilla.org/enUS/docs/Web/JavaScript/Reference/Template_literals (Last accessed: 01 June 2017) [40] https://mlab.com/ (Last accessed: 04 July 2017) [41] https://github.com/robertistok/utsocial (Last accessed: 04 July 2017) [42] http://www.stanforddaily.com/2017/02/28/cs-department-updates-introductory-courses/ (Last accessed: 14 April 2017) [43] https://angular.io/ (Last accessed: 14 April 2017) [44] https://github.com/erikras/ducks-modular-redux (Last accessed: 22 May 2017) [45] http://www.agilemodeling.com/artifacts/userStory.htm (Last accessed: 21 June 2017) [46] https://nodejs.org/en/download/ (Last accessed: 22 June 2017) [47] https://www.mongodb.com/download-center (Last accessed: 22 June 2017) [48] https://utsocial.herokuapp.com/ (Last accessed: 04 July 2017) [49] https://yarnpkg.com/en/ (Last accessed: 22 May 2017) [50] https://docs.mongodb.com/manual/core/data-model-design/(Last accessed: 21 June 2017) [51] https://www.npmjs.com/package/bcrypt-nodejs (Last accessed: 26 June 2017) [52] https://depinfo.utcluj.ro/GrupaOct2016/anul.asp (Last accessed: 26 June 2017) [53] https://www.npmjs.com/package/x-ray (Last accessed: 26 June 2017)

List of Figures
60 6 List of Figures FIGURE 2-1 DOCUMENT REPRESENTATION IN A MONGODB DATABASE ……………………………………………………………………………… 9 FIGURE 2-2 REACT DOM UPDATE STRATEGY ………………………………………………………………………………………………………….. 10 FIGURE 2-3 REDUX WORKFLOW …………………………………………………………………………………………………………………………. 12 FIGURE 3-1 USE CASE DIAGRAM FOR A TEACHER ……………………………………………………………………………………………………… 21 FIGURE 3-2 USE CASE DIAGRAM FOR A STUDENT ……………………………………………………………………………………………………… 22 FIGURE 3-3 USE CASE DIAGRAM FOR AN ADMIN ………………………………………………………………………………………………………. 23 FIGURE 3-4 DATABASE DESIGN ………………………………………………………………………………………………………………………….. 24 FIGURE 3-5 CLIENT-SERVER MODEL …………………………………………………………………………………………………………………….. 25 FIGURE 3-6 REDUX DATA FLOW …………………………………………………………………………………………………………………………. 26 FIGURE 3-7 MONGODB SETUP ………………………………………………………………………………………………………………………….. 29 FIGURE 3-8 VIRTUAL FIELD DEFINITION …………………………………………………………………………………………………………………. 31 FIGURE 3-9 PASSWORD ENCRYPTION BEFORE SAVE …………………………………………………………………………………………………… 31 FIGURE 3-10 SAMPLE OF A STUDENT BEFORE PARSING ………………………………………………………………………………………………. 33 FIGURE 3-11 PARSING ALGORITHM OF STUDENTS …………………………………………………………………………………………………….. 33 FIGURE 3-12 CONNECTION TO THE DATABASE ………………………………………………………………………………………………………… 34 FIGURE 3-13 SAMPLE ROUTE FOR GETTING THE CONVERSATIONS OF A USER ……………………………………………………………………… 35 FIGURE 3-14 PLACE OF THE CONTROLLERS IN AN APPLICATION ……………………………………………………………………………………… 35 FIGURE 3-15 SAMPLE FUNCTION FROM THE POSTS CONTROLLER FILE ………………………………………………………………………………. 36 FIGURE 3-16 EVENT FLOW IN THE APPLICATION ………………………………………………………………………………………………………. 37 FIGURE 3-17 COMPONENT DIAGRAM FOR THE STARTING POINT OF THE APPLICATION …………………………………………………………… 38 FIGURE 3-18 DYNAMIC IMPORT OF THE COMPONENTS ………………………………………………………………………………………………. 39 FIGURE 3-19 ROUTE DEFINITION FOR THE HOME COMPONENT …………………………………………………………………………………….. 39 FIGURE 3-20 SIMPLIFIED COMPONENT DIAGRAM FOR A TEACHER COMPONENT ………………………………………………………………….. 40 FIGURE 3-21 COURSE OVERVIEW FOR TEACHERS VIEWED ON A DESKTOP DEVICE …………………………………………………………………. 41 FIGURE 3-22 COURSE DETAILS ACCORDION SAMPLE ………………………………………………………………………………………………….. 41 FIGURE 3-23 ATTENDANCE TABLE ………………………………………………………………………………………………………………………. 42 FIGURE 3-24 SHOULDCOMPONENTUPDATE FOR THE ATTENDANCEITEM COMPONENT ………………………………………………………….. 42 FIGURE 3-25 GRADES COMPONENT FOR A TEACHER ………………………………………………………………………………………………….. 43 FIGURE 3-26 SIMPLIFIED COMPONENT DIAGRAM FOR A STUDENT COMPONENT …………………………………………………………………. 44 FIGURE 3-27 GRADES FUNCTIONALITY …………………………………………………………………………………………………………………. 45 FIGURE 3-28 SCHEDULE COMPONENT ………………………………………………………………………………………………………………….. 45 FIGURE 3-29 TABLE COMPONENT ………………………………………………………………………………………………………………………. 46 FIGURE 3-30 COLUMN COMPONENT …………………………………………………………………………………………………………………… 47 FIGURE 3-31 MESSAGES COMPONENT …………………………………………………………………………………………………………………. 47 FIGURE 3-32 GENERATING THE THREAD COMPONENTS ……………………………………………………………………………………………… 48 FIGURE 3-33 HEADER COMPONENT …………………………………………………………………………………………………………………….. 48 FIGURE 3-34 RENDERING OF THE DROPDOWN COMPONENT ……………………………………………………………………………………….. 49 FIGURE 3-35 HEADER COMPONENT ON AN IPHONE 6 ……………………………………………………………………………………………….. 49 FIGURE 3-36 REDUX STORE OF THE APPLICATION …………………………………………………………………………………………………….. 50 FIGURE 3-37 ACTION CREATOR RETURNING A THUNK, RESPONSIBLE FOR AUTHENTICATING USERS …………………………………………….. 50 FIGURE 3-38 AUTHREDUCER IMPLEMENTATION ………………………………………………………………………………………………………. 51 FIGURE 3-39 STYLED COMPONENT EXAMPLE ………………………………………………………………………………………………………….. 52 FIGURE 3-40 BEFORE MAKING A REQUEST …………………………………………………………………………………………………………….. 52 FIGURE 3-41 SUCCESSFUL LOGIN ……………………………………………………………………………………………………………………….. 53 FIGURE 3-42 PRIVATE CONTENT MOUNTED ……………………………………………………………………………………………………………. 53

List of Figures
61 FIGURE 3-43 BEFORE SENDING THE MESSAGE …………………………………………………………………………………………………………. 54 FIGURE 3-44 NEW MESSAGE SENT AND ARRIVED SUCCESSFULLY ……………………………………………………………………………………. 54 FIGURE 3-45 RESPONSIVENESS OF THE MESSAGES AND HEADER COMPONENTS ………………………………………………………………….. 55