The Flowchart Interpreter for Introductory Programming Courses

The Flowchart Interpreter for Introductory Programming Courses Thad Crews Uta Ziegler Department of Computer Science Western Kentucky University Bowling Green, KY 42101 Abstract An introductory programming course offers students problem solving analysis and design experience as well as exposure to the basic tenets of algorithmic thinking. Unfortunately, most introductory programming courses tend to concentrate on the syntax of a programming language (such as Basic, Pascal, C++, Java, etc.) at the expense of problem solving activities. The Flowchart Interpreter (FLINT) program supports problem solving activities while utilizing minimal-syntax flowcharts as visual representations of problem solving algorithms. FLINT provides the immediate feedback of an interpreted language as well as tools for simulation designed for use by novice programmers. This paper discusses the motivation for FLINT, including an analysis of the problems of typical introductory programming courses. An experimental study confirming the utility of flowcharts for introductory programming students is presented. Finally, the FLINT system is described in terms of its use by beginning programmers.

points out, “Learning to program benefits everyone.” (p. 22).

Teaching Programming is Problematic An introductory programming course has the potential to be a powerful learning opportunity for students to develop problem solving, design and thinking strategies. In practice this goal is difficult to achieve. We identify three reasons why teaching programming is problematic in the next section after a brief overview of the basic steps involved in developing good programs. Program Life Cycle Someone who learns how to design and write programs must learn a systematic way of attacking problems and translating them into a working program. These steps are referred to as the program life cycle and are summarized in Table 1. Table 1: The steps in the software life cycle

Introduction We should teach students to program. This is certainly true for students in the computational sciences. Likewise, there is general agreement that programming skills are advantageous for engineering students. But what about the students from the social sciences, management and the humanities? Would those students also benefit from a programming course? We believe the answer is “Yes.” In an article titled “Should We Teach Students to Program,” Elliot Soloway [5] asked the title’s question to a number of researchers at the National Science Foundation’s Advanced Applications of Technology (AAT) Program. The responses showed a general agreement that programming is the New Latin, meaning it is an excellent learning exercise and serves as a basis for many other learning opportunities. Writing programs requires problem-solving and critical thinking skills. These skills are important for any student to succeed in college and afterwards. The computer takes the role of an unbiased judge. It diligently exposes any error in a student’s reasoning, thus forcing the student to critically review and change the program. As the Soloway article

Step 1 2 3 4 5

Procedure Analyze the Problem Design a Solution Plan Construct an Algorithm Implement the Algorithm Test and Debug Algorithm

First the problem must be analyzed; that is, the student must determine what information is available and what is the intended outcome. Then the student must design a plan to determine what must be done and in which order to achieve the required outcome. Except for very simple problems, the plan must be hierarchical, meaning the problem is divided into subgoals which must be reached and a plan is developed for each subgoal (which might be divided into sub-subgoals). This hierarchical representation of the solution plan is often represented as a top-down chart. Once the solution plan has been established, the student starts to concentrate on how each step of the plan can be achieved by the computer. This requires the student to construct an algorithm for each goal/subgoal of the plan.

An algorithm is a series of actions in a specific order, and programmers often represent their algorithms as flowcharts. The fourth step in the program life cycle is the implementation of the algorithm in a particular programming language. This fourth step requires students to learn and understand the details of a programming language’s syntax. Syntax refers to the rules of a language, including such things as the proper use of semicolons and the exact format of each statement. When the program is free of syntax errors, the student must run the program to test the results. Developing good test cases to verify the correctness of a program is an important skill. When errors are identified, the process of debugging the program (identifying and correcting errors) begins, which involves reconsidering assumptions and decisions at each of the previous stages of the life cycle. We should point out that there is in fact a sixth stage in the full program life cycle: maintenance. This stage is difficult to address in an introductory programming course and is not usually discussed in significant detail until a software engineering course for CS majors. Three Problems Having discussed the five stages of the program life cycle, we now identify three problems we believe to be at the root of the problem with traditional Programming 101 courses. They are (1) too much focus on syntax, (2) not enough emphasis on problem solving, and (3) lack of support for experiencing program execution. Too much focus on syntax. Students do not experience programming as a combination of analysis, design, implementation and debugging. Even though many text books and instructors stress design, the natural tendency of beginning programming students is to concentrate on the most immediate problem at hand when writing programs: the syntax errors. The environment provided to most introductory programming students (an interpreter or compiler of a high-level programming language) forces them to get the syntax right before getting any feedback on their plan and algorithm. Instructors - trying to be helpful and avoiding some of the “syntax frustration” - spend considerable time in class discussing the syntactic details of the language. Thus the “big picture” of programming degenerates to an exercise in syntax satisfaction. This can be quite frustrating, particularly to beginning programmers. Not enough emphasis on problem solving. This second problem directly follows from the first. Because of the focus on syntax, there is little time for the other levels of the program life cycle. In particular, the first two levels (problem analysis and designing a solution) are typically

