An Integrated Program Development Tool for Teaching and Learning How to Program Uta Ziegler Department of Computer Science Western Kentucky University Bowling Green, KY 42101 (502) 7452911 Thad Crews Department of Computer Science Western Kentucky University Bowling Green, KY 42101 (502) 74!54643 uta.zieglerO wku.edu crews@wku.edu design am not supported in commercial IDES. Whereas professionaldevelopersuse powerful CASE tools to support the software life cycle, novice programmets receive no support from their development environment Thirdly, the debugging features of IDES am aimed at experienced pmgrammem,overwhelming studentswho arejust beginning to get an understandingfor programexecutionand debugging. Abstract Teaching and learning how to program requires environmentsdesignedto support theseactivities rather than available development commercially integrated environments. This paper presents an instructional enviromnent which embracesthe entire process of design algorithm development, testing and debugging while rhhhing the syntactic details with which students must cope. Students using this environment develop a view of programming in which design and testing are integral parts of program development. This paper proposesan instructional program development enviromnent for use in a CSl course. The instru&onal environmentpresentedhere consistsof an integratedsoflwate environment that supports the entire process of design implementation,testing and debugging.Furthermore,students receive timely and helpful feedback on their work to nxaximk learning. All along, the environment minim&es syntacticdetails and is languageindependent. Keywords Introduction to programming, instructional environment, integratedprogram developmenttool The next section summarizesresearchefforts relevant to the work presentedin this paper. This is followed by a detailed description of the instructional program environment under developmentat WesternKentucky University and how it can beusedinaCS1 course. 1 Introduction Instructing students in program development requires an environment tailored to the needs of teaching and learning how to program. Such an environment is different from commercially available production environment, such as BORLAND or CODEWAKKTOR, which are designed for matureusersdevelopinglarge programs. Using commercially available integmted development enhnments (IDES) has several disadvantagesfor students new to programmmg.First, only the complex syntax of a fullblown programming language is supported. Students often struggle with the syntax rules and come to the wrong conclusion that program development is primarily writing correct program statements.Secondly, problem solving and ~~,,,,,~s,on persona, ,o make cop,es a,e no, made tage an,, tha, c,,ples 70 copy otherwtse, ,ed,s,,,b”,e to SIGCSE’99 0 ,999 d,g,tal r,, ~,as~rrmm ,,SIS, 3/99 ACM or hard use copes IS granted of all or part without fee of this provided o, d,str!buted for proflt Or COmmerCia’ bea, th,s “otlce and the tUtI CltatlOn to republish. requres New 10 Post prior Orleans. 1.58113.085.6/99/0003...$5.00 SP’XlflC LA. USA on Ser’~erS PermlSSlon work advanOn the flrs1 01 tp and/or for tha’ a fee page 2 Environments for leaching Programming lnstrudonal environments for CSl courses are an area of active research. Two efforts, which sharesomesimilarity to our work, are described below. Other works deal with providing feedbackto students,mostly using visualization and animation [l, 7]. 2.1 lconic Programming BACCII/BACCII++ [2, 31 addresses the problem of mhimizhg syntactic detail. Calloni and Bagert developedan “iconic programmi& enviromnent. All program constructs (including variables) are represented through icons. The studentselectsan icon with the mousefrom the tool palette and drops it at the appropriateplace in the coding window. After the student has built a program, BACCII can generate syntactically correct source code for the program in one of 276 languages. The student must compile the source code and execute and test it elsewhere to get feedback on the program’s correctness. Students using BACCll performed significantly better on progmmming assignments, closed lab assignments, as well as exams compared to a control group that only used VAX PASCAL [2]. Students using the iconic interface to construct programs and to generate C+t code for assignments had a higher comprehension of C++ syntax than the control group and mote uniform learning took place among the students using the iconic interface [3]. 2.2 Pseudo Programming Shackelford and colleagues at Georgia Tech address the problem of teaching program design [4, 10, 11]. They teach program development in a two-course sequence. During the first course, students use a pseudo language to develop their algorithms. A high-level programming language is not introduced until the second course. The focus of the first course is on abstraction and the use of data structures and - to a lesser degree - the evaluation of the chosen algorithmic design. The pseudo language cannot be executed. Therefore, the students spend most of their time in program design and algorithm development (since there is nothing else to do). However, students also do not get immediate feedback on their work, which limits their testing and debugging opportunities. Feedback is provided thmugh weekly one-onone meetings with paid, undergraduate TAs. 3.1 Program Design in FLINT Program design answers the question “what must he done?” at increasing levels of detail. In FLINT, students use the process of step-wise refinement to construct a program design that is recorded in a top-down structure chart [6]. During this phase, students organize their approach to the problem and develop a plan for solving the problem. Often, the design phase must be revisited once problems have been uncovered during algorithm development or testing. FLINT supports such revisions and records all student design activities. These designs give the teacher valuable insight into a student’s design habits and abilities. ‘Ibis information may also be useful to students for reflective analysis after the project is complete. Figure 1 shows an example design. The first line in each box indicates the type of work that must be accomplished, such as getting information or calculating some values. The bold printed line is the name of the step. The algorithm that is later developed for this step is stored with that name (so it must be unique). The remaining text in each box is added by the student to describe what must be done. FLINT does not analyze this text, but stores the entire design to be later reviewed by the teacher and/or the student. 3 FLINT - An Integrated Program Dsvslopment Tool Each of these steps is discussed in more detail in the following sections. Figure 1: An example top-down design. The student wants to add another box to continue the refinement of the step “Calculate pay for the week” 271 Many teachers stress design, but too often their advice is not heeded. Too many students first get the program to run and then “abstract” the design from the algorithm. This is not possible in FLINT. The design must be specified before any algorithm construction can begin. An algorithm can be constructed for each box by double clicking on it. Once the student starts constructed the first algorithm for a problem, the design is stored in the system for later evaluation by the teacher. FLINT ensures that the algorithms developed by a student for a problem are consistent with the design. For example, for the design in Figure 1, FLINT rejects any algorithm for the top most box that does not include at least one reference each to Get_work_info, Calc_pay, and Print-y. Furthermote, it rejects any algorithm that includes a reference to a step that is not a direct successor of the top most box. Thus the student is forced to implement the design and if changes are necessary they must begin with changes in the design 3.2 Algorithm Dewebpment in FLINT Algorithm development answers the question “How can the program accomplish what must be done?” Each of the steps that have been developed during the design phase must now be complemented with a description of how that step is implemented. FLINT uses structured flowcharts to represent algorithms. Studies have shown that flowcharts are easier to understand and faster to evaluate than pseudo code for experienced A recent study of introductory programmers [8]. programming students examined students’ comprehension, confidence and speed when using flowcharts versus QBASIC code. Students in the flowchart group performed significantly better with respect to the correctness of their work, the time they needed to complete the work and the confidence they had in the correctness of their work [5]. The study also indicated that the benefits of flowcharts increased with the complexity of the algorithms. FLINT supports structured algorithms by allowing only complete program constructs to be added deleted, moved or copied (see Figure 2). Thus, the constructed flowchart will always be - and syntactically valid. FLlNT only supports the basic program structures of sequence, selection and repetition [6]. GOTOs and EXIT statements are not supported. Therefore, every logical part of an algorithm has only one entry and one exit, facilitating understanding, modifications and &bugging. Figure 2: Only complete program constructs can be added. The student added a conditional statement and a loop statement. The conditions to be tested are specified in separate dialogs. The true and false branches, as well as the joining of the branches are added by FLINT. The student cannot directly manipulate the connections among flowchart symbols. colors for easy recognition. only the important information for each statement is displayed on screen at all times. The other information (for example, the prompt for an input statement) is available by double clicking on the element on the screen. Figure 4 shows an algorithm for one of the steps in Figure 1. While developing the design and constructing the algorithms, students must declare what variables they want to use. For each variable, they must specify a name and provide a short description. During the construction of the algorithm, students can only select variables that have already been “declared” in this way (see Figure 3). Providing an explanation for each variable forces students again to clarify their plan and prevents them from using two different variable The point-and-click interface of the flowchart builder is easy to use and intuitive. Thus the teacher needs to spend very little class time on how to use the flowchart builder. The flowcharts are displayed using the conventional shapes and various Figure 3: Variable declarations in FLINT. 278 names for the same item (for example Pay and Wage) or one name for two different items. The algorithm development allows teachers to show students how to construct algorithms incrementally. For example, an algorithm can be developed (and tested and debugged) which only implements the bare minimum. After that is accomplished, bells and whistles can be added as desired. 3.3 Testing and Debugging in FLINT Testing attempts to answer the question “Are the design and the algorithms correct?" Students can execute the algorithms they developed with FLINT to get immediate feedback on their work. When using FLINT, students experience testing and debugging not as an add-on, but as an integral part of program development. In particular, black box testing techniques [9] are supported. When determining a program’s correctness, students need to clarify for themselves what output to expect for a given input. With FLINT, a teacher can specify how many test runs students need to perform with the program. FLINT prompts a student for the input and the expected output for each test run. It stores that information for later use by the teacher. When performing each test run, the student must specify whether the output is as expected. If a test reveals an error, the student must find the source of the error. For this, the student needs more control over the trace, such as executing each statement under student control or setting lmakpints. FLINT offers these possibilities. When tracing a program, each statement is highlighted before it is executed as are the variables involved. After the statement is executed the changed variables remain highlighted for a short time. Then the next statement to be executed is highlighted and so on. Thus the sequential nature of program execution becomes literally visible to students. The speed of the trace can be adjusted for maximum comprehension and the trace can be aborted at any time. Teachers can use FLINT’s program tracing to demonstrate how programs are executed and to show how new programming constructs operate. Students can watch execution traces to develop a thorough understanding of program execution as the sequential execution of program steps. Once the location of an error has been identified, the student must use his/her knowledge of the design and the algorithms to correct the error. This can involve slight or major changes to the algorithms and/or the design. 279 4 Use of FLINT in Classroom and Assignments FLINT can be used for in-class demonstration of program execution and tracing. However, its primary strength is support within a lab environment. During closed labs, studentscan perform short tasks individually on a computer, investigating a design or algorithm provided by the instmctor or another student. When used for out-ofGlass assignments, FLINT supports studentsthroughout the entire development processwith valuable assessmentdataautomatically collected for the instructor. FLINT is currently designedto be used for roughly the first half of the semesterin a CSl course. During this time, students are introduced to the topics of design implementation (including sequentialstatements conditional statements,loops and subroutines),testing and debugging.No high level languageis discusseduntil studentshave designed, implementedand evaluatedprogramsof significant size. This “concepts first” approach allows students to develop an appreciation for the entire sotbvare development process. Only then a high level languageis introduced,with the focus on the syntaxnecessaryto implementthe flowcharts. 5 conclusifxls FLINT is an instructional program developmentenvironment for use in a CSl course. FLINT provides au integratedview of program development by supporting design, algorithm developmentand testing and debugging.In FLINT, program developmentalways startswith a design phaseand students’ testing and debuggingskills grow along with their algorithm constmction skills. Whether a teacher focuses on new programming constructs,design skills or testing procedures, all activities are supported by FLINT’s over-spanning framework and understoodas such by the students. When usingFLINTastudentwilllearn--startingwiththevery~ program -- that programdevelopmentbeginswith a plan how to solve the problem and ends after the program passed sutlicient tests(and not simply after it “runs”). Since students actively design and develop their programs in FLINT, they will be able to test them efhzctively and to debug them efficiently if needed. The instructional environment described in this paper can change the way students perceive program development. It will benefit any student taking an introduction to progmmming courseby focusing on design and development rather than syntax. Moreover, it is expectedthat FLJNT will lay a solid foundation for students continuing with pro-g classes. 6 References 0. Astrachan, S. H. Rodger (1998). Animation, Visuulizatio~ and Interaction in CSI Assignments, in the pmceedhgs of the 29th SIGCSE Technical Symposiumon ComputerScienceEducation p 317321. [2] B. A. Calloni, D. J. Bagert(1994). Iconic Programming in BACCII Vs Textual Programming: which is a Better Learning Environment? in the proceedings of the 25th SIGCSE Technical Symposium on Computer ScienceEducation,p 188-192 [3] B. A. Calloni, D. J. I&@ (1997). Iconic Programming Proves Effective for Teaching the First Year Programming Sequence,in the proceedingsof the 28th SIGCSE Technical Symposium on Computer ScienceEducation,p 262-266. [4] M. J. Canup,R L. Shackelford(1998). Using software to SolveProblemsin Large Computing Courses,in tie proceed&s of the 29th SIGCSE Technical Symposiumon ComputerScienceEducation,p 135139. [S] T. R Crews,U. Ziegler (1998). TheFlowchart Interpreter for Introductory Programming Courses, in the I’meed@ of FlE ‘98 Conference,p 307-312. [6] J. K. Hughes, J. I. Michtom (1977). A Structured Approach to Programming,PrenticeHall. [7] R. S. Sangwan,J. R. Korsh, P. S. LaFollette (1998). A Systemfor Program Visualization in the Classroom, SIGCSEBulletin Vol30, No 1, p 272-276. [8] D. Scalan (1989). Structured Flowcharts Outperjkm Pseudocode:An Experimental Compariso@IEEE Soflware,Vo16, No 5, p 28-36. [9] S. R Schach (1999). Classical and Object-Oriented Sojiware Engineering, 4’ Edition, McGraw-Hill. [lo] R L. Shackelford(1998). Zntroductionto Computingand Algorithms, Addison-Wesley. [ 1l] R. L. Shackelford, R. Blanc (1997). Introducing Computer Science Ftou&unen.tais Before Programming, in the -8s of FJE ‘97 Science Education,p 188-192. 280 [l]