Gathering and scattering:

A study of the relationship between mental modeling, physical modeling and problem solving


Chong-ho Yu, Ph.D.,
Samuel A. DiGangi, Ph. D.,
Angel Jannasch-Pennell, Ph.D.,
Candace Collins, Ph.D.



During the 1980s educators believed that teaching children simple computer programming (e.g. LOGO) could enhance their problem-solving capabilities. However, empirical studies fail to find significant differences on mathematics achievement or knowledge-dependent problem solving between LOGO learners and non-learners though the LOGO group significantly outperformed the control group in executive-level problem solving (Battista & Clements, 1986). How computer programming influences human cognitive capacities, especially problem-solving, still remains an unresolved problem.

The purpose of this study is to examine the effects of including physical modeling and problem solving as components of computer programming instruction for children. Problem solving is defined as a mental modeling process in which relationships of components are restructured in order to form a functioning whole. Since physical modeling is a concrete representation to the abstract relationships of a problem, it is believed that learning objected-oriented programming along with physical modeling can help to enhance problem-solving skills.

Literature review

The potential of using computer programming languages to promote the development of higher order thinking skills, such as problem solving, has interested educators for some time (Palumbo, 1990). Many have argued that teaching computer programming to children can result in improvement in problem solving skills and attitudes toward using computers (Papert, 1990; Kafai & Resnick, 1996). But, more research is needed to determine the efficacy of computer programming activities on improving problem solving skills and attitudes toward computing (Dalton & Goodrum, 1991; Liu, 1997).

Some studies report positive effects of teaching programming on the development of problem solving skills (Becker, 1992; Lehrer and DeBernard, 1987; Lehrer, Guckenber, & Lee, 1988; Mayer, Dick, & Vilberg, 1989; McCoy & Dodl, 1989; Palumbo & Reed, 1987-1988; Reed & Palumbo, 1992; Swan & Black, 1988). However, many empirical studies do not support the use of computer programming as a means of developing logical thinking skills (Blume & Schoen, 1988; Jansson, Williams & Collens, 1987), skills of planning and problem solving (Clements & Gullo, 1984), or as a means of accelerating the cognitive development of young children (Ginther & Williamson, 1985).

Research suggests that spontaneous transfer of problem solving skills gained through programming to other domains is unlikely (Clement, Kurland, Mawby, & Pea, 1986; Ginther & Williamson, 1985; Linn & Dalbey, 1985) and instruction on how to apply strategies to new domains may be needed (Pintrich, Berger, & Stemmer, 1987;Salomon & Perkins, 1987). The literature on problem solving emphasizes two needs. The first need is for providing students with guidance to develop a self-inquiry approach in their learning (Avots, 1993; Newmann & Wehlage, 1993). The second need is for providing instruction that entails the active application of problem solving skills in the context of specific problems (Cardelle-Elawar, 1993, 1992; Merideth & Lotfipour, 1993, NCTM, 1989; Fay & Meyer, 1983). Therefore, this study will investigate the effect of an explicit problem-solving curriculum, which will be taught by providing instruction and practice within the context of the programming the students are learning.

Objectives

Because of the inconsistent and inconclusive results of previous research, this study attempts to approach several unanswered questions. One objective of this study is to examine the effect of including a problem solving curriculum when teaching children, who are between the ages of 7 and 9, Object-Oriented Programming (OOP) skills.

The second objective of this study is to examine the effect of including physical modeling as a component of teaching OOP skills. Students engage in physical modeling by using LEGO programmable bricks and LEGO building blocks to construct robots to execute the programs created in Robolab. The use of digital manipulatives such as the LEGO programmable bricks and computer-based modeling environments such as Stella, StarLogo, and Model-It have made it easier for pre-college students to model and explore systems phenomena such as feedback and emergence (Resnick, 1994; Roberts, Anderson, Deal, Garet, & Shaffer, 1983; Jackson, Stratford, Krajcik, & Soloway, 1996).

A third objective of this study is to examine the impact of including a problem solving curriculum and/or physical modeling in OOP language instruction. Specifically, the objective is to measure the impact of including problem solving curriculum and/or physical modeling on computer anxiety levels.

