An Integrated Programming Environment for ... - Semantic Scholar

An Integrated Programming Environment for Teaching the Object-Oriented Programming Paradigm Stelios Xinogalos and Maya Satratzemi Dept. of Applied Informatics, University of Macedonia Egnatia 156, P.O. Box 1591, 54006 Thessaloniki, Greece {stelios, maya}@uom.gr

Abstract. In this paper we propose a new integrated programming environment for teaching the object-oriented programming paradigm. The environment is based on the microworld approach to teaching programming and the programming language of Karel++. Its main features are: a series of e-lessons, a special kind of structure editor, run-time error detection, program animation and recordability of students’ actions. In this paper we present the programming environment, the results and our own experiences in using the integrated programming environment to teach object-oriented programming to undergraduate students.

1 Introduction Programming is without doubt one of the most difficult topics in Computer Science. The extended research that has been carried out over the past three decades showed that one of the most important factors that makes programming difficult to learn is the fact that students are taught the principles of programming by the classic approach [3], which is based on: • A general purpose programming language that is too big and too idiosyncratic. The volume of the language makes it difficult for the student to understand the conceptual basis of the language together with the main principles of programming properly. As a result students fail to assimilate what they are taught. Furthermore, special attention is paid from the students to learning the syntax of the language and not to obtaining problem solving skills. • A professional programming environment for the chosen programming language that does not support students neither in understanding the semantics of the control structures and the flow of control nor in the process of debugging their programs. • A set of problems from the area of number and symbol processing that are far from the students’ everyday experiences and are not attractive to them. The fact that the classic approach of teaching programming to novices does not fulfil their didactic needs resulted in many efforts to develop special methodologies, languages and tools. Each one of these approaches differs from the classic approach in at least one of its three main characteristics. The main proposed approaches to teaching programming [9] are:

M.H. Shafazand and A M. Tjoa (Eds.): EurAsia-ICT 2002, LNCS 2510, pp. 544–551, 2002. © Springer-Verlag Berlin Heidelberg 2002

An Integrated Programming Environment for Teaching

545

Microworlds. A representative educational tool that has been developed in the context of this approach is Karel Genie [7]. Compilers with Improved Diagnostic Capabilities. Representative educational tools of this category are THETIS [5] and CAP [8]. Iconic Programming Languages. A representative environment of this type is BACCII-BACCII++ [4]. Program Animation. A good example of a program animator is Dynalab [2]. Motivated by the research about the difficulties of novice programmers while learning to program, the small number of papers that explore the difficulties of objectoriented programming [6], and the efforts of researchers to develop educational tools that can help students, we developed an educational environment for teaching objectoriented programming. This environment extends the environment Karel++ [1] and attempts to incorporate the results of the research about the teaching of programming. The features that differentiate it from the existing environments are: a series of elessons that introduce the student from the beginning to the principles of objectoriented programming, a structure editor that makes the development of programs easier, and the ability to record students actions. The last feature provides invaluable assistance to the teacher, so as to detect students’ conceptions about programming, and especially object-oriented programming, and the techniques they use during program development. In this paper we present the programming environment and its use with students of an Informatics department.

2 Overview of the Programming Environment The extended research that we carried out about the various approaches to teaching programming and the educational tools that have been developed in the context of each approach [9] resulted in our decision to adopt the microworld approach, as the main approach, for our programming environment. The programming language of our environment is based on Karel++ [1], which is closely related to C++ and Java. The metaphor used is that of a world of robots. The actor of the microworld is a one or more robot (object) that is assigned various tasks in a world that consists of: crisscrossing horizontal streets and vertical avenues forming one block intervals, wall sections between adjacent streets or avenues used to represent obstacles (hurdles, mountains, mazes etc), and beepers – small plastic cones that emit a quiet beeping noise – placed on street corners. Students write programs that instruct robots how to perform their tasks. If the available class of robots – that o can move forward a block, turn in place (90 to the left), pick beepers from the current corner or put beepers from their bag to the corner – is not appropriate for a task, then students can create a new class of robots that inherit the properties and methods of the basic or a previously declared class and extend them. The sections that follow describe the most important features of our programming environment. E-lessons. The new integrated programming environment incorporates a series of elessons for supporting students in understanding the basic principles of objectoriented programming and the most common control structures. The main purpose of these lessons is to minimize the possibility of developing misconceptions and acquiring wrong or insufficient knowledge. For this purpose each lesson contains:

