JOHANNES KEPLER UNIVERSITAT¨ LINZ JKU

Faculty of Engineering and Natural Sciences

Online Collection of Algorithms

Master’s Thesis

submitted in partial fulfillment of the requirements for the academic degree Diplom-Ingenieur

in the Master’s Program Computer Science

Submitted by Wolfgang K¨ullinger,BSc.

At the Institut f¨urSystemsoftware

Advisor a.Univ.-Prof. Dipl.-Ing. Dr. G¨untherBlaschek

Linz, November 2015 Abstract

This thesis presents an interactive web platform, that provides an online knowledge base for common algorithms. The main target are algorithms that are important for ongoing computer scientists. The platform offers the possibility to try algorithms immediately. Every execu- tion step can be analyzed. The changes in the memory are visualized. Run-time statistics are collected and can be used to compare similar algorithms. New algorithms can be added using a registered user account. An author can use a graphical programming language to define algorithms. Any kind of information can be attached. Using comments and annotations, an algorithm can be explained in more detail. In particular students could benefit from the visual presentation of important algorithms. A web browser and an internet connection is needed in order to use the platform. There is no need to install any tools on the computer. It is not required to register for the basic functionality.

This thesis gives insights about the program’s internals. Some implementation details are explained extensively. The basic architecture is discussed and sketched schematically. It is a guide through the possibilities of the web application. All areas are explained using examples and illustrations. It also serves as documentation. A detailed guideline describes the necessary steps in order to install the system on a web server. All the possible configuration settings are explained in detail.

ii Kurzfassung

Diese Abhandlung pr¨asentiert eine interaktive Web-Plattform, die eine Sammlung von ublichen¨ Algorithmen bereith¨alt. Haupts¨achlich werden jene Algorithmen ge- sammelt, die fur¨ Informatik-Studierende relevant sind. Die Plattform bietet die M¨oglichkeit, Algorithmen sofort zu probieren. Jeder Ausfuhrungsschritt¨ kann dabei analysiert werden. Anderungen¨ im Speicher werden visualisiert. Eine Laufzeit-Statistik wird aufbereitet und kann dafur¨ verwendet werden, ¨ahnliche Algorithmen zu vergleichen. Mittels eines registrierten Kontos k¨onnen neue Algorithmen hinzugefugt¨ werden. Es kann auf eine grafische Programmiersprache zuruck¨ gegriffen werden, um einen Algorithmus zu definieren. Hintergrundinformationen k¨onnen hinzugefugt¨ werden. Kommentare und Anmerkungen k¨onnen dazu verwendet werden, einen Algorith- mus noch weiter auszufuhren.¨ Vor allem Studierende k¨onnten von der visuellen Pr¨asentation wichtiger Algorithmen profitieren. Um die Plattform verwenden zu k¨onnen, werden ein Web-Browser und eine Internetverbindung ben¨otigt. Es mussen¨ keine zus¨atzlichen Werkzeuge installiert werden. Auch eine Anmeldung ist nicht n¨otig, um die Grundfunktionalit¨at nutzen zu k¨onnen.

Die Abhandlung gew¨ahrt Einblicke in den Aufbau des Programms. Einige Imple- mentierungs-Details werden ausfuhrlich¨ erkl¨art und die grunds¨atzliche Architektur wird diskutiert und schematisch skizziert. Alle M¨oglichkeiten und Bereiche der Web-Anwendung werden exemplarisch beschrieben. Sie dient ebenso als Dokumentation. Genaue Anweisungen beschreiben die n¨o- tigen Schritte, um das Programm auf einem Web-Server zu installieren. Alle Kon- figurationsm¨oglichkeiten werden er¨ortert.

iii Contents

1 Introduction 1 1.1 Motivation ...... 1 1.1.1 Assignment ...... 1 1.1.2 Target groups ...... 2 1.2 Results ...... 3 1.2.1 Outline ...... 3 1.2.2 Supported algorithms ...... 4 1.3 Overview ...... 5

2 Foundations 6 2.1 Related work ...... 6 2.2 Environment ...... 9 2.2.1 FLOSS principles ...... 9 2.2.2 Web application ...... 9 2.3 Diagrams ...... 10

3 Language 13 3.1 Design ...... 13 3.2 Data types ...... 13 3.2.1 Type conversion ...... 14 3.2.2 Variables ...... 14 3.3 Building block elements ...... 15 3.3.1 Annotation building blocks ...... 16 3.3.2 Operation building blocks ...... 17 3.3.3 Structure building blocks ...... 20 3.3.4 Value building blocks ...... 22 3.4 Example ...... 22

4 Usage 25 4.1 User interface ...... 25 4.2 Algorithm user interface ...... 26 4.2.1 View perspective ...... 27 4.2.2 Edit perspective ...... 29

iv Contents

4.3 Management user interface ...... 32 4.3.1 Algorithm management ...... 32 4.3.2 User management ...... 33

5 Architecture 35 5.1 Rationale ...... 35 5.2 Server & Client ...... 36 5.2.1 Communication ...... 36 5.2.2 Tasks ...... 37 5.3 Database ...... 38

6 Implementation 40 6.1 Data types ...... 40 6.1.1 Variables ...... 41 6.2 Tree structure ...... 41 6.2.1 Building blocks and Nodes ...... 42 6.2.2 Parsing ...... 43 6.3 Tree traversal ...... 43 6.3.1 Execution ...... 44 6.4 Storage ...... 46 6.5 Used technology ...... 48

7 Configuration 49 7.1 Installation ...... 49 7.1.1 Prerequisites ...... 49 7.1.2 File system preparations ...... 50 7.1.3 Database preparations ...... 50 7.2 Settings ...... 51 7.2.1 Optional settings ...... 51 7.2.2 Language settings ...... 53 7.2.3 Section settings ...... 54

8 Technical data 55 8.1 Test environment ...... 55 8.1.1 System configuration ...... 56 8.1.2 Test algorithm ...... 57 8.2 Benchmarks ...... 58

9 Review 60 Creation ...... 60 Acknowledgements ...... 61

v Contents

List of Figures 63

List of Listings 64

Bibliography 65

A Benchmark data 67

vi 1 Introduction

This chapter gives insights about the idea that led to the development of the software system. Target groups are identified and the expected outcome is defined. It also serves as a guide through the rest of the thesis.

1.1 Motivation

Every computer scientist gets to know a lot of common algorithms during educa- tion. These are not always easy to understand. Simple diagrams can help. The static content of diagrams is not always able to make the flow of data understand- able. Yet the visualization of this flow is important. The idea is to provide an interactive system to simplify the learning process.

1.1.1 Assignment

The idea of an “Online Collection of Algorithms” is a web-based system used for the management of and interaction with algorithms. Algorithms should be prepared by the community. On the one hand it should serve as a centralized knowledge base that contains information about basic algorithms. On the other hand it should be easy to try this knowledge immediately. Teachers should be able to describe common algorithms in a visual way. These algorithms should be executable step by step. The student should be able to follow the stages of the execution in every detail. The definition and description of new algorithms should work without any fur- ther tools. When looking at an algorithm, the intention of its author should be easily understandable. The playback functionality should be simple and clearly

1 Introduction arranged. Following the control and data flow should be intuitive and predictable. The values of community should be promoted through the possibility to share content among other users. One explicit requirement is the possibility to compare algorithms. This requires the introduction of algorithm statistics and metrics. Pseudo-code and annotations should be available in order to support the intentions of authors. Textual as well as graphical representation of an algorithm should be supported. Cross-referencing between algorithms should be possible. General background information as well as external references should be attachable. Users should interact with the system using web browsers. This makes the system independent of the users’ operating systems. The aim is to create a system that can be run on most common server technology. An amount of predefined algorithms should demonstrate the functionality and the abilities of the system. These should preferably be algorithms that are impor- tant for computer science students.

1.1.2 Target groups

The major target groups can be found in an academic context. The knowledge about fundamental algorithms is part of every computer scientist’s education. Therefore the aim of this system is to support teachers on defining algorithms that can be presented in class. Students should be supported to understand algo- rithms more easily. Teachers are the first group that has contact with the system. Teachers for com- puter science do not necessarily need to have programming experience. Therefore the algorithm definition process has to be designed in a way that no program- ming skills are required. Computer scientists with experience concerning software development should also be able to define algorithms. This raises the idea of pro- viding a graphical system that is closely related to the usual textual way of writing algorithms. Students are the group that mainly uses algorithms that are already defined. The system should be aware of students that have little or no programming expe- rience. The relationship of the memory contents and the algorithm must be clearly

2 Introduction visible. If an instruction in the algorithm manipulates the contents of a memory cell, this must be obvious and easy to follow. The computation costs of selected operations are important for being able to compare algorithms. One basic use case can be concluded involving both major target groups. In order to prepare a lesson, a teacher defines an algorithm. Comments can be prepared and basic information attached. The algorithm can be either demonstrated to the students or students can play with the algorithm individually. Both alternatives can be directly applied in class.

1.2 Results

The program that was developed in the course of this thesis is named “kartuli- mardikas”. This is the Estonian name of the “Colorado potato beetle”. The name serves as working title during development. The nominal association with a software bug is intended. It characterizes software products in general, especially those in development. It might also serve as reminder for the future authors of algorithms who use this system. Programs and algorithms are always accompanied by mistakes and errors. The system has been developed as open-source project. It is hosted on a public platform providing details about the current development status and changes. This system is licensed under a GNU General Public License (GPL), which guarantees that everyone can use, copy and modify the software as long as all derivations are licensed under compatible licenses.[Smith 2007]