neglected. This is counter-productive. Educational researchers such as Papert [3] have found that students learn a great deal when they are actively involved in the process of design and creation. The first two stages of the software life cycle explicitly address these important tasks. When education researchers argue that programming helps one learn powerful problem-solving, design and thinking skills, they are referring to the full software life cycle with little interest in any specific programming language. In other words, a focus on syntax is exactly in the wrong place, and the cost of that focus is to remove attention from the powerful ideas which a programming course should--but typically does not--support. Lack of support for experiencing program execution. Students often do not see a program as a sequence of steps that must be executed one at a time. Rather, they view programs as a collection of statements that execute when necessary (as opposed to sequentially next). LET Pay = Hours * Wage INPUT Hours, Wage, Bonus DO WHILE Hours 0 LET TotalWage = Pay + Bonus PRINT TotalWage INPUT Hours, Wage, Bonus LOOP Figure 1: The first assignment does not determine a value, but a method of computation. The student assumes the value is computed each time Pay is used. Under this assumption, the exact placement of a statement is irrelevant for the correct working of the program (see Figure 1). Thus, students often write programs that contain the correct statements, but the order of the statements is incorrect. Since the program execution is not visible, the student often does not realize that there is a misconception. Visibly experiencing a program in execution can also help students find logic errors in their programs. Once the student sees the discrepancy between what the program ought to do and what it does, the student can identify the error and can fix the problem.

Using Flowcharts to Improve Learning Our proposed solution to address the problems identified above involves moving away from environments that force students to struggle with syntax in favor of a visual algorithmic design environment using flowcharts. Flowcharts were selected for use in our environment for three reasons. First, flowcharts involve a minimal syntax. By reducing the focus on syntax we are able to increase the

IF D > A THEN IF B > D THEN PRINT A + D ELSE PRINT B + C END IF ELSE PRINT A + B IF B > C THEN IF C > A THEN PRINT C + D ELSE PRINT B + D END IF ELSE PRINT A + C END IF END IF

IF A < D THEN PRINT A ELSE PRINT D IF B < C THEN PRINT B ELSE PRINT C END IF END IF

Figure 2. The simple algorithm (2 conditions) Figure 3. The medium algorithm (4 conditions) effort spent on problem analysis and solution design. Our second reason is that flowcharts are a “universal representation.” They present information clearly and “Introduction to Programming in BASIC” (no unambiguously. While there has been a growing interest in programming prerequisite). The experiment was conducted visual programming techniques, no visual system has in the seventh week of the 3-hour course. Students had been introduced to loops and conditional statements, and achieved the universal acceptance of flowcharts. Our final reason for pursuing flowcharts is our flowcharts had been used in both classes to illustrate the assumption that flowcharts are fundamentally easier for semantics of loops and conditional statements. CS230 is a introductory programming students to understand than general education course and both sections contained a mix structured code. This assumption is based on our classroom of students typical for this course. experience with students attempting to understand and modify written code (including their own code). To verify our assumption, we conducted an experiment to compare flowcharts to QBasic code in terms of student IF B > D THEN IF A > B THEN speed, accuracy and confidence. That experiment and PRINT C * C its results are now discussed. ELSE Experiment Various studies have been done which indicate that structured flowcharts are beneficial for various purposes and with various audiences (c.f., Scanlan [4], Kamman [2], Wright and Reid [9].) However, none of these experiments directly address our central assumption that introductory programming students perform with greater speed, accuracy and confidence when using flowcharts rather than a specific programming language such as QBasic. We conducted an experiment to evaluate our assumption using a design similar to that of Scanlan [4]. Method Subjects. The 58 subjects for this experiment were students from two sections of the course CS230

