A case study in an integrated development and problem solving environment.

This article describes an integrated problem solving and program development environment, illustrating the application of the system with a detailed case study of a small-scale programming problem. The system, which is based on an explicit cognitive model, is intended to guide the novice programmer through the stages of problem solving and program development, from problem formulation, planning, and design, to testing and delivery. Students learn problem solving and the elements of software engineering because of the way in which both methodologies are explicitly embedded in the system. The case study illustrates how systemic, cognitively-based dialogs facilitate the problem solving and program development tasks, while the overall architecture of the system continually re-enforces an understanding of software engineering methodology. An initial version of the system has been integrated into an introductory course on computing, and evaluated in terms of its effect on student learning.

**********

A primary motivation behind developing educational computing systems is to improve students' ability to learn independently. Beginning students face several challenges when learning programming: (a) deficiencies in problem solving strategies and tactical knowledge; (b) misconceptions about syntax, semantics, and pragmatics of language constructs; and (c) ineffective pedagogy of programming instruction. Tools and environments have already been created and implemented that assist independent learning in the domain of programming. However, after a comprehensive review of computer-based systems for learning programming, Deek and McHugh (1998) concluded that such environments devote a disproportionate amount of attention to syntax-related activities, leaving the preliminary tasks of problem definition, requirements, and specifications insufficiently addressed.

Deek and McHugh (1998) identified four categories of systems or tools developed to help students learn programming: (a) programming environments, (b) debugging aids, (c) intelligent tutoring systems, and (d) intelligent programming environments. They further contended that these systems are limited in two basic respects, functionality and practicality. Functionally, most of these systems do not provide problem solving/software engineering frameworks, and lack facilities to assist students in performing problem formulation, planning, design, and testing of solutions. There is an emphasis on implementation aspects of software development, resulting in an overemphasis on language syntax. Also, classroom experience indicates that the complex interfaces of these systems frustrate students. Intelligent systems are either rule or knowledge-based and so are inherently "incomplete," as it is impossible to assume that all rules or knowledge regarding a particular problem situation are represented. Their problem domains are correspondingly simple since for the intelligent tools to behave as experts, they must anticipate all options and require the use of simple examples. Basically, the intelligent tools impose constraints on the structure of a student's program to assure that a certain solution is found, thus impeding students' creativity and their development of cognitive skills.

Practically, there are few reports on the evaluation of tools or their integration into the classroom. This leaves important questions open: Are the tools' characteristics driven by actual classroom needs? What are the effects of these systems on students? An attempt to answer these questions is handicapped because many of these systems remain prototypes. The effectiveness of these tools and environments has yet to be ascertained because of limited classroom evaluation, while the absence of such significant evaluation stymies their integration in the classroom. There have been reports on positive evaluation of such environments (Guzdial, Hohmann, Konneman, Walton, & Soloway, 1998; Deek, 1997), but given the difficulties that students experience with programming, it is fair to conclude that the teaching and learning of programming would profit from continued investigation, application, and evaluation of new approaches and new tools.

Existing research, as indicated earlier, demonstrated that students experience three kinds of challenges when learning programming, especially the first language: (a) problem solving deficiencies, (b) syntactical/semantic difficulties, and (c) ineffective pedagogy. The authors summarize the issue here and refer to their earlier work for a more complete discussion (Deek, 1997; Deek & McHugh, 1998). The ability to solve a problem requires aptitudes beyond the syntax and semantics of a programming language (Mayer, 1981; Perkins & Martin, 1986; Perkins, Hancock, Hobbs, Martin, & Simmons, 1986; Spohrer & Soloway, 1985; Rist, 1986; Johnson, 1990; Navarat & Rozinajova, 1993; Weidenbeck, Fix, & Scholtz, 1993; Ebrahimi, 1994; Ennis, 1994). The lack of basic problem solving competence and thinking skills is a prominent problem with novice programmers. Errors in students' programs are commonly related to deficiencies in problem solving strategies and insufficient planning and design (Hohmann, Guzdial, & Soloway, 1992; Spohrer, 1992; Scholtz & Weidenbeck, 1992 & 1993; Anjaneyulu, 1994; Guzdial, Hohmann, Konneman, Walton, & Soloway, 1998). Both problem solving competence and understanding of the syntax, semantics, and pragmatics of a programming language constitute the foundation skills required to compose, comprehend, reuse, integrate, debug and test, modify and document programs, and students often do not appear to understand the purpose, structure and use of the programming language constructs they study (Soloway, Ehrlich, Bonar, & Greenspan, 1982; Bereiter & Scardamalia, 1985; Perkins & Martin, 1986; Johnson, 1990; Ebrahimi, 1994). Moreover, those studies that uncover novice difficulties with syntax conclude that more emphasis is needed in teaching planning and design strategies (Soloway, Ehrlich, Bonar, & Greenspan, 1982; Hohmann, Guzdial, & Soloway, 1992). Shackelford and Badre, (1993) suggested that current pedagogy is misdirected, and that students are not taught the skills necessary to discern between design and implementation. This article describes the cognitive basis and application of Specification Oriented Language in Visual Environment for Instruction Translation (SOLVEIT) through a detailed case study and discusses the impact of SOLVEIT on the problem solving and program development skills of a group of computer science students based on the results of a controlled experiment study (Deek, McHugh, & Hiltz, 2000).

COGNITIVE MODEL OF SOLVEIT

SOLVEIT provides a problem solving and program development environment designed to support beginning programmers. The software architecture of SOLVEIT was described in Deek and McHugh, (2000). The objective of SOLVEIT is to provide a methodological framework and support infrastructure to guide students through the problem solving and program development process from problem formulation, to planning, design, testing, and delivery. Support for the translation stage is provided by existing programming environments. The need for such conceptual structure is well established (Pea & Sheingold, 1987).

SOLVEIT is based on extensive research on tools and methods for learning programming which underscores the interdependent nature of the tasks of problem solving and program development and indicates the need for an integrated methodology (Mayer, 1983; Scholtz & Wiedenbeck, 1992; Ebrahimi, 1994, Deek, Kimmel, & McHugh, 1998; Deek & McHugh, 1998). Each stage of the SOLVEIT process relies on specific cognitive abilities, as demonstrated by the complementary research on the cognitive skills required for learning programming (Weinberg, 1971; Shneiderman, 1980; Mayer, 1988; Hoc, Green, Samurcay, & Gilmore, 1990; Lemut, du Boulay, & Dettori, 1993). SOLVEIT synthesizes the methods for problem solving and program development (Deek, 1999) with an explicit model for the cognitive activities, knowledge and skills required for the tasks of problem solving and program development. We call the resulting integrated model: the Dual Common Model for Problem Solving and Program Development (Deek, 1997).