1.2.1 Outline

The created web application can be accessed by the most common web browsers. It provides a graphical interface to almost all of its operations. The basic func- tionality of the software can be summarized as follows.

• Registration: Everyone can view a public algorithm. For defining new algo- rithms, registration is required. The system also provides a graphical user interface to manage user accounts.

3 Introduction

• Definition: The definition and description of an algorithm is supported by a visual programming language that was developed in the course of this project.

• Playback: The system provides the possibility to watch an algorithm execute. It is possible to observe the changes in the variable memory as well as in the statistics. The algorithm can be executed manually step by step or automatically with variable speed and breaks.

• Storage: All the defined algorithms that have been published can be ex- plored. There are several suggestions of what is new or recently edited. The whole database can also be filtered and searched. Tags are used to categorize algorithms.

• Administration: Users and algorithms can be managed using an administra- tion user interface. It provides global lists (also listing private algorithms) with the possibility to change common settings easily. This feature is only available for users that have extended user rights (Moderators and Adminis- trators).

The graphical interface is designed to be perfectly usable by mouse. Vertical scrolling as well as clicking is necessary in order to use the entire functionality. Due to accessibility reasons there is also support for keyboard usage in a wide range. Also touch-devices like tablets and smart phones are supported by the system. However very small displays might have troubles displaying very complex algo- rithms. The whole algorithm can be examined using basic scrolling.

1.2.2 Supported algorithms

The system supports two very basic data structures.

• an element can have one single value • a list can have multiple values The system is restricted to algorithms that do not need data structures different than elements and lists. Supported structures are conditions, loops and function calls amongst others. Given these structures, iterative as well as recursive algo-

4 Introduction rithms are generally definable.[B¨ohm1966] A detailed list of supported structures can be found in chapter 3.

1.3 Overview

This section gives a short introduction into the chapters of this thesis.

• Foundations: The second chapter contains a broad description of external in- fluences and the environment, in which this project is embedded. It provides references to projects that target similar aims.

• Language: Chapter three introduces a graphical programming language that was designed for this project. The language aims to allow general purpose programming for experts and especially for beginners.

• Usage: The fourth chapter demonstrates the visual programming language in action. It gives an idea about the broad functionality of the system. The graphical user interface is introduced.

• Architecture: The fifth chapter describes the design principles of the system. It outlines the collaboration mechanisms of all components. The concepts of data storage are presented.

• Implementation: Chapter six guides through a selection of important imple- mentation details. It describes the mechanisms and data structures that are used in order to make the visual programming language work.

• Configuration: The seventh chapter provides details about the installation of the system. All the possible configuration settings are listed and explained.

• Technical data: Chapter eight provides measurements about the system in action. An algorithm is executed on different web browsers in multiple envi- ronments in order to test the system.

• Review: The last chapter deals with the personal thoughts about the process of creating the system. It filters the problems and decisions during develop- ment, the errors from which could be learned.

5 2 Foundations

This chapter contains a broad description of external influences and the environment, in which this project is embedded. It provides references to projects that target similar aims.

2.1 Related work

There are several attempts to provide a comfortable environment for algorithm editing. One of these projects is Scratch1, a visual programming environment primarily aiming at children of ages 8 to 16. Scratch was published in 2003 and is being actively developed by the MIT Media Lab. The same laboratory developed and published “StarLogo” in 1996, which had a strong influence on Scratch.[Maloney 2010] Another popular algorithm editor is used in AppInventor2 for Android mobile phones, which was originally developed by Google Labs but is now being main- tained by the MIT Media Lab. It aims at users with hardly any programming experience. AppInventor provides two basic modules. One of the modules is for designing the user interface of the Android App. The other one deals with the logic below the surface and follows the same principles as Scratch.[Papadakis 2014] A more general approach is Blockly3, a project which is being developed by Google Labs. It was also influenced by Scratch and provides a block-based algo- rithm editor which can be used online with any common web browser. The projects above use block-based programming. This approach can be demonstrated using an example. Assume a script with only one variable a, which

1https://scratch.mit.edu/ 2http://appinventor.mit.edu 3https://developers.google.com/blockly/

6 Foundations

is initialized with the value 0. A loop checks whether the variable is smaller than 42. If true, the variable is incremented by 1. If false (after the last loop iteration) the loop is exited and the variable is printed. Listing 2.1 provides the pseudo code notation for this example.

1 a := 0

2 while ( a < 42) do

3 a := a + 1

4 write ( a )

Listing 2.1: Basic loop example in Pseudo code

Both Scratch and Blockly provide very colorful user interfaces. The block ele- ments can be moved and configured by mouse. Scratch uses a click at the green flag in the top right corner as trigger to start the script. Blockly does only provide a JavaScript function that needs to be called in order to step through the program.

(a) Scratch (b) Blockly

Figure 2.1: Basic loop example in Scratch and Blockly

The two examples above show a very simple algorithm definition and execution process. In order to write a new algorithm, the mouse can be used to move blocks. Every block represents one basic instruction or element of the program. The currently executed part of the program is highlighted.

7 Foundations

There are several projects that provide a collection of basic, often used algo- rithms. One of these projects is Daqwest4. It collects knowledge about a topic from different sources and combines it to one general knowledge base. This ap- proach is not exclusively used for algorithms but can cover any topic. Daqwest is supported by several universities and many coding communities. It also includes introductions and explanations from Wikipedia. The content is managed by a community. Every registered user can add and edit entries. One of the contributing community pages is GeeksforGeeks5. It hosts a com- prehensive list of algorithms. The platform also provides the possibility to test code snippets in an online scripting environment.

Figure 2.2: Basic loop example at GeeksforGeeks

The development environment of GeeksforGeeks supports the programming lan- guages C, C++, Java and Python. It allows instantaneous online scripting. One drawback is the execution of the script. The results are printed without any visu- alization. Individual stages and memory manipulations cannot be observed.

4http://www.daqwest.com 5http://www.geeksforgeeks.org

8 Foundations

2.2 Environment

Two fundamental concepts of this project are transparency and openness. The system requires and uses only software that is not restricted by copyright laws. It uses open web standards and common architecture principles. The algorithms that are produced with the help of this system are published without any restrictions.

2.2.1 FLOSS principles

The whole system is designed to use free and open-source software. These princi- ples can be described by the acronym FLOSS (Free/Libre/Open-Source Software). The FLOSS community advocates for the free use of software and against soft- ware patents. In different forms and organizations, the community provides more or less restrictive licenses. These ensure the rights of the original writer of the software, but encourage the free and unrestricted reuse by others.[Miller 2010]

2.2.2 Web application

In order to comply with universal usability, one very common approach is the usage of web technologies. Web browsers can be run on a wide variety of devices: smart phones, tablets, notebooks and desktop computers amongst others. Most modern browsers implement the following web technology standards.

• HTML5 is the language that is used to communicate via the world wide web. The latest version supports a lot of functionality that can be used for animation and interaction.[W3C 2014]

• CSS3 is used to attach style information to HTML tags. It can also be used for animations. The latest version allows easier definitions and provides more possibilities for mobile devices.[W3C 2013]

• JavaScript is a scripting language that runs on common graphical web browsers. It is standardized under the name “ECMAScript”. All dynamic interactions with the browser require JavaScript.[ECMA 2015]

Restricting a web application to these technologies ensures the compatibility of the supported devices. This is also the approach of this project.

9 Foundations

On the server side, a very common approach is the use of a LAMP software stack. LAMP in an acronym for “Linux, Apache, MySQL and PHP/Perl”. In further detail, this combines the following strategies:

• Linux6 is an operating system that can be run on the server. A Linux system can be installed choosing from a big variety of different distributions.

• Apache7 is a software package that provides an infrastructure for servers that host web projects.

• MySQL8 is a database software that provides a relational database service. Linux distributions often use a community-developed fork, “MariaDB”.

• PHP9 or a similar scripting language is used to generate dynamic HTML code and to communicate with clients. All of the above software products can be used under FLOSS licenses. This is the reason why this combination of software became popular in web development. It is used on a majority of web servers.[Koranne 2011] The LAMP idea comes with common variations. Every part can be replaced by a different product. One of the requirements for this project was to be able to run on a machine with a very basic LAMP installation.

2.3 Diagrams

There are several concepts for the illustration and visualization of algorithms. Diagrams play an important role in algorithm education. One of the most famous graphical notation standards for algorithms are Flowcharts. The concepts of Flowcharts are used in modern notation languages like UML. Boxes of different shapes are used to symbolize processes. Processes are connected with lines and arrows, which visualize the possible data and control flow during execution.

6https://www.linux.com/ 7https://httpd.apache.org/ 8https://www.mysql.com/ 9https://secure.php.net/

10 Foundations

Example

Set a to 0

Is a smaller than 42? YES NO Increment a by 1

Print a

End

Figure 2.3: Basic loop example as DRAKON diagram (extended Flowchart)

Another different approach is the Nassi-Shneiderman diagram. The usage of ordered structures and simple shapes are the central idea. No arrows are needed in this kind of graph. Rectangles are arranged vertically for the representation of consecutive processes. To express conditional processes the rectangles are arranged horizontally.[Nassi 1973]

Set a to 0 Is a smaller than 42? Increment a by 1 Print a

Figure 2.4: Basic loop example as Nassi-Shneiderman diagram

The simple and clear representation is the main benefit of Nassi-Shneiderman diagrams. A visualization method very similar to these diagrams is used in this project. The used version of the diagrams however has one major difference. Conditional branches are usually drawn as two columns next to each other. With increasing nesting level the diagrams grow in width. As the architecture is aimed at web browser usage, this growth is a drawback.

