Introductory Programming Technological Support at UPE

Technological support forms an integral part of the learning environment for any introductory programming course. Such a successful learning environment for an introductory programming course is described as one that satisfies the following constraints (Brusilovsky et al. 1994):

• The initial stages of learning to program are supported by a small, simple subset of a programming notation. As new features of the programming notation are learnt, they can be built onto the existing foundation.

• The visual appearance of a program solution structure makes it possible for the novice programmer to comprehend the semantics of the programming constructs introduced and also serves to shield them from misunderstandings.

Technological support in the learning environment of an introductory programming course in the form of visually based programming notations has become possible due to the rapid development in high speed, high resolution, large random access memory (RAM), low cost computers (Calloni et al. 1995). As a consequence of this observation together with the need for a successful learning environment for an introductory programming course, the selection of an experimental programming notation and associated development environment is influenced by a review of existing research (Chapter 3). The experimental technological support identified as being appropriate in the learning environment of an introductory programming course for the purposes of this investigation is classified in the category of visual programming notations (Section 3.4.6).

Visual programming notations and development environments generally minimise the mundane tasks of programming. Forms of this minimalism are ensuring that parentheses match or that lines in a program solution are terminated by a semicolon (Blackwell 1996). Visual programming notations have in the past been described as being potentially more intuitive and comprehensible to novice programmers than conventional textual programming notations because programming constructs are presented in a graphical form (Tanimoto et al. 1986).

The current investigation into programming notations and associated development environments in an introductory programming course focuses on the comparison of a traditional commercial textual programming notation and associated development environment with an iconic programming notation and its associated development environment. Delphi™ Enterprise (Borland 2003), a conventional commercial textual programming notation and development environment is one of the instruments of technological support considered in the delivery of the practical experience necessary for novice programmers in an introductory programming course at UPE (Section 5.2.1). The alternative form of technological support is that of B#, a locally developed visual iconic programming notation and development environment (Section 5.2.2).

5.2.1 Delphi™ Enterprise: A Textual Programming Notation and Development Environment

Delphi™ Enterprise is the programming notation and development environment currently prescribed for the introductory programming course presented by the Department of CS/IS at UPE (CS&IS 2003). The environment is based on the PASCAL programming notation which was originally developed by Niklaus Wirth specifically as an introductory programming teaching tool (Wirth 1971).

Delphi™ Enterprise is based on a simple textual programming notation with a limited grammar. One of the programming notation’s features is that it is easy to learn due to strong data typing and a clear distinction between functions and procedures. An example of the interface provided by Delphi™ Enterprise is illustrated in Figure 5.1. Only those features of the development environment that are emphasised on Figure 5.1 are necessary and used by novice programmers in the introductory programming course at UPE. All other features presented by the programming development environment are superfluous.

Despite the good intentions of the programming notation, the Delphi™ Enterprise programming development environment is an example of an environment to which blame has been partly attributed for the fact that introductory programming courses are perceived as being difficult (Hilburn 1993; Calloni et al. 1997; Warren 2000). One reason cited is that commercial textual programming notations and their associated development

environments (Section 3.3) like Delphi™ Enterprise tend to have been designed for experienced users who are developing large program solutions (Ziegler et al. 1999).

Debugging tools in Delphi™ Enterprise require the use of break points, which are markers placed by the programmer at specific points within a program solution. On execution of the specified sections of the program solution, the tracer is activated. Recognising appropriate programming statements at which to place break points requires the programmer to have a good comprehension of the program solution, the nature of the error present and the possible locations of the error. Furthermore, features such as the watchlist, which permits the values of variables to be displayed as the program solution is executed, are complex to initiate and use, and are often even avoided by more advanced programmers.

Figure 5.1: Borland© Delphi™ Enterprise version 6 Textual Programming Notation and Development Environment

In response to the challenge of increasing throughput in introductory programming courses, the Department of CS/IS at UPE identified the need for the development of an Options to create

a new, open an existing and save

a program solution Program solution editing pane Option to compile and execute a program solution

experimental iconic programming notation, B# (Brown 2001a; Thomas 2002b; Cilliers et al. 2003; Yeh 2003b). B# was deliberately designed to be a short term visual iconic programming notation providing initial technological support in the learning environment of an introductory programming course. A brief overview of B# is presented in the following section with the progress of the design and implementation of this programming notation and development environment being described in Section 5.3.