Problem solving tasks predominate in the earlier stages of the dual common model and include formulating the problem, planning, and designing the solution. Program development tasks dominate the later stages of the dual common model and include translating, testing, and delivering the solution. The activities of program development range from simple data representation, algorithm design, development, and coding, to more complex activities requiring additional skills and knowledge (Dijkstra, 1976; Boehm, 1976 & 1988; Pressman, 1987; Page-Jones, 1988). Programmers must develop additional skills including composing new programs; comprehending, reusing, and integrating existing programs; debugging programs; developing test data, and testing solutions; and modifying and documenting programs.

Every one of the tasks of problem solving and program development is highly dependent on cognitive skills and knowledge. Domain knowledge, and strategic and communication skills predominate in problem solving (Duncker, 1945; Polya, 1945; Newell & Simon, 1972; Rubinstein, 1975; Mayer, 1983). Additional organizational and metacognitive skills, as well as syntactical, semantic, and pragmatic knowledge are needed in program development (Wirth, 1971; Shneiderman, 1980; Rogalski & Samurcay, 1990, 1993.)

The models of problem solving extensively reviewed in Deek (1997) focused explicitly on the process of problem solving but only implicitly on the cognitive skills and knowledge required to accomplish these tasks. They did not specifically identify the corresponding cognitive support for these tasks. To do this, an explicit cognitive model must be developed. A cognitive model for problem solving should identify the cognitive processes that problem solvers use, the cognitive structures or systems that support these processes, and the cognitive results and effects on cognition of the problem solving process. The authors propose a model that has three elements: (a) a set of cognitive processes based on Bloom (1956), which is an extensively referenced model of thinking; (b) a cognitive structure based on Sternberg's (1985) well-known model of the human information-processing system, which postulates the cognitive systems presumed to underlie Bloom's cognitive processes; and (c) Gagne's (1985) identification of the cognitive results, outcomes and effects of these processes. Figure 1 identifies the cognitive activities, knowledge, and skills for each problem solving and program development stage in our model. Figure 2 gives a detailed outline of the problem solving and program development tasks. The following section provides an expanded view of this dual common model.

[FIGURE 1 OMITTED]

[FIGURE 2 OMITTED]

The first stage of the cognitive model is problem formulation. It requires domain knowledge and problem modeling skills to perform activities as indicated in the first block of Figure 1. If the problem involves interaction with the user for requirement analysis, then this stage also involves communications skills. The identification of knowledge through information gathering techniques and the representation of this knowledge are the primary requirements of this stage; combining this with domain knowledge leads to problem comprehension and knowledge acquisition, important cognitive processes (Bloom, 1956). The underlying cognitive structures are the knowledge acquisition processes used to acquire and integrate knowledge (Sternberg, 1985) for subsequent planning, design, and implementation activities. The cognitive outcome is the verbal information that confirms problem understanding and identification of facts essential at this stage (Gagne, 1985). The result of this first stage is a structured model of the problem (Mitroff & Turoff, 1973; Benbasat & Taylor, 1982; Pylyshyn, 1984; Rogalski & Samurcay, 1993).

The first block in Figure 2 shows how these cognitive activities are realized. Thus, the cognitive objective of a preliminary problem description is realized by constructing a well-defined description through progressive refinement and elaboration of the given problem statement, including written description, diagrams, mathematical formulation, and so forth. The preliminary mental model is obtained by refining the problem description using inquiry questions. Finally, a structured representation is obtained by extracting and organizing the relevant information (goal, givens, unknowns, conditions, constraints, resources, etc.) from the problem description (Hayes & Simon, 1976; Greeno, 1978; Simon, 1978; Mayer, 1983; Espinasse, 1994), a process we call information elicitation (Deek, 1997).

The second stage of the cognitive model is solution planning. It requires domain knowledge, problem-specific knowledge, and strategic skills to perform the activities indicated in the second block of Figure 1. Planning requires general problem solving strategies to discover and assess solution alternatives and produce a plan for the problem (Greeno, Collins, & Resnick, 1996). The application of knowledge, which involves problem analysis and decomposition or breaking the problem into component parts (Bloom, 1956), is the key requirement of this stage. The most relevant cognitive structure is the performance component which directs the solution planning, alternative evaluation, and the problem decomposition process (Sternberg, 1985). An important cognitive outcome of this stage is the intellectual skills that demonstrate the ability to apply knowledge (Gagne, 1985), which confirms its understanding (Moore & Newell, 1973). Outlining the steps necessary to reach a solution in turn demonstrates the ability to use facts, concepts, theories, or principles to plan a solution.

The second block in Figure 2 shows how these planning activities are realized. A strategy is discovered by first identifying alternative solutions using heuristics such as solving simpler, related or analogous problem. For example, in solution by analogy, correspondences between the current problem and related, previously solved problems are exploited, with similarities and differences between the problems providing hints to generate alternative strategies for the current problem, one of which, after evaluation, is selected (Polya, 1945). In goal decomposition, the original goal is decomposed into a collection of intermediate subgoals, based on the strategy selected; these are then decomposed into sub-subgoals, and so on (Duncker, 1945; Newell & Simon, 1972; Wickelgren, 1974; Rubinstein, 1975; Mayer, 1983). Data modeling, based on goal decomposition, is accomplished by organizing and associating with each subgoal its givens and unknowns.

The next stage of the cognitive model is solution design and it requires the same knowledge and skills as the planning stage, as indicated in the third block of Figure 1. The major cognitive activity at the solution design stage is synthesis, or the reintegration of interrelated components into a coherent whole. It refines and rearranges components when necessary, establishing a hierarchy, which organizes the problem into its parts and sub-parts, and producing a new and well-organized whole as a viable solution to the problem (Bloom, 1956). The most relevant cognitive structure is still the performance component, which in addition to directing the decomposition process, is concerned with the identification, selection, organization, and sequencing of these tasks (Sternberg, 1985). An important cognitive outcome of this stage is strategic ability demonstrated by the ability to specify detailed solution design (Gagne, 1985).

The third block in Figure 2 identifies the associated design tasks. First, the high-level plan produced by the preceding planning stage is refined. This involves the sequencing of subgoals, the determination of whether the subgoals require further decomposition, and the establishment of hierarchical relationships among the various solution components. The sub-components are now viewed as modules whose functions must be specified and the data associated with these modules (input, output, intermediate data) are more formally represented. A final detailed design task transforms each subgoal into a corresponding algorithmic specification (Wirth, 1971; Rogalski & Samurcay, 1990, 1993; Bertels, 1994).