11 Foundations

One modification has been made in order to avoid the growth in width. Similar to the loop syntax (see Figure 2.4), the boxes for conditional branches are arranged underneath each other. This modification avoids two-dimensional scrolling in the web browser. As a consequence the arrangement of the nested rectangles is more similar to the syn- tax of most modern programming languages. Algorithms are more readable by programming experts.

Condition Condition a Else Condition False True b Condition False True Else a b c c

(a) Original (b) Modified

Figure 2.5: Nested conditional branch as Nassi-Shneiderman diagram

12 3 Language

This chapter introduces a graphical programming language that was designed for this project. The language aims to allow general purpose programming for experts and especially for beginners.

3.1 Design

The language that was designed for this project has the aim of being simplistic and intuitive. It is planned to be easily usable by programming experts as well as beginners. Strongly motivated by existing solutions like Scratch and its deriva- tives (see section 2.1), it uses a similar system of blocks that can be combined to algorithms. An algorithm can be defined using building blocks, that are ordered in nested lists. These lists are arranged vertically according to the usual reading direction of programming languages. Building blocks can contain lists of building blocks themselves. The nesting level is not restricted by design. It can be restricted due to difficulties of the web browser’s layout engines though.

3.2 Data types

Currently there are three data types prepared to be used. Number represents negative and positive integers. Floating point numbers are not yet supported. Boolean allows the usage of true and false for the representation of logic values. In order to concatenate values, Lists allow storing Numbers, Booleans and other Lists. Multidimensional lists can be used to model matrices. The values that are stored in a List do not necessarily need to be of the same data types.

13 Language

These data types can be used both as constant values and in variables. Variables have to be declared separately before they can be used. The usage of both variables and constants follows the same rules. Values of data type List can be used in three different manners. Assume a variable called list of type List defined with the values 5, 4, 3, 2, 1. The list’s indices start from zero.

• list results in 5, 4, 3, 2, 1 • list[1] uses the second element of the list and results in 4. • list.length uses the property “length” of the list and results in 5. This is the only usable property of Lists.

3.2.1 Type conversion

The conversion of data types is handled as specified by ECMAScript [ECMA 2015] and used as implemented by web browsers. Table 3.1 gives an incomplete overview of the type conversions that are relevant for this project.

Operation Result Example Boolean + Boolean Number true + true → 2 Boolean + Number Number true + 16 → 17 Number + Boolean Number 16 + false → 16

Table 3.1: Data type conversions in case of addition

If a value of data type Boolean is used in an operation together with a value of data type Number, the Boolean value is converted to Number. Boolean true is interpreted as Number 1, Boolean false however as Number 0.

3.2.2 Variables

Variables can contain a value of one of the specified data types above. The name has to be unique for this algorithm. Variables do not need to be initialized, they can have one of the following initialization types:

14 Language

• Uninitialized: The variable does not have any value in the beginning. If it is used during execution it throws a run-time error.

• Random: The value is computed randomly when the execution of the algo- rithm is started.

• Parameter: The value has to be defined externally. Either the user sets it manually before usage or it is initialized by another algorithm (caller).

• Custom: The value can be specified manually. Variables have to be specified in a separate section. They can not be deleted any more if they are used by a building block.

3.3 Building block elements

This section describes all the possible building block elements that can be used to define an algorithm. There are four rough categories of building blocks:

• Structure: Conditions and Loops • Operations: Assignments, Comparisons, Function calls, Increments, Returns and Swaps

• Values: Variables and Constants • Annotations: Comments Each of the building block elements has a return value. This policy ensures that every element can be used as parameter for a function element or as condition for a structure element. A building block element can contain text fields. The interaction of the editor is needed in order to provide proper information for the building block. Generally there are two different kinds of text fields:

• Restricted fields: the values that can be used are in some way restricted (e.g. only variable names are allowed)

• General purpose fields: in these fields a variety of possible values are allowed: – Variables: the name of a declared variable

15 Language

– Constants: constants of the allowed data types – Expressions: simple expressions Basic expressions can directly be used in general purpose fields. These include arithmetic and logical binary operations involving constants and variables.

• Arithmetic operations: addition (+), subtraction (-), multiplication (*), di- vision (/) and modulo (%) • Logical operations: conjunction (&) and disjunction (|)

Binary operations can be nested using parentheses. The nesting level is not restricted, the parentheses however have to be balanced. Unary as well as n-ary operations (n > 2) are not supported. Some examples for general purpose fields can be found in Listing 3.1.

1 a % v a r i a b l e

2 42 % constant value of type Number

3 true % constant value of type Boolean

4 a+42 % simple expression 5 ( a+42)∗3 % nested expression Listing 3.1: General purpose fields: variables, constants and expressions

Throughout this chapter the two different kinds of input fields are graphically distinguishable by the dotted pattern of the general purpose field.

Figure 3.1: Restricted (left) and general purpose (right) input field

3.3.1 Annotation building blocks

Comment

The run-time system ignores the Comment building block. It can hold plain text only and can be used to annotate the algorithm.

16 Language

Figure 3.2: Comment building block

3.3.2 Operation building blocks

Assignment

In order to assign a value to a variable, the Assign building block can be used. The syntax is inspired by one of the first programming languages ALGOL: “:=”. Most common programming languages represent assignments by “=”. The ALGOL style implicates the asymmetry of the operation.

Figure 3.3: Assign building block collapsed and expanded

The left value is the destination variable. If the value is not a variable name, the run-time system will report an error and terminate the algorithm execution. As sketched in Figure 3.3 the right value can either be a compact value or be expanded to hold another list of building blocks. In this case only one block element can be put into the sub list. The return value of the element in the list is used as source value for the assignment. This value is also used as the return value of the Assign building block.

17 Language

Comparison

Using the Compare building block, two values can be combined using one of six possible operators. Each of the two values can be specified in general purpose text fields.

Figure 3.4: Compare building block using operation: greater-than

Table 3.2 gives an overview of the available operators as well as the corresponding return values of the building block. As the Boolean data type allows only two exclusive values the alternate value to the cases depicted in the table is false.

Operator Return value < true if the left value is smaller than the right value ≤ true if the left value is equal to or smaller than the right value = true if the left value is equal to the right value > true if the left value is greater than the right value ≥ true if the left value is equal to or greater than the right value 6= true if the left value is not equal to the right value

Table 3.2: Compare building block: Operators and corresponding return values

Function call

Other algorithms can be used by the Function building block. Function calls are required to allow recursion. The algorithm can be chosen from all the publicly defined algorithms in the system. As algorithm names are unique per user, the called algorithm can be chosen by user and name or by algorithm id. There are two ways to define parameters. In the collapsed form the general purpose field can be used to define a comma-separated list of parameters. The expanded form enables a sub-list of building blocks which are handed over to the called algorithm.

18 Language

Figure 3.5: Function building block collapsed and expanded

Increment

A specialization of a general binary addition/subtraction operation which is heav- ily used in algorithms is the increment and decrement of a variable by 1. The Increment building block offers the possibility to do both incrementation and decrementation.

Figure 3.6: Increment building block

The restricted input field can only contain the name of a variable. The variable does not necessarily have to be of type Number. One of two operations can be selected. The operation is performed after the variable is used. The return value of this building block is the value of the variable before the operation.

• The operation ++ increments the variable by 1. • The operation -- decrements the variable by 1.

In case the variable is not of the data type Number, consider the data type conversion rules specified in subsection 3.2.1.

19 Language

Returns

The Return building block enables the algorithm to exit. When the building block is executed the algorithm is stopped and the specified value is handed to the algorithm’s return value.

Figure 3.7: Return building block

This mechanism is necessary in order to perform function calls. The caller can retrieve the return value of the called algorithm in order to continue its computa- tions.

Swaps

The Swap building block is a specialization and simplification of Assign building blocks. It swaps the values of two variables without the need of a temporary storage. The two input fields must contain variables.

Figure 3.8: Swap building block

3.3.3 Structure building blocks

Two very fundamental structural building block elements are required in order to be able to design general purpose algorithms: conditional branches and loops.

20 Language

Conditional Branch

Conditional branches can be established using If building blocks. An If building block consists of three parts that are interpreted as condition, consequence and alternate consequence. Each part provides a slot for a certain amount of building blocks itself.

• Condition: If the building block that is put in the first slot can be inter- preted as true, the building blocks in the first slot (Then-body) are executed thereafter. Otherwise the building blocks in the second slot (Else-body) are executed. The condition slot can contain more than one building block which can be combined either by logical conjunction or logical disjunction.

• Then-body: The building blocks in this slot are executed if the condition is true. • Else-body: The building blocks in this slot are executed if the condition is false. To define a simple If-Then construction, the Else-body can simply be left empty. Both the Then- and the Else-body can contain an arbitrary amount of building blocks. Each one or both of them can also be left empty. The condition on the other hand has to contain at least one building block.

Loop

Loops can be defined using the While building block. A While building block provides two slots for additional building blocks. The first slot contains the con- dition, the second one the consequence. The building blocks in the second slot are executed as long as the condition can be interpreted as true. The condition slot must at least contain one building block. The consequence however can also be left empty. In the latter case it is very likely that the algorithm runs into an infinite loop which is explicitly not forbidden.

21 Language

(a) If building block (b) While building block

Figure 3.9: Structure building blocks

3.3.4 Value building blocks

Value

The Value building block does only contain a value that is returned on execu- tion. The general purpose field can be used in order to provide constants, variables as well as simple computations.