546

S. Xinogalos and M. Satratzemi

• \vspace*{-2mm}theory intended to teach a specific concept of object-oriented programming or a control structure. The most important aspects of the paradigm are disclosed before the control structures and are emphasized throughout the lessons. Students manipulate objects (robots) from the beginning and write their own classes almost immediately. Great emphasis is placed on eliminating wrong conceptions that students usually form.

Fig. 1. E-lesson Window

Fig. 2. Main Window and Program Animation.

• an activity that lies in the heart of the concept that the lesson is intended to teach. For example, the student can click on the buttons, labelled with the messages that the available object (robot Karel) understands; and watch (i) the robot execute the message, (ii) the syntax of the command in the programming language, as shown in Figure 1. We believe that these activities will help students internalise objectoriented programming concepts better and easier than if they were only presented with verbal descriptions. A special kind of Structure Editor. A structure editor, in contrast with traditional text editors, operates directly on an abstract syntax tree while the program is being developed. That means that the structure editor provides a menu of the syntactically correct transformations for any location in a partially complete program, yielding always syntactically correct programs [7]. The editor of our programming environment is a special kind of structure editor: • Writing a program is accomplished by: 1) choosing the appropriate action (class/method declaration, construction of object) or choosing a message to send to an object from a single menu as shown in Figure 2. This menu is automatically updated whenever the user deletes or edits a class/method or declares a new class/method. 2) interacting with the system through dialog boxes. For example, when the “Construction of robot” menu’s choice is clicked the dialog box shown in Figure 3 appears, so as to specify the name and the parent class of the robot and initialise its properties. • The source code is automatically indented, as shown in Figure 2, in order to avoid misleading appearances. • Logic and some syntax errors are deliberately not prevented.


Fig. 3. “Construction of Object” dialog box.

547

Fig. 4. History of Compilations

The design of the editor is the result of a didactic rationale that focuses on fulfilling specific didactic needs of students: • Development of programs becomes easier and the common problem of focusing on the syntactic details, even in the case of a simple language, is eliminated. Students can focus on acquiring problem solving skills and assimilating the principles of programming. • Long sessions of searching for and correcting syntax errors are eliminated. • The programming environment can be used for teaching programming to young students. • The editor’s partially compiled knowledge of the program gives us the chance to provide students with valuable information, such as run-time error detection and understandable error messages. Run-time Error Detection – Understandable Error Messages. The most difficult and frustrating phase of debugging is finding the logic errors of a program. Unfortunately commercial compilers are designed for experts rather than novices and so they do not really help students in debugging their programs [5]. Our programming environment intends to reduce this burden by detecting logic errors and reporting understandable and highly informative error messages: • The line number reported is the actual line of the mistake. • Messages report not only what is wrong but also explain why it is wrong. • The error messages use physical language and not codes. In this way the misconceptions that usually account for the errors are revealed to students. Furthermore, the run-time error detection saves on teachers’ time and effort while studying student’s errors and misconceptions because they do not have to check the programs themselves (for run-time errors), as is usually the case. Executing Programs - Program Animation. Since a program has been successfully compiled the user has three choices of executing it: 1. Running the program. This choice, which is the standard way of executing programs in professional environments, presents the user with the final result of the program’s execution. 2. Tracing through the program. The program is executed in slow motion and each command is highlighted (by changing its background colour from white to blue

548


and the font colour from black to white), while its execution’s result on the situation of the microworld and the actor is visible on the screen. 3. Executing the program step by step. In contrast with the previous ways of executing a program the user takes an active role and decides when the next command will be executed. Each command is executed in the same way as in tracing. The user can terminate the execution of the program at any time. The last two choices (2, 3) of executing a program, known as program animation, are of great importance to the student. Executing the program step by step in particular: • Reveals the dynamic nature of program execution. • Assists students in understanding the semantics of the control structures and flow of control, and supports them in finding logic errors. • Gives instructors the chance to cover more material in less time. When the student uses the last two choices (2, 3) of executing programs, he is also presented with explanatory messages about the semantics of the command being executed. The explanatory messages use physical language and are presented in the pane that stretches across the bottom of the window (Figure 2). This feature is known as explanatory visualisation. Recordability of Students’ Actions. With the term recordability we refer to the system’s ability to auto save the student’s program and its errors/warnings each time the program is compiled. The history of compilations is presented in a separate window with the form of a two-level tree as shown in Figure 4. The first level presents as with the names of the programs that have been developed and the second one with the date and time of each compiled version of the selected program. When a version of a program is selected the source code and the compilation’s result is presented as shown in Figure 4. Source code is prefixed with line numbers so as to make studying of versions of a program easier. The aim of this module is to: • assist teachers in studying students’ errors and misconceptions when they are introduced to the object-oriented programming paradigm. • help teachers detect students’ problem-solving techniques, since each compiled version of a program represents a step in the development of the problem’s solution.