The fourth stage of the cognitive model is solution translation and it requires, in addition to the knowledge and skills of the previous stage, additional organizational, syntactical, semantic and pragmatic skills as indicated in the fourth block of Figure 1. The major cognitive activities at the solution translation are application and knowledge, synthesis, and organization. This requires the ability to maintain and access previously generated and organized knowledge (Bloom, 1956). The relevant cognitive structures are the knowledge acquisition component and the performance component, which here are concerned with the execution of a planned design, knowledge organization, and access (Sternberg, 1985), which are essential for syntactical and semantic information. An important cognitive outcome are the intellectual skills required for logical or deductive ability (Gagne, 1985), demonstrated by the diagnostic analysis of programming errors.

The tasks required to realize these solution translation activities are shown in the fourth block of Figure 2. This is a syntax-related stage, where the student makes the transition into the programming language environment. Organizational skills such as creating and maintaining an orderly development environment are critical. The design specification performed in the previous stage forms the basis for mapping module specifications from algorithmic logic into correct programming language syntax and is the major objective of this stage. In addition to composing new code, program development also entails comprehending, reusing, and integrating existing code, when possible. Finally, considerable logical and deductive skills are required in order to diagnose and correct syntax error.

The fifth stage of the cognitive model is solution testing and it requires similar cognitive skills to the previous stage, but with the addition of metacognitive skills as shown in the fifth block of Figure 1. The major cognitive activities at the solution testing stage are critical analysis, evaluation, and revision (Bloom, 1956). The relevant cognitive structure is the metacognitive component, concerned with monitoring the thinking process and evaluating the solution (Sternberg, 1985). An important cognitive outcome is a self-critical attitude (Gagne, 1985), the ability to critically assess one's own thought processes (self-appraisal) as well as ones' own intellectual creations.

The corresponding tasks for solution testing are shown in the fifth block of Figure 2. In a software environment, testing entails the generation of test cases on the basis of problem requirements and certifying that the proposed solution satisfies the test results. Test generation itself is a nontrivial activity. It may require considerable creativity in the first place to recognize an appropriate test suite even for a very elementary problem. It may often require careful judgment to select the most important cases from a possibly large domain of test cases, which may have to be pruned. Test results must be tested not only for correctness and completeness, but also performance oriented criteria such as efficiency, reliability, readability, usability, and so forth. Modification to the implementation, strategy or even problem formulation may be required on the basis of testing. In addition to product testing, process evaluation, and feedback is also an integral part of the problem solving methods. Process exit review is a customary activity at this point.

The sixth stage of the cognitive model is solution delivery and it requires organizational and communication skills. The problem solving and program development cognitive activities will be completed by this stage and no further problem transformations will be required. The information produced during the course of previous stages has to be organized, presented, and possibly disseminated as shown in the sixth block of Figure 1. The documentation of the solution strategy, code, and test results is the first task in block six of Figure 2. In the case of large or group projects, the results may have to be orally presented. Moreover, for some projects it may be appropriate to disseminate the information to an appropriate community of interest, a task made both more feasible and more important by the availability of Internet technology.

APPLICATION OF SOLVEIT: A CASE STUDY

The SOLVEIT environment provides an integrated set of tools to support the process of problem solving in problem formulation, planning, designing, testing, and delivering the solution, while the existing complementary tools of traditional programming environments (i.e., syntax editors, compilers, debugging utilities) facilitate the translation process. This section describes the functionality provided by SOLVEIT using a detailed case study. It traces the functionality and interaction provided by the tools for each problem solving and program development task.

Figure 3 shows the tools relevant to each stage of the process. Some of the tools are general-purpose, and are shared by the entire SOLVEIT environment; others are associated with the specific stages of the process and facilitate various tasks of problem solving and program development. The task-specific tools are described in the case study. There are four general-purpose tools: (a) a reference database, (b) a system project recorder, (c) a project notebook/graphics editor, and (d) an algorithmic constructs toolbox. These tools provide support for each stage of the process.

[FIGURE 3 OMITTED]

The outcomes of each stage are stored in a reference database for access in subsequent stages. The reference database contains the result of all data transformation within SOLVEIT, beginning with entering problem description through the development of the algorithmic solution. The database organizes this information and makes it available to SOLVEIT and the student in subsequent stages of the problem solving process.

Dynamic information is logged to a system project recorder where it is maintained for access during and after the problem solving session. The recorder monitors the student's activities within SOLVEIT and acts as an event-capture log, allowing the student and teacher to later replay the activities of a problem solving session, including a transcript of all interactions (questions, verbalizations, etc.). Each time the student enters a stage within SOLVEIT, the event and the task performed are recorded. Snapshots of the reference database, built by various stages of the process, are also copied to the recorder as the student advances through SOLVEIT. An activity log which lists the sequence in which students enter and exit SOLVEIT stages (perhaps repeatedly) is also maintained. The recorder can be used by the instructor to evaluate the student's thinking process and approach to problem solving, and can be examined by students to retrace their progress toward the solution.

The students also have access to a project notebook/graphics editor that can be used to write notes, record ideas, test possibilities, draw diagrams, and introduce notations to represent aspects of the solution as the student deems necessary. The student is prompted to invoke the editor during the problem formulation stage, but it can be invoked at any time during the problem solving process.

The algorithmic constructs toolbox is a tool for pseudocode specification of algorithms. It uses a toolbox of types, control structures, abstractions, and so forth, and is accessible from within the design stage.

An illustrative SOLVEIT window in shown in Figure 4. The tool bar in this example is specific to the problem formulation stage; the left-hand frame contains links to tools for other SOLVEIT stages.

Support for the Problem Formulation Stage

Students begin the SOLVEIT process by describing the problem to be solved, then carefully analyzing their description to identify and extract the information necessary to solve the problem. Finally, they formally specify the relevant facts of the problem: goal, givens, unknowns, conditions, constraints, and resources. The results are stored in the reference database. Problem formulation consists of three stages: (a) the problem description; (b) the verbalization; and (c) the information elicitation.

The problem description phase supports the objective of producing a well-defined problem description through progressive refinement. A problem description editor allows students to enter the problem description in their own words and provides access to basic editing functions and a graphics scratchpad notebook, to which the student can iteratively return.

[FIGURE 4 OMITTED]

The output of the problem description phase for the case study follows:

Case Study: Pre-Verbalization Problem Description

  A rocket blasts off at a departure time given in hours, minutes, and
  seconds. The trip takes a length of time specified in seconds.
  Depending on the length of the trip, the rocket has to set aside a
  fixed amount of time for refueling. The problem is to calculate the
  return time of the rocket in hours, minutes, and seconds. Given the
  blast-off-time of the rocket ship represented as 3 numeric values
  (hours, minutes and seconds) and a 4th numeric value representing the
  ship's flight-time given in seconds, the return time of the rocket
  (time-of-day and day) should be calculated. Rocket refueling must be
  taken into consideration as follows: for every 6 hours of fight-time a
  15 second refuel-time is required. The program will run (accept
  keyboard input) as many times as the user requests.