5.2.2 B#: A Visual Iconic Programming Notation and Development Environment

Based on an intensive literature survey of educational programming notations and development environments (Chapter 3), it was determined that the category of visual programming notations was most responsive to the requirements of a novice programmer (Table 2.1 derived in Chapter 2). Further, it appears as if related international research with respect to the use of an iconic programming notation (BACCII©) in an introductory programming course has been terminated31 after initial empirical studies (Calloni et al. 1994, 1995, 1997). These two observations influenced the choice of category of programming notation on which B# was originally modelled. B# consequently supports a visual programming notation, specifically one that is iconic.

A number of issues need to be considered when designing a visual programming notation and development environment for novice programmers, these issues being summarised below (Chattratichart & Kuljis 2002):

• Different programming notations highlight certain information types while hiding others (Green & Petre 1996).

• In order to reduce the extraneous cognitive load on a novice programmer, there must be a close mapping between the mental representation and the external representation of a program solution (Garner 2001). The closeness of the mapping is determined by a correspondence between the graphical representation and programming task, or a correspondence between programming constructs and the

31

As noted earlier in Chapter 1, no further documentary evidence of follow-up studies since 1997 has been located (Calloni et al. 1994, 1995, 1997). The author of the research, Ben A. Calloni, is currently employed at an institution different to that where the empirical studies were originally conducted (Calloni 2002).

programmer’s preferred strategy. An important element in the improvement of programming education is the support for mental model-building with efficient educational support tools (Astrachan 1998).

• Novice programmers are affected by paradigm difference. Research32

has indicated that novice programmers prefer the control flow paradigm.

• Different representations of the same program solution may require different cognitive effort.

• Graphical representation traversal direction, namely the direction of easiest traversal, for example horizontal or vertical traversal, may affect the cognitive demand on the novice programmers’ comprehension of a presented program solution.

• The comprehension of programming constructs can be enhanced by the appropriate design of the visualisation capabilities of the educational programming notation and development environment (Wright et al. 2000).

Iconic programming notations traditionally attempt to simplify the programming task by reducing the level of precision and manual typing usually required in conventional textual programming notations (Calloni 1998). The associated development environments also attempt to increase the speed at which problem-solving and implementation of program solutions occur.

Many issues were considered during the design and implementation of the experimental iconic programming notation and development environment, B# that was developed in the Department of CS/IS at UPE over a period of 3 years (Brown 2001a, b; Thomas 2002a, b; Cilliers et al. 2003; Yeh 2003a, b; Cilliers et al. 2004b). All successive versions of B# were required to be implemented using only the Delphi™ Enterprise programming notation and development environment. The specific design and implementation issues considered are elaborated on in the following section.

32

(Adelson 1984; Corritore & Wiedenbeck 1991; Good et al. 1999; Good 1999; Oberlander, Brna et al. 1999; Oberlander, Cox et al. 1999; Chattratichart & Kuljis 2000; Chattratichart et al. 2002)

5.3

Development of B#

In defining the scope and functionality of the B# visual iconic programming notation and development environment, decisions had to be made concerning the programming structures and generated textual programming notations that were to be supported. Furthermore the task model had to be implemented in such a way that B# could be used as an effective teaching tool which implements a strategy that emphasises the reading of good examples of program solutions (Fincher 1999; Kolling & Rosenberg 2001).

Iconic programming notations are defined as visual programming notations where each visual sentence in a program solution is a spatial arrangement of icons with each icon having a distinct meaning (Chang et al. undated). Consequently, various interface issues that were considered in the design of B# included the choice of icons to represent the different programming structures, the program solution representation, design of different icon dialogues as well as the screen design.

This section focuses on each of the 6 aforementioned issues considered to be pertinent to the development of B#. The description of each issue is in the format of a report on the design and implementation decisions made during the development of B#. Where appropriate, decisions are supported by citations to related work that influenced the design decision. Deliberation on the design and implementation decisions made appears in Chapter 8.

5.3.1 Scope of B#