IF C > A THEN IF D > C THEN IF B > C THEN PRINT B * C ELSE PRINT C * D END IF ELSE PRINT A * B END IF ELSE PRINT A * C IF A > D THEN PRINT A * D ELSE PRINT B * D END IF END IF END IF ELSE PRINT A * A END IF

Figure 4. The complex algorithm (6 conditions)

Materials. The experiment tested three algorithms: simple, medium and complex. Each algorithm had a flowcharted version and a QBasic program version involving simple conditions and outputs. Figures 2 - 4 show the six versions of the three algorithms. The contents of the flowchart symbols were a random placement of the same conditions and print statements as in the related program code. They are not reproduced in the figures due to size. Each of the six versions were printed on a separate sheet of paper. Six answer sheets were constructed, each containing three sets of input values and a request for the corresponding output. Each answer sheet also contained a place for subject to write down the time when they completed the three inputs and their confidence ranking of their solution. Procedures. The experiment took place during a regular class meeting time. Subjects were randomly assigned a simple flowchart or a simple program along with a random answer sheet. After completing the first algorithm, subjects were given the remaining simple algorithm at the next stage. This process was repeated for the medium algorithms and then the complex algorithms.

Correctness Scores 3 2 1 0 Simple

Medium

Flowchart

Complex Program

Figure 5. Correctness scores for each algorithms (significant at p ≤ 0.002)

Confidence Scores

5 4 3 2

Results 1

Scoring. The six answer sheets for each subject were graded as follows. One correctness point was awarded for each of the three outputs that were correct. The time score was the number of seconds the subject required to determine the three outputs. The confidence score was ranked 1 to 5 as subjectively identified by the student (see Figures 5 - 7). Statistical Analysis. Independent sample T-Tests were run to verify that there were no differences resulting from teacher or method. Scores for correctness, confidence and time were then run as paired-samples analyzing the difference in the scores between the measures. In all three cases and at all three levels of difficulty, the differences in scores were strongly significant. In addition, we found that the advantages of flowcharts became more dramatic as the complexity of the algorithms increased. Discussion. The results of this experiment confirm our assumption that introductory programming students benefit from the use of flowcharts rather than actual program code for representing algorithms. Beginning students made significantly fewer errors, had significantly more confidence in their answers, and spent significantly less time determining answers. It is also important to realize that the more complex the algorithm, the more beneficial flowcharts are over program code.

Simple

Medium

Flowchart

Complex Program

Figure 6. Confidence scores for each algorithm (significant at p ≤ 0.003)

Time Required

175 150 125 100 75 50 25 0 Simple

Flowchart

Medium

Complex Program

Figure 7. Average time required in seconds to complete each algorithm (significant at p ≤ 0.000)

The Flowchart Interpreter System The Flowchart Interpreter (FLINT) System was developed to address the problems of syntax, problem solving, and support for program execution in a unified manner. FLINT is a visual development environment that

facilitates the construction of top-down design charts and the implementation and simulation of algorithms as flowcharts. FLINT presents programming to the student as activities surrounding design (using structure charts), implementation (using flowcharts), and testing and debugging (using the interpreter). Thus it allows introductory programming students to advance their programming skills within the “big picture” of the full software life cycle. FLINT removes the focus from the syntactic details of a programming language by Figure 8. Using FLINT to design a top-down chart. providing students with an iconic interface for developing flowcharts. The point-and-click interface hides low-level This controlled simulation fosters the early familiarity with details from the user, thus freeing the students to program tracing and opens the door for students to develop debugging skills to complement their growing concentrate on how to solve the problem. Just removing the (inappropriate) focus on syntax does programming skills. Figure 8 shows the FLINT problem-design interface not mean that students will focus on more appropriate while solving a bi-weekly paycheck problem. Students use issues (e.g., problem solving and design). Therefore, FLINT visual techniques to design a top-down chart for their supports the problem-solving and design activities that solution. The student may then solve each leaf node in the should precede the implementation of a program. In FLINT, top-down chart by developing an associated flowchart. For a student begins by designing a structure chart for the example, Figure 9 illustrates the student’s algorithm for problem at hand before being allowed to start working on computing pay when processing a record. Once the solution the flowchart. The structure chart is a division of the problem into its major steps. This forces the student to think about the problem, about what must be done, before concentrating on how it should be done. Each of the major steps developed in the structure chart can be implemented by a separate flowchart. To a FLINT user, the sequential nature of programs becomes literally visible as every flowchart can be executed step-bystep. The statement that is currently interpreted is highlighted and control passes to the next statement at the student’s command. In addition, FLINT makes variable values observable, allowing the student to follow the Figure 9. The FLINT interface while constructing an algorithm effects of the program statements.