The verbalization phase not only supports obtaining a preliminary mental model using inquiry questions but also guides the student to refine the problem description. A verbalization tool, invoked after problem description, poses questions about the problem intended to provoke the student into thoughtfully re-examining and modifying the problem statement. The interaction for the verbalization is modeled on Polya's (1945) problem solving method, and can be dynamically adapted to fit the type of problem being solved. The questions address the identification of problem facts such as goal, givens, unknowns and other problem requirements.

The output of the verbalization phase for the case study follows:

Case Study: Problem Verbalization

Q: What is the goal?

A: To find the return time of a rocket given its blast-off-time.

Q: Do any of these goals require clarification?

A: The return time should give both the return-days and time-of-day in military time.

Q: Do any of these goals require clarification?

A: The blast-off-time should be a valid military time. The return-days should be the number of elapsed calendar days since blast off.

Q: Are there any other explicit or implicit problem requirements?

A: Input data should be appropriately echoed and labeled and tested for validity. Outputs should also be clearly labeled.

Q: What are the givens?

A: The blast-off-time of the rocket, in hours, minutes and seconds. The ship's flight-time in seconds. The refuel time in seconds and the refuel frequency in hours.

Q: Are there any flow control related inputs or givens?

A: The user is asked whether to repeat process by indicating [Y/N].

Q: What are the unknowns?

A: The return time: return-days and time-of-day.

Q: Are there any conditions and constraints.

A: The blast off time should be verified to be valid military time.

The verbalization phase leads to the following post-verbalization problem description modified to reflect enhancements and clarifications from the verbalization phase. This revised problem description will be used as the basis for the subsequent information elicitation phase.

Case Study: Post-Verbalization Problem Description

  A rocket blasts off at a departure time. The blastoff time is given in
  hours, minutes, and seconds, and should be a valid military time
  between 0 and 24 hundred hours. The trip takes a length of time, its
  flight time, given in seconds. Depending on the length of the trip,
  the rocket has to set aside a fixed amount of time for refueling. The
  refuel time is 15 seconds; the refuel frequency is every 6 hours of
  fight-time. The problem is to calculate the return time of the rocket
  in days and time of day given the blast-off-time and the flight-time.
  The days is the number of elapsed calendar days since the departure;
  the time-of-day is given in hours, minutes and seconds in military
  time. The program should test the blast-off-time for validity: it
  should be a valid military time. The program should ask the user
  whether to repeat the process using Y/N to indicate their response.

The information elicitation phase supports obtaining a more complete and structured representation of the problem by helping the student extract and organize relevant information in the post-verbalization problem description. Information elicitation transforms the problem description from textual format to a database of problem facts suitable for the transformations in subsequent stages. An elicitation tool guides the student in extracting from the post verbalization problem description, the goal, givens, unknowns, conditions, and constraints. The resulting information is stored in the reference database accessible by other stages of SOLVEIT.

The output of the information elicitation phase for the case study follows, including a reformulated goals and givens.

Case Study: Information Elicitation

  Goal
      Calculate the return time of rocket given the blast-off-time and
      the flight-time.

  Givens
      blast-off-time: hours, minutes, seconds, in military-time
      flight-time: seconds
      refuel-time: 15 seconds
      refuel-frequency: 6 hours
      repeat-process: [Y/N]

  Unknowns
      Return time:
      Return time-of-day: return-hour, return-minute, return-second, in
      military-time
      return-days: number of elapsed calendar days

  Conditions and constraints
      Test-blast-off-time for validity (valid military time)

Support for the Solution Planning Stage

After identifying the goal, givens, unknowns, conditions, and constraints in the problem formulation stage, students form an initial plan for solving the problem, integrate this plan with information gathered at problem formulation, refine the plan into subgoals, and define the associated preliminary data model. The subgoals and associated data descriptions are stored in the reference database. By the end of solution planning, the problem has been partitioned into major sub-problems. The solution planning stage consists of three phases: (a) the strategy discovery, (b) the goal decomposition, and (c) the data modeling.

The strategy discovery phase supports discovering a strategy for solving the problem by helping identify alternative solutions using heuristics. A strategy discovery tool guides the student in evaluating these alternative approaches, then selecting one as the chosen approach. The student defines an initial project plan, which outlines the steps for solving the problem, and which serves to coordinate the student's thoughts and activities in the subsequent phases on problem solving.

The output of the strategy discovery phase for the case study follows:

Case Study: Strategy Discovery

Q: Identify a strategy for solving the problem.

A: Calculate the total flight time of the rocket including the refueling time.

Convert this to days and time of day in hours, minutes, and seconds.

Add this to departure time in order to calculate the return time.

Q: Are there any difficulties to this strategy?

A: It requires conversion from seconds to hours, minutes, and seconds. Additionally, adding the total flight time in hours, minutes, and seconds to the departure time in hours, minutes, and seconds is difficult because the units are mixed an irregular.

Q: Identify an alternative strategy for solving the problem.

A: Calculate the total flight time of the rocket including the refueling time, in seconds.

Convert this to seconds.

Convert the departure time to seconds.

Add the total flight time and departure time, in seconds.

Convert the resulting time to days and time of day in hours, minutes, and seconds.

Q: Are there any difficulties to this strategy?

A: It requires conversion from seconds to hours, minutes, and seconds.

Q: Identify the better alternative and explain your choice.

A: The second alternative is better because it avoids complicated mixed unit calculations.

Selected Solution Strategy:

Display general instructions to user regarding program function and operation. Then, obtain the blastoff time and flight time of rocket from user. Calculate the return time as follows: Calculate the total flight time of the rocket including the refueling time.

Convert the total flight time to seconds. Convert the departure time (blast-off-time) to seconds. Add the departure time and the total flight time. Convert the resulting return time to days and time of day in hours, minutes, and seconds. Display results and ask user whether to continue.

Q: Are there any special formulas and techniques needed to implement this strategy?

A: Conversion methods should be stated in details. The following techniques will be used to convert:

1. Military time [hh:mm:ss] to seconds:

(3600 * hh) + (60 * mm) + ss

2. Seconds [sec] to days [days] and time of day in military time [hh:mm:ss]

days = sec/86400

hh = sec/3600

mm = (sec % 3600)/60

ss = (sec % 3600) % 60