These objectives will be addressed by evaluating students who participate in the Conexiones Project (Collins, Wijesuriya, DiGangi, Jannasch-Pennell, & Cohn, 1999), a mentoring program for children of migrant farm workers. Forty-eight children from grades 7 through 9 will learn Robolab's OOP language (Johnson, 1997).

Problem solving, OOP, mental modeling, physical modeling, as well as their relationships will be explained in the following.

Problem solving

Problem solving has been defined in a number of ways. It has been defined in terms of a academic discipline, such as math or science, and it has been defined in terms of the ability to process abstract concepts, such as spatial ability. Problem solving in this study is limited to the context of the OOP curriculum. Students who receive instruction in problem solving will learn how to debug programs. They will be taught a specific approach, developed and contextualized by the Conexiones staff. The problem-solving curriculum that will be offered in this study is based on the following research. Studies performed by Greeno (1980), Soloway, Lockhead, & Clement (1982), Schoenfeld (1979), and Mayer (1983; 1986) suggest that the following procedures might be useful in developing problem solving ability:

  1. Translation training. Providing sufficient practice for the problem solver in developing internal representations of a problem.

  2. Schema training. Providing sufficient practice for the problem solver in putting the elements of a problem into a coherent whole.

  3. Strategy training. Providing sufficient practice for the problem solver in the application of the "process" of problem solving instead of the generation of "products."

  4. Algorithm automicity. Providing sufficient practice for the problem solver in the component skills (e.g., computation) required to solve problems.

In the present study, problem solving is approached from two perspectives. First, it is defined as the ability to modularize a task and restructure the relationships among objects or components to form a functioning model (Kohler, 1925; 1969). Second, it is viewed as processing previous relevant knowledge learned in another situation and applying it to an unfamiliar situation (Cronbach, 1988). From this perspective, if an evaluator presents to the student a problem that exactly matches the learning objectives, recalling, rather than problem solving, becomes the focused construct. In real-world applications, most problems are vaguely defined and unstructured, thereby requiring complex information processing skills such as gathering scattered data and restructuring the relationships between the components. In this view, the emphasis of problem-solving is process-oriented rather than product-oriented (Keller, 1990). Thus, by definition, problem solving involves transfer and transformation of information. It is hypothesized that through instruction and experience with OOP, learners can enhance their ability to form mental models of problems and over time increase and refine their repertoire of problem solving approaches.

Object-oriented programming

In this study, every participant will learn an object-oriented programming (OOP) language. Object-oriented programming can be viewed as a specific application of mental modeling. In OOP, a programmer can use and reuse ready-made objects from a library of commands and operations. Each object belongs to a specific class, has specific properties, and performs specific functions. In addition, the objects can interact with each other by exchanging messages and values or parameters.

The degree to which a programming language constitutes a true OOP environment is debatable. For example, Java (Sun MicroSystems, 1994/1999) and C++ (Stroustrup, 1997) are considered OOP environments even though they require more code-based manipulation than some programming applications that are more consumer-oriented.

Participants will learn an OOP language developed for children: ROBOLAB (LEGO, 1998). ROBOLAB is based on LabVIEW, an industry-standard, graphical programming language (LabVIEW, 1998; Johnson, 1997). In ROBOLAB, programmers write a program by selecting, ordering, and structuring relationships among objects.

Mental and physical modeling

The physical modeling with LEGO bricks is meant to complement the abstract mental modeling necessary for programming by providing students with a digital manipulative that can provide feedback as well as a physical representation of component building. Mental modeling is a process of problem solving that entails forming an abstract representation of a problem and visually constructing a functional relationship between its components (Barsalau, 1992; Muller, 1997). Object-oriented programming can be viewed as a specific application of mental modeling in which programmers construct functional relationships between components or objects. When physical modeling is taught in conjunction with mental modeling, students have a feedback mechanism and concrete manipulative in addition to the abstract mental modeling necessary for programming.