Figure 3.10: Value building block

This building block can be defined in order to use a variable or constant as condition for a structural building block.

3.4 Example

The example in Figure 3.11 illustrates the algorithm building block system. It defines an algorithm that computes the minimum of two values and returns it. The example is used throughout the thesis and therefore uses not the most efficient way of computation. Instead it is defined to demonstrate all of the different building block categories and some special cases.

22 Language

Figure3.11:Example: Minimum usingbuildingblocks

IntheprogramminglanguageCthealgorithmcouldlooklikethefollowing snippet:

1 // Minimum //acomment

2 min=a; //assumeaisthe minimum

3 if (b < a) { //findoutifbissmallerthana

4 min=b; //ifyes:set minimumtob

5 } else { } //otherwise:nothinghastobedone

6 return min; //returnthe minimum

Listing3.2:AlgorithmtocomputetheminimuminC

Assumethreevariables, aand binitializedwithvaluesoftypeNumberand min whichisnotinitialized.Sevenbuildingblocksandrepresentativesofallfour buildingblockcategoriesareusedtodefinethescriptinthevisualprogramming language. •Annotations:Commentbuildingblock •Operations:Assign,CompareandReturnbuildingblocks •Structure:Ifbuildingblock

23 Language

• Values: Value building block The Assign building block is used in two different shapes. The compact version after the Comment and the expanded version together with a nested Value building block.

24 4 Usage

This chapter demonstrates the visual programming language in action. It gives an idea about the broad functionality of the system. The graph- ical user interface is introduced.

4.1 User interface

The system provides a web platform that can be accessed via modern graphical web browsers. It can be explored using mouse and keyboard. The landing page presents popular algorithms and contains a short description of the project. The user interface is divided into three main parts.

A

B 1 2 3

C

Figure 4.1: General user interface showing the algorithm section

25 Usage

The top navigation (Figure 4.1, letter “A”) provides links to the most impor- tant sections and perspectives. The user management system is located on the right. If a user is signed in, the profile page can be accessed from here. Otherwise a small form can be used in order to sign in. A link to the registration form is also provided. The main window (“B”) is used to display the content. In Figure 4.1 the algorithm section is selected. Therefore the main window is used to display the current algorithm in the Edit view. There are two major scenarios for dealing with contents. The section Algorithm (see section 4.2) provides an interface to define and execute algorithms. Lists of defined algorithms and registered users are described in the Management section (see section 4.3). The bottom navigation (“C”) offers the possibility to link static pages or external references. On the right it also supports the selection of the user interface language.

4.2 Algorithm user interface

This section provides interfaces for the core application of the project, the defini- tion and execution of algorithms. Three major perspectives provide a comprehen- sive set of operations.

• View perspective (Figure 4.1, number 1): Execute and watch the defined algorithm. See subsection 4.2.1.

• Edit perspective (2): Allows the definition of variables and building blocks for the algorithm. The meta data such as title, description and tags can be set. See subsection 4.2.2.

• Settings perspective (3): Make the algorithm publicly visible or delete it. Publishing an algorithm requires a valid algorithm title.

The “New” operation in the top navigation starts the creation of a new algorithm scope. It prepares all the necessary entries in the database and redirects to the Edit perspective in order to start defining the empty algorithm.

26 Usage

4.2.1 View perspective

The View perspective provides the user interface for the execution of algorithms. It consists of six panels that provide a variety of run-time information. User inter- action is needed in order to run the algorithm. Several settings can be manipulated in this perspective.

Figure 4.2: Example: Minimum in the view perspective

At the top the algorithm’s name is displayed in a tab that indicates the current scope. If the algorithm calls another program, the inner scope is opened in another tab. The tab is closed again when the scope is left. In order to keep track of all the provided information, the panels can be col- lapsed and expanded individually. The algorithm itself cannot be changed in this

27 Usage perspective. The variables and parameters however can be manipulated any time during execution.

Controls panel

This panel contains buttons to trigger the algorithm’s execution: ´ Sets the execution back to the initial state. · Activates the continuous execution of the remaining building blocks. ¸ Executes the next building block. ¹ Continuously executes the remaining building blocks without a stop. A slider can be used to adjust the execution speed in case the play button is pressed. The execution is usually stopped at specific points between building blocks. Two buttons can be used to specify the inspection behaviour. The system either stops before/after the execution of a building block, or both.

Algorithm and Source code panel

The building blocks in the algorithm panel are the core of the algorithm execution. A cursor indicates the current run-time state. It points above or below a building block. It indicates the position of the currently active inspection point. The source code panel contains the same information as the Algorithm panel but uses a syntax of a textual programming language, namely Python. Python, as well as most of its derivatives use indentation to deal with blocks. Programming experts may prefer this version.

Description panel

Algorithms can be categorized using tags. If the algorithm was tagged, the at- tached tags can be used to navigate to algorithms with the same tag. The author of the algorithm can leave a description. This can contain formatted text including links and images. The description is not limited in length and is meant to provide background information about the algorithm.

28 Usage

Memory panel

Variable contents can be monitored in this panel. Every variable has a row in the table which contains the current value. A small eye-icon and a green background indicate a variable read. When the variable is written, the background turns red and the icon shows a small pencil. A variable can be manipulated during run-time with a simple mouse click. It can be changed to any valid data type and value. Hitting the Enter-key stores the new value. This action increases the statistics for assignments. Leaving the manipulation area somehow else resets the variable to its original value.

Statistics panel

Statistics are kept in this panel. The following operations are monitored:

• Accesses: counts the the number of read accesses of variables • Assignments: counts the number of write accesses of variables • Comparisons: counts performed comparison operations • Arithmetic/logical: counts performed arithmetic or logic operations In order to keep track of recent changes, the background color of the counters are highlighted when they are increased.

4.2.2 Edit perspective

The Edit perspective is opened when a new algorithm is created or an existing algorithm is changed by its owner. Three collapsible panels are used to manage all the necessary preparations. An algorithm can only be edited by the user who created it. All changes are saved automatically in case all the provided information and the construction are valid. In case of an error, changes are not saved and an error message appears. The building blocks that need modification are labelled with “invalid”.

29 Usage

Figure 4.3: Example: Minimum in the edit perspective

General Information

Four input fields offer the possibility to provide meta data and background infor- mation for the algorithm:

• Algorithm name: The identifier for other users to find the algorithm. In order to publish the algorithm, this field is compulsory.

• Description: A very short description that is used in lists and as tooltip for the algorithm. It is limited in length.

• Tags: A comma-separated list of tags. Tags are used for the categorization of algorithms. The amount of tags is not restricted.

• Long description: A description of the algorithm and its backgrounds. It can be formatted using Markdown language and does not have a limit in length.

30 Usage

Variables

Variables have to be defined before they can be used in the algorithm. This panel provides the possibility to either add new or edit existing variables: 1. Pick a name for the variable. It has to be unique for this algorithm. 2. Select the data type for initialization:

• Number or Boolean • List of Number or Boolean 3. Select the initialization method:

• random: The values are computed when the algorithm is loaded in View perspective.

• uninitialized: The values remain unknown unless they are defined by the algorithm or manually by a user.

• parameter: The values have to be defined by the user or calling algo- rithm before the variable can be used.

• Custom values can be chosen by entering some value. A variable cannot be deleted if it is already in use. The usage counter gives information on how often it is used in the current construction.

Algorithm

The algorithm can be constructed using this panel. In a row of drop-down menus a new building block can be selected. It will be added to the bottom of the construction. All existing building blocks can be moved by drag and drop with the help of the mouse. Building blocks can also be dropped on certain input fields in order to expand the surrounding building blocks. The construction is saved automatically after every change. If the saving is successful a small notification is printed. Otherwise an error message is displayed. Small “invalid” labels appear on the affected building blocks if a compulsory input field has no valid value. It also appears if the number of nested building

31 Usage blocks does not match the expected amount. As long as there are “invalid” labels on any building block the construction is not saved. Input fields of certain building blocks give hints and suggestions about a possible value. Details about the visual programming language can be found in chapter 3.

4.3 Management user interface

Tables provide an interface to list all the registered users and the defined algo- rithms. Depending on the user rights the table also provides tools to manipulate the entries:

• Everybody can use public algorithms. • Users can manage their own algorithms. • Moderators can manage all algorithms. • Administrators can manage all algorithms and grant Moderator rights. Deleted algorithms and users still have entries in the lists. Using this user interface these entries can be restored or permanently erased from the database. The tables can be sorted using the arrow icons in the first row. They can be searched and filtered by the use of the input fields in the second row.

4.3.1 Algorithm management

All the algorithms that have an entry in the database are displayed in the algorithm management table. Private algorithms are labelled accordingly, deleted algorithms are crossed out. The table provides information about attached tags, creator, date of creation and last changes and the size in the database. Moderators have the possibility to access all perspectives of the owner (View, Edit, Settings) as well as direct deletion by clicking the four icons in the right-most column. Deleted algorithms can be restored by clicking the heart icon or erased by clicking the minus icon.

32 Usage

Figure 4.4: Algorithm management

4.3.2 User management

The user management table contains an entry for every user in the database. Deleted users are crossed out. Users with special privileges (Moderator, Adminis- trator) are labelled with a key icon. Using the letter icon next to the user name an email to the user’s address can be composed. The table offers information about the used language, the number of published algorithms as well as registration and last sign-in date.

Figure 4.5: User management

33 Usage

The right-most column provides direct access to the user’s profile as well as the possibility to delete it. Administrators can grant Moderator privileges using the key icon. Deleted users can be restored by clicking the heart icon and erased by clicking the minus icon.