The goal decomposition phase helps the student iteratively decompose the original goal into subgoals. The goal identified in the information elicitation phase is decomposed into subgoals that must to be completed to solve the problem. First, the goal identified in problem formulation is retrieved from the reference database. The student then partitions the goal into subgoals, assigning an identifier and description to each subgoal. Only first level subgoals are identified at this stage, but these will be refined at the solution design stage.

The output of the goal decomposition phase of the case study follows:

Case Study: First Level Goal Decomposition

Sub-goal 1

Display Instructions: to screen.

Sub-goal 2

Get Valid Input: blast-off-time and flight-time.

Sub-goal 3

Calculate Return Time: return-days and return-time-of-day.

Sub-goal 4

Display Results: to screen.

The data modeling phase integrates the givens and unknowns from the elicitation phase with the refined goals identified at goal decomposition, yielding a preliminary data model. The inputs and outputs associated with each of the components are identified and named for all the major components identified at goal decomposition. A data modeling tool populates a table of inputs, outputs, and intermediate data with the variable names, and provides blank fields for data description, data origin/destination, and the subgoal[s] using the data. The origin/destination and subgoal fields are then specified using pull-down menus, while the description field is entered by the user.

The output of the data modeling phase for the case study follows:

Support for the Solution Design Stage

The high-level plan produced by the planning stage is refined into a detailed hierarchically organized solution that includes inter-module communications and high-level algorithmic specifications. The solution design stage consists of three phases: (a) the module organization/refinement, (b) the data flow/module specification, and (c) the module logic specification.

The module organization/refinement phase supports refining the high-level plan given in the stage. A module organization/refinement tool first presents a tree-diagram view automatically derived from the first level goal decomposition. It then helps the student establish a more detailed component hierarchy by allowing the student to organize, refine, and modify the hierarchy of subgoals, using the structure chart approach. Subgoals can be added, removed, or merged on the basis for the need for further refinement and reorganization. Information about the organization/hierarchy of subgoals in the resulting structure chart is maintained in the reference database.

The output of the module organization/refinement phase for the case study follows; the first level tree decomposition is shown first:

[GRAPHIC OMITTED]

[GRAPHIC OMITTED]

  The second level refinement is derived from the first level
  decomposition. The Get-Input module has 2 subtasks--one to get the
  data from the user and one to check the validity of the data entered.
  The Calculate-Return-Time module also has two major subtasks, which
  calculate the return time of day and return days of the rocket. The
  resulting second level structure chart follows:

The data flow/module specification phase supports specifying modules, including representation of their input, output, and intermediate data, the module function, the preliminary module logic, and the data flow between modules. Module functions are specified by simple or compound statements. The preliminary module logic includes an indication as to how to accomplish the function. Intermediate data may have to be introduced, reflecting subgoal decomposition, and existing entries for intermediate data are updated. Data flows between modules are identified using the information gathered during the formulation and planning stages; the students select each data element, associating it with a specific module as the input/output and identifying the data type. The result is an enhanced structure chart with data flow shown and a data tables which are stored in the reference database.

The output of the module specification phase of the case study, including module specifications, data tables, and data flow/structure chart follow:

[GRAPHIC OMITTED]

The output of the module logic specification phase for the case study follows:

Case Study: Module Logic Specification

1.0 Display Instructions // Show user instructions

2.0 Get Valid Input // Gets validated data

2.1 Get data: hours, minutes, seconds, flight-time // Flight starting time and time of flight

2.2 Check data validity // Validate the inputs

2.2.1 Check hours, minutes, seconds, and flight-time for range validity

2.2.2 if valid continue with step 3.0

2.2.3 else repeat step 2.1

3.0 Calculate Return Time // Find the return time: time-of-day and days

3.1 Calculate return time-of-day

3.1.1 Convert blast-off-time to seconds and add flight-time to get return time in seconds temp = (3600 * hours) + (60 * minutes) + seconds + flight-time

3.1.2 Calculate refuel time needed and add to temp to get total return time in seconds total-time = temp + (flight-time / REFUEL_TIME) * TIME_TO_REFUEL)

3.1.3 Convert total-time to return time-of-day // Convert from seconds to military time

return-hour = (total-time / 3600) % 24

return-minute = temp / 60

return-second = temp % 60

3.2 Calculate return days

3.2.1 return-days = total-time / 86400

4.0 Display Results // Show the return time on the screen

4.1 Display return-days, return-hour, return-minute, and return-second

5.0 Check if user wants to repeat process

5.1 if Repeat-process is yes, then return to step 1.0

5.2 else end

Support for the Solution Translation Stage

The translation stage produces code ready for compilation compiled and testing using an existing programming language environment. We have explicitly not automated the pseudocode to source code translation because SOLVEIT's intended audience is the beginning student, learning a first programming language. It is essential for these students to gain experience in generating the actual code, although the algorithmic logic is used as the basis for code translation. The programming environment is assumed to contain syntax editors, code libraries, and debugging utilities. The output from this stage is the typical program source code, not shown here.

Support for the Solution Testing Stage

Solution testing determines whether the original problem goals are met, unlike debugging which addresses the syntactical correctness of the program. It requires a review of the original requirements of the problem and the specification of a test suite to verify problem goals have been met. The tool implements black-box and white-box testing: Black-box for testing results against system specifications, white-box for testing based on implementation internals, like designed a test to force a particular condition to be executed. The black-box testing phase engages the students in formulating test cases. A black-box testing tool allows for an interaction and elicitation process similar to the process used in problem formulation; the test cases are typically based on domain characteristics of the data. The white-box testing phase determines system test based not merely on the solution specifications but also on the implementation details as well. A white-box testing tool prompts the student to select/mark control structures and variables in the program and provide test input that triggers different control behavior, often related to the data domain characteristics of the problem.

The output of the testing phase follows:

Case Study: Black-box Testing

Q: Are there any domain restrictions that distinguish between valid and invalid input data?

A: The blast-off-time must be a valid military time.

Q: Are all invalid inputs the same?

A: No. The invalid inputs can have either invalid hour (> 24) or invalid minutes (>60) or invalid seconds (> 60).

Q: Give an instance of each invalid input and the required system response.

A: 1. Invalid hours (27:30:40), system response: "invalid military time".

2. Invalid minutes (21:70:40), system response: "invalid military time".

3. Invalid seconds (21:40:70), system response: "invalid military time".

Q: Are all valid inputs similar?

A: We can distinguish between return-days = 0 and return-days > 0 as well as when refueling is required or not.

Q: Give an instance of each valid input and the required system response.

A: 1. return-days = 0, no refueling: blast-off-time (20:30:40), flight-time (3700), system response: "21:32:20, return-days = 0".