Research Hypotheses

  • Null Hypothesis 1: There will be no differences in computer programming gain scores among students who learn OOP with an explicit problem solving curriculum and students who learn OOP without an explicit problem solving curriculum.

  • Null Hypothesis 2: There will be no differences in the problem solving skills among students who learn OOP with an explicit problem solving curriculum and students who learn OOP without an explicit problem solving curriculum.

  • Null Hypothesis 3: There will be no differences in the level of computer anxiety among students who learn OOP with an explicit problem solving curriculum and students who learn OOP without an explicit problem solving curriculum.

Method

Population and sample

The target population of this study includes all migrant school children in Southwest America whereas the accessible population consists of migrant school children in Phoenix, Arizona. By convenience sampling, forty-eight students who have been identified as migrant school children will be chosen to participate in the study. The sample size determination is based upon the power analysis program Sample Power (SPSS, 1999). Given that the Cohen's effect size is .48, the alpha level is .05, and the power is .80, the desired sample size would be 40 in total or 10 per cell. Eight extra students will be chosen to ensure that the sample size of 40 will be maintained even if there is attrition or noncompliance.

Design

The design will be a 2X2 ANOVA. Each participant will receive instruction in Robolab's OOP language. The first factor is problem solving curriculum, which has two levels: 1) the presence of problem solving curriculum, and 2) the absence of problem solving curriculum. The second factor is physical modeling, which also has two levels: 1) the presence of physical modeling, and 2) the absence of physical modeling. The design is orthogonal because all cell sizes will be equal. Descriptions of the four groups follow:

    1. Learning Robolab's OOP language with problem solving curriculum
    2. Learning Robolab's OOP language with physical modeling
    3. Learning Robolab's OOP language with both problem solving curriculum and physical modeling
    4. Control: Learning Robolab's OOP language with neither problem solving curriculum or physical modeling

Strength and integrity of treatment will be ensured by the following means, which have been identified by Sechrest et al. (1979). Primary instruction will be provided by four computer experts with Masters degrees in Educational Media and Computers and at least two years of teaching experience, which includes teaching limited-English proficient students who have participated in the Conexiones Program. These instructors will be assisted by bilingual students in education and computer programming. Curriculum will be developed based on the Robolab curriculum. Curriculum development will be supported and supervised by a team of university professors and research specialists who have PhDs in education and at least five years of teaching experience, which includes teaching limited-English proficient students who have participated in the Conexiones Program.

Instructors and assistants will participate in a forty hours of training that will prepare them for teaching and curriculum implementation. During this training, they will receive a detailed schedule of teaching activities that will be monitored by the curriculum development supervisors via spot checking of treatment sessions. Participant attendance will be monitored by instructors and assistants who will record the dates, times, and names of participants for each session. Video recording of a sample of treatment sessions will be conducted so that sessions can be analyzed for conformance to treatment requirements.

Instruments

There will be three dependent measures. The first measure is a criterion-referenced test specific to Robolab programming. This criterion-referenced test will require participants to complete a programming task. Participants will be videotaped as they engage in Think Aloud Protocol while they complete the task. The videotape will be analyzed by four raters who are experts in computer programming and who will evaluate the test on the basis of efficiency, time necessary to complete the task, and accuracy. The inter-rater reliability will be calculated. Because the participants will have had no previous instruction in computer programming, a pre-test will not be administered to assess their skills. However, a test will be administered to all students after they have engaged in one half of the curriculum for OOP.

The second measure is the change score of an attitude survey, the Computer Anxiety Index (CAIN). The CAIN is a standard instrument for measuring computer anxiety (Simonson,, Maurer, Montag-Toradi, & Whitaker, 1987). A pretest to assess computer anxiety will be administered before the treatment and a posttest will be administered after the treatment.

The third measure is the gain score of problem solving skills. Students will be asked to debug Robolab programs. Students will be presented with this task after 10, 20, and 30 hours of programming instruction. The internal consistency of the second and third instruments will be evaluated by Cronbach coefficient Alpha.

Procedures

Students will be randomly assigned to one of four treatment conditions. At the beginning all subjects will be asked to complete the pretests in the CAIN and problem solving skills. Students will also be surveyed to determine their level of access to computers and whether or not they are receiving any additional instruction in computer use or programming during the treatment. If so, these factors will be used as covariates. To avoid the threat against internal validity caused by a demoralizing effect (Cook & Campbell, 1979), the four groups will be separated into four rooms so that subjects will not be aware of what treatment their counterparts will receive. This is especially important among children who may or may not be using LEGO building bricks in their treatment.

