Using a Flowchart Simulator in a Introductory Programming Course

Flowchart Simulator

1

Using a Flowchart Simulator in a Introductory Programming Course Thad Crews Western Kentucky University 1 Big Red Way (270) 745-4643

[email protected] Abstract Right From the Start is a project at Western Kentucky University designed to provide novic e students with a foundation for later programming study through a series of interactive design tasks involving fundamental logic structures. To support this goal, the instructional tool Visual has been developed and used in classroom settings. (To obtain copies of the Visual software and related support materials for academic use, visit http://cis1.wku.edu/visual ). Visual is an instructional tool designed for novice programmers and is intentionally easy to learn and use. When using this tool, students may design, develop, test and evaluate computer programs before introducing any traditional high -level language. This paper reports the results of an experimental design involving the use of Visual during the first five weeks of an introductory course. The results suggest instructional benefits for students who use interactive flowcharts to emphasize logic and design early in the first programming course.

Introduction According to a recent National Academy of Sciences report, a number of essential elements are necessary for a person to achieve fluency with information technology (NAS, 1999). One of the essential elements identified in the report is exposure to computer programming. The report concludes that programming knowledge and experience is beneficial to everyone in an information society. “The continual use of abstract thinking in programming can guide and discipline one's approach to problems in a way that has value well beyond the information technology-programming setting. In essence, programming becomes a laboratory for discussing and developing valuable life skills, as well as one element of the foundation for learning about other subjects.” (NAS, 1999, p. 48). National Science Foundation (NSF) researchers suggest that programming instruction should not be limited to students in computer departments, noting that learning to program has been

PDF created with FinePrint pdfFactory trial version http://www.fineprint.com

Flowchart Simulator

2

shown to have benefits ranging from teaching general-purpose problem solving and thinking skills to helping students appreciate and understand how computers work (Soloway, 1993). Over two decades ago, MIT computer scientist Seymour Papert reported that a deep understanding of programming, in particular the design activity of successive decomposition as a mode of analysis and debugging of trial solutions, results in significant educational benefits in many domains of discourse, including those unrelated to computers and information technology per se. By transforming abstractions into concrete representations via programming, students "build their own intellectual structures with materials drawn from surrounding culture" (Papert, 1980, pp. 3132). While programming is considered a valuable learning activity, it is also a complex task and is often difficult for novices to master (Sleeman, 1986; Spohrer & Soloway, 1986; Malik, 2000). The following section provides an overview of previous attempts to improve the process of learning to program. This is followed by a report of two studies examining programming instruction using simple, intuitive flowcharts to abstract fundamental concepts that are foundational to all programming languages. Experimental investigations of the utility of flowcharts for novice programmers and the impact of a flowchart based learning tool on students understanding of fundamental programming activities are presented, followed by a general discussion of the results and its implications for educational technology. Prior Research on Programming as Design Advocates of programming as a learning activity are often not supportive of traditional programming courses which emphasize programming languages such as C++, Java, Visual Basic or Pascal (Saret, 2001; Sprankle, 1998). Rather, these advocates of programming as a learning activity emphasize the design process over the subtleties of syntax (Farrell, 1999; Kafai, 1995).

PDF created with FinePrint pdfFactory trial version http://www.fineprint.com

Flowchart Simulator

3

There have been numerous efforts to improve the programming process by minimizing the complexity of the syntax and increasing design activities (NAS, 1999; Robertson, 2000). The following section presents several examples of related studies that have received considerable attention and form the basis for this research project. Using Mini-Languages to Teach Novice Programmers One popular approach to teaching computer programming involves the use of minilanguages.

The mini-language uses a programming environment with relatively few

instructions/commands (e.g., Brusilovsky, Calabrese, Hvorecky, Kouchnirenko & Miller, 1997). Mini-languages are designed to be intuitive to novice programmers, allowing them to freely explore the problem-solving context without being burdened by syntax construction. These environments do not introduce any of the complex commands typically found in traditional highlevel languages. Instead, the programmer is provided with a set of basic commands that may be used to create simple solutions. One of the earliest examples of this approach was the Logo programming language as described in the book Mindstorms (Papert, 1980). Originally designed for children, Logo allows computer novices to create unusual geometric designs and cartoon drawings by controlling a programmable turtle with a small number of simple commands (e.g., “forward,” “back,” “left turn”). The Logo language has been well received for two decades, with various adaptations along the way. Another significant contribution to the simplified syntax effort was Karel the Robot (Pattis, 1981). It was designed specifically to provide “a gentle introduction to programming.” In 1996, Karel++ (Bergin et al., 1997) was developed to provide a similarly simple introduction to object-oriented programming. Logo, Karel, Karel++ and similar tools attempt to address the

PDF created with FinePrint pdfFactory trial version http://www.fineprint.com

Flowchart Simulator

4

design/syntax problem by making the design environment intuitive and the syntax simple. However, while reading the first programming chapter in Karel++, a novice is exposed to the following: punctuation rules, grammar rules, instructions, messages, classes, reserved words (e.g., void, task, class), special symbols, main task block, delimiters, declarations, error shutoff, lexical error, syntax error, execution error, intent error, and debugging. Some novices may disagree that this represents a “gentle introduction.” Iconic Programming An alternative to languages with a simplified syntax uses graphics instead of textual instructions. Calloni, Bagert, and Haiduk (1997) address the problem of minimizing syntactic detail though the use of BACCII, an iconic programming environment. All program constructs (including variables) are represented through icons. After the student builds a program solution using a logical series of appropriate icons, BACCII generates syntactically correct source code for the program in a traditional high-level programming language. The drawback is that the student must then compile the source code, execute and test it in the high-level language environment. Furthermore, all error messages and debugging requirements are communicated to the student using the syntax of the high level language rather than the familiar iconic representation. Pseudo Programming Another popular approach to programming instruction uses a procedural language, but relaxes the strict syntactical rules that often confuse students. Shackelford (1998) has developed an approach whereby novices use a pseudo language to develop their algorithms. The psuedolanguage allows students to write programs using common English words of their choosing. Pseudo-languages do not have to follow strict syntax rules making them easier to work with by

PDF created with FinePrint pdfFactory trial version http://www.fineprint.com

Flowchart Simulator

5

novices. Since the pseudo-language cannot be executed, students spend more time on designing a solution than dealing with implementation details. The limitation of this approach is the inability to actually execute the program results in a lack of real-time feedback to the student. The pseudo-language approach requires human evaluation for feedback, typically provided by the TAs or the instructor.

There are also concerns regarding the consistency of human

evaluations of pseudo-language solutions. The Utility of Flowcharts Supporters of programming in education are constantly looking for ways to emphasize the valuable learning activities of logic, design, problem solving, critical reflection, and selfexpression. A common goal of many computing educators is to somehow capture the essence of solution design without introducing the complexity of a high-level implementation language. One representational technique that has long been used to capture the essence of procedures is flowcharting. A flowchart is a diagram that shows step-by-step progression through a procedure. In computer programming, flowcharts allow a conceptual representation of important issues such as input, output, assignments, conditions, and loops. Some anecdotal data suggests that novice students perform better, faster and with more confidence when they examine designs represented as flowcharts rather than high-level language syntax. Apparently this observation is not unique, as the majority of introductory programming textbooks have traditionally used flowcharts when introducing important concepts. The potential value of flowcharts is further supported in the educational-psychology literature.

Bloom’s

Cognitive Taxonomy (Bloom, 1956) is a classification of levels of activities for human learning. Mastering the syntax of a traditional high level programming language primarily involves memorizing and recalling particular language details. Such activities are at Bloom’s lowest level

PDF created with FinePrint pdfFactory trial version http://www.fineprint.com

Flowchart Simulator

6

of learning. Flowcharts can be used to minimize the detail of language syntax while allowing students to work at a conceptual level—thereby supporting higher level learning activities. A number of studies have been conducted that examine the utility of flowcharts for various purposes and with various audiences (e.g., Higgins, 1987; Kammann, 1975; Ramsey, Atwood, & Van Doren, 1983; Scanlan, 1989; Shneiderman, 1975; Vessey & Weber, 1986; Wright & Reid, 1973). However, none of these studies compare flowcharts to language syntax with respect to novice programming students. The goal of these studies is to address this missing knowledge area, examining the utility of flowcharts for novice programmers for understanding computer algorithms. PROCEDURE Two experiments were conducted as part of the present study. The goal of the experiments is to examine the utility of flowcharts versus program code for novice students’ understanding of computer algorithms. Hypothesis 1.1: Novice programming students will develop more accurate program solutions using flowcharts than with structured code. Hypothesis 1.2: Novice programming students will develop program solutions more quickly using flowcharts than with structured code. Hypothesis 1.3: Novice programming students will have higher confidence in their program solutions using flowcharts than with structured code. Hypothesis 1.4: The benefits of flowcharts will be more pronounced as the problem algorithms become more complex.

PDF created with FinePrint pdfFactory trial version http://www.fineprint.com

Flowchart Simulator

7

Method Participants The participants for this study were 58 undergraduate students from two 100-level introductory Quick Basic (QBasic) programming courses. Both the instructors were computer science professors, and they used the same textbook, lesson plans, and pedagogy. Students in the courses came from different backgrounds and had different majors. There was an equal mix of males and females. Apparatus Using a methodology based on that of Scanlan (1989), the experiment required subjects to determine output solutions for three different problems—each more difficult than the last. Each problem had a flowchart representation and a Basic syntax representation. Each of the six representations was printed on a separate sheet of paper. Figures 1 - 3 show the flowchart and structured-coded representation of each problem. 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 constraints. Each answer sheet contained three sets of values representing inputs to the computer program with corresponding space for the program output. Each answer sheet also contained a place for subjects to record the time when they finished from a digital clock clearly projected on a large screen throughout the experiment. Each answer sheet also contained space for subjects to identify how confident they were about their solutions. Insert Figure1 (Simple Problem) About Here

Insert Figure 2 (Medium Problem) About Here

PDF created with FinePrint pdfFactory trial version http://www.fineprint.com

Flowchart Simulator

8

Insert Figure 3 (Complex Problem) About Here

Procedure The experiment was conducted in the seventh week of the 3-hour course, approximately halfway through the course. Participants had been introduced to input, output, assignment and conditional statements, and flowcharts had been used in both classes to illustrate the semantics each statement type. The experiment took place during a regular class meeting time. Participants were randomly assigned an initial representation (either flowchart or structured code) for the “simple” problem along with a random answer sheet. Participants determined the output for each of the three program inputs provided on the answer sheet. After determining the three outputs for the problem, the subjects recorded the time as displayed on the projection screen. Finally, participants recorded their confidence level for their solutions on a 5-point scale (1 = not confident, 5 = very confident). All participants were given sufficient time to complete the task. Then subjects were given the alternate representation of the “simple” algorithm, a new answer sheet, and again determined the three problem outputs, recorded the overhead time, and rated their confidence in their solutions. This process was repeated for the two “medium” and two “complex” problems. Results The correctness score was determined by awarding one correctness point for each of the three outputs that was correct per solution sheet. The time data was recorded as the number of seconds required for determining the outputs for each given input. The confidence score was recorded

PDF created with FinePrint pdfFactory trial version http://www.fineprint.com

Flowchart Simulator

9

from the 5-point scale. This grading process was the same for each of the six answer sheets provided by each participant. Independent sample t-tests verified there were no differences attributed to teacher or method. Scores for correctness, confidence and time were then analyzed as paired-samples for significant differences. Hypothesis 1.1 suggests that novice programmers will generate more accurate solutions for computer problems represented as flowcharts than represented as structured program code. Support was provided for this hypothesis as participants’ flowchart-representation correctness scores were significantly higher (p D THEN IF A > B THEN PRINT C * C ELSE 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

22

Correctness Scores 3 2 1 0 Simple

Medium

Flowchart

Complex Program

Figure 4. Correctness scores for each algorithms (significant at p ≤ 0.05) Time Required

175 150 125 100 75 50

Figure 3. The complex algorithm (6 conditions)

25 0 Simple

Medium

Complex

Flowchart

Program

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

Confidence Scores

5 4 3 2 1 Simple

Flowchart

Medium

Complex Program

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

PDF created with FinePrint pdfFactory trial version http://www.fineprint.com

Flowchart Simulator

TABLE 1: PROBLEM SET FOR UNDERSTANDING PROGRAMMING LOGIC EASY PROBLEM

MEDIUM PROBLEM

COMPLEX PROBLEM

If A < D Then Print D Else Print A If B < C Then Print C Else Print B End If End If

Do While A < 4 If A < D Then Print B Else Print A If C < B Then If A < B Then Print C Else Print D End If Else Print A End If End If A = A + 1 Loop Print C

Do While B B Then Do While C >= 2 Print C C = C – 1 Loop If A < B Then Print D End If Else Print B If B < C Then If A < B Then Print A Else Print B End If Print C Else Print D If A < B Then Print B End If End If End If B = B + 1 Loop Print C

Figure 7 – Simple Flowchart Solution

PDF created with FinePrint pdfFactory trial version http://www.fineprint.com

23

Flowchart Simulator

Figure 8 – Assignment Statement Edit Dialog

PDF created with FinePrint pdfFactory trial version http://www.fineprint.com

24

Flowchart Simulator

Figure 9 – Sample FLINT Execution

PDF created with FinePrint pdfFactory trial version http://www.fineprint.com

25

Flowchart Simulator

3

Average Score

2.5 2 1.5 1 0.5 0 Simple

FLINT

Medium

Complex

Control

Figure 11 – Program Understanding Results

100% 80% 60% 40% 20%

C

d ea R

al cL oo p Se le ct io n R ec or dO Ac ut cu m ul at or O ut C al c O ut Se le ct Fo ot er

Lo op

el l Sh

op Lo

H

ea

de

r

0%

FLINT

Control

Figure 12 – Solution Generation Results

PDF created with FinePrint pdfFactory trial version http://www.fineprint.com

26

Flowchart Simulator Table 2: Analysis of Solution Generation Elements ANOVA

Report Header Output

Record Processing Loop

Record Input

Record Grade Calculation

Record Letter Grade Selection Record Output

Record Accumulation

Class Grade Calculation

Class Letter Grade Selection Report Footer Output

Between Groups Within Groups Total Between Groups Within Groups Total Between Groups Within Groups Total Between Groups Within Groups Total Between Groups Within Groups Total Between Groups Within Groups Total Between Groups Within Groups Total Between Groups Within Groups Total Between Groups Within Groups Total Between Groups Within Groups Total

Sum of Squares 9.998 7.840 17.838 7.149 10.000 17.149 2.324 15.311 17.635 1.686 7.678 9.365 .424 3.360 3.784 .286 18.160 18.446 2.824 15.662 18.486 1.245 16.160 17.405 2.791 14.844 17.635 3.762 12.454 16.216

df 1 72 73 1 72 73 1 72 73 1 72 73 1 72 73 1 72 73 1 72 73 1 72 73 1 72 73 1 72 73

Mean Square 9.998 .109

F 91.817

Sig. .000

7.149 .139

51.470

.000

2.324 .213

10.929

.001

1.686 .107

15.814

.000

.424 4.667E-02

9.081

.004

.286 .252

1.134

.291

2.824 .218

12.984

.001

1.245 .224

5.549

.021

2.791 .206

13.538

.000

3.762 .173

21.751

.000

PDF created with FinePrint pdfFactory trial version http://www.fineprint.com

27