2. return-days = 1, refueling: blast-off-time (23:50:00), flight-time (21600), system response: "05:50:15, return-days = 1".

3. return-days = 1, no refueling: blast-off-time (23:50:00), flight-time (21000), system response: "05:40:00, return-days = 1".

Q: Are there any flow control requirements?

A: The user should be able to repeat the process.

Q: What are the input case required to test this effect?

A: his can be tested during the valid input stages by submitting all two cases on one execution and one case on another execution.

Case Study: White-box Testing

Q: By examining algorithmic statements/source code, can any white-box test cases be developed to check the control or data structures of the program?

A: The calculation used to determine the value of the internal variables (temp, total-time) should be tested. The program should be instrumented with "print" statements to echo the internal values or debugger that traces variables can be used.

Q: Indicate the corresponding white-box test.

A: 1. Internal variable: temp and total-time; blast-off-time (21:50:10), flight-time (21600); system response: temp = 100800, total-time = 100815.

Support for the Solution Delivery Stage

The student completes the SOLVEIT process by proceeding to the delivery stage. The document delivery management tool helps create a complete documentation package. Using the information produced in previous stages, including: source code, the test results, the content of the reference database. The result is a fully documented and organized solution package. The combination of the output of the above stages constitutes the project turn-in package.

EVALUATION

Integration and evaluation of the initial version of the system took place over two semesters. Students were split into an experimental group and a control group. There were 81 students the first semester (48 control and 33 experimental) and 105 students the next semester (30 control, 75 experimental). Two thirds of the students were computer and information science majors. Individual characteristics were collected via a course questionnaire. Cross-tabulations and chi square tests performed on the results of the course questionnaire items, students' SAT scores, and placement tests found no significant difference in any category. Specifically designed questions on the midterm and final exams formed the basis for hypothesis testing. The validity and reliability of grading instruments were verified using inter-rater reliability tests, with reliability coefficients ranging from 0.82 to 0.95 (Deek, Hiltz, Kimmel, & Rotter, 1999). These instruments were used to grade the exam problems. A spectrum of analysis of variance (ANOVA) tests and means comparisons for students' performance were performed. The experimental group's scores on the midterm and final exams showed statistically significant differences.

The first hypothesis tested, which concerned problem solving ability, was as follows. Students in the experimental group will show superior problem understanding as demonstrated by their ability to clearly and correctly state problems and extract problem facts better than students in the control group. The associated problem formulation questions for midterm and final exams revealed statistically significant differences as follows: final/semester 1 (F=15.652, p=.001), midterm/semester 2 (F=13.596, p=.001), and final/semester 2 (F=13.304, p=.001). SOLVEIT was available only a week before the midterm/semester 1 exam, so the results for that exam were not significant. Interestingly, the means were twice as high for the experimental as for the control group on all exams, except again for midterm/semester 1.

The second hypothesis tested, which concerned solution planning solving ability, was as follows. Students in the experimental group will show superior planning skills as demonstrated by their ability to provide detailed and clear plans, complete goal refinements and representation of facts, better than students in the control group. The solution planning questions for midterm and final exams revealed statistically significant differences as follows: final/semester 1 (F=9.056, p=.004), midterm/semester 2 (F=2.002, p=.160), and final/semester 2 (F=13.958, p=.001). Once again, the results on the solution planning question on midterm/semester 1 were not significant for similar reasons to the first hypothesis. The means were twice as high for the experimental as for the control group on all exams, except again for midterm/semester 1.

The next hypothesis tested, which concerned solution design solving ability, was as follows. Students in the experimental group will show superior design skills as demonstrated by their ability to refine, sequence, and organize solution components as well as specify data and algorithmic logic better than students in the control group. The solution design questions for both two semesters indicate only a slight difference between the two groups. This was expected as the SOLVEIT prototype used in the experiment had only a bare bones stub for the design stage features. The prototype was available a week before midterm/semester 1, so those results were not significant. The results for final/semester 1 were: (F=1.977, p=.164), with the means for final/semester 2.71 [experimental], 1.69 [control]. The results for the second semester were not significant, though the experimental means were higher: 1.87 [experimental], 1.63 [control] for midterm/semester 2; and 1.76 [experimental], 1.57 [control] for final/semester 2.

An analysis of students' grades in the follow-up course in computer science did not reveal statistically significant differences between the groups. Nonetheless the experimental means exceed the control means for both semesters: the means for semester 1 were 3.44 [experimental] and 2.71 [control], the means for semester 2 were 2.69 [experimental] and 1.75 [control].

CONCLUSIONS

SOLVEIT provides an integrated environment, based on an explicit cognitive model, to help guide students through the stages of problem solving, from problem formulation, planning, and design, to testing, and delivery, with the program translation stage being supported using existing environments. Using SOLVEIT, the student learns both problem solving and the elements of software engineering because of the way in which both methodologies are explicitly embedded in SOLVEIT. Systemic, cognitively-based SOLVEIT dialogs facilitate problem solving and program development tasks, and the overall architecture of the system continually re-enforces software engineering methodology. In the SOLVEIT environment:

* Students describe the problem in written form, refine it, and update it as required. This is done freely, without imposing such restrictions as requiring a specific problem definition language, as is the case with some intelligent systems.

* Students identify problem facts through a formal interaction and elicitation process. Goal, givens, unknowns, conditions, constraints, and resources are identified and organized in a reference database that can be refined and restructured as more knowledge is gained.

* Students access automated planning and design features. Goal decomposition, data modeling, subgoal hierarchy, data flow, and logic specification are performed using specialized tools.

* Students create test cases using an interaction and elicitation process similar to the process for problem formulation. The problem requirements, data modeling and design specifications are provided to establish the strategy for both black-box and white-box testing.

Problem solving self-monitoring and feedback is achieved by maintaining progress records that can be examined by both the student and instructor. The requirements, specifications, code, testing and results are presented as the final deliverable.

The SOLVEIT system surmounts the functional and practical problems discussed earlier associated with current environments by:

* Taking into consideration the skills that programmers must master to address the tasks required for problem solving and program development. The essential facilities to assist the students in learning these skills are provided. Students produce their solutions in an environment that does not restrict creativity or cognitive development.

* Removing the emphasis on language syntax. In SOLVEIT, problem solving and program development are addressed as progressive tasks, beginning with problem formulation using language-independent tools and continuing through the subsequent planning, design, and testing stages of problem solving. Translation to code takes place later in the process using traditional program environments (i.e., Pascal, C and C++).

* Providing the framework and facilities that allow programmers to deal with common difficulties related to problem solving. SOLVEIT's tools facilitate information gathering, organization and retrieval, solution planning, and problem decomposition, while the overall framework of SOLVEIT helps ensure task flow coordination.