Students will be tested with different programs after intervals of 10, 20, and 30 hours of instruction. To prevent test-retest effects, the problems will vary. To avoid ceiling effects, the problems will increase in difficulty as the students receive more instruction. The entire study will last four weeks. Instruction will take place for 3 hours after school each weekday. Participant attrition and non-compliance with treatment will be monitored by recording attendance during all sessions. To account for attrition and non-compliance, analyses of data will be conducted according to percentage of treatment received.

Time and resource constraints for both the program and the students involved preclude offering the treatments for extended periods of time; however, the literature suggests that significant periods of time are required for teaching computer programming skills. Liu (1997) found that enhancement of problem solving skills by learning HyperCard occurred after 150 hours of instruction. In a study by Palumbo and Reed, significant benefits of problem solving skill enhancement occurred after 91 hours of Basic programming instruction. Nevertheless, Basic and HyperCard are not Object-Oriented Programming languages. Second, they are not designed for children. The time and resource constraints might cause a failure to deliver a treatment with adequate intensity.

Proposed Analyses

Analysis will include examination of both the main effects and the interaction effects of the factors. Although the intended design is orthogonal, dropouts and outliers may lead to uneven cell sizes and thus render the design non-orthogonal. To compensate for this, Type III Sum of Squares analysis will be used.

Parametric assumptions such as the homogeneity of variances and normality of sample data will be examined. If a violation of the assumption is detected, data transformation procedures will be employed.

References

Avots, J. (1993). Technology as a bridge. Educational Leadership, 50, 83-84.

Barsalau, L. (1992). Cognitive psychology: An overview for cognitive scientists. Hillsdale, N.J.: Erlbaum.

Battista, M., & Clements, D. (1986). The effects of Logo and CAI problem-solving environments on problem-solving abilities and mathematics achievement. Computers in Human Behavior, 2, 183-193.

Becker, H. (1992). Computer education, In M.C. Alkin (Ed.), Encyclopedia of Educational Research, (6th ed., pp. 232-234). New York: Macmillan.

Cardelle-Elawar, M. (1993). The teacher as researcher in the classroom. Action in Teacher, 25, 49-57.

Cardelle-Elawar, M. (1992). Effects of teaching metacognitive skills to students with low mathematical ability. Teaching and Teacher Education: An International Journal, 8, 3-14.

Clement, C. A., Kurland, D. M., Mawby, R., & Pea, R. P. (1986). Analogical Reasoning and Computer Programming, Journal of Educational Computing Research, 2, 473-486.

Clements, D. H., & Gullo, D. F. (1984). Effects of computer programming on young children's cognition. Journal of Educational Psychology, 76, 1051-1058.

Collins, C., Wijesuriya, R., DiGangi, S., Jannasch-Pennell, A., & Cohn, S. (March, 1999). Conexiones: New approaches to technology and diversity in education. Arizona Council for Exceptional Children, Tucson, AZ.

Fay, A. L., & Mayer, R. E. (1988). Learning Logo: A cognitive analysis. In R. E. Mayer (Ed.), Teaching and learning computer programming (pp. 555-74). Hillsdale, NJ: Lawrence Erlbaum Associates.

Ginther, D. W., Williamson, J. D. (1985). Learning Logo: What is really learned? Computers in the Schools, 2, 73-78.

Jackson, S., Stratford, S., Krajcik, J., and Soloway, E. (1996). A Learner-centered tool for students building models. Communications of the ACM 39, 48-49.

Jansson, L. C., Williams, H. D., Collens, R. J. (1987). Computer programming and logical reasoning. School Science and Mathematic, 87, 371-379.

Johnson, G. W. (1997). LabVIEW graphical programming : practical applications in instrumentation and control. New York: MacGraw-Hill.