34 5 Architecture

This chapter describes the design principles of the system. It outlines the collaboration mechanisms of all components. The concepts of data storage are presented.

5.1 Rationale

The requirements describe an interactive online system. Interoperability and scal- ability are major architectural drivers. In order to follow the restrictions of the requirements a client-server architecture is used. One advantage of this distributed system is the load share. The client performs computations individually without the need of the server’s resources. The server is used as layer between the user and the database. Prohibiting direct access to the stored data increases security. A major drawback is the maintainability of the clients. In this system the clients are web browsers. The provided software is compatible with common modern web standards. In order to guarantee portability the system relies on browsers to implement these standards.[Bass 2012] The system supports web browsers that are standard compliant. It also provides extensions to deal with a variety of widely used browsers that do not follow the standards. Some browsers are not supported at all. Another disadvantage is the dependency on the world wide web as communica- tion medium. The clients are not able to run the system without connection to the server.

35 Architecture

5.2 Server & Client

The project is designed as a distributed system. Most parts of the computations are performed on the server. Other parts are directly run on the client. The server is mainly in charge of providing the static contents and the dynamic content information. The client on the other hand uses the information and runs the dynamic content independently. Logically the system consists of three layers. Figure 5.1 shows the schematic layer architecture. The layers are distributed between clients and server.

Presentation layer Client

Logic layer Server Data layer

Figure 5.1: The three layered distributed architecture

The server provides an Application Programming Interface (API) for the client to communicate. Requests are sent to the API and processed by the server. When the computation is finished the server responds to the client and triggers a call back function. This is the only way the client can communicate with the data layer.

5.2.1 Communication

The communication between server and client takes place in the Application layer according to ISO Open Systems Interconnection (OSI) model. The requests are asynchronous in order to prevent the client from being blocked in case of bad connectivity. HTTP requests are used to transmit the messages between the client and the API. The diagram in Figure 5.2 shows the schematic communication between the server and two clients. The server provides the content for the client (white arrow

36 Architecture heads). Dashed lines symbolize the communication between the clients and the server. The diagram also shows the used technologies.

Figure 5.2: Architecture diagram including specific technologies

The PHP engine on the server provides the API and communicates with the MySQL database. The clients are usually web browsers that are capable of running the HTML source code, including CSS styles and JavaScript. JavaScript is also in charge of communicating with the server via its API.

5.2.2 Tasks

The system shares functionality between client and server. It is the client’s re- sponsibility to trigger operations the server has to perform.

• Algorithm creation: When a user creates a new algorithm, the server inserts an empty entry into the database, so that the algorithm gets its identification number. The client opens the edit view for the specified algorithm id.

• Algorithm definition: The interactive algorithm construction is the client’s task. Whenever the construction or any other information has changed, the client sends everything to the server where it is checked and stored in the database.

• Algorithm execution: The server provides all the static information from the database. The client uses the information to run the algorithm. The execution happens on the client alone.

37 Architecture

• User registration: When a new user fills out the registration form, the client sends all entered information to the server. The server checks the information and creates a database entry for the new user if the information is valid.

• User authentication: The user authentication requires access to the database as well. The server deals with requests from the client and stores the au- thentication information to the session.

5.3 Database

The database layout is designed for relational database system architectures. It consists of three tables:

• The table user contains information about registered users. The unique iden- tification number is called uid. The table is also used to store authentication and basic log information about every user.

• Table algorithm is used to store algorithm information. It references the table user in order to store the algorithm’s author. Every entry has an aid as unique identifier. The table also contains statistical information about the algorithm.

• The table tag has references to table algorithm and contains tags that are attached to the corresponding algorithms.

The table algorithm makes also use of NoSQL database system ideas. Document- oriented database systems can store structured document objects as key-value pairs.[Strauch 2011]

1 {

2 "0":{" name ":"a", " type ":"elem -int", " value ":"7"},

3 "1":{" name ":"b", " type ":"elem -int", " value ":"5"},

4 "2":{" name ":"min", " type ":"elem -int", " value ":"?"}

5 }

Listing 5.1: Variables of the Minimum example as JSON document

38 Architecture

Construction trees and variable information of algorithms are stored as textual JavaScript Object Notation (JSON) documents. This information has to be trans- mitted to the client in order to be interpreted. Storing it in relational schemes does not make sense. Instead it is stored as a text value. The document texts are parsed and used by the client directly. Listing 5.1 shows the JSON document for the variables of the Minimum example. The numbers on the left are the variable identification numbers vid. Inside the curly brackets the variable properties are defined.

39 6 Implementation

This chapter guides through a selection of important implementation details. It describes the mechanisms and data structures that are used in order to make the visual programming language work.

6.1 Data types

The system works with the ECMAScript [ECMA 2015] implementation JavaScript on the client-side and PHP scripting language [PHP 2015] on the server-side. Representations of supported data types are defined as in Table 6.1.

Data type Representation PHP ECMAScript Number language.types.integer primitive Number {..., −2, −1, 0, 1, 2, ...} (platform-dependent) [−(253 − 1), 253 − 1] Boolean language.types.boolean primitive Boolean true or false TRUE or FALSE true or false List language.types.array object Array

Table 6.1: Overview of data types and structures

The system makes use of the web browser’s implemented JavaScript data types. Therefore the values in the table and the real values may vary according to the browser’s level of standard compatibility.

40 Implementation

6.1.1 Variables

Variables can have any of the above data types. The number of variables is not restricted by design. All variables have a unique identifier vid which are positive integer numbers starting with one. The name has to be unique in order to avoid ambiguousness during execution. The initialization values are set when the algorithm is loaded for the first time. For variables with initialization type Random values are generated. If the algo- rithm is called by another algorithm that provides parameters, these are initialized as well. Variables that are neither initialized during algorithm load nor later by the user cause run-time errors when they are executed.

6.2 Tree structure

The project makes use of the Document Object Model (DOM) of the running web browser. Technically the DOM consists of structured text tags. More specifically it is a tree of tags. Every object that is displayed in the browser document is part of the DOM tree.[W3C 2004] Once a user defines an algorithm, the result is a set of tag elements in the docu- ment’s DOM tree. The browser interprets the tags as HyperText Markup Language (HTML) and displays the elements on the screen. All the user interactions with the algorithm cause DOM tree manipulations. Those manipulations influence the view on the screen. The DOM itself can be iterated through and parsed object by object. The parsing of the algorithm’s building blocks is initiated by selecting one root element in the DOM. Using specialized DOM traversal tools, the sub elements can easily be found. All the collected important information of each object is put together into a combined data structure. These objects are named Nodes and packaged into JSON format. JSON allows serialization of structured hierarchical data.

41 Implementation

6.2.1 Building blocks and Nodes

A building block in the DOM tree is a group of HTML tags that are parsed and displayed by the web browser’s layout engine. Every building block structure has a Node representation both on the client-side (JavaScript) and on the server-side (PHP). Each Node implements the function- ality to parse the tree, mark the node that is the next to be used and execute the necessary actions of the marked node. The validity of the tree can also be proofed using the parsing mechanisms of these representations.

Building block (see section 3.3) corresponding Node Assign building block AssignNode Comment building block CommentNode Compare building block CompareNode Function building block FunctionNode If building block IfNode Increment building block IncrementNode Return building block ReturnNode Swap building block SwapNode While building block WhileNode multiple building blocks BlockNode

Table 6.2: Building blocks and the corresponding Nodes

BlockNodes can deal with a group of Nodes. This is necessary to represent multiple Nodes that are nested in a Node. A BlockNode can contain an arbitrary amount of Nodes, which are considered to be in linear order. Structure building blocks (If and While) make use of BlockNodes in order to pro- vide scopes for the different bodies. Operation building blocks do also sometimes use building blocks as children (e.g. Assign). The main scope can also consist of multiple building blocks. Therefore the root element of every algorithm has to be a BlockNode.

42 Implementation

6.2.2 Parsing

The hierarchy of Nodes is parsed in a bottom-up manner. Children Nodes are traversed before parent Nodes. This leads to the fact that the root Node is always the last traversed Node. Every Node has a unique NodeId which serves as identifier for references. The order of the identification numbers is crucial for the execution of the Nodes. Each Node stores the NodeIds of its children as references. Variables are also stored as references. Additional information can be stored directly in the Node.

11 Block

0 Comment 1 Assign 9 If 10 Return

3 Block 7 Block 8 Block

2 Compare 6 Assign

5 Block

4 Value

Figure 6.1: Minimum-example: The generated syntax tree of Nodes together with their identification number (NodeId)

The tree in Figure 6.1 shows the Node representation of the Minimum example. The BlockNode on the top contains the four Nodes that correspond to the building blocks that have been originally defined. It is the root of the tree.

6.3 Tree traversal

During execution the generated tree is traversed step by step. Every step is trig- gered by user interaction. The procedure includes two stages.

43 Implementation

1. execute: The currently prepared Node is executed. 2. mark: The succeeding Node is marked for execution.

The currently marked Node is processed during execute stage. Corresponding operations are performed. The Node has a return value and can specify a reference to the succeeding Node. During the mark stage the succeeding Node is identified and prepared. The preparation causes the user interface to highlight the corresponding building block and decorate it with the cursor. The two stages are performed consecutively on every step the user triggers. There are two exceptions. In the initialization phase of the algorithm only the second stage is performed. After the execution of the last Node however, the mark phase can be skipped.

6.3.1 Execution