* Providing a state-of-the-art user interface. The system uses a GUI interface that was subject to protocol analysis during and after development.

* Integrating the tool into the learning environment. SOLVEIT is being used in the classroom as an integral part of a classroom environment for and introductory course on problem solving and programming. It provides tools for facilitating instructor interaction with the student using a development log that records progressive versions of a student's work, which can be reviewed and commented on by the instructor.

* Evaluating the impact of SOLVEIT on the learning process. An experimental study using an initial version SOLVEIT was conducted over two semesters in multiple sections of an introductory course on problem solving and programming. The study supported the positive impact of using SOLVEIT on student problem-solving and program development skills.

Case Study: Preliminary Data Modeling

Input (givens)

Name               Description/Units            Origin       Used in

hours              blast-off-time: hours      Keyboard       Subgoal 2
minutes            blast-off-time: minutes    Keyboard       Subgoal 2
seconds            blast-off-time: seconds    Keyboard       Subgoal 2
flight-time        length of trip: seconds    Keyboard       Subgoal 2
Repeat-process     user repeat request: Y/N   Keyboard       main
REFUEL-FREQUENCY   tank fuel capacity: hours  Constant       Global
REFUEL-TIME        time to refuel: seconds    Constant       Global

Output (unknowns)

Name               Description                Destination    Used in

return-hour        return time: hours         Screen         Subgoal 3
return-minute      return time: minutes       Screen         Subgoal 3
return-second      return time: seconds       Screen         Subgoal 3
return-days        elapsed days               Screen         Subgoal 3

Case Study: Module Specification/Data Tables/Data Flow

  Name: Main
  Input: none
  Output: none
  Function: Calculates return time (time-of-day, return-days) of a
            rocket given blast-off-time (hours, minutes, seconds) and
            flight-time

  Data:

  Name                  Type                 Structure

  hours                 Integer              Basic
  minutes               Integer              Basic
  seconds               Integer              Basic
  flight-time           Integer              Basic
  Repeat-process        Char                 Basic
  REFUEL-FREQUENCY      Integer Constant     Basic
  REFUEL-TIME           Integer Constant     Basic
  return-hour           Integer              Basic
  return-minute         Integer              Basic
  return-second         Integer              Basic
  return-days           Integer              Basic
  Is-Valid              Integer              Basic

  Name: Display Instructions
  Input: none
  Output: none
  Function: Provide instructions to user

  Name: Get Valid Input
  Input: none
  Output: hours, minutes, seconds, flight-time
  Function: Gets validated hours, minutes, seconds and flight time

  Name: Get data from user
  Input: hours, minutes, seconds, flight-time
  Output: hours, minutes, seconds, flight-time
  Function: Gets pre-validated input from user

  Name: Check data validity
  Input: hours, minutes, seconds
  Output: Is-Valid: 1 for valid input; 0 otherwise
  Function: Checks to see if input represents valid military time

  Name: Calculate Return Time
  Input: hours, minutes, seconds, flight-time
  Output: return-hour, return-minute, return-second, return-days
  Function: Calculates return time and return days from blast-of-time,
            flight-time, and refueling constants

  Data:

  Name          Type          Structure

  temp          Integer       Basic
  total-time    Integer       Basic

  Name: Calculate return time of day
  Input: hours, minutes, seconds, flight-time
  Output: return-hour, return-minute, return-second, total-time
  Function: Calculates return time from blast-of-time, flight-time, and
            refueling constants

  Name: Calculate return days
  Input: total-time
  Output: return-days
  Function: Calculates how many days rocket flight takes

  Name: Display Results
  Input: return-hour, return-minute, return-second, return-days
  Output: none
  Function: Displays return time and return days on screen

References

Anjaneyulu, K.S.R. (1994, April). Bug analysis of Pascal programs. ACM SIGPLAN Notices, 29(4), 15-22.

Benbasat, I., & Taylor, R.N. (1982 July/August). Behavioral aspects of information processing for the design of management information systems. IEEE Transactions on Systems, Man, and Cybernetics, Vol. SMC-12(4).

Bereiter, C., & Scardamalia, M. (1985). Cognitive coping strategies and the problem of inert knowledge. In S.S. Chipman, J.W. Segal, & R. Glaser (Eds.), Thinking and Learning Skills, Current Research and Open Questions, 2, 65-80. Hillsdale, NJ: Lawrence Erlbaum.

Bertels, K. (1994). A dynamic view on cognitive student modeling in computer programming. Journal of Artificial Intelligence in Education, 5(1), 85-105.

Bloom, B.S. (Ed.). (1956). Taxonomy of educational objectives, handbook I: Cognitive domain. New York: McKay.

Boehm, B.W. (1976). Software engineering. IEEE Transactions on Computers, C-25, (pp. 1226-1241).

Boehm, B.W. (1988). A spiral model of software development and enhancement. IEEE Computer, 21(5), 61-72.

Deek, F.P. (1997). An integrated environment for problem solving and program development. Unpublished doctoral dissertation, New Jersey Institute of Technology.

Deek, F.P. (1999). The software process: A parallel approach through problem solving and program development. Journal of Computer Science Education, 9(1), 43-70.

Deek, F.P., Hiltz, S.R., Kimmel, H., & Rotter, N. (1999). Cognitive assessment of students' problem solving and program development skills. Journal of Engineering Education, 88(3).

Deek, F.P., Kimmel, H., & McHugh, J.A. (1998). Pedagogical changes in the delivery of the first course in computer science: Problem solving then programming. Journal of Engineering Education, 87(3), 313-320.

Deek, F.P., & McHugh, J.A. (1998). A survey and critical review of tools for learning programming. Journal of Computer Science Education, 8(2), 130-178.

Deek, F.P., & McHugh, J.A. (2000, April). Problem solving and the development of critical thinking skills. Journal of Computer Science Education--ISTE SIGCS, 14, (1/2), 6-12.

Deek, F.P., McHugh, J.A., & Hiltz, S.R. (2000, June-July). Methodology and technology for learning programming. Journal of Systems and Information Technology, 4(1), 25-37.

Dijkstra, E. (1976). A discipline of programming. Englewood Cliffs, NJ: Prentice Hall.

Duncker, K. (1945). On problem solving. Psychological Monographs, 58(5), 270.

Ebrahimi, A. (1994). Novice programmer error: Language constructs and plan composition. International Journal of Human-Computer Studies, 41, 457-480.

Ennis, D. (1994). Combining problem solving and programming instruction to increase the problem solving abilities in high school students. Journal of Research on Computing in Education, 26(4), 488-496.

Espinasse, B. (1994). A cognitivist model for decision support: COGITA project, a problem formulation assistant. Decision Support Systems, 12, 277-286.