Kafai, Y., and Resnick, M., eds. (1996). Constructionism in Practice: Designing, Thinking, and Learning in a Digital World. Mahwah, NJ: Lawrence Erlbaum. Keller, J. (1990). Characteristics of Logo instruction promoting transfer of learning: A research review. Journal of Research on Computing in Education, 23, 55-71.

LabVIEW (1998). (Version 5.0) [Computer software]. Austin: National Instruments.

LEGO Dacta (1998). ROBOLAB [Computer programming language]. Billund, Denmark: LEGO.

Lehrer, R. & DeBernard, A (1987). Language learning and language of computing: the Perceptual model. Journal of Educational Psychology, 79, 42-48.

Lehrer, R., Guckenberg, T., & Lee, O. (1988). Comparative study of the cognitive consequences of inquiry-based Logo instruction. Journal of Educational Psychology, 80, 543-553.

Linn, M. C. & Dalbey, J. (1985). Cognitive Consequences of Programming Instruction: Instruction, Access, and Ability. Educational Psychologist, 20, 191-206.

Liu, M. (1997). The effects of Hypercard programming on teacher education students' problem solving ability and computer anxiety. Journal of Research on Computing in Education, 29, 248-264. McCoy, L. P., & Dodl, N. R. (1989). Computer programming experience and mathematical problem solving. Journal of Research on Computing in Education, 22, 14-25.

Mayer, R. E., Dick, J. L., & Vilberg, W. (1989). Learning to program and learning to think: What's the connection?, In Studying the Novice Programmer. Soloway, E. & Spohrer (eds.). New York: Academic Press.

Merideth, E. M. ,& Lotfipour, (1993). Reflecting through technology: a computer-laserdisc model of cooperative learning. Journal of Technology and Teacher Education, 24, 33-41.

National Council of Teachers of Mathematics [NCTM]. (1989). Curriculum and Evaluation Standards for School Mathematics. Reston, VA: Author.

Newman, E. M. & Whelage, G. G. (1993). Five standards of authentic instruction. Educational Leadership, 50, 8-12.

Palumbo, D.B. (1990). Programming language/problem-solving research: A review of relevant issues. Review of Educational Research, 60, 65-89.

Palumbo, D.B., & Reed, W.M. (1987-1988). Intensity of treatment and its relationship to programming problem solving. Computers in the Schools, 4, 113-126.

Papert, S. (1980). Mindstorms: Children, Computers, and Powerful Ideas. New York: Basic Books.

Pintrich, P.R., Berger, C.F., & Stemmer, P.M. (1987). Students' programming behavior in a Pascal course. Journal of Research in Science Teaching, 24, 451-466.

Reed, W.M., & Palumbo, D.B. (1992). The effect of BASIC instruction on problem solving skills over an extended period of time. Journal of Educational Computing Research, 8, 311-325.

Resnick, M. (1994). Turtles, termites, and traffic jams. Cambridge, MA: MIT Press. Roberts, N., Anderson, D., Deal, R., Garet, M., and Shaffer, W. (1983). Introduction to computer simulation: A system dynamics modeling approach. Reading, MA: Addison-Wesley.

Salomon, G. & Perkins, D.N. (1987). Transfer of cognitive skills from programming: When and how? Journal of Educational Computing Research, 3, 149-169.

Sechrest, L, West, S., Phillips, M., Redner, R., & Yeaton, W. (1979). Some neglected problems in evaluation research: Strength and integrity of treatments. Evaluation Studies Review Annual, 4, 15-35.

Simonson, M. R., Maurer, M., Montag-Toradi, M., & Whitaker, M. (1987). Development of a standardized test of computer literacy and a computer anxiety index. Journal of Educational Computing Research 3, 231-247.

Stroustrup, B. (1997). The C++ programming language. New York: Addison-Wesley Pub Co.

Sun Microsystems. (1994/1999). Java technology. [On-line] Available: http://www.sun.com/java.

Swan, K., & Black, J.B. (1988, April). The cross-contextual transfer of problem-solving strategies from Logo to noncomputer domains. Paper presented at the annual meeting of the American Educational Research Association, New Orleans, LA.


Navigation
 

Publications TOC

Simplified Navigation

Table of Contents

Search Engine

Contact Me