Traversing the tree is a hierarchic process. When the algorithm is initialized, the system asks the root Node to perform the first mark stage. Thereafter the user triggers the procedures interactively. The task to perform the two stages however is addressed to the root Node in any case. It redirects the commands to the corresponding child Nodes. The answer goes through the root Node as well. Similarly the commands and responses are directed through all the Nodes that are hierarchically higher. This can be seen in the example of the Minimum al- gorithm. In order to execute the algorithm, the variables have to be initialized. Assume the two variables a and b as follows: a := 7 b := 5 The sequence diagram in Figure 6.2 gives a schematic overview of the algorithm’s execution. It shows the communication between the system and the tree of Nodes. The Nodes are represented as vertical lines with a label on top. The left-most vertical line symbolizes the system that triggers the commands. The Nodes are arranged by NodeId starting from the highest. Hence the root Node is the first one.

44 Implementation SYSTEM 11 BlockNode 10 ReturnNode 9 IfNode 8 BlockNode 7 BlockNode 6 AssignNode 5 BlockNode 4 ValueNode BlockNode3 2ConditionNode 1AssignNode 0 CommentNode

m[11] m[0] [] 0 m[1] [1] [1] e[1] e[1] 7 [9] 7 [] 1 m[9] m[9] min := 7 m[3] m[2] [2] [2] [2] [2] e[2] e[2] e[2] e[2] true [] true [] true [7] true [7] 2 5 < 7 m[7] m[7] m[7] m[6] [6] [6] [6] [6] e[6] e[6] e[6] e[6] 5 e[5] e[4] 5 [] 5 [] 5 [] 5 [] 3 5 [10] 5 [] m[10] m[10] min := 5 [10] [10] e[10] e[10] 5 4 5 [] 5 []

Figure 6.2: Minimum example: The execution of the algorithm: Stage 1: execute (continuous lines, “e[NodeId]”) Stage 2: mark (dashed lines, “m[NodeId]”)

45 Implementation

The communication is symbolized by arrows between these lines. Dashed arrow lines are mark commands, continuous arrow lines are execute commands. The arrow labels are shortcuts of the commands (e for execute, m for mark). References to Nodes are printed using the NodeId between square brackets. Response values are printed outside the brackets without any decoration. The diagram is divided into five phases, numbered 0-4. Phase 0 is triggered during the initialization of the algorithm. The execute command is skipped in this phase. As described in section 6.2, the root Node has to be a BlockNode. BlockNodes do not have any operations to perform. Every command is redirected to its children. The system asks the root Node to mark itself (m[11]). The root Node redirects this command to its first child, the CommentNode (m[0]). The CommentNode cannot be marked, it returns an empty reference. In order to compute a valid response, the root Node asks the second child to mark itself (m[1]). The AssignNode can be marked and returns a reference to itself. The root Node returns the reference to the system. After this phase the Assign building block in the user interface is highlighted and decorated with the cursor. Phase 1 is the first to be triggered by user interaction. The marked AssignNode is executed and changes the value of the variable min to the value of variable a, which is 7. The response to the execute command contains the value of min and an empty reference, as there are no hints about the successor yet. The mark stage returns a reference to the ConditionNode inside the IfNode. The Phases 2 and 3 are computed in a similar way. Phase 4 only performs the execute stage. The execution of the ReturnNode terminates the algorithm.

6.4 Storage

The syntax tree can be stored in a linear way. First the structure is transformed to a one-dimensional list of nodes. The indices can be interpreted as the NodeId of the contained Node. Every Node can store references, either to other Nodes or variables. Some information can also be stored directly in the Node itself.

46 Implementation

Table 6.3 shows the flat representation of the tree schematically. References to other Nodes are symbolized by square brackets surrounding the NodeId (e.g. [3]), variable references are typed in typewriter fonts (e.g. a).

tree Node References 0 CommentNode comment text 1 AssignNode variables min, a 2 CompareNode variables b, a and operator < 3 BlockNode node [2] 4 ValueNode variable b 5 BlockNode node [4] 6 AssignNode variable min and node [5] 7 BlockNode node [6] 8 BlockNode 9 IfNode nodes [3], [7], [8] 10 ReturnNode variable min 11 BlockNode nodes [0], [1], [9], [10]

Table 6.3: Minimum-example: schematic representation of the tree in a list

Variables are stored in similar lists. Every variable has a unique identifier which is used as index. The additional information is the variable name, the initialization data type and method and the size in case the variable is a list itself. Table 6.4 shows a schematic list for variable storage of the Minimum example, assuming the variables to be initialized with the values 7 and 5.

var Name Initialization 0 a number 7 1 b number 5 2 min uninitialized number

Table 6.4: Minimum-example: schematic representation of the variables in a list

The JSON format is capable of serializing arrays. Using JSON functionality, the lists can be transformed to text. These texts can be stored into arbitrary relational database systems.

47 Implementation

6.5 Used technology

For the development of the project a number of supporting technology was used. On the client side four projects supported the composition of the layout.

• jQuery 1 was used to enable DOM tree manipulations and animations. The drag and drop functionality is based on the jQueryUI extension. JQuery is the most famous JavaScript library, used by over 65% of the websites on the World Wide Web.[W3Techs 2015]

• CoffeeScript 2 is a scripting language that compiles to JavaScript. It allows dealing with classes and using common object oriented functionality. The effort of writing code is reduced heavily as there are many short-cuts for frequently used patterns. The output is plain JavaScript, which guarantees compatibility with modern web browsers.

• Bootstrap3 is a framework that was originally written by Twitter developers. It provides comfortable style classes that are compatible with modern acces- sibility and responsive design guidelines. Bootstrap allows very simple and fast development of web sites.

• Less4 is a pre-processor for CSS style sheets. It allows hierarchic definition of styles, custom functions and many other simplifications for styling. It outputs plain CSS files.

1https://jquery.com/ 2http://coffeescript.org/ 3http://getbootstrap.com/ 4http://lesscss.org/

48 7 Configuration

This chapter provides details about the download and installation of the system. All the possible configuration settings are listed and explained in detail.

7.1 Installation

It takes two steps to run the project. This first section is a guide to fetch the necessary files in order to set up the project on a web server. The second section provides configuration details.

7.1.1 Prerequisites

The project was designed to be run on top of a LAMP stack. It can be installed on any web server that provides at least the following software.

• PHP 1 is a scripting language that is being developed for web applications. This scripting framework is used for dynamic computation of contents. The project is compatible with PHP version 5.5 and higher.

• MySQL2 is a relational database management system, which is being devel- oped as free and open source software. The project was developed and tested with MySQL version 5.5. The operating system as well as the web server software is not restricted in any way. A recommendation however is the use of the Apache server software on top of a free Linux operating system.

1https://php.net/ 2https://www.mysql.com/

49 Configuration

7.1.2 File system preparations

The project was developed using the version control system Git 3. The web service GitHub provides the infrastructure to host the project. In order to keep track of maintenance releases it is recommended to install the project using this service. The following command can be used to create a local repository. It downloads and prepares the necessary files for the project.

$ git clone https://github.com/wurfmaul/kartulimardikas.git Using the Git system, it is very easy to keep the system up to date. The following command can be used to fetch the latest changes from the repository. If files were manually manipulated this can cause merging errors.

$ git pull Alternatively the files can be downloaded as a compressed package from GitHub using the following URL. The package has to be extracted manually afterwards. https://github.com/wurfmaul/kartulimardikas/releases/latest In both cases the files should be installed in a directory that is addressable through the web server. The web server should be configured in a way that the direct access to the following directories is prohibited:

• config/: contains confidential information • includes/: contains helper classes that should not be called directly • maintenance/: contains scripts that manipulate the file system • partials/: contains partial scripts that should not be called directly If the Apache server is used, this task is already prepared by .htaccess files in the affected directories.

7.1.3 Database preparations

The database system needs to create a new database which is exclusively used by the project. It is recommended to set up a new user that has basic access and privileges for this database.

3https://git-scm.com/

50 Configuration

In order to set up the tables and views for the project, the commands in the file config/database.sql have to be performed. This should create the following structure:

• empty table algorithm • empty table tag • table user containing one user: admin • empty view algorithm public

7.2 Settings

Once the files are present on the file system and the database is prepared, the project has to be configured. The configuration file is named config.php and is not part of the installed files. The file can be set up by copying the contents of config.default.php which contains basic settings and default values. The only settings that need to be changed are the ones for database access:

• DB HOST: The database host address. Default: ’localhost’ • DB NAME: The database name. Default: ’kartulimardikas’ • DB USER: The database user name. Default: ’root’ • DB PASSWORD: The password for the user. Default: ’’ All the remaining configuration entries can be left untouched. A basic setup is prepared by the default values.

7.2.1 Optional settings

• PROJECT NAME: The name of the project. Default: ’kartulimardikas’ • DEBUG MODE: Error messages that are not fatal are usually hidden. Set to true in order to enable extra output in case of an error. Default: false • LIBRARY MODE: Defines, where the library packages are located. Options: – ’LOCAL’: use library files from the local file system

51 Configuration

