ESTADO PRESUPUESTAL Y EJERCIDO DE OBRA PÚBLICA

Programming is defined as a process of transforming a mental plan of the problem domain that is in familiar terms into one that is more compatible with the computer, namely the program domain (Pane et al. 2001; Mattson undated-a). The problem

domain is the definition of the problem and is generally represented in an abstract form. The program domain is the representation corresponding to the solution of the presented problem in some programming notation. Novice programmers are those computer users who typically have little or no experience in the program domain (Mayer 1981; Sutherland 1995).

The theory of learning to program emphasises the interaction between the novice programmer’s conceptual model of the problem domain together with the programming notation and associated development environment in the program domain, where a conceptual model is defined as the understanding of the scenario described (Shih & Alessi 1993). It is generally accepted that programmers construct complex hierarchical conceptual models of the problem domain that represent similar structures in the program domain (Toombs 1987). The construction of conceptual models of the problem domain is categorised as intrinsic cognitive load (Garner 2001).

The intrinsic cognitive load evident in novice programmers is high (in terms of large amount of effort required), and is, unfortunately, not directly subject to modification by the use of technological support in the teaching model of an introductory programming course. In contrast, extraneous cognitive load is subject to modification in the teaching model of an introductory programming course. Extraneous cognitive load comprises of the interaction with the programming notations and associated development environments forming the instructional format used in the teaching and learning process in the program domain. Extraneous cognitive load should thus be lowered in order to minimise the total cognitive load of a novice programmer learning to program (Garner 2001).

The extraneous cognitive load can be reduced for a novice programmer by a programming notation and development environment being sensitive to the way in which a novice programmer functions in the program domain, defined previously. A novice programmer functions on two levels of learning when implementing solutions in the program domain, namely at the superficial and in-depth levels of learning (Mayer 1981; Perkins et al. 1988; Carter et al. 2001; Jenkins 2002). Superficial learning is characterised by novice programmers memorising programming concepts

for automatic future use. The other level of learning, in-depth learning, requires comprehension of the effects of programming concepts so that they can be applied in the future implementation of solutions. In-depth learning is often the source of confusion for novice programmers (Shneiderman 1983).

An overview of the problem domain of novice programmers focussing on the format of the conceptual model constructed by a novice programmer in the problem domain is provided (Section 2.2.1). The limitations evident in the conversion by novice programmers of the conceptual model in the problem domain to a solution in the program domain are identified. A detailed discussion of the program domain of novice programmers (Section 2.2.2) focuses on novice programmer experiences of the superficial and in-depth levels of learning.

2.2.1 Problem Domain

The problem domain conceptual model for any problem typically consists of dataflow and task knowledge (Ramalingam et al. 1997). Dataflow knowledge is concerned with the transformations which data items undergo, consequently being fundamental to the goals of the tasks of a corresponding program domain representation (Shih et al. 1993; Wiedenbeck et al. 1999). Even though all programmers experience intrinsic cognitive overload, it remains particularly difficult for novice programmers since they have not yet developed strategies to reduce and effectively manage the intrinsic cognitive load. Consequently, novice programmers may not detect losses of information from working memory, thereby neglecting small but important portions of the problem domain (Spohrer et al. 1986). An appropriate and precise conceptual model representing the novice programmer’s conceptual understanding of a specified problem is therefore necessary before an accurate conversion to the program domain can be made.

Performance in the problem domain can also be affected by the way in which a problem is presented and phrased (Whitley 1997). Novice programmers frequently do not translate a given problem into a conceptual model that is independent of the original external representation, namely the presented problem. The external representation of a problem can therefore restrict the internal conceptual model

representation. Furthermore, novice programmers will not necessarily use efficient conceptual models to represent problems (Petre & Blackwell 1999). The type of conceptual model typically used by novice programmers in programming exercises is indicative of the level of confidence experienced by the novice when learning to program.

The types of conceptual models have been observed to prominently feature the use of diagrams as notation and structure in the interpretation of programming problems by non-programmers (Pane et al. 2001). The visual imagery typically appeared early during the problem-solving process. In related studies of the conceptual models used for learning control constructs in programming problems, it was also evident that figures featured prominently during the initial analysis of a problem (Green 1997; Ginat 2001). Visual conceptual models as opposed to verbal conceptual models were the preferred medium by subjects in another related study (Shih et al. 1993).

