PICTURES TO OBJECTS:TRANSITIONING TO OBJECT ORIENTED PROGRAMMINGSarah HeimlichBachelor of EngineeringSoftware EngineeringDepartment of EngineeringMacquarie UniversityApril 11, 2016Supervisor: Prof. Michael Johnson ACKNOWLEDGMENTSI would like to acknowledge a number of people who helped me throughout thecourse of my undergraduate degree and this thesis.First of all my parents who gave me my love of learning and showed me thesky is the limit. Thank you for breaking down stereotypes and giving me thecourage to pursue what Im passionate about. Also thank you to my sister Jayefor putting up with all my crazy questions and late night working.Thank you to Prof Michael Johnson for giving huge amounts of flexibility inthis thesis { from the topic to the timing and location. I truly appreciate howmuch time and attention you have given this project. STATEMENT OF CANDIDATEI, Sarah Heimlich, declare that this report, submitted as part of the requirement for the award of Bachelor of Engineering in the Department of ElectronicEngineering, Macquarie University, is entirely my own work unless otherwise referenced or acknowledged. This document has not been submitted for qualificationor assessment an any academic institution.Students Name: Sarah HeimlichStudents Signature: Sarah Heimlich (electronic)Date: April 11, 2016 ABSTRACTTeaching programming is considered hard, but transitioning from procedural toobject oriented programming is even harder. Yet, this is what the new NationalDigital Technologies curriculum expects of every Australian student. An examination of the literature reveals that transitioning to object oriented programmingis difficult, but for unknown reasons. Here, we examine this transition and propose a new visual programming language for the LEGO Mindstorms EV3 thatcan assist in the transition to object oriented programming. ContentsAcknowledgments iiiAbstract viiTable of Contents ixList of Figures xiList of Tables xiii1 Introduction 11.1 Project Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Background and Related Work 32.1 Computer Science Education . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.1 Curricula Requirements . . . . . . . . . . . . . . . . . . . . . . . . 32.1.2 Pedagogy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.3 Languages to teach programming . . . . . . . . . . . . . . . . . . . 52.1.4 Programming Paradigms . . . . . . . . . . . . . . . . . . . . . . . . 62.2 LEGO Mindstorms EV3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.1 EV3 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.2 EV3 Programming Languages . . . . . . . . . . . . . . . . . . . . . 62.3 Object Oriented Programming . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.1 Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.2 Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.3 Polymorphism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4 Visual Programming Languages . . . . . . . . . . . . . . . . . . . . . . . . 82.4.1 Syntax of Visual Programming . . . . . . . . . . . . . . . . . . . . 82.5 Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Experimental Procedures 134 Results 15ixx CONTENTS5 Requirements 175.1 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.1.1 System Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.1.2 User Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175.1.3 Hardware Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.1.4 Software Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.1.5 Communications Interfaces . . . . . . . . . . . . . . . . . . . . . . . 185.2 Nonfunctional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 185.2.1 Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.2.2 Availability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.2.3 Maintainability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195.3 Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 Language Design 216.1 Language Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 Language Implementation 237.1 Language Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237.1.1 Phratch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237.1.2 EV3 Mindstorms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 Discussion 259 Conclusions 2710 Future Work 2911 Abbreviations 31A Requirements 33B Survey Information 39B.1 Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39B.2 Survey Recruitment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44C Graph Grammar 47Bibliography 47List of Figures2.1 Mapping different robotics programs and countries programming languagerequirements to years in school [1, 2, 4, 6, 7, 19, 22]. The orange line depictsthe average learning curve expected of students. . . . . . . . . . . . . . . . 102.2 Example Graph Grammar . . . . . . . . . . . . . . . . . . . . . . . . . . . 117.1 Square function added to the Sample Data Block. . . . . . . . . . . . . . . 247.2 Underlying LabVIEW for the square function. . . . . . . . . . . . . . . . . 24B.1 Survey Recruitment Brochure . . . . . . . . . . . . . . . . . . . . . . . . . 45C.1 Graph grammar for class definition. . . . . . . . . . . . . . . . . . . . . . . 48C.2 Graph grammar for inheritance . . . . . . . . . . . . . . . . . . . . . . . . 48C.3 Graph grammar for a definition sequence . . . . . . . . . . . . . . . . . . . 48C.4 Graph grammar for ending a definition sequence . . . . . . . . . . . . . . . 48C.5 Graph grammar for defining a primitive. . . . . . . . . . . . . . . . . . . . 49C.6 Graph grammar for defining a function. . . . . . . . . . . . . . . . . . . . . 49C.7 Graph grammar for defining a statement sequence. . . . . . . . . . . . . . 49C.8 Graph grammar for ending a statement sequence. . . . . . . . . . . . . . . 50C.9 Graph grammar for an if statement. . . . . . . . . . . . . . . . . . . . . 50C.10 Graph grammar for a while loop. . . . . . . . . . . . . . . . . . . . . . . . 50xi List of TablesA.1 System Interface requirements for the system . . . . . . . . . . . . . . . . . 33A.2 User Interface requirements for the system . . . . . . . . . . . . . . . . . . 34A.3 Hardware Interface requirements for the system . . . . . . . . . . . . . . . 35A.4 Software Interface requirements for the system . . . . . . . . . . . . . . . . 36A.5 Communication Interface requirements for the system . . . . . . . . . . . . 36A.6 Reliability requirements for the system . . . . . . . . . . . . . . . . . . . . 36A.7 Availability requirements for the system . . . . . . . . . . . . . . . . . . . 36A.8 Maintainability requirements for the system . . . . . . . . . . . . . . . . . 37A.9 Functional requirements for the system . . . . . . . . . . . . . . . . . . . . 38xiii Chapter 1IntroductionThe world requires engineers to provide the necessary and expected utilities of a modernnation in a sustainable manner [5]. However, there is an incredible lack of professionalsin engineering and Information and Communication Technology (ICT) related careers.Many of these Computer Science (CS) employees are in industries other than ICT withan estimated 100,000 new ICT positions becoming available by 2020 [33]. To meet thisgrowing need, Australian companies are recruiting from outside the country. In 2015,Four of the top 15 primary occupations of skilled worker (subclass 457) visa recipientswere in ICT related careers with ICT professionals accounting for 12% of subclass 457visas [23] [33].With this setting as the backdrop, it is easy to understand why CS education hasbecome an increasing priority in Australia and around the world. In particular, this canbe seen through the introduction of computer science curricula in countries includingAustralia [2] and The United Kingdom [19]. As students progress from primary schoolto secondary and tertiary education, these curricula take pupils from visual to objectoriented programming languages.It is widely recognized that students struggle with transitioning from procedural toobject oriented programming. There is research to support that learning Object OrientedProgramming (OOP) first enables students to easily transition back to procedural structures [31]. However, with an increasing priority on computer science education, nationalcurricula often mandate students begin programming before they can fully comprehendabstraction [52]. This abstraction ability is critical for computing and object oriented programming [42]. As a result of this early start, curricular requirements on beginning withvisual programming, and a number of robotics competitions that require visual languages,students are often learning procedural languages first. This creates an obvious tensionbetween what is considered best practice and what curriculum mandates that ultimatelymakes learning object oriented programming more difficult for students.With this tension, one would expect a large amount of academic research into how tobridge the gap between procedural and object-oriented programming. Yet, there is verylittle information available. The literature abruptly stops with the problem, offering nosolutions.12 Chapter 1. Introduction1.1 Project GoalThe goal of this project is to create a programming language for the LEGO MindstormsEV3 that will assist a students transition from procedural to object oriented programming.To accomplish this, an understanding of why students are struggling must first beobtained. A literature review has proven insufficient for the requirements elicitation. Asa result, a study must be conducted to better understand the problem.A visual language for the EV3 was decided upon for a number of reasons. First of all, avisual language reduces the overhead for younger students who are struggling with literacy.Additionally, a visual language enables students to better visualize what is happening asthey program. The EV3 was chosen for similar reasons. By having an interactive system,students are better able to understand the implications of their programs.Chapter 2Background and Related Work2.1 Computer Science Education2.1.1 Curricula RequirementsAs computer science becomes an increasing priority around the world, this subject hasreceived more academic attention. In particular, researchers have discovered it takes 10years of experience to progress from a novice to an expert programmer [51]. Despitethis, most undergraduate degrees vary in length from 3-4 years. As a result, to graduateexpert programmers, we must introduce programming in years 5-6. This is reflected inthe Australian and UK national computing curricula as outlined below.The transition from visual to object oriented programming languages is mandated incurriculum in some countries. In Australia, students are required to begin learning agraphic programming language in year 3, a general purpose text language in year 7, andan object oriented language in year 9 [2]. From years 1-2, students begin understandingalgorithms, but are not required to learn a programming language.This contrasts quite significantly with the United Kingdoms where the computingcurriculum begins in year 1 with visual programming languages and transitions to a textual language in year 7 [4,19]. Despite starting to program sooner, there is no requirementfor students in the UK to learn an object oriented language.The transition between programming languages occurs outside of curriculum as well.The FIRST Robotics family of competitions for students in years 1-12 also has studentstransitioning from visual to object oriented programming. In general, FIRST students usevisual programming languages from years 1-6 and object oriented programming languagesfrom years 7-12.A graph of these different programs and curriculum mapping to programming paradigmsis shown in Fig. 2.1. By examining this figure, we note the steep learning curve expectedof students from general purpose text languages to object oriented.34 Chapter 2. Background and Related Work2.1.2 PedagogyIn the words of a University of Helsinki research group, Teaching programming is hard[57]. As of 2011, the University of Helsinkis long term average drop out rate was at 45%c.a. As a result, it is easy to understand why so many different languages and approachesare used in teaching programming. Debates in teaching programming range from depthvs. breadth to procedural vs. object oriented, and many more [25]. Here, we provide anoverview of some proposed methods for teaching programming.ApprenticeshipOne approach found advocates for an apprenticeship model to be used in teaching programming. In contrast to a traditional apprenticeship which is based off of manual skills,CS falls under the cognitive apprenticeship category. Cognitive apprenticeships can bedivided into 3 stages{modeling, scaffolding, and fading [57].In the modeling stage, the teacher provides an understanding of how a problem wouldbe solved [57]. This could occur through worked examples in a lecture or better understanding programming theory.From modeling, students move along to scaffolding. In this stage, the teacher providesstructured exercise [57]. This could occur through assignments or other types of exercise.The final stage is fading. Here, the teacher provides less contrived solutions and allowsthe apprentice to solve full problems [57]. This slowly moves the apprentice to becomingself-sufficient and ready to tackle challenges on their own [25].Low Floor, High Ceiling, Wide WallsThe principle of creating a teaching environment with a low floor, high ceiling, and widewalls, was found in several papers [34, 36, 50, 60]. This does not refer to the locationin which students are taught, but rather the limitations placed upon students. Theselimitations maybe placed by the language or by the concepts taught.The low floor and high ceiling are by far the more prevalent concepts. The low floorindicates an easy entry point for beginners [34]. For example, in COMP115 at MacquarieUniversity, students are taught Processing instead of Java. This is done because Processing has fewer requirements to begin writing a program. This provides a lower entry pointfor students who are taking their first computing class. The high ceiling speaks to thelanguages ability to support complex projects [36].The Lifelong Learning group at MIT also coined the term wide walls which reflectsthe breadth of projects that can be completed using the language [50,60].Student EngagementIt is also critical to find ways to fully engage students in programming classes. Thiswas found through numerous papers supporting different pedagogies [25, 30, 45, 50, 57].Interactive languages that enable visual feedback are highly recommended as the student2.1 Computer Science Education 5can see the direct impact of their code [30, 45]. By seeing the impact, students arebetter able to understand what their program is doing. This in turn enables a deeperunderstanding of the impact of each statement.2.1.3 Languages to teach programmingUnlike most debates over language, here we do not consider the type of language (functional, object oriented, etc.). Instead, we elect to focus on how the languages is presentedby considering a number of factors. In particular, text, visual, programming by example,and tiered languages were considered [48] [46].Most programmers are familiar with text-based languages (such as C/C++) and visuallanguages (such as LabVIEW) however programming by example and tiered languagesare not often discussed. As a result, we focused our investigation in these areas.The paper the author studied on programming by example was from 1986 [46], andthus it was assumed programming by example had fallen aside as the industry progressed.This was found to be untrue with a plethora of papers published in the past 15 years onprogramming by example. One such paper claimed programming by example was theultimate way to teach programming as it was closer to how humans, instead of com
putersthink [53]. However, this claim appears to be debunked as the company making thesoftware described closed in 2014 [15].Tiered languages have different levels that build on one another [48]. As a studentbecomes more adept with the language, they move to the next level which introducesmore concepts and provides more commands. This allows the language to easily have alow entry point yet high ceiling.To better understand programming languages designed for teaching, we explore theScratch programming language in depth below.ScratchScratch is one of the most popular languages for introducing students to computing withnearly 14 million projects shared on the Scratch website [14]. Developed at MITs MediaLab by Mitch Resnik, Scratch is a visual language that allows users to program numerouscharacters, called sprites, in scenes. Scratch was built off the theory of having a low floor,high ceiling, and wide walls as discussed in Section 2.1.2. There are a number of Scratchscharacteristics that makes it easy for users to learn.Firstly, the language components act like puzzle pieces, only the correct parts canfit together [45]. For example, an integer cannot fit where a function or number is required. This allows the user to intuitively see where each part can, and cannot, be placed.Following on from this, each program created is automatically syntactically correct [45].Scratch is an event driven language. Each section of the code begins when a differenttrigger occurs. Triggers can range from the keyboard, to sprite interaction, and many moreoptions. Scratch provides three first-class data types{boolean, number, and string{andautomatic conversion between numbers and text as required [45].6 Chapter 2. Background and Related WorkThe Scratch language revolves around Sprites that are manipulated in different ways.Sprites can contain variables and behaviors making the language object-based [45]. Despite this, Scratch cannot be considered Object Oriented as it does not support inheritanceor polymorphism. A sprite can communicate with other spirtes using the broadcast system. The broadcast system is one-to-many [45], a sprite will broadcast a message whichcan trigger behaviors in other sprites.2.1.4 Programming ParadigmsThere is much debate over what paradigm to first teach students. Some argue procedurallanguages are the best place to start as they offer the simplest option [27]. However, thisview appears to be in the minority with most researchers agreeing it is easier to learnobject orientated programming than later transition to this paradigm [31,41,51].What the literature does not address is what makes this transition difficult for students.This gap in the literature is very significant. It is impossible to create new methodologiesto help students transition to object oriented programming without first understandingwhy they are struggling.2.2 LEGO Mindstorms EV3The EV3 is the hardware the language will control. As a result, it is important to fullyunderstand this platform. The EV3 was released in 2013 as the third evolution of theLEGO Mindstorms platform. Its predecessors were the RCX and NXT. Known at LEGOas the PBrick, or PBR for short [16], the EV3 has been used by primary and secondaryschools, universities, and even NASA [35].2.2.1 EV3 HardwareThe EV3 uses a 32-bit ARM9 processor, Texas Instrument AM1808 at 300MHz andincludes 64MB of DDR RAM [18]. The device has inbuilt Bluetooth and USB communication abilities. Additionally, there is an SD card and USB port for off-device storage [18].Alternatively, the USB port can be used to house a NetGear WNA110 USB dongle, thusenabling WiFi connectivity.There are 4 input and 4 output ports for sensors and motors [18]. LEGO sells 2 typesof motors (large and mini) and numerous sensors (light/colour, touch, ultrasonic, gyro,etc.) for the device [9, 10]. Additionally, other vendors have created sensors that arecompatible with the EV3.2.2.2 EV3 Programming LanguagesThe interesting part of this area of investigation was not the programming languagesavailable but rather the rationale behind each language. A plethora of languages are2.3 Object Oriented Programming 7available, from LabVIEW based languages such as NXT-G, RoboLab, and EV3 [8,12,35],to text based versions such as Not Quite C (better known as NQC) [40].Plenty of the languages were designed to be used from primary to graduate schools.While this may seem like an unfeasible ideology, several of them succeeded and are usedat schools including Tufts University [35]. Other languages focused on a particular demographic such as an artificial intelligence class [40].Many EV3 programming languages are designed to be extensible{users are able toadd new elements. In particular, we consider two extensible EV3 visual programminglanguages: EV3 by LEGO and Phratch.EV3 Mindstorms by LEGOEV3 Mindstorms is the programming language that LEGO distributes alongside the EV3hardware. As a result, it is one of the most widely used platforms for programmingthe EV3. Versions of the software are available for Windows, OS X, iOS and Android.EV3 Mindstorms is built off of National Instruments LabVIEW Web UI Builder and isa procedural language that supports multi-tasking. EV3 Mindstorms can communicatewith the EV3 using USB, Bluetooth, or WiFi.Users can create their MyBlocks from existing blocks. In addition to this, throughthe LEGO Mindstorms EV3 Block Developer Kit for Windows, LEGO enables advancedusers to create new blocks using the NI LabVIEW Web UI Builder [16].PhratchPhratch is based off the popular Scratch programming language from MIT which wasdescribed in more detail in Section 2.1.3. Consequently, Phratch has the puzzle piecestructure and underlying object basis of Scratch. Phratch only communicates with theEV3 using WiFi, thereby requiring users to purchase the NetGear WNA110 USB dongleto make their EV3 WiFi capable.Unlike Scratch, Phratch is built in Pharo and has a JetStorm plugin that enables it torun on the EV3 [44]. Pharo is a open source purely object oriented programming languagewith its own IDE [13]. Phratch is designed to be extensible with the build in Build yourown blocks (BYOB) feature which allows users to combine blocks to form new blocks.Additionally, the Pharo source code can be directly edited as it is freely available.2.3 Object Oriented ProgrammingAs the subject of this project is to create a programming language that mimics objectorientation, it is important to fully understand object oriented programming. Here weconsider the three fundamental components of object orientation{encapsulation, inheritance, and polymorphism [58].8 Chapter 2. Background and Related Work2.3.1 EncapsulationEncapsulation allows objects to hide their data members and as a result is sometimesreferred to as data-hiding. By hiding information, programmers are encouraged to createmodular designs so the different classes can interact [47]. Some researchers have arguedthat inheritance can hurt encapsulation since child classes can access information fromtheir parents in many programming languages [54].2.3.2 InheritanceInheritance creates an is-a relationship between different classes [41]. A class, calledthe child, can claim inheritance from a second class, called the parent. Once a parentclass is noted, the child receives all the data members and functions associated with theparent.2.3.3 PolymorphismPolymorphism, meaning many forms, enables different classes with the same parent tobe used in the same location. This occurs when a function requires a parent class as aparameter. A purely object-oriented language recognizes the is-a relationship throughinheritance and will therefore accept any of the child classes in the parents place. Whileoften referred to as a core concept of object orientation [56], Polymorphism is simply anextension of inheritance [58].2.4 Visual Programming LanguagesVisual programming languages use pictures instead of words to communicate meaning [37].As a result, visual languages have unique properties. Some of these properties enablevisual languages to be easier to learn [28, 39]. For example visual languages are betterat expressing structure, enable pre-literate children to program, and provide a superiorresemblance to the surrounding world [28]. Additionally, several articles point to thefact that a picture is worth a thousand words [28,37], and is thus able to convey moremeaning. One paper points out the brain considers a picture as a single unit and thereforeit is easier to understand multiple items about a command in a visual language [28].2.4.1 Syntax of Visual ProgrammingAs with any programing language, the creation of a visual language begins with defining the syntax of the language. For textual languages, this is done using context freegrammars. These grammars define how each part of the language interacts and combinesto form the overall program. Context free grammars are based off of text and are thusinappropriate for defining the syntax of a visual language.2.5 Abstraction 9Instead, visual languages are defined with shapes, lines, and text [38]. It is still criticalto ensure visual languages have well defined specifications [24]. Due to the graphic natureof visual programming, we can use graphs to represent the most basic form of a visuallanguage [37]. Therefore, in visual programming languages graph grammars are used.While numerous flavors of graph grammars are available, the underlying concept of all ofthem is the same [37,38].Graph grammars define different nodes and show or describe how they can be combinedto form the overall program. Put another way, graph grammars define the only allowabletransformations on the graph. By defining these valid transformations, graph grammarsensure proper syntax in the same manner as a context-free grammar. Just like context-freegrammars, graph grammars create allowable transformations through production rules.A production rule contains two graphs as shown in Fig. 2.2. The left-hand side ofthe production can be transformed into the right-hand side. Fig. 2.2 effectively says astatement can be comprised of multiple statements.Graph grammars are often not context-free as this restriction has proven too difficultto create many visual languages [49]. As a result, the general rule is to ensure the lefthand side of the productions has fewer elements than the right-hand side. This allows thelanguage to be built up through the graph grammar.Examples of graph grammars abound in the literature, including graph grammars forScratch and Lograph [26,45].2.5 AbstractionAs humans our ability to abstract starts at the beginning of our lives and develops as wemature [52]. Abstraction is our mental process in which some attribute or characteristicis observed independently of other characteristics of an experience as a whole. [59]. Putmore simply, abstraction is simplifying and finding commonalities between different elements [42]. These elements could be objects, experiences, or other items. From Picassoscubism and Louis Armstrongs jazz music to maps of train networks and classes in objectoriented programming [42], abstraction is used in numerous and diverse fields.In computing, abstraction is a key concept. Abstraction is obviously used in objectoriented programming through inheritance and encapsulation. Beyond this, abstraction isused to create models, a critical tool for engineers regardless of their area of expertise [42].By the above definition of abstraction, it is important to note abstraction occurs froman element to a higher level. For this to occur, we must therefore have something toabstract from. As a result, some researchers claim object oriented programming cannotbe taught first as students must have an understanding of what they abstracting to ahigher level [27].Studies have shown numerical abstraction occurs for infants as young as 6 monthsold [55]. However, these abilities are nowhere near the level needed to understand largerabstract concepts such as object oriented programming. Additional studies indicate thatmath is a critical tool to helping students develop their abstraction abilities [42].10 Chapter 2. Background and Related WorkFigure 2.1: Mapping different robotics programs and countries programming languagerequirements to years in school [1, 2, 4, 6, 7, 19, 22]. The orange line depicts the averagelearning curve expected of students.2.5 Abstraction 11Figure 2.2: Example Graph Grammar12 Chapter 2. Background and Related WorkChapter 3Experimental ProceduresTo understand how to create a programming language to assist students transition toobject oriented programming, it is critical we understand what makes this conversion sodifficult. As discussed in Section 2.1.4, we know this transition is difficult but there isvery little research on what makes it a challenge. As a result, to create a useful system,requirements elicitation is required.As a member of the target audience, the author has her experiences as a starting point,but this is purely anecdotal evidence and is thus not suitable for a rigorous academicapproach. Therefore, it was determined a survey needed to be created and conducted tobetter understand the issues the language needs to address.To achieve this, the survey targets those whose first programming language was procedural and have since learned an object oriented programming language. Participants ofthe survey were required to be over 16 for consent purposes. Survey recruitment will befocused on FIRST Robotics Competition and FIRST Tech Challenge students and alumnias this demographic meets the requirements for survey participation.The survey created aims to discover what object oriented concepts cause studentsto struggle along with which concepts are easy to grasp. To create an unbiased survey,respondents are prompted to provide components of object oriented programming theyfound easy along with those they found difficult to understand. The survey goes on toask about particular areas of interest to the project. In particular, respondents are askedhow easily they grasped concepts such as encapsulation, inheritance, and polymorphismalong with programming conventions such as multiple files, abstract methods, etc.A copy of the survey and recruitment brochure are provided in Appendix B.1314 Chapter 3. Experimental ProceduresChapter 4ResultsTo be completed once the survey has been conducted.1516 Chapter 4. ResultsChapter 5RequirementsThis section is based off 10.1109/IEEESTD.1998.88286, recommendations for softwarerequirements specification documents [29]. Here, the system is considered from a numberof perspectives to elicit requirements. Based on this, the requirements are provided inAppendix A.5.1 InterfacesThe system will need to interface with a variety of other components. These componentsare defined and the interfaces specified in sections below.5.1.1 System InterfacesThe system needs to interface with a computing device and the EV3. In particular,the programming should be completed on a Windows XP, Windows 7 or Windows 8/8.1machine as these three operating systems have over 85% market share [21]. Systeminterface requirements are found in Table A.1.5.1.2 User InterfacesIn order to define the user interfaces, it is important to first know the target audience.Based on the national curricular requirements and robotics programs considered in Section2.1.1, the system is targeted for students in years 5-8.To help bridge the gap between the visual procedural languages learnt in years 1-4 andobject oriented programming, the system will be a visual programming language. Thiswill also decrease the literacy requirements for younger children learning the system.The user interface requirements appear in Table A.2.1718 Chapter 5. Requirements5.1.3 Hardware InterfacesThe hardware interfaces can be divided into two main categories; the computer and theEV3 ecosystem. On the computer side, there are no major requirements as the OS ensuresa well-defined interface. For the EV3, the system must be able to properly interface witha variety of input/output hardware. For the purposes of this project, we have limitedthese inputs and outputs to the hardware that comes in the EV3 LEGO Education andLEGO Retail kits, including the input/output on the EV3 brick. The exact details areoutlined in Table A.3.5.1.4 Software InterfacesAside from t