Gagne, R.M. (1985). The conditions of learning (4th ed.). New York: Holt, Rinehart and Winston.

Greeno, J.G. (1978). Natures of problem-solving abilities. In W.K. Estes (Ed.), Handbook of Learning and Cognitive Processes, 5, 239-270. Hillsdale, NJ: Lawrence Erlbaum.

Greeno, J.G., Collins, A.M., & Resnick, L.B. (1996). Cognition and learning. In D.C. Berliner & R.C. Calfee (Eds.), Handbook of Educational Psychology, (pp. 15-45). New York: Simon & Schuster Macmillan.

Guzdial, M., Hohmann, L., Konneman, M., Walton, C., & Soloway, E. (1998). Supporting programming and learning-to-program with an integrated CAD and scaffolding workbench. Journal of Interactive Learning Environments, 6(1-2), 143-179.

Hayes, J.R., & Simon, H.A. (1976). Understanding complex task instruction. In D. Klahr (Ed.), Cognition and Instruction. Hillsdale, NJ: Lawrence Erlbaum.

Hoc, J.-M., Green, T.R.G., Samurcay, R., & Gilmore, D.J. (Eds.). (1990). Psychology of programming. London: Academic Press.

Hohmann, L., Guzdial, M., & Soloway, E. (1992). SODA: A computer-aided design environment for the doing and learning of software design. In Proceedings of Computer Assisted Learning 4th International Conference, Nova Scotia, Canada, (pp. 307-319).

Johnson, W.L. (1990). Understanding and debugging novice programs. Artificial Intelligence, 42, 51-97.

Lemut, E., du Boulay, B., Dettori, G. (Eds.). (1993). Cognitive models and intelligent environments for learning programming. Berlin: Springer-Verlag.

Mayer, R.E. (1981, March). The psychology of how novices learn computer programming. ACM Computing Surveys, 3(1), 121-141.

Mayer, R.E. (1983). Thinking, problem solving, cognition. New York: W.H. Freeman.

Mayer, R.E. (1988). Introduction to research on teaching and learning computer programming. In R.E. Mayer (Ed.), Teaching and Learning Computer Programming, (pp. 1-12). Hillsdale, NJ: Lawrence Erlbaum.

Mitroff, I.I., & Turoff, M. (1973). Technological forecasting and assessment: Science and/or mythology? Technological Forecasting and Social Change, 5, 113-134.

Moore, J., & Newell, A. (1973). How can MERLIN understand? In L. Gregg (Ed.), Knowledge and cognition. Hillsdale, NJ: Lawrence Erlbaum.

Navarat, P., & Rozinajova, J. (1993). Making programming knowledge explicit. Computers and Education, 21(4), 281-299.

Newell, A., & Simon, H.A. (1972). Human problem solving. Englewood Cliffs, NJ: Prentice Hall.

Page-Jones, M. (1988). The practical guide to structured systems design, (2nd ed.). Englewood Cliffs, NJ: Yourdon Press, Prentice Hall.

Pea, R.D., & Sheingold, K. (Eds.). (1987). Mirrors of minds: Patterns of experience in educational computing. Norwood, NJ: Ablex.

Perkins, D.N., Hancock, C., Hobbs, R., Martin, F., & Simmons, R. (1986). Conditions of learning in novice programmers. Journal of Educational Computing Research, 2(1), 37-56.

Perkins D.N., & Martin, F. (1986). Fragile knowledge and neglected strategies in novice programmers. In E. Soloway & S. Iyengar (Eds.), Empirical studies of programmers, (pp. 213-229). Norwood, NJ: Ablex.

Polya, G. (1945). How to solve it. Princeton, NJ: Princeton University Press

Pressman, R. (1987). Software engineering: A practitioner's approach, (2nd ed.). New York: McGraw-Hill.

Pylyshyn, Z.W. (1984). Computation and cognition. Cambridge, MA: MIT Press.

Rist, R.S. (1986). Plans in programming: Definition, demonstration and development. In E. Soloway & S. Iyengar (Eds.), Empirical studies of programmers: First workshop, (pp. 28-47). Norwood, NJ: Ablex.

Rogalski, J., & Samurcay, R. (1990). Acquisition of programming knowledge and skills. In J.-M. Hoc, T.R.G. Green, R. Samurcay, & D. Gilmore (Eds.), Psychology of Programming, (pp. 157-174). London: Academic Press.

Rogalski, J., & Samurcay, R. (1993). Task analysis and cognitive model as a framework to analyze environments for learning programming. In E. Lemut, B. du Boulay, G. Dettori (Eds.), Cognitive models and intelligent environments for learning programming, (pp. 6-19). Berlin: Springer-Verlag

Rubinstein, M. (1975). Patterns of problem solving. Englewood Cliffs: NJ: Prentice Hall.

Scholtz, J., & Wiedenbeck, S. (1992). The role of planning in learning a new programming language. International Journal of Man-Machine Studies, 37, 191-214.

Scholtz, J., & Wiedenbeck, S. (1993). An analysis of novice programmers learning a second language. In Proceedings of the Fifth Workshop on Empirical Studies of Programmers, (pp. 187-205). Palo Alto, CA.

Shackelford, R., & Badre, A. (1993). Why can't smart students solve simple programming problems? International Journal of Man-Machine Studies, 38, 985-997.

Shneiderman, B. (1980). Software psychology: Human factors in computer and information systems. Boston: Little, Brown and Company

Simon, H.A. (1978). Information-processing theory of human problem solving. In W.K. Estes (Ed.), Handbook of learning and cognitive processes. Hillsdale, NJ: Lawrence Erlbaum.

Soloway, E., Ehrlich, K., Bonar, J., & Greenspan, J. (1982). What do novices know about programming? In A.N. Badre & B. Shneiderman (Eds.), Directions in human-computer interaction. New York: Ablex.

Spohrer, J. C. (1992). MARCEL: Simulating the novice programmer. Norwood, NJ: Ablex.

Spohrer, J. C., & Soloway, E. (1985). Putting it all together is hard for novice programmers. Proceedings of the IEEE International Conference on Systems, Man, and Cybernetics, (pp. 728-735).

Sternberg, R.J. (1985). Beyond IQ: A triarchic theory of human intelligence. Cambridge, MA: Cambridge University Press.

Weidenbeck, S., Fix, V., & Scholtz, J. (1993). Characteristics of the mental representations of novice and expert programmers: An empirical study. International Journal of Man-Machine Studies, 39, 793-812.

Weinberg, G.M. (1971). The psychology of computer programming. New York: Van Nostrand Reinhold.

Wickelgren, W.A. (1974). How to solve problems.