The main aim of B# (Brown 2001a, b) is for the provision of a programming notation and development environment for novice programmers that minimises the extraneous cognitive load (Pane et al. 2001). Consequently, B# hides low level programming details and encourages the development of problem-solving and programming development skills (McIver 2000; Sanders et al. 2003a, b). At the same time novice programmers are exposed to automatically generated and syntactically correct textual programming notation program solutions in an integrated development environment.

The programming notation of B# is required to particularly provide support for a small number of powerful, non-overlapping programming constructs. B#, as a first programming notation, is thus limited to support only the foundation programming constructs of sequence, selection, iteration and variables (Mayer 1981; Shu 1985; Blackwell et al. 2000; McIver 2000; Howell 2003; Warren 2003). The effect of this design decision is that many powerful programming constructs are excluded from the B# programming notation in order that the programming notation remain as simple as possible. In this way, it is intended that B# support a programming notation that is easy to learn.

A further exclusion from B# is the representation of primitive arithmetic operations such as addition and subtraction as independent programming constructs. This design decision not only reduces the level of complexity, but also simplifies the functionality of the programming notation.

The intention is not to classify B# as a programming development environment that solely simplifies the generation of textual programming notation program solutions. B# is designed to provide an iconic programming notation in support of a textual programming notation within an integrated development environment that allows novice programmers to easily write, read and watch the effect of program solutions. Furthermore, B# is deliberately designed to be a short term programming notation and development environment to be used in the context of the initial stages of an introductory programming course.

5.3.2 Functionality of B#

Throughout the development of the consecutive versions of B#, the developers of the development environment were constantly aware that novice programmers would be the main users of the programming notation and development environment. A great deal of consideration was consequently given to the design and implementation of the development environment interface as well as the functionality (Cilliers et al. 2003, 2004a, b).

The functionality of B# incorporates provision for support in each of the following areas:

• composition of program solutions; • introductory programming constructs;

• integration with equivalent textual programming notation program solutions; and • appropriate visual feedback on program solution execution.

This section discusses each of the above mentioned areas of functionality, concluding with a presentation of the general task model for composing a program solution in B#.

Program Solution Composition

Novice programmers using the B# programming notation and development environment use a drag-and-drop technique to compose the program solution to a programming problem in the form of a flowchart of icons, with each icon representing a specific and unique programming construct (Section 5.3.4). The program solution representation is thus in the form of a flowchart, with the flowchart being the program solution to which icons can be appended in any order (Blackwell et al. 2001; Mattson undated-b). The flowchart was selected as the visual representation of a program solution in B# since it provided a natural progression from the prescribed methodology used to illustrate problem-solving in the initial stages of the introductory programming course at UPE (Wright et al. 2000).

Variables and constants can be declared as and when needed by programming constructs during flowchart creation in B# (Blackwell et al. 2000). A novice programmer using B# is thus not restricted to the order in which subtasks of the programming task is done.

It has been observed in a recent study conducted by Wright (2002) that multiple representations of a program solution combined with good program solution visualisation support assists novice programmers in building a good mental model of conventional textual programming constructs during the task of programming. In B# the novice programmer would thus be concurrently visually exposed to the equivalent and correct textual programming notation of program solutions generated by the development environment (Mayer 1981; Blackwell et al. 2000).

It has further been observed in various related studies (Mayer 1981; Astrachan 1998; Howell 2003) that when well-defined images are contained in a technical textual notation, novice programmers tend to perform best on recollecting these familiar images and tend to recognise the information in the textual notation associated with the images. The association of generated textual notation program solution extracts with corresponding B# iconic programming notation programming construct images would be required to be supported by B#. B# was, however, required to be robust enough to be used for program solution development without a novice programmer requiring to learn or know the syntax of the textual programming notations supported (Calloni et al. 1994).

The textual programming notation program solution generated by B# is required to always exhibit properties of good programming practice and secondary notation33 to encourage the transfer of textual programming notation knowledge (Cant et al. 1995; Hendrix et al. 1998; Blackwell et al. 2000; Lister 2000; Applin 2001). The requirement for programming knowledge transfer necessitated sensitivity to the equilibrium between shielding novice programmers from all forms of notational syntax and permitting them to learn from their errors.

