radius (r) PI is the value 3.14 Set area to PI x r x r Display area
Stop
Is radius > 0? Display messageNo
Yes
Figure 3.9: Example of a flowchart that calculates and displays the area of a circle
A flowchart thus facilitates a conceptual representation of the sequence of significant programming constructs such as input, output, assignments, conditions and looping structures in relation to one another. Consequently, flowcharts support higher level
learning activities in the program domain (Crews 2001). Flowcharts assist novice programmers in following a program’s decision structure (Curtis 1981).
It has been observed that flowcharts, when compared with structured textual programming notation program solution, are useful conceptual tools for assisting novice programmers to better understand abstract problems specifically with respect to solution accuracy and time to completion when generating program solutions (Crews et al. 2002). It was also observed that significant benefits existed with respect to novice programmer confidence and incidence of errors in program solutions. Examples of technological tools that support the flowchart technique are flowchart simulators, namely the Structured
Flow Chart Editor (SFC) (Watts 2003), FLowchart INTerpreter (FLINT) (Crews et al.
1998) and the Rapid Algorithmic Prototyping Tool for Ordered Reasoning (RAPTOR) (Carlisle et al. 2004).
A novice programmer develops a flowchart representation of a program solution using SFC (Watts 2003). An equivalent textual programming notation representation (in C or PASCAL-like programming notation) of the program solution is concurrently displayed. In order to complete the program solution, the novice programmer is required to copy and paste the textual programming notation representation into a text editor and make modifications in the latter environment.
FLINT is a visual instructional programming development environment that makes use of minimal programming notation top-down design flowcharts as visual representations of program solutions (Ziegler et al. 1999). FLINT facilitates the removal of attention from the syntactic details of a programming notation by providing novice programmers with an iconic interface for developing flowcharts (Crews et al. 1998; Garner 2003). Programmers create flowcharts by dragging-and-dropping the flowcharting icons onto a design panel. Timely and helpful feedback is presented to support the learning process by means of automated feedback of the graphical program solution entered. An example of a program solution in the FLINT visual programming development environment appears in Figure 3.10.
The FLINT development environment was specifically designed to provide programmer interaction with solution design activities without the need to interact with a traditional
textual programming notation. FLINT is thus designed for novice programmers and is intended to be easy to use (Crews 2001). The environment is an attempt to address the problems associated with programming notation syntax, problem-solving and support for program solution execution in a unified manner (Crews et al. 1998).
Figure 3.10: FLINT flowchart simulator
The main strength of FLINT is in the role of a support tool for novice programmers within a laboratory learning environment (Ziegler et al. 1999). An evaluation of the use of FLINT with novice programmers suggests that instructional benefits exist for novice programmers who use the interactive flowcharts provided by FLINT to emphasise logic and design early in an introductory programming course (Crews 2001; Crews et al. 2002). There is, however, an argument that FLINT does not have the capability to support a complete range of programming constructs (Garner 2003).
A general argument that is also applicable to FLINT is that flowcharts that are too large to be displayed wholly on a screen offer poor visibility and lead to discontinuities of focus of attention. This is apparent as the novice programmer scrolls the view window to a different part of the flowchart, thereby becoming distracted from the problem-solving process (Blackwell et al. 1999b). Flowcharts themselves, however, have been questioned as being an effective means of aiding program solution comprehension (Waddel et al.
1988; Warren 2003). They are prone to allow too many structural deviations (Meyer et al. 2000) and could thus become just as unstructured as equivalent textual programming notation program solutions (Curtis 1981).
The initial argument against the use of flowcharts had little to do with the flowchart design technique itself and was more concerned with the tediousness involved with maintaining modifications to them manually (Curtis 1981). FLINT, as a flowchart simulator tool, is an attempt to address this issue.
The most recent successor to FLINT, Visual Logic (Crews 2003), continues the support for the development of structured flowcharts to represent program solutions. Testing and debugging of program solutions is supported through a built-in flowchart interpreter, using a graphical trace to step through the flowchart one programming construct at a time. The system supports the exporting of flowcharts to a number of traditional textual- based programming notations. An example of the interface presented by Visual Logic appears in Figure 3.11.
As with FLINT and its successor, Visual Logic, RAPTOR permits novice programmers to compose and execute program solutions within the same development environment (Carlisle et al. 2004). Although both environments support a similar visual programming notation, the difference between the two development environments is that RAPTOR allows novice programmers to compose program solutions incrementally whereas FLINT and Visual Logic enforce composition on program solutions in a top-down fashion. RAPTOR ensures that it is not possible to compose a syntactically incorrect flowchart. In an experiment comparing the performance achievement of novice programmers using RAPTOR with others using a conventional textual programming notation, it was observed that the former group of novice programmers outperformed the latter group25.
Iconic Programming Notations
Iconic programming notations are visual notations where each visual sentence is a spatial arrangement of icons (Chang et al. undated). The notation is based upon a vocabulary of icons where each icon has a specific meaning. Further semantics are conveyed via the spatial arrangement of the icons.
Iconic programming notations attempt to simplify the programming process by reducing the level of precision and manual typing usually required in equivalent textual programming notations to successfully design and implement program solutions in the program domain (Calloni 1998). This type of notation is potentially more intuitive and comprehensible to programmers than conventional textual programming notations because computing concepts are presented in a graphical fashion (Tanimoto & Glinert 1986). Examples of iconic programming notations used by novice programmers in an introductory programming course are the Ben A. Calloni Coding Iconic Interface (BACCII©) (Calloni et al. 1994, 1995, 1997; Calloni 1998) and the SImple VIsual
Language (SIVIL) (Materson et al. 2001). Two other examples of iconic programming
notations that are not discussed further in this section, Youngster (Studer et al. 1995) and
Empirica Control (EC) (Lavonen et al. 2003), have also been successfully used in the
teaching of programming.
25
Programming constructs in BACCII© are represented by means of graphical images. The creation of program solutions is completed by a series of point, click, drag-and-drop actions by the novice programmer (Calloni 1998). The novice programmer is assisted by intuitive screens to construct a syntactically correct flowchart representing the solution to a given problem. A textual programming notation program solution corresponding to the syntactically correct flowchart may be generated upon completion of the construction of the said flowchart (Calloni et al. 1995). Figure 3.12 depicts a program solution in the BACCII++© version 1.50 iconic programming notation.
Figure 3.12: BACCII++© version 1.50 Iconic Programming Environment (Calloni 1998)
Empirical testing has shown a significant improvement in the results obtained by novice programmers in an introductory programming course using the BACCII© iconic programming notation (Calloni et al. 1994, 1995, 1997). A conclusion made by the investigators was that the novice programmers benefited from being exposed to the syntactically correct textual programming notation program solutions generated by BACCII©. This conclusion was due to the fact that the group of novice programmers using only BACCII© outperformed the group using only the PASCAL textual
programming notation with respect to PASCAL textual programming notation specific examinations26.
A negative aspect of BACCII© is the requirement for novice programmers to simultaneously function in two independent programming development environments when converting an iconic program solution to an equivalent textual programming notation program solution. Novice programmers are required to generate equivalent syntactically correct textual programming notation program solutions from a previously implemented iconic program solution from within BACCII©. The textual programming notation program solution must then be compiled, tested and debugged in an independent conventional textual programming development environment (Calloni et al. 1994, 1997; Crews 2001). The result of this feature is that all error messages and debugging requirements are communicated to the novice programmer using the syntax of the conventional textual programming notation rather than the familiar iconic program solution representation (Crews 2001).
Another iconic programming notation, SIVIL, makes use of labelled icons to teach introductory programming concepts (Materson et al. 2001). A visual program solution in SIVIL consists of boxes and arrows to support the control flow paradigm. SIVIL has been proposed as an educational support tool to supplement a traditional textual programming notation.
Based on the preceding discussions on visual programming notations, the following section elaborates on the support provided by such a programming notation in response to the novice programmer requirements derived in Chapter 2.
Visual Programming Notation Support for Novice Programmer Requirements
In a comparison of visual programming notations, it was observed that some forms of visual program solutions are not easy to read (Hansen et al. 1994). The problem is attributed to a lack of standardisation on computational icons and their associated meanings. It was also shown that the use of well selected icons can aid in the
26
comprehension of a program solution while the use of badly selected icons can lead to confusion (Tanimoto et al. 1986; Koelma et al. 1992; Chang et al. 1999). Novice programmers using visual programming notations have, however, illustrated different experiences when using alternative visual programming paradigms.
A study that compares novice programmer comprehension of visual program solutions in one of two paradigms, namely the control flow and dataflow paradigms, suggests that specific properties of visual programming notations result in differences in program solution comprehension (Good & Brna 1999; Good 1999; Oberlander et al. 1999). The control flow paradigm appeared to be associated with faster program task performance, with the dataflow paradigm being associated with the abstract functional descriptions of program solutions. The study by Good et al. (1999) produced evidence that novice programmers were more inclined towards the control flow programming paradigm.
Regardless of the programming paradigm supported, visual programming notations suffer from shortcomings. One major disadvantage of any visual programming notation is that there exists a limitation on the number of visual programming constructs being displayed concurrently on the screen during the development of a program solution (Koelma et al. 1992; LaLiberte 1994; Whitley 1997). This limit is somewhat lower than the restriction existing in a conventional textual programming notation (LaLiberte 1994; Whitley 1997). The impact of this restriction is that visual programming notations could be viewed as impractical if the programming development environment does not allow the viewing of sufficient programming constructs on the screen at the same time (Whitley 1997). Combining the visual programming notation with a textual programming notation in a single program solution has been an attempt to address this limitation (Koelma et al. 1992). A further disadvantage of visual programming notations is that they tend to be less obviously related to natural language (Blackwell 1996).
Despite disadvantages, there exists an argument that a programming notation that uses two-dimensional diagrams and icons is often more easily understood by novice programmers than a conventional textual programming notation (Koelma et al. 1992; Cranor et al. undated). There is also evidence that imagery positively influences the mental representations of programmers when comprehending program solutions (Navarro-Prieto et al. 1999, 2001). Based on the positive effects of imagery in program
solutions, it has been recommended that by adopting a model-based approach using, for example, a flowchart simulator, to teach introductory programming concepts to novice programmers will enhance their ability to think and reason formally, develop program solutions rigorously and conceptually program better (Roussev 2003).
Visual programming notations, however, are still dependent upon some form of syntax (Schiffer et al. 1995). Consequently, translating a large collection of textual programming constructs into a large collection of visual programming constructs merely replaces textual complexity with visual complexity (Freeman et al. 1996; Shannon 2003). In related research, Pandey & Burnett (1993) have concluded that composing a program solution in a visual programming notation is at least as easy as composing one in a conventional textual programming notation.
Requirements for Novice Programmer Technological Support Supported R1: Elimination of finer implementation details typically found
at the superficial learning level of the program domain
9
R2: Increased level of program solution comprehension at the in-
depth learning level of the program domain
9
R3: Increase in level of motivation when using the programming
notation
R4: Designed specifically for use by novice programmers
9
R5: Provision of visual techniques to aid comprehension processat the in-depth learning level of the program domain
9
R6: Support for reduced mapping between the problem and
program domains
9
R7: Increased focus on problem-solving
9
R8: Increase in novice programmer performance achievementmeasured in terms of higher level of accuracy in program
solutions in program domain
9
Table 3.7: Support for Novice Programmer Requirements by Visual Programming Notations
In the context of the preceding discussion on various visual programming notations and their associated programming development environments, Table 3.7 summarises the support provided by visual programming notations as technological support in the
program domain for novice programmers, according to the requirements derived in Chapter 2.
A review of the literature available on the use of visual programming notations in introductory programming courses provides evidence to deduce that the visual programming notation category in the role of programming notation and development environment supports all of the novice programmer requirements except for requirement R3 (Table 3.7).
3.5 Conclusion
Programming tools are important, if not crucial to the programming activity. It is clear from a review of the literature that there exists much dissatisfaction with the manner in which conventional textual programming notations and their associated development environments fail to provide the necessary support for novice programmers (Section 3.3).
Requirements for Novice Programmer Technological Support Supported R1: Elimination of finer implementation details typically found
at the superficial learning level of the program domain
8
R2: Increased level of program solution comprehension at the in-
depth learning level of the program domain
8
R3: Increase in level of motivation when using the programming
notation
R4: Designed specifically for use by novice programmers
8
R5: Provision of visual techniques to aid comprehension processat the in-depth learning level of the program domain
R6: Support for reduced mapping between the problem and
program domains
8
R7: Increased focus on problem-solving
8
R8: Increase in novice programmer performance achievementmeasured in terms of higher level of accuracy in program solutions in program domain
Table 3.8: Support for Novice Programmer Requirements by Conventional Textual Programming Notations
An extensive review of available literature emphasises that conventional textual programming notations fail to support many of the novice programmer requirements (Table 3.8). At the same time, the literature review is unsuccessful to provide evidence of support for any of the novice programmer requirements in the framework derived in Chapter 2. Despite the evidence of discontent, this type of programming notation and development environment remains the most widely used in the learning environment of introductory programming courses.
The amount of dissatisfaction in the use of conventional textual programming notations and their associated development environments is also evident from the many types of alternative programming notations and development environments that have been explored internationally as technological support in the learning environments for novice programmers. There is, however, no evidence of a single type of alternative experimental programming notation and associated development environment being widely accepted for use.
Despite much active research in the area of novice programmer programming notations and development environments over the past decade, it is clear that there remains a requirement for a programming notation to fully support the mental model of the novice programmer, the requirements for which are derived in Chapter 2 (Table 2.1 duplicated as Table 3.1). A novice programmer programming notation should match the task of the novice programmer. This task primarily involves the comprehension and composition of small program solutions. In aiding the novice programmer in this task, the necessary skills for the programming of more complex program solutions are developed.
The programming notation and development environment should strive to be simple by providing support for only the most basic programming concepts and avoid the tendency of complexity found in so many modern textual programming notations and associated development environments. Such a programming notation should be sensitive to the current domain knowledge of the novice programmer and make use of this knowledge as a foundation for creating new programming knowledge, specifically encouraging the skill of “chunking” programming constructs. Finer and mundane implementation details should be separated from the programming concepts and concealed until the novice programmer has developed the necessary skills to manage them with more ease. In so
doing, the programming notation should provide a scaffolding learning environment that allows the novice programmer to gradually educate themselves about the syntax, semantics and applications of the programming notation via the supports provided.
The novice programmer programming notation must encourage the secure comprehension of programming concepts. This can be ensured by means of a rigid programming notation that is easy to read as well as providing facilities for the novice programmer to create a program solution, watch the result of the program solution being executed and read the programming statements that caused the production of the results, all within the same integrated development environment. Studies have shown that flowcharting techniques, being programming notation independent, support higher level learning activities in the program domain and provide instructional benefits by assisting in the comprehension of the decision structure of program solutions.
There is also evidence that novice programmers are suited to a control flow sensory notation, of which a visual programming notation is an example. This observation is strengthened by the fact that an extensive literature review of alternative educational programming notations revealed that the category of visual programming notations is most responsive to the novice programmer requirements derived in Chapter 2 (Table 3.7).
The design and implementation of B# has been influenced by the discussion contained in this chapter. B# is an experimental visual iconic programming notation for novice programmers that is integrated with that of a textual programming notation. The details regarding the design and implementation of B# for use in the current investigation is discussed in Chapter 5.
In preparation for the discussion on the methodology (Chapter 6) applied during the current investigation using the experimental instrument described in Chapter 5, Chapter 4 summarises related research on the selection and placement of introductory programming students. The focus of Chapter 4 is on the results of research used to date by the Department of CS/IS at UPE, since the subjects of this empirical investigation have been exposed to this procedure of pre-selection.