– ’DEBUG’: use un-minimized library files from the local file system – ’CDN’: use library files from global content delivery networks Default: ’CDN’ • DEFAULT PAGE: Action that is used if the user does not specify a valid action. This setting is used to define the home page of the project. Possibilities: – ’home’: Home page that shows latest algorithms and a big banner. – ’index’: Shows lists of algorithms as well as a tag cloud. Default: ’home’ • DEFAULT LANG: Specifies the language of the user interface if not selected manually. See subsection 7.2.2 for more information. Default: ’en’ • ARRAY MIN SIZE: Minimum definable size of an array. Default: 2 • ARRAY MAX SIZE: Maximum definable size of an array. Default: 13 • DEFAULT INDENT: Indentation that is used for the source code panel. Usually a string of blanks. Default: ’’ • SPEED: Animation speed, when executing an algorithm (milliseconds between the steps). Default: 500 • MAX STEPS: Maximum number of steps an algorithm is allowed to take. De- fault: 1000 • DEFAULT BREAKPOINT: The execution of the algorithm is stopped once per step. Options: – ’before’: Inspection point before the execution of the line. – ’after’: Inspection point after the execution of the line. – ’both’: Both the above options. Default: ’before’ • SHORT CIRCUIT: Whether or not short circuit evaluation is enabled. This setting is needed for logical operations. If false, all operand building blocks are executed. If true, only necessary operands are executed in order to compute the proper return value. Default: true

52 Configuration

• MAX RANDOM INT: Maximum number that can be generated for random vari- ables. Default: 100 • NUMBER OF LATEST ALGORITHMS: Maximum number of algorithms that are displayed in the home action. Default: 5 • NUMBER OF MY ALGORITHMS: Maximum number of a registered user’s algo- rithms. Default: 25 • MAX NUMBER OF ENTRIES: Number of list entries that are displayed in the index action. Default: 10 • MAX MINUTES FOR LABEL: Maximum age (in minutes) for an algorithm to be marked with a ’new’ label. Default: 120 • MAX DESCRIPTION LENGTH: Number of characters the description is reduced to, in algorithm lists. Default: 240 • SECTIONS VIEW: Default section status for the view perspective. See subsec- tion 7.2.3 for more information. Default: 27 • SECTIONS EDIT: Default section status for the edit perspective. See subsec- tion 7.2.3 for more information. Default: 4

7.2.2 Language settings

The language of the user interface can be changed by a drop-down menu in the foot navigation. Available languages can be defined using the associative array $AVAILABLE LANG in the configuration file. The language settings are used in the form ’language code’ => ’language name’. The language codes should match the ISO 639-1 nomenclature.4. The default array contains English and German:

1 $AVAILABLE_LANG = [

2 ’en ’ => ’English ’,

3 ’de ’ => ’German (Deutsch)’

4 ];

Listing 7.1: Array containing the supported languages

4https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes

53 Configuration

A language is defined in the directory config/lang/. The file name consists of “l10n. + the language code + .php” (e.g. l10n.en.php for English). In order to include another language, a new translation file has to be defined. Another constant defines the default language: DEFAULT LANG. The value has to be a key of the array above. Default: ’en’

7.2.3 Section settings

The panels in the view/edit action of the user interface can either be collapsed or expanded. In order to configure the default status, the two settings SECTIONS VIEW and SECTIONS EDIT are used. The value is one single number each. To compute the number, the panels are numbered by powers of 2 (1, 2, 4, 8, etc.). The sum of all the expanded panel numbers is used to express the state as one number. This concept is inspired by binary encoding.

54 8 Technical data

This chapter provides measurements about the system in action. An al- gorithm is executed on different web browsers in multiple environments in order to test the system.

8.1 Test environment

The system relies on the performance of the users’ web browsers. A test environ- ment is used to measure the execution times of the Minimum example in different configurations. Two measurements are taken. The Highest-speed execution measures the elapsed time between the click on the play button and the execution of the last building block. It is assumed that the highest possible playback speed is selected. The time between the execution of two building blocks is then 50 milliseconds. The second measurement is the Fast-forward execution. When the fast- forward button is pressed, all the remaining building blocks are executed without interruption. The big difference compared to the first measurement method is the reduced demand on layout changes. The graphical user interface does not have to be repainted after every execution. In order to measure the elapsed time, the play button and the fast-forward button are manipulated to generate a time stamp before their action is performed. Another time stamp is computed after the execution of the last building block. The difference of these two time stamps gives the total elapsed time in milliseconds.

55 Technical data

8.1.1 System configuration

Three machines were used to measure the run-time of the test suite. Every machine has a different operating system. The following configurations were used.

• Configuration A: Arch Linux on an Intel Core2 Duo machine • Configuration B: Windows 10 Pro on an Intel i5 machine • Configuration C: Mac OS X 10.9.5 on an Intel Core2 Duo machine Different web browsers were used to run the test algorithm. The selection is an attempt to use every popular web engine. The web engine is the core of the browser. It is responsible for the layout of the content as well as for the execution of JavaScript code.

• Gecko web engine – Mozilla Firefox is the default browser of many Linux distributions. It is run on configurations A, B and C.

• Trident web engine – Microsoft Internet Explorer was the default browser of Microsoft Win- dows operating systems prior to version 10. It is run on configuration B. – Microsoft Edge is the successor of the Internet Explorer. It uses the web engine “EdgeHTML”, which is based on Trident. Edge is the default browser of Microsoft Windows 10. It is run on configuration B.

• WebKit web engine – Apple Safari is the default browser of Mac OS and a variety of mobile devices. It is run on configuration C. – Google Chrome is a web browser that uses the web engine “Blink”, which is a fork of WebKit. It is the default on mobile devices that use the Android operating system. Chrome is run on configurations A, B and C. – GNOME Web is a popular web browser for Linux which uses a modifi- cation of WebKit. It is run on configuration A.

56 Technical data

Appendix A summarizes the used configurations in more detail. It specifies the used hardware and the versions of web browsers and operating systems.

8.1.2 Test algorithm

A test algorithm BrowserTest is used to run the Minimum example 100 times. It is shown in Figure 8.1. BrowserTest computes the minimum of all the values, the called algorithm returns. The Minimum algorithm is modified for the tests. The variables a and b are changed to be initialized randomly. On every load of the algorithm new values are generated. The pseudo random number generator provides integer numbers in the interval [0, 100].

Figure 8.1: Algorithm BrowserTest is used to benchmark the web browsers

The MinimumTest algorithm is initialized with the following values: i := 0 min := 100 tmp := 0 In every loop iteration the return value of Minimum is stored to the variable tmp. If it is smaller than the current minimum min, it replaces min. At the end the global minimum is returned.

57 Technical data

8.2 Benchmarks

All the benchmarks are ordered by total time. The slowest execution is on top. The shorter the elapsed time, the better. The figures on the right indicate the measured time in seconds. The BrowserTest algorithm is run five times each. The benchmarks take the average of the five measurements. Detailed measurement data can be found in Table A.1 and Table A.2. The first benchmarks in Figure 8.2 show the elapsed time for the Highest- speed execution. The web engine has to perform all the necessary layout changes and animations.

Internet Explorer @ B 97,44 Edge @ B 76,09 Chrome @ B 54,70 Firefox @ B 54,18 Safari @ C 53,07 Chrome @ C 49,85 Firefox @ C 48,27 Con fi guration Chrome @ A 47,91 Firefox @ A 47,60 Web @ A 47,27

0 20 40 60 80 100 120 Seconds

Figure 8.2: Benchmarks for the Highest-speed execution

Machine A appears to be the fastest, machine B to be the slowest. The hard- ware and software configuration of the three machines is different and cannot be compared directly. The execution times of different browsers on the same machine is comparable though. Firefox and Chrome are the only browsers that run on every configuration. They are the fastest browsers on two of the three configurations. Only the Linux browser Web has better measurements for configuration A. The Apple browser Safari executes the algorithm slower. Also the Microsoft browsers Internet Explorer and Edge have worse benchmarks for configuration B.

58 Technical data

The Fast-forward execution measurements can be seen in the second bench- marks. The setup is the same as for the first benchmarks. The algorithm is run without animation though. Figure 8.3 shows the execution times.

Internet Explorer @ B 57,56 Edge @ B 31,98 Chrome @ B 17,96 Chrome @ C 14,23 Safari @ C 12,62 Chrome @ A 9,74 Web @ A 6,60 Con fi guration Firefox @ B 6,55 Firefox @ C 4,33 Firefox @ A 3,31

0 10 20 30 40 50 60 70 Seconds

Figure 8.3: Benchmarks for the Fast-forward execution

The Firefox browser appears to have the best strategy for the execution without animation. The differences between the configurations do not seem to play a big role. The Microsoft browsers are the slowest to perform the test algorithm. The execution using the Internet Explorer takes approximately nine times longer than the fastest alternative on the same configuration.

59 9 Review

This chapter deals with the personal thoughts about the process of cre- ating the system. It filters the problems and decisions during develop- ment, the errors from which could be learned.

Creation

The development of the software project has lasted more than eighteen months and it is still not finished. In this period I was able to learn a lot about software development. First of all, that proper requirements engineering is the key to avoid a lot of coding. The requirements were refined in every meeting. I always created very detailed prototypes. New ideas came in and the complete implementation had to be changed again. After that I learned my lesson and the prototypes got rougher. Even pen-and-paper sketches were used for prototyping coarse ideas. During the first presentations I figured out that it is not so easy to satisfy all involved target groups. I was convinced to have found a perfect solution to provide algorithms for programming novices. A couple of questions during the seminars convinced me of the contrary. The balance between simplicity and usability is hard to keep. The chance to create a project from scratch was overwhelming. I had the free choice of tools and libraries I like. Interfaces were defined as I wanted them to be. There was no predefined style I had to stick to. I used this chance to try technologies that were completely new to me (CoffeeScript, LESS, . . . ). One of the most useful tools was a versioning control system. Both the project and the master’s thesis itself were developed using GitHub for versioning and as