The results of the aforementioned studies and others (Dillon et al. 1994; Astrachan 1998) support early evidence (Mayer et al. 1986) that success in learning to program is related to the problem representation skill of diagramming. It can thus be concluded that the conceptual models of programmers within the problem domain tend to feature visual imagery as opposed to textual imagery. The acknowledgement of this factor is applicable in the selection of an appropriate technological support in the learning environment of an introductory programming course (Chapter 5).

Appropriate training and support in the learning environment of introductory programming courses can assist novice programmers in the construction of effective conceptual models which provide appropriate representations of the states and relationships of data elements within the problem domain (Ben-Ari 1998, 2001; Dagdilelis et al. 2002). Using these conceptual models, the misconceptions of novice programmers are reduced and the novices thus perform tasks more like expert programmers, especially in the conversion process from the problem domain to that of the program domain (Shih et al. 1993).

In a review of studies of novice programmers using textual programming notations, one of the most prominent problems was identified as the limitation on the closeness

of the mapping of the problem domain to the program domain and the use of unfamiliar terminology (Pane & Myers 2000). The finding was also evident in an earlier related study conducted by Perkins et al. (1988) where it was found that the formal context of the program domain might have hindered the transfer of problem- solving skills (problem domain) to be practiced in programming a solution to a problem (program domain).

The observations just presented support the fact that novice programmers are perhaps able to determine what needs to be done when solving a problem, but often are confused only about how to convert and convey that requirement in a specific programming notation in the program domain (Bonar et al. 1983). Attempts to compensate for this limitation include the situation where introductory programming educators design learning activities that explicitly encourage and support the correct and appropriate conversion from problem domain to program domain (Shih et al. 1993).

In order to perform the conversion from problem domain to program domain successfully, a novice programmer must concurrently master the skills of syntax, semantics, structure and style of the specific programming notation being used for accurate implementation in the program domain (Studer et al. 1995; Proulx et al. 1996; Carter et al. 2001; Jenkins 2002). The majority of these skills, which form a substantial part of the discussion in the following section, are furthermore required to be mastered at a high level of accuracy (Lischner 2001; Pane et al. 2001; Jenkins 2002).

2.2.2 Program Domain

Learning to program using a specific programming notation is one of the first and most fundamental ways to learn about the functionality of computers, thus computer programming has been the major focus of most computer introductory courses (Urban-Lurain & Weinshank 2000). Program solution generation in a programming notation has consequently become one of the primary skills desired as an outcome of an introductory programming course. Therefore, the specific practice of program

solution generation is recommended in order to cultivate programmers skilled in the writing of computer program solutions (Shih et al. 1993).

The writing of computer program solutions can be viewed as a type of symbolic encoding (Toombs 1987) and is a formal task requiring a high level of accuracy (Lischner 2001; Pane et al. 2001; Jenkins 2002). Programming is learnt by a novice programmer in two ways, namely at the superficial level and the in-depth level (Mayer 1981; Perkins et al. 1988; Carter et al. 2001; Jenkins 2002). The superficial level which typically precedes the in-depth level, incorporates techniques of memorisation in the representation of problems in the program domain. In contrast, the in-depth level requires the comprehension of programming constructs used in the program domain, with a view to the composition of novel solutions to programming problems.

One of the objectives of an introductory programming course is to produce programmers who will be able to create original solutions to problems (Mayer 1981; Shih et al. 1993). Consequently, novice programmers are expected not to merely be proficient in a specific programming notation at the superficial level, but to exhibit expertise at the in-depth level of the program domain (Lockard 1986; Kushan 1994; Studer et al. 1995; Proulx et al. 1996; Dingle et al. 2001; McCracken et al. 2001; Jenkins 2002). This section thus focuses on the characteristics of the superficial and in-depth levels of learning, these being the components of the program domain.

Superficial Level of Learning

