PICTURES TO OBJECTS | My Assignment Tutor

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 I’m 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.Student’s Name: Sarah HeimlichStudent’s 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 student’s 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 Kingdom’s 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 Helsinki’s 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 thelanguage’s 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 computersthink [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 MIT’s 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 Scratch’scharacteristics 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 piece”structure 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 parent’s 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 Picasso’scubism and Louis Armstrong’s 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 the operating system interfaces outlined in Section 5.1.1, the system will alsoneed to interface with the operating system on the EV3. In particular, the EV3 has aLinux kernel [17] which can be found on GitHub [11].The software interface requirements appear in Table A.4.5.1.5 Communications InterfacesThe EV3 supports two main communication protocols for downloads – Bluetooth andMicro USB. As a result, both of these communication protocols will be used. Given thecomplex requirements for adapting the EV3 for WiFi, it was decided this communicationsprotocol would not be supported. The communication interface requirements appear inTable A.5.5.2 Nonfunctional RequirementsThe system’s nonfunctional requirements are the attributes. They relate to no singlefunction of the system, but rather its overall implementation.5.2.1 ReliabilityIn the author’s ten years of competitive LEGO robotics experience, the majority offirmware for LEGO Mindstorms programming languages will corrupt itself within twoto four weeks of extensive use. As a result, the system’s firmware should have a MeanTime Between Failure (MTBF) of 3 weeks under extensive usage.The reliability requirements appear in Table A.6.5.2.2 AvailabilityThe availability requirements are straight forward and therefore are only shown in TableA.7.5.3 Functional Requirements 195.2.3 MaintainabilitySeveral LEGO Mindstorms languages support the ability to download updates and patches[3] [20]. Perhaps this is due in part to the extensive user feedback LEGO Educationreceives once the product is released. As a result, the system created must also enableupdates to be sent after the system is released.The maintainability requirements appear in Table A.8.5.3 Functional RequirementsThe main aim of the project is to create a programming language that helps studentstransition from procedural to object oriented programming. This is the core objectiveand thus forms the basis of all the functional requirements. It is important to note thatthe system does not need to be fully object oriented as the goal is not to create an objectoriented language. In particular, we have decided to focus on data encapsulation andinheritance.Data encapsulation was chosen for a number of reasons. Firstly, data encapsulation iseasy to understand as it is based off of information hiding and secrecy. Children as youngas 8 have been shown to understand the concept of secrecy [43]. We believe this concepteasily extends to objects thereby making it a good concept to include in the language.To be an object oriented language, some form of abstraction is needed. As a result, weconsidered both inheritance and polymorphism. Polymorphism is a more complex implication of inheritance. One cannot understand polymorphism without first understandinginheritance. As a result, we have concluded that inheritance should be taught beforepolymorphism. Remembering the purpose of the system is to assist students’ transitionto object oriented programming, it becomes obvious that polymorphism is not essential for the programming language. With this in mind, we have elected to not includepolymorphism in the functional requirements.It is important to note that these functional requirements are based off the author’sexperiences and some basic information found through the literature review. As furtherrequirements elicitation occurs through the survey, it is anticipated the requirements willevolve. A full list of the functional requirements appears in Table A.9.20 Chapter 5. RequirementsChapter 6Language DesignTo create any programming language, it is critical to first design the language. This beginswith defining the syntax for the language. For visual languages, this is accomplished usinggraph grammars as discussed in Section 2.4.1 Here we present a syntax for the systemthat meets all the requirements outlined in Chapter 5.6.1 Language SyntaxThe language’s syntax is defined using graph grammars. Just like Java, each file is a class.Classes are defined by a series of definitions that come under the public or private node.These definitions can be either variables (primitive or otherwise) or functions. The initialclass definition graph grammar is shown in Fig. C.1. To enable inheritance, a parent classis attached to the top of the child class node as shown in Fig. C.2.Variable definitions, shown in Fig. C.5, map a name to a value. Function definitionsmap a name to a sequence of statements as shown in Fig. C.6. Due to the definitionof sequence statements discussed below, this means variables and functions cannot bedeclared within functions. This was done deliberately. Understanding variable scope isa part of encapsulation, but it is not unique to object oriented programming. Manyprocedural and functional programming languages have variable scope. In addition tothis, the requirements only say the programming language needs to support public andprivate methods and data. As a result, it was decided to not support variable declarationswithin functions to avoid confusion around scope.A statement sequence is comprised of statements as shown in Fig. C.7 and Fig. C.8.Statements are the most basic element of the language. For the purposes of this high-levelsyntax definition, we have left out the majority of statements. These will be comprisedof provided functionality such as function calls, mathematical formulas, etc. In addition,sequences include if statements as shown in Fig. C.9 and while loops as shown in Fig.C.10.The full set of graph grammars defined for the language are provided in Appendix C.2122 Chapter 6. Language DesignChapter 7Language Implementation7.1 Language PlatformTo enable quick prototyping and creation of the system, it was decided to build thelanguage on top of an existing platform. This reduces the overhead of creating a visuallanguage. Two languages were considered{Phratch and EV3 Mindstorms. Both languagesrun on the EV3 with no extra effort required. Here, we discuss each language platformand how it would work as a platform for this project.7.1.1 PhratchPhratch is a port of Scratch in Pharo and was discussed in Section 2.2.2. Scratch wasdiscussed in Section 2.1.3.The benefits of using Phratch include its familiarity to the target audience. Phratchhas the same appearance, and many of the same building blocks, as Scratch. GivenScratch’s popularity, many members of the target audience will have had experience withScratch. With the software being open source, it is easy to modify the language. Anadditional benefit of Phratch is it is already object-based. This will make it easier totransform into a language with object oriented properties.The major disadvantage to using Phratch is the lack of communication protocolssupported. Bluetooth and USB communication would need to be added because Phratchonly supports WiFi. Additionally, to begin development, a NetGear WNA110 USB donglewould need to be obtained.7.1.2 EV3 MindstormsEV3 Mindstorms is the default software that LEGO provides alongside the EV3 and wasdiscussed in Section 2.2.2.As with Pratch, the target audience is incredibly familiar with EV3 Mindstorms. Thisis probably the most familiar language for those learning to program the EV3. Because2324 Chapter 7. Language ImplementationFigure 7.1: Square function added to the Sample Data Block.Figure 7.2: Underlying LabVIEW for the square function.the software was released by LEGO, it supports both major communication protocols{Bluetooth, and USB.The Software Development Kit provided by LEGO allows anyone to create new blocksusing National Instruments LabVIEW Web UI Builder. To test this, a square functionwas added to the provided sample data icon. This was properly built into a block thatwas successfully tested on the EV3. The block is shown in Fig. 7.1 and the underlyingLabVIEW is shown in Fig. 7.2.Perhaps the biggest downside to using EV3 Mindstorms is there is no underlying objectorientation. LabVIEW is a dataflow language, making it more difficult to transform intoan appropriate form. Additionally, because the software is not open source, it is moredifficult to modify the appearance of the blocks to meet the graph grammar.Chapter 8DiscussionTo be completed once the language has been created.2526 Chapter 8. DiscussionChapter 9ConclusionsTo be completed after Chapter 8.2728 Chapter 9. ConclusionsChapter 10Future WorkIn the first half of the project, a literature review has been conducted, a survey has beencreated, an initial set of requirements have been obtained, a syntax for the languagehas been defined using graph grammars, and an analysis of potential platforms has beenconducted. The literature review has been conducted across a wide range of topics toensure a complete understanding of the project’s domain. The survey created will enablea better set of requirements in the second iteration of the project. The current set ofrequirements are based on the author’s experience and information derived from theliterature. Using graph grammars, a thorough syntax has been created for the system.Finally, two platforms were considered for implementing the language.Future work falls into two main categories – implementation and refinement. With aninitial set of requirements and graph grammars, the language is ready to be implemented.This first implementation will be based off the author’s experience and information gleanedfrom the literature as no data is available yet from the survey. It is anticipated once thesurvey results become available, the requirements will change and as a result the systemwill need to be refined.Based on the foundation set in the first half of the project, we feel confident of theproject’s success.29 Chapter 11Abbreviations CSComputer ScienceEV3LEGO Mindstorms EV3ICTInformation and Communication TechnologyOOPObject Oriented Programming 3132 Chapter 11. AbbreviationsAppendix ARequirementsThe requirements for the system are shown in Tables A.1, A.2, A.3, A.4, A.5, A.6, A.7,A.8, and A.9.Table A.1: System Interface requirements for the system Ref NumberRequirementRationaleSI1The system must interface with EV3.The system must properly operate on the LEGO MindstormsEV3.SI2The user must be able to program on aWindows XP, Windows 7 or Windows8.8.1 machine.These three operating systemshold 85.45% market share [21]. 3334 Chapter A. RequirementsTable A.2: User Interface requirements for the system Ref NumberRequirementRationaleUI1The system must have a graphic programming interface.To enable primary schoolstudents to use the system,a graphics-based approach isused. This enables students tofocus on mastering programming skills instead of theirstill-developing spelling andlanguage skills.UI2The system must not require reading/writing for the student user. To enable primary schoolstudents to use the system,a graphics-based approach isused. This enables studentsto not worry about theirstill-developing spelling andlanguage skills.35Table A.3: Hardware Interface requirements for the system Ref NumberRequirementRationaleHI1The system must interface with theEV3 servo motor, including the abilityto most the motor at a particular speedand take readings from the built-in rotation sensor.The EV3 servo motor is partof the LEGO Retail and LEGOEducation EV3 kits [10] [9].HI2The system must interface with theEV3 mini-motor, including the abilityto most the motor at a particular speedand take readings from the built-in rotation sensor.The EV3 mini-motor is part ofthe LEGO Retail and LEGOEducation EV3 kits [10] [9].HI3The system must interface with theEV3 ultrasonic sensor to read its output.The EV3 ultrasonic sensor ispart of the LEGO Retail andLEGO Education EV3 kits [10][9].HI4The system must interface with theEV3 touch sensor to read its output.The EV3 touch sensor is partof the LEGO Retail and LEGOEducation EV3 kits [10] [9].HI5The system must interface with theEV3 color sensor to read its output.The EV3 color sensor is partof the LEGO Retail and LEGOEducation EV3 kits [10] [9].HI6The system must interface with theEV3 ultrasonic sensor to read its output.The EV3 ultrasonic sensor ispart of the LEGO Retail andLEGO Education EV3 kits [10][9].HI7The system must interface with theEV3 gyro sensor to read its output.The EV3 gyro sensor is part ofthe LEGO Education EV3 kit[10] [9].HI8The system must interface with thelights on the EV3.The lights are an input/outputdevise and thus must be considered.HI9The system must interface with theEV3’s screen.The screen is an input/outputdevise and thus must be considered.HI10The system must interface with EV3buttons.The buttons are an input/output devise and thusmust be considered. 36 Chapter A. RequirementsTable A.4: Software Interface requirements for the system Ref NumberRequirementRationaleSW1The system must interface with theEV3 Linux kernel.To properly run, the systemmust interface with the operating system on the EV3. Table A.5: Communication Interface requirements for the system Ref NumberRequirementRationaleCI1The system shall support communication via Bluetooth.Bluetooth is one of the twomajor communication protocolsthe EV3 supports.CI2The system shall support communication via a USB to Micro USB cable.Micro USB is one of the twomajor communication protocolsthe EV3 supports. Table A.6: Reliability requirements for the system Ref NumberRequirementRationaleR1The system’s firmware shall have aMTBF of 3 weeks with extensive use.The MTBF of most languagesis 2-4 weeks. Table A.7: Availability requirements for the system Ref NumberRequirementRationaleA1The system shall be available 99.99% ofthe time.With a high MTBF, the systemshould be available nearly constantly. 37Table A.8: Maintainability requirements for the system Ref NumberRequirementRationaleM1The system shall be able to be updatedonce released.As with other LEGO Mindstorms languages, the systemshould be able to be updated after released. 38 Chapter A. RequirementsTable A.9: Functional requirements for the system Ref NumberRequirementRationaleF1The system must mimic a common object oriented programming language.The whole point of the system is to enable students tolearn object oriented programming, thus the system musthave many of these traits.F1.1The system must allow different files tointeract as the program executes.In object oriented programming, different files must worktogether in the program execution.F2The system must allow users to createobjects.Objects are the key concept ofobject oriented programming,thus they must be supported.F2.1Objects must be able to contain attributes.Without the ability to storedata within an object, it ismeaningless.F2.2Objects must be able to contain functions.Without the ability for objectsto do things, they would bemeaningless.F3The system must support data encapsulation.Data encapsulation is a key concept of object oriented programming and thus needs to be included.F3.1Attributes and functions must be ableto be public or private.Public vs. Private is a key component of data encapsulation.F4The system must support inheritance.Inheritance is a key concept ofobject oriented programming,as a result this must be included.F5The system must support assignment,variable declaration, sequence, test,and loop.Most programming languagesare comprised of at least fiveconstructs; assignment, variabledeclaration, sequence, test, andloop. These constructs form thelanguage’s imperative core [32]. Appendix BSurvey InformationB.1 Survey393/23/2016 Qualtrics Survey Softwarehttps://mqedu.qualtrics.com/ControlPanel/Ajax.php?action=GetSurveyPrintPreview 1/4Pictures to ObjectsPictures to Objects Understanding how students transition from graphic to object orientedprogrammingParticipation in this survey is anonymous and purely voluntary. Information collected willbe used in an undergraduate research thesis at Macquarie University and any futurepublications of this project.Participants of this survey must: Be at least 16 years of age. If under 18 years of age, have parental permission to complete this survey. Reside in Australia, Canada, or the United States of America. Have begun programming with a graphic (visual, icon-based) programming language. Have learned an object oriented programming language.By ticking this box you agree you meet the participation requirements and understand theterms outlined above.How old were you when you began programming in a graphic programming language?What was your rst graphic programming language?I agreeLEGO Mindstorms (RCX)LEGO NXT-G (NXT)RoboLab (RCX or NXT)3/23/2016 Qualtrics Survey Softwarehttps://mqedu.qualtrics.com/ControlPanel/Ajax.php?action=GetSurveyPrintPreview 2/4What was the rst style of text-based language you learned?How old were you when you began programming in an object-oriented language?What was your rst object oriented programming language?With what level of ease did you transition to these programming methodologies?What object oriented concept did you nd the easiest to understand?LEGO EV3ScratchVisual BasicOther:Object OrientedProceduralFunctionalOther:JavaC++PythonProcessingOther:VeryEasily EasilyA littleEasilyA littledif cultly Dif cultlyVeryDif cultlyNotApplicableObject OrientedFunctional3/23/2016 Qualtrics Survey Softwarehttps://mqedu.qualtrics.com/ControlPanel/Ajax.php?action=GetSurveyPrintPreview 3/4What made this concept easier to understand?What object oriented concept did you nd the most dif cult to understand?What made this concept dif cult to understand?With what level of ease did you understand the following Object Oriented Concepts?To receive a copy of the study’s results once complete, please enter your email addressbelow.VeryEasily EasilyA littleEasilyA littledif cultly Dif cultlyVeryDif cultlyI’m notsurewhatthatmeansHow the different lesinteracted.Method Calls.Accessing Variables.Public vs. Private.Inheritance.AbstractMethods/Variables/ClassesPolymorphismEncapsulation3/23/2016 Qualtrics Survey Softwarehttps://mqedu.qualtrics.com/ControlPanel/Ajax.php?action=GetSurveyPrintPreview 4/4Powered by Qualtrics44 Chapter B. Survey InformationB.2 Survey RecruitmentA copy of the survey recruitment flyer is shown in Fig. B.1B.2 Survey Recruitment 45Figure B.1: Survey Recruitment Brochure46 Chapter B. Survey InformationAppendix CGraph Grammar4748 Chapter C. Graph GrammarFigure C.1: Graph grammar for class definition.Figure C.2: Graph grammar for inheritanceFigure C.3: Graph grammar for a definition sequenceFigure C.4: Graph grammar for ending a definition sequence49Figure C.5: Graph grammar for defining a primitive.Figure C.6: Graph grammar for defining a function.Figure C.7: Graph grammar for defining a statement sequence.50 Chapter C. Graph GrammarFigure C.8: Graph grammar for ending a statement sequence.Figure C.9: Graph grammar for an if” statement.Figure C.10: Graph grammar for a while loop.Bibliography[1] 2015 first lego league (fll) challenge,” [Accessed 7-April-2016]. [Online]. Available:http://www.firstlegoleague.org/sites/default/files/TRASH-TREK-Challenge.pdf [2] Digitalable:technologies,”[AccessedApril6,2016].[Online].Availhttp://www.australiancurriculum.edu.au/technologies/digital-technologies/curriculum/f-10?layout=1[3] Downloads,” [Accessed: 30-May-2015]. [Online]. Available: http://education.lego.com/en-au/downloads/?q=%7bdc0ce993-6544-45a1-8680-b2a547d1eeb6%7d[4] Education system in the uk,”[Accessed 7-April-2016]. [Online]. Avail able: https://www.gov.uk/government/uploads/system/uploads/attachment data/file/219167/v01-2012ukes.pdf [5] Engineering for the developing world,” [Accessed:6-April-2016]. [Online].Available: http://www.engineeringchallenges.org/cms/7126/7356.aspx[6] First lego league jr.” [Accessed 7-April-2016]. [Online]. Available:http://www.firstinspires.org/robotics/flljr[7] First robotics competition,” [Accessed 7-April-2016]. [Online]. Available: https://firstaustralia.org/programs/first-robotics-competition/[8] Learn to program,” [Accessed:31-May-2015]. [Online]. Available:http://www.lego.com/en-us/mindstorms/learn-to-program[9] Legoline].mindstormsAvailable:edev3baseset,”[Accessed:30-May-2015].[Onhttp://www.mooreed.com.au/LEGOregEducationResources/LEGOMindstormsEdEV3BaseSet.aspx[10] Lego mindstorms ev3,” [Accessed:30-May-2015]. [Online]. Available: http: //shop.lego.com/en-AU/LEGO-MINDSTORMS-EV3-31313[11] Lego mindstorms ev3 source code,” [Accessed: 30-May-2015]. [Online]. Available:https://github.com/mindboards/ev3sources[12] Nxt-g,” [Accessed: 31-May-2015]. [Online]. Available: http://www.legoengineering.com/program/nxt-g/5152 BIBLIOGRAPHY[13] Pharo,” [Accessed April 11, 2016]. [Online]. Available: http://pharo.org/[14] Scratch,” [Accessed 7-April-2016]. [Online]. Available: https://scratch.mit.edu/[15] Stagecast,” [Accessed: 31-May-2015]. [Online]. Available: http://www.stagecast.com/[16] Creating blocks for lego mindstorms ev3,” Tech. Rep., 2013, [Accessed: 11-April-2016]. [Online]. Available: https://education.lego.com/en-au/learn/middle-school/mindstorms-ev3/support/ev3-developer-kits [17] Hackable lego robot runs linux,”January 2013,[Accessed:30-May-2015]. [Online]. Available:https://www.linux.com/news/software/applications/ 688254-hackable-lego-robot-runs-linux[18] Lego mindstorms ev3 firmware developer kit,” Tech. Rep., 2013, [Accessed 7-April-2016]. [Online]. Available: https://education.lego.com/en-au/learn/middle-school/mindstorms-ev3/support/ev3-developer-kits[19] National curriculum in england: computing programmes of study,” Sep 2013,[Accessed April 6, 2016]. [Online]. Available: https://www.gov.uk/government/publications/national-curriculum-in-england-computing-programmes-of-study/national-curriculum-in-england-computing-programmes-of-study[20] Robolab 2.9.4c patch,” July 2013, [Accessed: 30-May-2015]. [Online]. Available:http://www.legoengineering.com/robolab-2-9-4c-patch/[21] Desktop operating system market share,” April 2015, [Accessed: 30-May-2015]. [Online]. Available: http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=0 [22] Ftctechtalk:Programming,”March2015,[Accessed7-April-2016]. [Online]. Available:http://firsttechchallenge.blogspot.com.au/2015/03/ftc-tech-talk-programming.html[23] Subclass457quarterlyreport:quarterendingat31december2015,”able:Tech.Rep.,2015,[Accessed:6-April-2016].[Online].Availhttp://www.border.gov.au/ReportsandPublications/Documents/statistics/ 457-quarterly-report-2015-12-31.pdf#search=457quarterlyreport[24] D. H. Akehurst, An oo visual language definition approach supporting multipleviews,” in Visual Languages, 2000. Proceedings. 2000 IEEE International Symposiumon. IEEE, 2000, pp. 57{58.[25] O. Astrachan and D. Reed, Aaa and cs 1: the applied apprenticeship approach tocs 1,” ACM SIGCSE Bulletin, vol. 27, no. 1, pp. 1{5, 1995.BIBLIOGRAPHY 53[26] O. Banyasad and P. T. Cox, Design and implementation of an editor/interpreter fora visual logic programming language,” International Journal of Software Engineeringand Knowledge Engineering, vol. 23, no. 06, pp. 801{838, 2013.[27] M. Ben-Ari, Constructivism in computer science education,” Journal of Computersin Mathematics and Science Teaching, vol. 20, no. 1, pp. 45{73, 2001.[28] A. F. Blackwell, Metacognitive theories of visual programming: what do we think we are doing?” in Visual Languages, 1996. Proceedings., IEEE Symposium on.1996, pp. 240{246.IEEE, [29] I. C. S. S. E. S. Committee and I.-S. S. Board, Ieee recommended practice for software requirements specifications.” Institute of Electrical and Electronics Engineers,1998.[30] S. Cooper, W. Dann, and R. Pausch, Alice: a 3-d tool for introductory programmingconcepts,” in Journal of Computing Sciences in Colleges, vol. 15, no. 5. Consortiumfor Computing Sciences in Colleges, 2000, pp. 107{116.[31] R. Decker and S. Hirshfield, The top 10 reasons why object-oriented programmingcan’t be taught in cs 1,” ACM SIGCSE Bulletin, vol. 26, no. 1, pp. 51{55, 1994.[32] G. Dowek, Principles of programming languages. Springer Science & Business Media,2009.[33] D. A. Economics et al., Australia’s digital pulse: key challenges for our nation:digital skills, jobs and education,” 2015.[34] B. Erwin, M. Cyr, and C. Rogers, Lego engineer and robolab: Teaching engineering with labview from kindergarten to graduate school,” International Journal ofEngineering Education, vol. 16, no. 3, pp. 181{192, 2000.[35] ||, Lego engineer and robolab: Teaching engineering with labview from kindergarten to graduate school,” International Journal of Engineering Education, vol. 16,no. 3, pp. 181{192, 2000.[36] Q. FACTS, Designing personal robots for education: Hardware, software, and curriculum,” 2008.[37] E. J. Golin, Theory of visual languages,” Journal of Visual Languages & Computing,vol. 2, no. 4, pp. 309{310, 1991.[38] E. J. Golin and S. P. Reiss, The specification of visual language syntax,” in VisualLanguages, 1989., IEEE Workshop on. IEEE, 1989, pp. 105{110.[39] T. R. Green, M. Petre, and R. Bellamy, Comprehensibility of visual and textual programs: A test of superlativism against thematch-mismatchconjecture,” ESP, vol. 91,no. 743, pp. 121{146, 1991.54 BIBLIOGRAPHY[40] F. Klassner and S. D. Anderson, Lego mindstorms: Not just for k-12 anymore,”IEEE Robotics & Automation Magazine, vol. 10, no. 2, pp. 12{18, 2003.[41] M. K¨olling and J. Rosenberg, Bluea language for teaching object-oriented programming,” in ACM SIGCSE Bulletin, vol. 28, no. 1. ACM, 1996, pp. 190{194.[42] J. Kramer, Is abstraction the key to computing?” Communications of the ACM,vol. 50, no. 4, pp. 36{42, 2007.[43] U. Last and A. Aharoni-Etzioni, Secrets and reasons for secrecy among school-agedchildren: Developmental trends and gender differences,” The Journal of GeneticPsychology, vol. 156, no. 2, pp. 191{203, 1995. [44] J. Laval, Phratch,” [Accessed April 11, 2016]. [Online]. Available://www.phratch.com/http: [45] J. Maloney, M. Resnick, N. Rusk, B. Silverman, and E. Eastmond, The scratch programming language and environment,” ACM Transactions on Computing Education(TOCE), vol. 10, no. 4, p. 16, 2010.[46] B. A. Myers, Visual programming, programming by example, and program visual ization: a taxonomy,” in ACM SIGCHI Bulletin, vol. 17, no. 4.59{66.ACM, 1986, pp. [47] G. Pascoe, Elements of object-oriented programming.” Byte, vol. 11, no. 8, pp.139{144, 1986.[48] K. Powers, P. Gross, S. Cooper, M. McNally, K. J. Goldman, V. Proulx, andM. Carlisle, Tools for teaching introductory programming: what works?” in ACMSIGCSE Bulletin, vol. 38, no. 1. ACM, 2006, pp. 560{561.[49] J. Rekers and A. Sch¨urr, Defining and parsing visual languages with layered graphgrammars,” Journal of Visual Languages & Computing, vol. 8, no. 1, pp. 27{55, 1997.[50] M. Resnick, J. Maloney, A. Monroy-Hern´andez, N. Rusk, E. Eastmond, K. Brennan,A. Millner, E. Rosenbaum, J. Silver, B. Silverman et al., Scratch: programming forall,” Communications of the ACM, vol. 52, no. 11, pp. 60{67, 2009.[51] A. Robins, J. Rountree, and N. Rountree, Learning and teaching programming:A review and discussion,” Computer science education, vol. 13, no. 2, pp. 137{172,2003.[52] I. E. Sigel, Developmental trends in the abstraction ability of children,” Child Development, pp. 131{144, 1953.[53] D. C. Smith, A. Cypher, and L. Tesler, Programming by example: novice programming comes of age,” Communications of the ACM, vol. 43, no. 3, pp. 75{81,2000.BIBLIOGRAPHY 55[54] A. Snyder, Encapsulation and inheritance in object-oriented programming languages,” in ACM Sigplan Notices, vol. 21, no. 11. ACM, 1986, pp. 38{45.[55] P. Starkey, E. S. Spelke, and R. Gelman, Numerical abstraction by human infants,”Cognition, vol. 36, no. 2, pp. 97{127, 1990.[56] B. Stroustrup, What is object-oriented programming?” Software, IEEE, vol. 5,no. 3, pp. 10{20, 1988.[57] A. Vihavainen, M. Paksula, and M. Luukkainen, Extreme apprenticeship methodin teaching programming for beginners,” in Proceedings of the 42nd ACM technicalsymposium on Computer science education. ACM, 2011, pp. 93{98.[58] B. E. Wampler, The essence of object-oriented programming with Java and UML.Addison-Wesley, 2002.[59] H. Werner, Comparative psychology of mental development.” 1948.[60] U. Wolz, H. H. Leitner, D. J. Malan, and J. Maloney, Starting with scratch in cs1,” in ACM SIGCSE Bulletin, vol. 41, no. 1. ACM, 2009, pp. 2{3.