60 Review backup. The provided services are valuable not only for the development itself. Milestones can be planned, issues collected and managed. This helps a lot to keep track. In the end the major requirements were met and a system has been created that I am proud of. I am happy about the experiences I could make during the time of development.

Acknowledgements

Finally I want to thank all the people that supported me during these months. First of all Prof. Blaschek who never lost hope and supported me in every aspect. Also the colleagues in the master’s thesis seminars who delivered valuable insights and ideas. Thanks to my employer Markus Hohenwarter, who gave a lot of motivation and appreciation towards my thesis. Also my colleagues and friends, first of all Fabian Jordan and Bal`azsBencze for reading my thesis and giving feedback. Thanks to Stefanie Bogner for the nice photograph and a lot of warm words. Also to my family and closest friends I want to say thanks. Thanks for the support, thanks for the motivation, thanks for the valuable time.

61 List of Figures

2.1 Scratch & Blockly: Simple loop example ...... 7 2.2 GeeksforGeeks: Simple loop example ...... 8 2.3 DRAKON diagram: Simple loop example ...... 11 2.4 Nassi-Shneiderman diagram: Simple loop example ...... 11 2.5 Nassi-Shneiderman diagram: Nested branch example ...... 12

3.1 Prototype: Input fields ...... 16 3.2 Prototype: Comment building block ...... 17 3.3 Prototype: Assign building block ...... 17 3.4 Prototype: Compare building block ...... 18 3.5 Prototype: Function building block ...... 19 3.6 Prototype: Increment building block ...... 19 3.7 Prototype: Return building block ...... 20 3.8 Prototype: Swap building block ...... 20 3.9 Prototypes: Structure building blocks ...... 22 3.10 Prototype: Value building block ...... 22 3.11 Prototype: Minimum example ...... 23

4.1 User interface: Algorithm section ...... 25 4.2 View perspective: Minimum example ...... 27 4.3 Edit perspective: Minimum example ...... 30 4.4 Algorithm management ...... 33 4.5 User management ...... 33

5.1 Layered architecture ...... 36 5.2 Architecture diagram ...... 37

6.1 Syntax tree: Minimum example ...... 43 6.2 Execution sequence diagram: Minimum example ...... 45

62 List of Figures

8.1 The benchmark algorithm ...... 57 8.2 Benchmarks for Highest-speed execution ...... 58 8.3 Benchmarks for Fast-forward execution ...... 59

63 Listings

2.1 Pseudo code: Simple loop example ...... 7

3.1 Examples for general purpose fields ...... 16 3.2 Example: Minimum in C ...... 23

5.1 JSON document: Minimum example - variables ...... 38

7.1 Default language settings ...... 53

64 Bibliography

L. Bass, P. Clements, and R. Kazman. Software Architecture in Practice. Addison- Wesley, 3rd edition, 2012. C. B¨ohmand G. Jacopini. Flow diagrams, turing machines and languages with only two formation rules. Commun. ACM, 9(5):366–371, May 1966. ISSN 0001-0782. doi: 10.1145/355592.365646. URL http://dx.doi.org/10.1145/ 355592.365646. ECMAScript 2015 Language Specification. ECMA International, June 2015. http://www.ecma-international.org/publications/files/ECMA-ST/ Ecma-262.pdf. S. Koranne. Web and database systems. In Handbook of Open Source Tools, pages 455–471. Springer US, 2011. ISBN 978-1-4419-7718-2. doi: 10.1007/978-1-4419-7719-9 20. URL http://dx.doi.org/10.1007/ 978-1-4419-7719-9_20. J. Maloney, M. Resnick, N. Rusk, B. Silverman, and E. Eastmond. The scratch programming language and environment. Trans. Comput. Educ., 10(4):16:1– 16:15, Nov. 2010. ISSN 1946-6226. doi: 10.1145/1868358.1868363. URL http: //dx.doi.org/10.1145/1868358.1868363. K. Miller, J. Voas, and T. Costello. Free and open source software. IT Professional, 12(6):14–16, Nov 2010. ISSN 1520-9202. doi: 10.1109/MITP.2010.147. URL http://dx.doi.org/10.1109/MITP.2010.147. I. Nassi and B. Shneiderman. Flowchart techniques for structured programming. SIGPLAN Not., 8(8):12–26, August 1973. ISSN 0362-1340. doi: 10.1145/953349. 953350. URL http://dx.doi.org/10.1145/953349.953350. S. Papadakis, M. Kalogiannakis, V. Orfanakis, and N. Zaranis. Novice program- ming environments. scratch & app inventor: A first comparison. In Proceed-

65 Bibliography

ings of the 2014 Workshop on Interaction Design in Educational Environments, IDEE ’14, pages 1:1–1:7, New York, NY, USA, 2014. ACM. ISBN 978-1-4503- 3034-3. doi: 10.1145/2643604.2643613. URL http://dx.doi.org/10.1145/ 2643604.2643613. PHP Manual - Language Reference. The PHP Group, 2015. http://php.net/ manual/en/langref.php. B. Smith. A Quick Guide to GPLv3. Free Software Foundation, Inc., 2007. https: //www.gnu.org/licenses/quick-guide-gplv3.pdf. C. Strauch. Nosql databases. Lecture notes, Stuttgart Media University, February 2011. http://www.christof-strauch.de/nosqldbs.pdf. W3Techs. Usage of javascript libraries for websites. Internet, October 2015. http: //w3techs.com/technologies/overview/javascript_library/all. Document Object Model (DOM) Level 3 Core Specification. World Wide Web Consortium, April 2004. http://www.w3.org/TR/2004/ REC-DOM-Level-3-Core-20040407/DOM3-Core.pdf. CSS Style Attributes. World Wide Web Consortium, November 2013. http:// www.w3.org/TR/2013/REC-css-style-attr-20131107/. HTML5 - A vocabulary and associated APIs for HTML and XHTML. World Wide Web Consortium, October 2014. http://www.w3.org/TR/2014/ REC-html5-20141028/.

66 A Benchmark data

Machine A Machine: Intel Core2 Duo CPU P8800 @ 2.66GHz × 2 OS: Arch Linux 64 Bit Memory: 4 GiB RAM Web browsers:

• Mozilla Firefox 42.0 (64 bit) • Google Chromium 46.0.2490.86 (64 bit) • GNOME Web 3.18.0 (64 bit) Machine B Machine: Intel Core i5-4200U CPU @ 1.6GHz × 4 OS: Windows 10 Pro Build 10240 Memory: 8 GiB RAM Web browsers:

• Mozilla Firefox 42.0 (32 bit) • Google Chrome 46.0.2490.86 (32 bit) • Microsoft Edge 20.10240 (64 bit) • Microsoft Internet Explorer 11.0.10240.16590 (64 bit) Machine C Machine: Intel Core2 Duo CPU @ 2.13GHz × 2 OS: Mac OS X 10.9.5 Memory: 2 GiB RAM Web browsers:

• Mozilla Firefox 42.0 (32 bit) • Google Chrome 46.0.2490.86 (32 bit) • Apple Safari 7.0.6 (9537.78.2)

67 Benchmark data

Runs Machine Web browser 1 2 3 4 5 Avg Chrome 47400 47207 47737 49007 48210 47912 A Web 47447 47365 47333 46982 47212 47268 Firefox 47366 47784 47814 47374 47665 47601 Chrome 55723 51461 55200 55592 55519 54699 Edge 79133 74474 75033 75619 76187 76089 B Firefox 53179 54537 54482 54716 54006 54184 Internet Explorer 97321 97441 97171 97529 97735 97439 Chrome 50041 49500 49738 49958 50019 49851 C Firefox 48555 48019 48325 48334 48105 48268 Safari 53835 53979 52512 52115 52889 53066

Table A.1: Benchmark measurements in milliseconds for the Highest-speed execu- tion

Runs Machine Web browser 1 2 3 4 5 Avg Chrome 9663 10001 9831 9639 9583 9743 A Web 5964 6133 6599 6989 7320 6601 Firefox 3339 3270 3299 3328 3298 3307 Chrome 19508 17191 17588 16970 18540 17959 Edge 31269 31398 32392 32565 32263 31977 B Firefox 6551 6568 6544 6572 6496 6546 Internet Explorer 58165 57164 56710 58686 57067 57558 Chrome 14315 14132 14152 14404 14135 14228 C Firefox 4370 4252 4264 4260 4483 4326 Safari 13515 11957 11981 11957 13697 12621

Table A.2: Benchmark measurements in milliseconds for the Fast-forward execu- tion

68 Curriculum Vitae

Personal information

Name Wolfgang K¨ullinger Address Friedhofgasse 21a 4210 Gallneukirchen Austria E-mail [email protected] Birthday August 29, 1989

Professional experience

2014-today Junior Software Developer, GeoGebra, Linz 2012-2014 Tutor, Institute for System Software, JKU Linz

Education

2009-2013 BSc in Computer Science Johannes Kepler University Linz, Austria 2000-2008 Matura, Bundesrealgymnasium Hamerlingstraße Linz, Austria 1996-2000 Volksschule I Gallneukirchen, Austria

69 Eidesstattliche Erkl¨arung

Ich erkl¨are an Eides statt, dass ich die vorliegende Masterarbeit selbstst¨andig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen und Hilfsmittel nicht benutzt bzw. die w¨ortlich oder sinngem¨aß entnommenen Stellen als solche kenntlich gemacht habe. Die vorliegende Masterarbeit ist mit dem elektronisch ubermittelten¨ Textdokument identisch.

Linz, am 22. November 2015 Wolfgang Kullinger,¨ BSc.

70