The superficial level of learning in the program domain is characterised by attention to finer detail and typically occurs at a low level of abstraction (Ramalingam et al. 1997; Wiedenbeck et al. 1999). Mastering of the superficial level is evident in the accurate and correct application of the lexical and syntactical rules of a particular programming notation. Both the lexical and syntactical rules of a particular programming notation can be accurately memorised with minimum effort by novice programmers for application in solutions to programming problems.

In order to master the lexical and syntactical rules of a programming notation, the novice programmer must be sufficiently knowledgeable in the use of the individual programming notation operations and their associated grammatical restrictions to produce program solutions that are of the correct format for the programming notation being used. This involves the correct combination of program statements using the available programming notation operations in the correct sequence (Howe 2003). The rigidity of the requirements for evidence of successful superficial learning in the program domain does, however, possess the potential to hinder the overall progress of learning to program for novice programmers, especially during the composition of novel solutions to problems.

Conventional textual programming notations traditionally used in introductory programming courses require absolute accuracy in the representation of the format of a program solution in the program domain. The precision of the programming notation’s lexical and syntactical constraints must be in place before any evaluation of the actual program tasks corresponding to the conceptual model of the problem domain can take place. The ultimate task of having a functioning program at the in- depth level is thus delayed until such time as the program satisfies all of the lexical and syntactical constraints of the programming notation being used at the superficial level. The following discussion illustrates the potential for a delay in the process of learning to program with respect to the level of accuracy required in the syntax of a textual programming notation.

Figure 2.1: Textual programming notation fragments: Syntax if (num > 10) then

write(‘More than 10’)

else

write(‘Not more than 10’);

writeln;

if (num > 10) then

write(‘More than 10’);

else

write(‘Not more than 10’);

writeln; Syntactically correct fragment Syntactically incorrect fragment Offending statement separator

Figure 2.1 illustrates two textual programming notation program solution fragments. They are a correct syntax (top) and incorrect syntax (bottom) for a conditional statement in the commercial textual programming development environment Delphi™ Enterprise using the PASCAL textual programming notation. Even though the fragments are visually very similar, the subtle incorrect placement of the statement separator, the semicolon (;), in the bottom fragment results in a syntactical error being detected by the textual programming notation compiler. In fact, the compiler highlights the line containing the else statement and displays a message similar to

';' not allowed before 'ELSE'. There is, in fact, no ; before the else statement. The offending ; occurs in the previous line which is not directly highlighted as containing an error. The novice programmer is thus alerted to the incorrect line of the program solution.

The potential thus exists that a novice programmer will not speedily detect the offending semi-colon, especially within a larger and more complex program solution fragment, thereby delaying the progress of constructing a functioning solution representation in the program domain.

The potential consequences of the aforementioned scenario are aggravated by the fact that supporting texts for introductory programming courses typically focus on the instruction of the syntax of textual programming notation constructs (Hennefeld & Burchard 1998; Williams & Walmsley 1999; Kerman 2002). The novice programmer is encouraged to view the result of the programming process as being the textual program solution itself. Attention to detail at the superficial level is perceived by novice programmers as the focus of the problem-solving process (Soloway 1986; Hilburn 1993; Wiedenbeck et al. 1999).

Novice programmers may consequently quickly acquire an understanding of the lexical and syntactical constraints of a programming notation, yet this narrow focus of exclusive memorisation can result in a novice programmer missing the broad function of the solution representation in the program domain (McIver 2000). The effect is that the program logic content that is learned at the superficial level can rarely be

effectively transferred because of a lack of conceptual understanding of the underlying tasks of the program solution (Jonassen 2000).

Using the superficial learning approach exclusively, novice programmers are consequently not able to relate the programming constructs in a program domain representation to an understanding of how the desired results were produced (Mayer 1981; Liffick et al. 1996). A comprehension of the higher level effects of programming constructs within a solution representation in the program domain empowers a novice programmer to construct novel solutions to similar problems (Spohrer et al. 1986; Ginat 2001; Mattson undated-a). Such comprehension and transfer is evidence of in-depth learning in the program domain, which is the focus of the next subsection.

In-depth Level of Learning

In the process of learning to program, the novice programmers’ comprehension of the effects and implementation of individual programming constructs is the abstract understanding that complements the superficial level of learning in the program domain. The successful transference and application of the comprehension of programming constructs to new but similar problems is evidence of achievement in the in-depth learning level of the program domain (Mayer 1981; Shih et al. 1993; Wiedenbeck et al. 1999).

