Invisibility is an inherent and significant problem in the task of developing large software systems. There are no direct solutions to this problem

this paper, I present: . Definitions of scaffolding and software-realized scaffolding; . A description of Emile as an instance of a computer-based learning environment designed to provide software-realized scaffolding; . The setting for the evaluation of Emile, data collected, and analysis methods used; and . The results, discussion, and my conclusions.

A study by a ITiCSE 2001 working group ("the McCracken Group") established that many students do not know how to program at the conclusion of their introductory courses. A popular explanation for this incapacity is that the students lack the ability to problem-solve. That is, they lack the ability to take a problem description, decompose it into sub-problems and implement them, then assemble the pieces into a complete solution. An alternative explanation is that many students have a fragile grasp of both basic programming principles and the ability to systematically carry out routine programming tasks, such as tracing (or “desk checking”) through code. This ITiCSE 2004 working group studied the alternative explanation, by testing

In learning to program, students must gain an understanding of how their program works. They need to make a connection between what they have written and what the program actually does. Otherwise, students have trouble figuring out what went wrong when things do not work. One factor that contributes to making this connection is an ability to visualize a program's state and how it changes when the program is executed. In this paper, we present Alice, a 3-D interactive animation environment. Alice provides a graphic visualization of a program's state in an animated small world and thereby supports the beginning programmer in learning to construct and debug programs.

The field of software design patterns has seen an explosion in interest in the last three years. Work to date has been on the recognition, cataloging, and finding of patterns with little attention to the use of patterns especially by students and practitioners not well-versed in object-oriented technologies. This project addresses novice use directly yielding benefits for both the established pattern community and to students and educators new to the field. Although we do not claim that design patterns are Brooks' silver bullet [8], their use can help cope with the accidental complexity of software development and, we argue, their use is essential for a successful adoption of object-oriented techniques in academic computer science programs. This project addresses practical and pedagogical concerns of the computer science and software engineering communities by addressing the teaching and learning of patterns. In this paper we argue that design patterns are an essential programming and ...

The task of specializing programming environments for novices begins with the recognition that programming is a hard skill to learn. The lack of student programming skill even after a year of undergraduate studies in computer science was noted and measured in the early 80’s [32] and again in this decade [20]. We know that students have problems with looping constructs [31], conditionals [8], and assembling programs out of base components [33]—and there are probably other factors, and interactions between these factors, too. What are the critical pieces? What pieces, if we “fixed ” them (made them better for novice programmers), would make programming into a more manageable, learnable skill? If we developed a language that changed how conditionals work or loops, or make it easier to integrate components, would programming become easier? That’s the issue that developers of educational programming environments are asking. Each novice programming environment (or family of environments) is attempting to answer the question, “What makes programming hard? ” Each answer to that question implies a family of environments that address the concern with a set of

Program comprehension is a very important activity during the development and the maintenance of programs. This activity has been actively studied in the past decades to present software engineers with the most accurate and—hopefully—most useful pieces of information on the organisation, algorithms, executions, evolution, and documentation of a program. Yet, only few work tried to understand concretely how software engineers obtain and use this information. Software engineers mainly use sight to obtain information about a program, usually from source code or class diagrams. Therefore, we use eye-tracking to collect data about the use of class diagrams by software engineers during program comprehension. We introduce a new visualisation technique to aggregate and to present the collected data. We also report the results and surprising insights gained from two case studies. 1

A new programming course to prepare novices for the traditional Computer Science 1 course (CS1) is proposed. The course uses 3-D interactive animation in a novice-friendly environment to introduce object-oriented programming concepts and help students develop problem-solving skills. Pedagogical issues are presented that involve the use of visualization and graphics concepts, the notion of state, and programming language concerns. A study of practice and experimentation with this course is underway. Early results are summarized along with observed benefits and concerns. USING ANIMATED 3D GRAPHICS TO PREPARE NOVICES FOR CS1

Text elision is a user interface technique that aims to improve the efficiency of navigating through information by allowing regions of text to be `folded' into and out of the display. Several researchers have argued that elision interfaces are particularly suited to source code editing because they allow programmers to focus on relevant code regions while suppressing the display of irrelevant information. Elision features are now appearing in commercial systems for software development. There is, however, a lack of empirical evidence of the technique's efficiency. This paper presents an empirical evaluation of source code elision using a Java program editor. The evaluation compared a normal `flat text' editor with two versions that diminished elided text to levels that were `just legible' and `illegible'. Performance was recorded in four tasks involving navigation through programs. Results show that programmers were able to complete their tasks more rapidly when using the elision interfaces, particularly in larger program files. Although several participants indicated a preference for the `just legible' elision interface, performance was best with illegible elision.

Accelerating the learning curve of software maintainers working on systems with which they have little familiarity motivated this study. A working hypothesis was that automated methods are needed to provide a fast, rough grasp of a system, to enable practitioners not familiar with it, to commence maintenance with a level of confidence as if they had this familiarity. Expert maintainers were interviewed regarding their strategies and information needs to test this hypothesis. The overriding message is their need for a “starting point ” when analysing code. They also need standardised, reliable and communicable information about a system as an equivalent to knowledge available only to developers or experienced maintainers. These needs are addressed by the proposed “roughcut” approach to program comprehension. Work underway assesses the suitability of using data mining techniques on data derived from source code to provide high level models of a system and module interrelationships. 1. Background Program comprehension is a demanding task comprising up to 90 % of the total time spent on software maintenance [2], [21], [27], which in turn is the most expensive process in the lifetime of software [2]. This has been attributed to a plethora of problems reported in the literature, such as lack of up-to-date and precise documentation, inadequate communication, and unavailability of the original designers and programmers [11], [13]. Researchers have been trying to improve and accelerate the process of program comprehension in a number of ways. Because of the limited amount of information that a maintainer can assimilate at one time, the as-needed strategy suggests maintainers gain an understanding of the application while performing the change process [13]. Similarly partial comprehension has