Abstract. The goal of our study is to evaluate the effect on program comprehension of three factors that have not previously been studied in a single experiment. These factors are programmer expertise (expert versus novice), programming task (documentation versus reuse), and the development of understanding over time (phase 1 versus phase 2). This study is carried out in the context of the mental model approach to comprehension based on van Dijk and Kintsch’s model [(1983) Strategies of Discourse Comprehension. New York: Academic]. One key aspect of this model is the distinction between two kinds of representation the reader might construct from a text: (1) the textbase, which refers to what is said in the text and how it is said, and (2) the situation model, which represents the situation referred to by the text. We have evaluated the effect of the three factors mentioned above on the development of both the textbase (or program model) and the situation model in object-oriented program comprehension. We found a four-way interaction of expertise, phase, task and type of model. For the documentation group we found that experts and novices differ in the elaboration of their situation model but not their program model. There was no interaction of expertise with phase and type of model in the documentation group. For the reuse group, there was a three-way interaction between phase, expertise and type of model. For the novice reuse group, the effect of the phase was to increase the construction of the situation model but not the program model.

This article presents a cognitively oriented viewpoint on design. It focuses on cognitive, dynamic aspects of real design, i.e., the actual cognitive activity implemented by designers during their work on professional design projects. Rather than conceiving designing as problem solving—Simon’s symbolic information processing (SIP) ap-proach—or as a reflective practice or some other form of situated activity—the situativity (SIT) approach—we consider that, from a cognitive viewpoint, designing is most appropriately characterised as a construction of representations. After a critical discussion of the SIP and SIT approaches to design, we present our viewpoint. This presentation concerns the evolving nature of representations regarding levels of abstraction and degrees of precision, the function of external representations, and specific qualities of representation in collective design. Designing is described at three levels: the organisation of the activity, its strategies, and its design-representation construction activities (different ways to generate, transform, and evaluate representations). Even if we adopt a “generic design ” stance, we claim that design can take different forms depending on the nature of the artefact, and we propose some candidates for dimensions that allow a distinction to be made between these forms of design. We discuss the potential specificity of HCI design, and the lack

While early reuse techniques were based largely on the programmer's memory, more recent techniques give the programmer access to a library of existing programs or models. The problem arises of how to use these `external memories': that is, how to structure the memories and their access methods effectively. To study this problem from a cognitive point of view, we have to know how the programmer deals with programs, and more precisely, what knowledge a programmer has of a program when he reuses it. There are different models of those internal representations of programs. This paper looks at how programs are internalized (i.e. how this knowledge is build), and how programmers externalize their representations of programs. The problem is made more difficult by the fact that software reuse is made of four steps (finding, understanding, specializing and integrating a component), which differ slightly from one reuse technique to another, and which involve different cognitive processes. Each s...

This paper is a general overview of state-of-the-art software reuse. It presents the different techniques considered as software reuse, and for each of them tries to draw a list of their important issues. Contents 1 Introduction 1 2 Opportunistic reuse techniques 2 2.1 Syntax checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1.2 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2 Write/Copy/Paste . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2.2 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Code scavenging . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . 5...

While early reuse techniques were based largely on the programmer's memory, more recent techniques give the programmer access to a library of existing programs or models. The problem arises of how to use these `external memories': that is, how to structure the memories and their access methods effectively. To study this problem from a cognitive point of view, we have to know how the programmer deals with programs, and more precisely, what knowledge a programmer has of a program when he reuses it. There are different models of those internal representations of programs. This paper looks at how programs are internalized (i.e. how this knowledge is build), and how programmers externalize their representations of programs. The problem is made more difficult by the fact that software reuse is made of four steps (finding, understanding, specializing and integrating a component), which differ slightly from one reuse technique to another, and which involve different cognitive pro...

Managing change in an information systems development organization: understanding developer transitions from a structured to an object-oriented development environment 1

In the presence of undocumented and unfamiliar hardware, the process of program comprehension becomes more complex. To perform maintenance activities, programmers must understand the functioning of each element independently, as well as their interactions. In this paper we examine the process taken by the first author during the analysis, porting and re-implementation of a software system that has a heavy reliance on undocumented customized hardware interfaces. This process also demonstrates the use of a twophase approach when migrating a mission-critical software system. The software was first ported to a new platform running a semi-compatible BASIC interpreter (phase 1) before a complete re-implementation was performed (phase 2). The experiences, strategies used, and lessons learned during the process are reported here. 1