3 Empirical Study The software we developed was tested and evaluated by 20 undergraduate students from the department of Applied Informatics of the University of Macedonia in st Greece. The students that participated in the empirical study had attended in the 1 semester the compulsory course “Programming”, which is based on the procedural programming paradigm and uses Pascal as the programming language, and they had all failed in the exams. The students were separated into 10 groups. Six lessons were carried out, all of them at the laboratory, and the programming environment was used as the medium of instruction - occasionally the blackboard was used too. We also used Camtasia Recorder for recording (video) the actions of 2 groups. The lessons took place weekly, and their duration was 2 hours. In each one of the first 5 lessons we used the theory of the lessons that are incorporated in the programming environment in order to teach the basic concepts of each lesson. Next, students used


549

the activities that are incorporated in the programming environment, and in some cases existing programs, so as to assimilate the concepts and become familiar with the features of the programming environment. Finally, the groups developed one or two th programs without help from the teacher. The 6 lesson was devoted to the assessment of students’ knowledge and the evaluation of the programming environment and the series of lessons from the students. Next, we give the subject taught in each of the five lessons. st 1 Lesson – Objects-Classes. nd 2 Lesson – Inheritance. rd 3 Lesson – Polymorphism & Overriding. th 4 Lesson – Conditional Structures. th 5 Lesson – Repetitive Structures. th 6 Lesson. The aim of this lesson is: (i) the evaluation of students’ knowledge, and (ii) the evaluation of the programming environment and the series of lessons by the students. To be more specific, the students: • test and debug an existing program that includes all the categories of errors. • answer – personally – open type questions, so as to detect to what degree they understood the basic concepts of the object-oriented programming paradigm. • fill in - personally – a questionnaire that includes open and closed type questions. The results. For each one of the first 5 lessons: • the teacher recorded difficulties in understanding the taught concepts, drawbacks and problems that were encountered while using the programming environment, • the consecutive versions of the students’ programs were studied, • the recorded actions and dialogues of two groups were analysed. The most important conclusions that were drawn from the analysis of the data are: st 1 Lesson – Objects-Classes. The programming environment and the problems stimulated student’s interest. Students became familiar with the programming environment very quickly, and from the study of the consecutive versions of their programs we concluded that they had no difficulties in understanding the taught concepts. The detection and correction of logic errors was immediate due to step by step execution and explanatory visualisation. nd 2 Lesson – Inheritance. Students solved the proposed problems without having any particular difficulty. Only one group seems to confuse the concept of class with the concept of object. Although students assimilated the concept of inheritance without difficulty – only 15% of the programs included semantic errors – they had difficulty in developing the programs – 60% of the programs led to run-time errors. rd 3 Lesson – Polymorphism & Overriding. Several students had difficulty in understanding the concepts of polymorphism and overriding. With the help of step by step execution of existing programs they all understood that when a method declared in different classes with the same name is called, then the class of the objects decides which method will execute. The thorough study of the students’ programs made clear that 50% of the students assimilated the concepts of polymorphism and overriding, while 20% of them did not understand the concept of overriding or confuses the two concepts. th 4 Lesson – Conditional Structures. The syntax errors that were detected, in the programs of nearly all the groups, were mainly related to the omission of the syntactic markers that define the scope of the then and else parts of the conditional structures. Several students seem to become tense when the programming environment reports

550