B# was expected to immediately detect syntactical errors as data is progressively entered by the novice programmer. As a result, the implementation of its own compiler module was essential. Considerable effort was required to be put into the design and development of this module, with a view to make it easily extendible for future programming constructs.

Programming Construct Support

The B# development environment had to ultimately provide for general programming constructs, particularly those required during the initial phase of an introductory programming course at UPE. Time constraints on the development of the first version of the system, however, necessitated a restriction on the number of programming constructs

33

Extra information present in a program solution representation other than formal programming notation syntax. Examples are indentation, colour highlighting and grouping of related constructs. These techniques’ main function are to convey meaning to the human reader, thereby enhancing comprehension of a program solution (Green & Petre 1996).

initially supported (Brown 2001a, b). The programming constructs supported by B# ver. 1.0 appear in the upper blue portion of the list in Table 5.1.

Programming constructs supported by B# ver. 1.0 (Brown 2001a, b)

• Constants and variables of type integer, float, char, string and boolean; • Assignment programming construct;

• Simple conditional programming constructs, restricted to the use of a single branching construct, equivalent to the IF programming construct;

• Complex conditional programming constructs, restricted to the use of a multiple branching construct using multiple nested single branching constructs, equivalent to nested IF programming constructs;

• Iteration or looping programming constructs, restricted to the use of a counting looping construct, equivalent to the FOR programming construct;

• Keyboard input; and • Screen output.

Additional programming constructs supported by B# ver. 2.0 (Thomas 2002a, b)

• Simple conditional programming constructs including the use of a single multiple branching construct, equivalent to the CASE programming construct;

• Looping programming constructs including the use of sentinel looping constructs, equivalent to the WHILE and REPEAT programming constructs;

• Procedures; and • Functions.

Table 5.1: Programming constructs supported by B# (Brown 2001a, b; Thomas 2002a, b)

In its support of the iteration programming construct, B# was required to facilitate both horizontally parallel and temporally dependent forms of iteration. Horizontally parallel iteration is where the outcome of one cycle of an iteration has no affect on the outcome of a subsequent cycle, whereas temporally dependent iteration implies a sequential dependence between consecutive cycles (Mosconi & Porta 2000).

The B# development environment had to be developed and continuously adapted in such a way that future additions of programming constructs could be supported without major difficulties. This requirement was necessary because of the limitations placed on the development of the initial version of B# and the need to use B# in an introductory

programming course requiring future additional programming constructs. The result was that specific consideration was required in the design of a generic internal and external data model that would facilitate this requirement. The successful inclusion of the additional programming constructs listed in the lower green section of Table 5.1 into B# ver. 2.0 by an independent developer determined that the generic data model designed in B# ver 1.0 was effective (Thomas 2002a, b).

Textual Programming Notation Support

The initial B# development environment was required to concurrently produce syntactically correct textual programming notation program solutions in either C++, PASCAL or JAVA forms during flowchart program solution composition. At any time during program solution composition the programmer could select that the textual program solution representation be in an alternative textual form. It would not, however, be possible to view all three textual programming notation forms concurrently. As the flowchart of icons is built, the corresponding textual programming notation is generated simultaneously and is able to be viewed by the programmer.

During the development of B# ver. 2.0, the addition of the procedure and function programming constructs (Blackwell et al. 2000) necessitated the decision to facilitate the generation of three textual programming notations to be revisited. The reason for this is that the textual programming notations of C++ and JAVA implement both procedures and functions in a similar fashion, with procedures being a special type of a function. PASCAL, however, implements procedures and functions as distinct programming constructs. With Delphi™ Enterprise being the prescribed textual programming notation and development environment in the introductory programming course used in the current investigation, a decision was made to restrict the generation of equivalent textual program solution representation to a single programming notation, namely PASCAL.

Visual Feedback on Program Solution Execution

Novice programmers often do not comprehend that a program is a sequence of steps that are executed consecutively (Crews et al. 1998). Programs tend to be viewed by novice

programmers as a collection of programming statements that are executed when necessary. Novice programmers thus neglect to pay attention to the accurate placement of programming constructs within a program solution. Consequently, many misconceptions and logical errors are overlooked due to a lack of sufficient and relevant program solution execution feedback.

In order to encourage the transfer of knowledge from introductory to intermediary