An effect of a low level of conceptual understanding in novice programmers is that they neglect to successfully transfer existing programming knowledge and consequently approach each problem as if it was unique (Urban-Lurain et al. 2000). Novice programmers thus require strategies to enable them to view a current problem in terms of previously encountered problems, so that known solution strategies can be transferred to the current problem (Soloway 1986; Perkins et al. 1988; Jonassen 2000). The application of this in-depth learning in the program domain is a reflective process, in contrast to the reflexive process of the application of superficial learning, and is evidence of successful problem-solving in the program domain.

During the development of in-depth learning, novice programmers are required to comprehend existing solutions in a particular programming notation. The comprehension process typically occurs in two successive phases (Navarro-Prieto & Cañas 1999). During the first phase the novice programmer develops an understanding of the control flow of the solution in terms of the structure of the solution and outcomes of individual programming constructs making up the solution. The second phase is a determination of the transformation procedures and tasks applicable to data elements of the problem, known as dataflow comprehension. The latter phase is classified as comprehension at a higher level of abstraction and is thus experienced as being the more difficult of the two phases.

Each of the control and dataflow comprehension phases is discussed in turn. If the necessary support in the learning environment that encourages successful in-depth learning is lacking, novice programmers might develop a conceptual understanding of the control and dataflow of solutions which is ineffective and flawed (Ben-Ari 2001), ultimately resulting in misconceptions. This trait has been identified as one of the greatest obstacles novice programmers face in learning to program (Shih et al. 1993; George 2000). For this reason, the subsection concludes with a description of the requirements for educational support of in-depth learning in the program domain.

Control Flow Comprehension

Comprehension of the control flow of a program solution results in a knowledge structure representation of how the program functions (Navarro-Prieto et al. 1999) and is usually as a result of reading an existing programming notation solution with evidence of pre-existing superficial learning (Ramalingam et al. 1997). Typical examples of control flow concepts are looping and branching programming constructs, as well as the ordering of individual programming constructs in relation to one another, also referred to as program structure.

Novice programmers who master the comprehension of the control flow of existing solutions in a particular programming notation in the program domain are able to provide evidence of understanding the outcome of each individual program statement in the solution (Mayer 1981). They have thus successfully learnt both the syntactical

and semantical constraints of the programming notation, as well as appropriate program structure (Shih et al. 1993; Deek 1999; Howe 2003).

Figure 2.2 and Figure 2.3 illustrate effects of applied misconceptions related to control flow comprehension. Figure 2.2 shows two sample PASCAL textual programming notation program solution fragments, each being syntactically correct. The program solution fragments are attempts to solve the problem to display an appropriate message depending upon the value of the variable mark. The upper program solution fragment illustrates the use of PASCAL textual programming notation programming constructs in a correct semantic interpretation. The lower program solution fragment will not work correctly should the variable mark take on a value less than 50. Due to an erroneous interpretation of the semantics of the PASCAL textual programming notation conditional statement in the lower program solution fragment a logical error is introduced into the program solution.

if (mark < 50) then writeln(‘Fail’) else if (mark < 75) then writeln(‘Pass’) else writeln(‘Distinction’); if (mark < 75) then writeln(‘Pass’) else if (mark < 50) then writeln(‘Fail’) else writeln(‘Distinction’);

Figure 2.2: Textual programming notation fragments: Semantics

Similarly, in order to master the structure of a programming notation, the novice programmer is required to comprehend the restrictions placed on the order of programming notation statements in relation to one another. Students often do not see a textual program solution as a sequence of steps that must be executed one at a time (Crews et al. 1998). They tend to view program solutions as a collection of

This statement will never be executed Semantically and syntactically correct fragment Semantically incorrect; syntactically correct fragment

statements that execute when necessary, and thus do not pay attention to the correct and exact placement of statements within a program.

Figure 2.3 illustrates the effect of structure comprehension by means of two sample PASCAL textual programming notation program solution fragments, each of which exhibits syntactically correct textual programming notation statements. The program solution fragments are attempts to solve the same problem described for Figure 2.2