has been generated, students are able to test their algorithms through the flowchart interpreter.

Comparison to Related Works FLINT aims at integrating problem analysis & design, implementation and testing. Thus, it moves well beyond projects that merely concentrate on eliminating the focus on syntax. One such example is BACCII/BACCII++ [1], an “iconic programming language” which has many features of a flowchart. A student programs by selecting an icon from a tool palette (all the major programming constructs are represented by icons) and placing it on the screen where needed. Icons are connected by appropriate lines. Whereas FLINT flowcharts are immediately executable, BACCII’s iconic programs are used to generate syntactically correct source code that is separately compiled and executed. Another effort aimed at reducing the focus on syntax is Georgia Tech’s two-course sequence to introduce students to “an appropriate foundation in the conceptual and intellectual foundation of computing” [6, 7]. Implementation is de-emphasized to the extent that a highlevel programming language is not introduced until the second course. During the first course, students use a pseudo language to develop their algorithms. Because the pseudo language is never executed (or interpreted by software), students receive feedback from humans such as undergraduate TAs or the instructor. Feedback from FLINT’s interpreter is, of course, less personal than that which a TA might provide. However, it is immediate and accurate and requires no additional resources.

Summary Problem analysis, solution design, and algorithm construction are some of the powerful learning opportunities associated with programming. In practice, however, most introductory programming courses spend a disproportionate amount of time on learning the syntax of a particular high-level language at the expense of the other stages of the program life cycle. Furthermore, most software development environments are not designed for the novice user and lack the proper tools to support beginning programmers. The Flowchart Interpreter System is a visual development environment capable of handling top-down structure charts and associated visual algorithmic solutions which can be run in a step by step fashion. FLINT allows students to concentrate on problem solving skills, design issues, and debugging processes rather than being bogged down with syntactical, language specific details. The FLINT system is still a relatively young system. We continue to refine the system’s functionality, develop

supporting materials, and redesign our introductory programming course to focus on problem solving rather than syntax skill.

References [1] Calloni, B. & Bagert, D., “An iconic syntax-directed system for teaching procedural programming,” Proceedings of the 31st ACM Southeast Conference, Birmingham AL, 1993, pp. 177-183. [2] Kammann, R., “The Comprehensibility of Printed Instructions and the Flowchart Alternative,” Human Factors, Feb. 1975, pp. 183-191. [3] Papert, S. Mindstorms: Children, computers and powerful ideas. New York: Basic Books, 1980. [4] Scanlan, D., “Structured Flowcharts Outperform Pseudocode: An Experimental Comparison,” IEEE Software, Sept. 1989, pp. 28-36. [5] Soloway, E., “Should We Teach Students to Program?” Communications of the ACM 36(10), Oct. 1993, pp. 21-24. [6] Shackelford, R., Introduction to Computing and Algorithms, Addison-Wesley, 1998. [7] Shackelford, R. & LeBlanc, R., “Introducing Computer Science Fundamentals Before Programming,” in the Proceedings of FIE ‘97, 1997 p. 285-299. [8] Shneiderman, B., Mayer, R., McKay, D. & Heller, P., “Experimental Investigations of the Utility of Detailed Flowcharts in Programming,” Communications of the ACM 20(6), June 1977, pp. 373-381. [9] Wright P. & Reid, F., “Written Information: Some Alternatives to Prose for Expressing the Outcomes of Complex Contingencies,” Journal of Applied Psychology, Feb. 1973, pp. 160-166.