syntax error messages, since they immediately compile the program without having made any attempt to correct it. However, the vast majority of syntax errors is corrected with the first attempt due to “good” error messages (plain and physical language is used, the actual line of the error is reported). The study of the consecutive versions of students’ programs made clear that without the assistance of the programming environment – “good” error messages, step by step execution, explanatory visualisation – most of the groups would not have been able to solve the problem, or at least they would have had great difficulty. th 5 Lesson – Repetitive Structures. Students had difficulty with repetitive structures. The study of the consecutive versions of programs made clear that a significant number of students finds it difficult to (i) distinguish the structures if and while, and (ii) develop programs that need both if and while. th 6 Lesson. After studying the versions of the programs that were developed by the students we concluded that: (i) understanding and debugging an existing program is quite difficult and time-consuming for some students, and (ii) editing a program, with the syntax editor, is easy. The results of the test are in agreement with the results of the 5 lessons. The analysis of the questionnaires showed that students evaluated positively the programming environment and the series of lessons. There were not reported any usability problems, and generally there was not reported any kind of problem. All the students stated that step by step execution helped them. The vast majority of students mentioned that: (i) used the lessons (theory, activities) that are incorporated in the programming environment during program development, (ii) was benefited by explanatory visualisation, and (iii) the structure editor assisted them in developing their programs.

4 Conclusions The educational programming environment that we developed was based on the results of the extended research about teaching and learning programming. Furthermore, we tried to incorporate those features that would give as the chance to record the students’ difficulties when they are taught object-oriented programming, since the research that has been carried out until now has revealed important facts about teaching programming but very few about object-oriented programming. The results of the empirical study that we carried out show that the programming environment can help invaluably the teacher and the student in teaching and learning programming respectively. The most important conclusions are: • The ability to record students’ actions provides invaluable assistance to the teacher, so as to detect students’ conceptions about object-oriented programming and the techniques they use during program development. • The structure editor solves the problem of focusing on the syntactic details and gives the chance to focus on understanding the concepts and principles of objectoriented programming, structure matters and developing problem-solving skills. Furthermore, we would like to mention the ease with which all the students used the structure editor. • The incorporation of the lessons (theory, activities) in the programming environment helped students during instruction and program development.


551

• Step by step execution, tracing through the program and explanatory visualisation helped students understand flow of control and the semantics of control structures, and helped them overcome their difficulties and misconceptions. Furthermore, the pilot use of the programming environment showed that it is possible to teach object-oriented programming in a short period of time with specially designed educational environments, while this is impossible with the usual professional programming environments.

References 1. Bergin, J., Stehlik, M., Roberts, J. and Pattis, R.: Karel++ - A Gentle Introduction to the Art of Object-Oriented Programming. 2nd edn. , Wiley, New York (1997) 2. Birch, M., Boroni, C., Goosey, F., Patton, S., Poole, D., Pratt, C., Ross, R.: DYNALAB: A Dynamic Computer Science Laboratory Infrastructure Featuring Program Animation. Papers of the 26th SIGCSE technical symposium on Computer Science Education, ACM Press, Nashville, TN USA (1995) 29–33. 3. Brusilovsky, P., Calabrese, E., Hvorecky, J., Kouchnirenko, A., Miller, P.: Mini-languages: a way to learn programming principles. Journal of Education and Information Technologies, 2, Kluwer Academic Publishers (1997) 65–83 4. Calloni, B. A., Bagert, D. J.: Iconic Programming Proves Effective for Teaching the First Year Programming Sequence. In the Proceedings of the 28th SIGCSE technical symposium on Computer Science Education, ACM Press, San Jose, CA USA (1997) 262–266 5. Freund, S. N., Roberts, E. S.: THETIS: An ANSI C programming environment designed for introductory use. In Proceedings of the 27th SIGCSE technical symposium on Computer Science Education, ACM Press, Philadelphia, PA USA (1996) 300–304 6. Holland, S., Griffiths, R., Woodman, M.: Avoiding Object Misconceptions. SIGCSE ’97 CA, USA, ACM Press (1997) 131–134 7. Miller, P., Pane, J., Meter, G., Vorthmann. S.: Evolution of Novice Programming Environments: the Structure Editors of Carnegie Mellon University. Computer Science Department, Carnegie Mellon University, Pittsburgh, PA 15213–3890 (1994) 8. Schorsch, T.: CAP: An automated self-assessment tool to check Pascal programs for syntax, logic and style errors. Papers of the 26th SIGCSE technical symposium on Computer Science Education, ACM Press, Nashville, TN USA (1995) 168–172 9. Xinogalos, S., Satratzemi, M., Dagdilelis, B.: Introduction to programming: Teaching Approaches and Educational Tools. In Proceedings of the 2nd Pan Hellenic Conference with International Participation “Information and Communication Technologies in Education”, Patra, (2000) 115–124 (in Greek)